Renumbering Still Needs Work

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

(Ron Bonica) Yes

(Cullen Jennings) Yes

Comment (2009-11-18 for -)
No email
send info
I'm happy to see this draft published as is, but I would be happier if:

1) when discussing how UDP and TCP sessions fail, point out that many applications today deal with this already at the application layer. If you are running an application and you switch from a wired interface to wireless interface, this looks exactly like a renumbering to the application.  Any decent IM client, softphone, or web application (such as facebook, gmail) will just deal with it and from the users point of view nothing broke and the application just kept working as the renumber happened. 

2) Although there are multiple ways to update a DNS record in a secure way, the most prevalent by far is dyn-dns. This is widely supported in most home gateways today.

(Dan Romascanu) Yes

(Jari Arkko) (was Discuss) No Objection

Comment (2009-11-19)
No email
send info
Section 2.6. talks about SLP. It is unclear to me what the real significance of this is, how widely has it been deployed? AFAICT, what has been deployed is DHCP based discovery of certain key services.

The document says:

   Until this ambiguous behaviour is clearly resolved by the IETF,
   operational problems are to be expected, since different host
   operating systems have taken different approaches.  This makes it
   difficult or impossible for a site network manager to configure
   routers and DHCPv6 servers in such a way that all hosts boot in a
   consistent way.  If one operating system starts a DHCPv6 client by
   default, and another one starts it only when it receives the M bit,
   and yet another uses SLAAC even if the M bit is set, systematic
   address management becomes impossible.

You present this in a light where there's a problem and that it will
eventually be solved. I think that is a little bit too optimistic.
I think the reality is that since the different interpretations got
into implementations from day one, it has been very hard to come to
any conclusion about the desired changes in the IETF specifications.
More fundamentally, the change in the IETF specifications no longer
solves this problem, as the code is already out there. That is,
when stateful address allocation is used, IPv6 does not guarantee
full uniformity on host behavior. However, I do not see this as a
fundamental problem -- you just have to deal with it. Also, what does
all this have to do with the topic of the document?

And, the document says:

   The IETF needs to resolve the 'IPv6 ND M/O flag debate' once and for
   all, with default, mandatory and optional behaviors of hosts being
   fully specified.

I disagree, for the reasons stated above.

The document says:

   In contrast, SCTP already supports dynamic multi-homing of session
   end-points, so SCTP sessions ought not be adversely impacted by
   renumbering the SCTP session end-points [RFC4960], [RFC5061].

Yeah. And this has no relevance for the topic at hand. The point is
that there are protocols that are bound to IP addresses, and as long
as there exists protocols like this then a change of an IP address
is going to disruption sessions. Not that this matters, IMHO, because
in IPv6 a sudden change is not what is recommended. For IPv4 that
is of course all we have.

The document says:

  7.2. Router-related gaps

You are not listing DHCP-based prefix discovery. I think we have all
the components necessary for this to work automatically, but AFAIK
this has never been either explained or used in real networks.

The document says:

   Security issues
   related to SLAAC are discussed in [RFC3756].

You are singling SLAAC out here. DHCP has similar issues (and
also unsolved, as far as practical deployment goes). Then again,
we've had this issue for 20 years and the Internet is still up.

The document says:

   Whatever authentication method(s) are adopted, key distribution will
   be an important aspect.  Most likely, public key cryptography will be
   needed to authenticate renumbering announcements passing from one
   site to another, since one cannot assume a pre-existing trust
   relationship between such sites.

Hmm. I'm not necessarily convinced that we need a GLOBAL renumbering
support. Just being able to do this locally would be already great.

(Ross Callon) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2009-11-17)
No email
send info
The authors might consider adding text to section 3, referencing draft-ietf-v6ops-ipv6-cpe-router-02, explaining the use of DHCPv6 to assign an IPv6 address to the SP-facing interface of an IGD.  Also under discussion for inclusion in draft-ietf-v6ops-ipv6-cpe-router-02 is the use of the default router information from a RA received from a SP edge router to establish a default route in the IGD forwarding table.
Toward the end of section 5.1.1:

   Neither the SLAAC approach, nor DHCP without pre-registered MAC
   addresses, will work reliably in all cases of systems that are
   assigned fixed IP addresses for practical reasons.

For example, servers that that need a fixed IP address and for which the network admin doesn't want a dependency on the DHCP service?
In section 5.3.4, the 6net project deliverables D3.6.1 and D3.6.2 might be cited as providing relevant experience in managing a renumbering event.  If I recall correctly, it was reported in one of those deliverables that coordinating the renumbering processes across admin domains, and the blocking that happens when another admin domain doesn't follow through, caused the greatest delay int he renumbering process.
In section 6.3:

   A DHCPv6 extension has been proposed which could convey alternative
   routes, in addition to the default router address, to IPv6 hosts
   [I-D.dec-dhcpv6-route-option].  This might be extended as a way of
   informing hosts dynamically of prefix changes.  Other DHCP options
   are also on the table that may offer information about address
   prefixes and routing to DHCP or DHCPv6 clients, such as
   [I-D.ietf-dhc-subnet-alloc] and [I-D.sun-mif-route-config-dhcp6].

it's not at all clear to me from this text how the cited DHCP options have anything to do with renumbering.
Section 7.3 - what does DNSsec have to do with renumbering?
Also in section 7.3: traffic monitoring, either with a traffic analyzer or a specialty tool like NDPmon, can be a very useful tool to confirm that renumbering has completed successfully or that some traffic is still using the old prefixes

(Lisa Dusseault) No Objection

(Pasi Eronen) No Objection

Comment (2009-11-17 for -)
No email
send info
Minor semi-editorial nits:

- Section 2.5: I think "MS Exchange" is the email server product; 
DNS and DHCP come with "Windows Server".
- Section 2.5: the last paragraph seems largely unrelated to
- Section 6.3: s/DNSOPS WG/DNSOP WG/
- Section 6.3: It looks like NSCP is an individual draft, not
something DNSOP WG is working on yet.

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

(Magnus Westerlund) No Objection