Procedures for Renumbering an IPv6 Network without a Flag Day
draft-ietf-v6ops-renumbering-procedure-05

[Ballot comment]
>    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?

[Ballot discuss]
This document doesn't mention Unique Local Addresses. It probably
should, since for configuration (e.g., bootstrapping) using such
addresses may reduce the pain of renumbering. I don't think a lot of
text is required, but a paragraph mentioning their existance and how
they might help seems appropriate.

Security Considerations seems weak. The first few paragraph seem to
have nothing to do with security.

Second, this docuemnt recommends using DNS names rather than
hard-coded IP addresses in order to simplify renumbering. But some
folk use addresses because they are more secure than relying on an
(unsecured) DNS lookup. This issue should be dicussed in this  section.

[Ballot comment]
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"?

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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.