Renumbering Still Needs Work
draft-carpenter-renum-needs-work-05

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

[Ballot discuss]
This is a very good document. I had a few small issues with it, however,
and wanted to talk about them before we publish this as an RFC.

The document says:

  It would also be possible to use ULAs for all
  on-site network management purposes, by assigning ULAs to all
  devices.  This would make these on-site activities immune to
  renumbering of the prefix(es) used for off-site communication.

My understanding is that the fact that ULAs came out after RFC 3484
implies there are some residual issues with address selection when
you have both a global and ULA address. I wonder if the positive
assessment above is really accurate.

The document says:

  The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203].
  This is specifically unicast-only; a DHCP client must discard a
  multicast FORCERENEW.  This could nevertheless be used to trigger the
  renumbering process, with the DHCP server cycling through all its
  clients issuing a FORCERENEW to each one.  DHCPv6 has a similar
  feature, i.e., a unicast RECONFIGURE message, that can be sent to
  each host to inform it to check its DHCPv6 server for an update.
  These two features do not appear to be widely used for bulk
  renumbering purposes.

The FORCERENEW RFC says that DHCP authentication is a MUST, and as we
know, DHCP authentication has not been deployed in any wide scale
and perhaps not even in any single network. As a result, it is very
unrealistic to assume that FORCERENEW as currently defined would be
helpful here. Perhaps the somewhat positive assessment above should
somehow take this into account.

The document says:

  On the latter point, the capability to use FQDNs as endpoint names in
  IPsec VPNs is not new and is standard (see [RFC2407] Section 4.6.2.3
  and [RFC4306] Section 3.5).  This capability is present in most IPsec
  VPN implementations.  There does seem to be an "educational" or
  "awareness" issue that many system/network administrators do not
  realise that it is there and works well.

The ability to identify endpoints with fqdns != the ability of the
software to dynamically re-establish sessions when DNS starts to
give a different answer for the fqdn.

The document says:

  However, SEND appears to be very difficult to actually
  deploy and operate.  At present it is unclear whether or when SEND
  might be widely implemented or widely deployed.

Hmm. I would suggest replacing the above with just "At present it is
unclear whether SEND will be widely implemented." I'm not sure why
you would say that its very difficult to deploy and operate. It
doesn't require per-host config, for instance. I think the reason
why it hasn't been deployed has more to do with lack of need than
the operational difficulties.

Also, the document says:

  For IPv6, addresses are intended to be protected against forgery
  during neighbor discovery by SEcure Neighbor Discovery (SEND)
  [RFC3971].  This appears to be a very useful precaution during
  dynamic renumbering, to prevent hijacking of the process by an
  attacker.

Its not clear to me why the renumbering situation poses any
particular difficulties for securing ND and RD information.
Obviously, without a secure ND process an attacker can hijack
the process at any time, be there renumbering in progress or not.

The document says:

  6.1. SHIM6

  SHIM6, proposed as a host-based multihoming mechanism for IPv6, has
  the property of dynamically switching the addresses used for
  forwarding the actual packet stream while presenting a constant
  address as the upper layer identifier for the transport layer
  [RFC5533].  At least in principle, this property could be used during
  renumbering to alleviate the problem described in Section 5.1.2.

I'm not sure why we are singling SHIM6 out here. HIP, SHIM6, MOBIKE,
Mobile IPv6, SCTP and multipath TCP all have the same property
described above.

Also, you seem to be missing the most relevant (IMHO) mechanism,
which is application protocols that are capable of restarting
themselves as connectivity changes.

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

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.

[Ballot discuss]
This is a very good document. I had a few small issues with it, however,
and wanted to talk about them before we publish this as an RFC.

The document says:

  It would also be possible to use ULAs for all
  on-site network management purposes, by assigning ULAs to all
  devices.  This would make these on-site activities immune to
  renumbering of the prefix(es) used for off-site communication.

My understanding is that the fact that ULAs came out after RFC 3484
implies there are some residual issues with address selection when
you have both a global and ULA address. I wonder if the positive
assessment above is really accurate.

The document says:

  The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203].
  This is specifically unicast-only; a DHCP client must discard a
  multicast FORCERENEW.  This could nevertheless be used to trigger the
  renumbering process, with the DHCP server cycling through all its
  clients issuing a FORCERENEW to each one.  DHCPv6 has a similar
  feature, i.e., a unicast RECONFIGURE message, that can be sent to
  each host to inform it to check its DHCPv6 server for an update.
  These two features do not appear to be widely used for bulk
  renumbering purposes.

