The IESG has approved the following document: - 'Renumbering still needs work ' <draft-carpenter-renum-needs-work-05.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-05.txt 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. Although the proposed status of the document is Informational the editors and the sponsoring AD decided to run an IETF Last Call because of the various areas that the content relates to. Document Quality This is not a protocol spec. It is clearly written with thorough references. Personnel Dan Romascanu is the sponsoring Area Director. RFC Editor Note Please make the following changes: 1. in Section 2.5: s/MS Exchange/Windows Server/ 2. in Section 5.1.1: OLD: 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. NEW: 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 for a site network manager to configure systems in such a way that all hosts boot in a consistent way. Hosts will start SLAAC if so directed by appropriately configured RA messages. However, if one operating system also starts a DHCPv6 client by default, and another one starts it only when it receives the M bit, systematic address management is impeded. 3. in Section 6.3: s/DNSOPS WG is working/DNSOP WG has considered/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
