Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks
RFC 6866

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)
No email
send info
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)
No email
send info
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

Comment (2012-12-24)
No email
send info
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)
No email
send info
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.