IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
draft-ietf-6renum-enterprise-06
Yes
(Ron Bonica)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Robert Sparks)
(Russ Housley)
(Stewart Bryant)
(Wesley Eddy)
Note: This ballot was opened for revision 04 and is now closed.
Ron Bonica Former IESG member
Yes
Yes
(for -04)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -05)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -04)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2013-01-09 for -05)
Unknown
For the record, let me cut and paste it here what has been discussed with the authors. From the charter, I believe that this document fits the following: 1. To undertake scenario descriptions, including documentation of current capability inventories and existing BCPs, for enterprise networks, including managed and unmanaged elements. These texts should contribute towards a gap analysis and provide an agreed basis for subsequent WG rechartering towards development of solutions (which may be more appropriate for other WGs to undertake) and improved practices. Operator input will be of high value for this text. Reading this reading, I asked myself: what is the specific scope of this document? I see a mix of scenarios, listing of the existing solutions, best current practices (corrected btw in the version 5), etc... and I'm wondering where this document fits in all the IPv6 documents renumbering documents: RFC 5887, this document, Enterprise IPv6 Deployment Guidelines draft-ietf-v6ops-enterprise-incremental-ipv6-01, rfc4192, etc... By "etc", I mean searching for "renum" in https://www.ietf.org/download/rfc-index.txt. It seems that many of these documents have the same type of content. Too many actually. Don't get me wrong, there is good text in this document. Bottom line: if someone is interested in renumbering, what is the ordered list of documents to be read, with the respective content. My conclusion is that there will be a lot of overlap. I would happy to stand corrected. Note: I did my home work trying to find the answer: read RFC 5887, listened to the IETF 85 meeting recording, etc... Answer from Brian Carpenter This is a tricky point. RFC 5887 could probably never have been developed by a WG - in fact it was a non-IAB revisit of an IAB document (RFC 1900). And it succeeded, because 6renum was chartered. But 6renum was not chartered to design solutions or even to write a cookbook. I believe that the nature of the present draft is only to describe the situation and the existing tools. At some point the IESG will be given draft-ietf-6renum-gap-analysis which "briefly introduces the existing mechanisms that could be utilized for IPv6 site renumbering and tries to cover most of the explicit issues and requirements of IPv6 renumbering. Through the gap analysis, the document provides a basis for future works..." I think that the whole picture will be clearer then - and the IESG will hopefully decide which of the gaps require IETF action. draft-carpenter-6renum-next-steps-00 may also help to answer your question. While the draft improves from version 4 to 5, for example by removing the BCP, I'm not totally convinced by the usefulness of this yet-another document. However, I won't get in the way of its publication. Specifically because my concern is not really actionable at this point in time. EDITORIAL: Dynamic Host configuration Protocol -> Dynamic Host Configuration Protocol
Brian Haberman Former IESG member
No Objection
No Objection
(2013-01-04 for -05)
Unknown
I have no objection to the publication of this document, but I do have a question (that is not DISCUSS worthy). The primary focus of this document appears to be the actual address configuration issues surrounding a renumbering event. While DNS, ACLs, and firewall rules are briefly mentioned, I am curious as to the lack of mention, in any detail, of text-based configuration files. Was that aspect considered?
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -05)
Unknown
Martin Stiemerling Former IESG member
(was Discuss)
No Objection
No Objection
(2013-01-08 for -05)
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
(2013-01-09 for -05)
Unknown
Minor suggestion: the "Information Refresh Time Option" (RFC 4242) is useful for managing the lifetime of configuration information provided through DHCPv6 when a host has no leased addresses (section 4.2).
Robert Sparks Former IESG member
No Objection
No Objection
(for -05)
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(for -05)
Unknown
Sean Turner Former IESG member
No Objection
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-01-08 for -05)
Unknown
Just wondering - would use of e.g. amazon EC2 or equivalent might be relevant for any of this, e.g. if the service provider for such a thing used IPv6 addresses for access controls or something. Maybe that's theoretical for now though or you don't consider that part of an enterprise network, either of which seem reasonable.
Stewart Bryant Former IESG member
No Objection
No Objection
(for -05)
Unknown
Wesley Eddy Former IESG member
No Objection
No Objection
(for -05)
Unknown