Procedures for Renumbering an IPv6 Network without a Flag Day
draft-ietf-v6ops-renumbering-procedure-05
Yes
No Objection
(Jon Peterson)
(Russ Housley)
(Scott Hollenbeck)
No Record
Note: This ballot was opened for revision 05 and is now closed.
David Kessens Former IESG member
Yes
Yes
(2004-07-15)
Unknown
First line of abstract needs to be changed to make it understandable english.
Bill Fenner Former IESG member
No Objection
No Objection
(2004-07-22)
Unknown
In section 2.3, are these two sentences talking about the same thing? The new link prefixes may be advertised by the network elements, but the router advertisements should not cause hosts to perform SLAC on the new link prefixes; in particular the "autonomous address-configuration" flag [RFC2461] should not be set in the advertisements for the new link prefixes. Network elements may have IPv6 addresses from the new link prefixes assigned to interfaces, taking care that this assignment does not interfere with the use of IPv6 addresses from the old prefix and does not cause the new link prefix to be advertised to hosts. The first sentence seems to say that it's ok for a network element to advertise the link prefix as long as it doesn't set the aa flag; the second seems to prohibit any advertising of the link prefix. In section 3.2: To better support renumbering, network elements can: o provide uniform support for renumbering in all user interface and configuration mechanisms, such as replacement of one prefix with another through a single command How does "replacement of one prefix with another" support make-before-break? Shouldn't this be "add an additional prefix with all the same configurations as the existing prefix"?
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Scott Hollenbeck Former IESG member
No Objection
No Objection
()
Unknown
Steven Bellovin Former IESG member
No Objection
No Objection
(2004-07-19)
Unknown
2.2.2: There's a dangling word at the end of th section. Mention ACLs in firewalls? Mention use of honeypot-like machines to catch residual uses of the old prefix after renumbering is putatively completed?
Ted Hardie Former IESG member
No Objection
No Objection
(2004-07-20)
Unknown
I went back and forth on this being a discuss, and decided that since this is informational, it should not be. But I think section 3.1 is very weak compared to the extensive work that has been done in v6ops on application protocols. Here's the current text: Application designers frequently take short-cuts to save memory or increase responsiveness, and a common short-cut is to use static configuration of IP addresses rather than DNS translation to obtain the same. The downside of such behavior should be apparent; such a poorly designed application cannot even add or replace a server easily, much less change servers or reorganize its address space. The short-cut ultimately becomes expensive to maintain and hard to change or replace. As a result, in view of the possibility that a network may need to be renumbered in the future, any application: o should obtain addresses of other systems or services from the DNS, rather then having those addresses manually configured, o must obtain a new translation if a new session is opened with the same service after the lifetime of the DNS RR expires, o when addresses are configured rather than translated, should provide a convenient programmatic method to reconfigure the addresses that can be executed using a script or its equivalent. Application designers, equipment vendors, and the Open Source community should take note. There is an opportunity to serve their customers well in this area, and network operators should take note to either develop or purchase appropriate tools. There are lots of cases when these choices are not nearly the capricious or short-sighted decisions that this document makes them out to be. For one example familiar to this set of authors, look at how people configure BGP sessions, and tell them they should use DNS lookup of the peer address to handle possible renumbering of the peer's network. Sure, it's possible, but lots of people make other choices for pretty good reasons. Making these statements about why the decisions are made don't really help anyone figure out what to do about it, at least in my opinion. I would personally suggest that they replace the entire section with the short phrase from the definition section: Finding everything that must be updated and automating the process may require significant effort. This process must be tailored to the needs of each network. As what is there isn't really advice to those engaged in renumbering, but advice to a different population.
Thomas Narten Former IESG member
(was Discuss)
No Objection
No Objection
(2004-07-22)
Unknown
> Network element: Any network device, such as a router, switch or > firewall Might be good to state here that "hosts" are specifically excluded, at least, that is my conclusion based on the following: > IPv6 addresses assigned to interfaces on network elements: These > addresses are typically assigned manually, as part of configuring > network elements. not sure I agree with "typically", if it applies to hosts as well. Host addresses are typically managed using, e.g., DHCP. Section 1.3 is organized a but funny. Is the formatting right? E.g., should some of this stuff be clearly itemized to show what belongs to what? E.g.,: > Routing information propagated by network elements Seems like maybe this is a subsection heading, or the start of an itemized list? > o The DHCP Reconfigure message can be sent from the server to the > hosts to cause the hosts to contact the server. immediately Extra/missing text? > The new prefix is added to the routing infrastructure, firewall > filters, ingress/egress filters and other forwarding and filtering > functions. The new link prefixes may be advertised by the network > elements, but the router advertisements should not cause hosts to Maybe reword above (to make more clear talking about route injection) to something like: Routes for the new link prefixes may be injected by routing protocols into the routing subsystem, but ... > configurations that depend on it.If any configuration has been insert space > During this phase the registries are informed that the old prefix is > no longer in use, and addresses within that prefix are removed from A > records associated with name servers and the corresponding name > server configurations. Who are "registries", and indeed, is that the right word to use here (e.g., for end sites, who get addresses from ISPs) > The difficult operational issues in Section 2.3, Section 2.6, and > Section 2.7 are in dealing with the configurations of routers and > hosts which are not under the control of the network administrator or > are manually configured. Examples of such devices include voice over > IP (VoIP) telephones with static configuration of boot or name > servers, dedicated devices used in manufacturing that are configured > with the IP addresses for specific services, the boot servers of > routers and switches, etc. mention unique local addresses here? Can they play a role?
Harald Alvestrand Former IESG member
(was No Objection)
No Record
No Record
(2004-07-21)
Unknown
Reviewed by Michael Patton, Gen-ART