The FORCERENEW RFC says that DHCP authentication is a MUST, and as we
know, DHCP authentication has not been deployed in any wide scale
and perhaps not even in any single network. As a result, it is very
unrealistic to assume that FORCERENEW as currently defined would be
helpful here. Perhaps the somewhat positive assessment above should
somehow take this into account.

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

[Ballot discuss]
This is a very good document. I had a few small issues with it, however,
and wanted to talk about them before we publish this as an RFC.

The document says:

  It would also be possible to use ULAs for all
  on-site network management purposes, by assigning ULAs to all
  devices.  This would make these on-site activities immune to
  renumbering of the prefix(es) used for off-site communication.

My understanding is that the fact that ULAs came out after RFC 3484
implies there are some residual issues with address selection when
you have both a global and ULA address. I wonder if the positive
assessment above is really accurate.

The document says:

  The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203].
  This is specifically unicast-only; a DHCP client must discard a
  multicast FORCERENEW.  This could nevertheless be used to trigger the
  renumbering process, with the DHCP server cycling through all its
  clients issuing a FORCERENEW to each one.  DHCPv6 has a similar
  feature, i.e., a unicast RECONFIGURE message, that can be sent to
  each host to inform it to check its DHCPv6 server for an update.
  These two features do not appear to be widely used for bulk
  renumbering purposes.

The FORCERENEW RFC says that DHCP authentication is a MUST, and as we
know, DHCP authentication has not been deployed in any wide scale
and perhaps not even in any single network. As a result, it is very
unrealistic to assume that FORCERENEW as currently defined would be
helpful here. Perhaps the somewhat positive assessment above should
somehow take this into account.

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

[Ballot discuss]
This is a very good document. I had a few small issues with it, however,
and wanted to talk about them before we publish this as an RFC.

The document says:

  It would also be possible to use ULAs for all
  on-site network management purposes, by assigning ULAs to all
  devices.  This would make these on-site activities immune to
  renumbering of the prefix(es) used for off-site communication.

My understanding is that the fact that ULAs came out after RFC 3484
implies there are some residual issues with address selection when
you have both a global and ULA address. I wonder if the positive
assessment above is really accurate.

The document says:

  The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203].
  This is specifically unicast-only; a DHCP client must discard a
  multicast FORCERENEW.  This could nevertheless be used to trigger the
  renumbering process, with the DHCP server cycling through all its
  clients issuing a FORCERENEW to each one.  DHCPv6 has a similar
  feature, i.e., a unicast RECONFIGURE message, that can be sent to
  each host to inform it to check its DHCPv6 server for an update.
  These two features do not appear to be widely used for bulk
  renumbering purposes.

The FORCERENEW RFC says that DHCP authentication is a MUST, and as we
know, DHCP authentication has not been deployed in any wide scale
and perhaps not even in any single network. As a result, it is very
unrealistic to assume that FORCERENEW as currently defined would be
helpful here. Perhaps the somewhat positive assessment above should
somehow take this into account.

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

[Ballot discuss]
This is a very good document. I had a few small issues with it, however,
and wanted to talk about them before we publish this as an RFC.

The document says:

  It would also be possible to use ULAs for all
  on-site network management purposes, by assigning ULAs to all
  devices.  This would make these on-site activities immune to
  renumbering of the prefix(es) used for off-site communication.

My understanding is that the fact that ULAs came out after RFC 3484
implies there are some residual issues with address selection when
you have both a global and ULA address. I wonder if the positive
assessment above is really accurate.

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

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

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

[Ballot comment]
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 a IM client, or using facebook, and you switch from a wired interface to wireless interface, this looks exactly like a renumbering to the application and any decent IM client, softphone, or web application 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.

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

[Ballot discuss]
Toward the end of section 5.1.1, this text:

  and yet another uses SLAAC even if the M bit is set, systematic
  address management becomes impossible.

is somewhat misleading.  The use of SLAAC is entirely independent of the M bit; SLAAC is controlled by the A bit associated with each prefix in its PIO.

