Procedures for Renumbering an IPv6 Network without a Flag Day
RFC 4192

Note: This ballot was opened for revision 05 and is now closed.

(David Kessens) Yes

Comment (2004-07-15 for -)
No email
send info
First line of abstract needs to be changed to make it understandable english.

(Steven Bellovin) No Objection

Comment (2004-07-19 for -)
No email
send info
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?

(Bill Fenner) No Objection

Comment (2004-07-22 for -)
No email
send info
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"?

(Ted Hardie) No Objection

Comment (2004-07-20 for -)
No email
send info
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.

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(Thomas Narten) (was Discuss) No Objection

Comment (2004-07-22)
No email
send info
>    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?

(Jon Peterson) No Objection

(Harald Alvestrand) (was No Objection) No Record

Comment (2004-07-21 for -)
No email
send info
Reviewed by Michael Patton, Gen-ART