Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks
Note: This ballot was opened for revision 02 and is now closed.
(Ron Bonica) Yes
(Wesley Eddy) Yes
Barry Leiba Yes
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Benoît Claise) No Objection
(Adrian Farrel) No Objection
Comment (2012-12-12 for -02)
I have no objection to the publication of this document. I have a concern that the security considerations may need more work. For example, ACLs seem to rely on well-known IP addresses. Those addresses are often manually configured and the synchronisation during renumbering is surely a vulnerability. I am sure there are plenty of other issues that should be considered. === I also have some petty nits that you might want to address to improve the document. --- I would like it if for clarity the document title could reflect the limitation of this document to entreprise networks. --- ULA is used without expansion --- Section 2.7 It is quite common practice that some such addresses will have no corresponding DNS entry. Jane Austen and I would like to know whether you mean "quite" in the correct English sense as "completely", or in the modern sense of "relatively" or "somewhat". Actually, I suggest you delete the word. --- Section 3 The hanging rhetorical question in the first paragraph is disconcerting. Is this a question that someone doing renumbering should consider, or is it targeted at the reader of the document? Is the word "Alternatively" really appropriate since it suggests that the choice is between telling the NEs and NMS, and not disrupting the network. --- Section 3 therefore this situation should be avoided except for very small networks I presume you do not mean the situation of renumbering such networks! But how do we avoid the situation of networks that are numbered in the way you describe? For most existing networks, the only way to avoid the situation is to renumber! So I assume that you are giving advice to people deploying new equipment and networks - please make this clear.
(Stephen Farrell) No Objection
(Brian Haberman) (was Discuss) No Objection
Comment (2012-12-11 for -02)
1. In the introduction, shouldn't the list of reasons to use static addresses include their use within ACLs and other security mechanisms based on IP addresses? If so, a corresponding subsection in section 2 would be warranted.
(Russ Housley) No Objection
(Pete Resnick) (was Discuss) No Objection
Thanks for clarifying section 2.3 in response to my comments. I hope to see more of this discussion continue in the other documents this group is working on.
(Robert Sparks) No Objection
(Martin Stiemerling) No Objection
(Sean Turner) No Objection
(Ralph Droms) Abstain
Comment (2012-12-13 for -02)
I'm entering Abstain for this document, because I think it has many flaws, some important and some less important, but still may be useful. Here are some of the problems I see in the document. DNS, mDNS and SLP are mentioned in the context of name resolution. Is SLP deployed widely enough to warrant mention? What about LLMNR and uPNP? I don't understand why ULAs are identified as somehow affecting the use or impact of static addresses. DHCPv6 PD should be mentioned in the context of prefix assignment. Is it really still common practice that " printers in particular are manually assigned a fixed address (typically an [RFC1918] address) and that users are told to manually configure printer access using that fixed address"? In section 2.3, addresses assigned through DHCPv6 are considered problematic because the address might expire, but later DHCPv6 is suggested as a way of assigning addresses to solve renumbering of static addresses. I don't understand the first sentence of 2.4. Isn't the requirement for a static address based on the need to maintain transport sessions over VM movement (which isn't really how I understand the first sentence). In section 2.5, if asset management is based on MAC addresses, why are static IP addresses an issue? I don't understand the connection between "If [...] a particular host is found to be generating some form of unwanted traffic, it is urgent to be able to track back from its IP address to its physical location" and renumbering of static addressing. How does "using addresses under an enterprise's ULA prefix for software licensing" solve the renumbering problem? There may be a clue in section 2.7, where addresses assigned from ULAs are suggested as the solution for renumbering network elements. Perhaps the bit I'm missing is that addressing from ULAs avoids forced renumbering when the organization prefix changes due to external causes? In section 2.7, this claim may be true: In any case, when network elements are renumbered, existing user sessions may not survive, because of temporary "destination unreachable" conditions being treated as fatal errors. This aspect needs further investigation. but what is its connection to renumbering static addresses? Section 2.8 makes a valid point about the relationship between static addresses and asset management, but goes into solution space when it talks about DHCPv6 for configuring static addresses. I don't understand the first paragraph of section 3. From section 3: 4. If external prefix renumbering is required, the RFC 4192 procedure is followed. What about renumbering required by strictly internal topology changes in the network? I.e., I think "external" can be dropped.