Regarding the discussion of M/O bits, SLAAC and consistent address assignment, I agree that the current state of the definition and semantics of the M and O bit are problematic.  In fact, some OSes (e.g., Linux-based OSes) don't have an API to make the M/O bits accessible to a user-level DHCPv6 client.  As a practical matter, it is relatively easy to have all the hosts on a link use either SLAAC or DHCPv6:

* for SLAAC, configure the A-bit 'on' in the PIO for any prefixes and don't configure any DHCPv6 service for address assignment; any hosts that try to use DHCPv6 for address assignment will fail while still obtaining any other configuration information through DHCPv6
* for DHCPv6, don't enable the A-bit in any PIOs and enable the M/O bits; hosts won't use SLAAC and will start DHCPv6 whether or not they respsect the M/O bits

[Ballot comment]
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, this text:

  and yet another uses SLAAC even if the M bit is set, systematic
  address management becomes impossible.

is somewhat misleading.  The use of SLAAC is entirely independent of the M bit; SLAAC is controlled by the A bit associated with each prefix in its PIO.

I agree that the current state of the definition and semantics of the M and O bit are problematic.  In fact, some OSes (e.g., Linux-based OSes) don't have an API to make the M/O bits accessible to a user-level DHCPv6 client.  As a practical matter, it is relatively easy to have all the hosts on a link use either SLAAC or DHCPv6:

* for SLAAC, configure the A-bit 'on' in the PIO for any prefixes and don't configure any DHCPv6 service for address assignment; any hosts that try to use DHCPv6 for address assignment will fail while still obtaining any other configuration information through DHCPv6
* for DHCPv6, don't enable the A-bit in any PIOs

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

PROTO write-up by Brian Carpenter:

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the document
        and, in particular, does he or she believe this version is ready
        for forwarding to the IESG for publication?

> Dan Romascanu; yes

  (1.b) Has the document had adequate review both from key members of
        the interested community and others? Does the Document Shepherd
        have any concerns about the depth or breadth of the reviews that
        have been performed?

> Document has been discussed in IETF73 and IETF OPSAREA meetings
> and on OPSAREA list. At least twelve people have commented on it.


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective, e.g.,
        security, operational complexity, someone familiar with AAA,
        internationalization or XML?

> Security and Gen-ART reviews at Last Call are desirable.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he or
        she is uncomfortable with certain parts of the document, or has
        concerns whether there really is a need for it. In any event, if
        the interested community has discussed those issues and has
        indicated that it still wishes to advance the document, detail
        those concerns here.

> No

  (1.e) How solid is the consensus of the interested community behind
        this document? Does it represent the strong concurrence of a few
        individuals, with others being silent, or does the interested
        community as a whole understand and agree with it?

> This document touches on many areas; Last Call comments are needed

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

> No

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits?
        (See the Internet-Drafts Checklist and 
        http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
        enough; this check needs to be thorough. Has the document met all
        formal review criteria it needs to, such as the MIB Doctor, media
        type and URI type reviews?

> Two references are out of date; these can be corrected after Last Call

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that are
        not ready for advancement or are otherwise in an unclear state?
        If such normative references exist, what is the strategy for their
        completion? Are there normative references that are downward
        references, as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call procedure
        for them [RFC3967].

> All references are informative

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body of
        the document? If the document specifies protocol extensions, are
        reservations requested in appropriate IANA registries? Are the
        IANA registries clearly identified? If the document creates a new
        registry, does it define the proposed initial contents of the
        registry and an allocation procedure for future registrations?
        Does it suggested a reasonable name for the new registry? See
        [I-D.narten-iana-considerations-rfc2434bis]. If the document
        describes an Expert Review process has Shepherd conferred with the
        Responsible Area Director so that the IESG can appoint the needed
        Expert during the IESG Evaluation?

> OK

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML code,
        BNF rules, MIB definitions, etc., validate correctly in an
        automated checker?

> N/A

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Writeup? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

    This document reviews the existing mechanisms for site renumbering
    for both IPv4 and IPv6, and identifies operational issues with those
    mechanisms.  It also summarises current technical proposals for
    additional mechanisms.  Finally there is a gap analysis identifying
    possible areas for future work.


    Working Group Summary

    This is an individual submission. Discussion took place in OPSAREA
    meetings and on the OPSAREA list. All the comments made were
    constructive suggestions and no dissent was noted.

    Document Quality   

    This is not a protocol spec. It is clearly written with thorough
    references.