Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt

[Brian E Carpenter <[e-mail]>]

Hi,

I don't understand why you mention RFC 1918 in a document about
IPv6 deployment.

In the table in 2.1.1, I object strongly to the comment against
private (i.e. ULA) addresses
"Will probably require some sort of NAT on links to the Internet."

That isn't the architecture. The architecture is that nodes have multiple
addresses, and only use ULAs for internal traffic, and use PA or PI addresses
for Internet traffic. We shouldn't be documenting any other usage of
ULAs. We shouldn't be making statements like this:

"For an enterprise, the use of private address space is	
reasonable, but the enterprise will need to use NAT44 and/or	
NPT[RFC6296] on links to the Internet."

We clearly can't pretend that NAT44 isn't widely used, but IMHO it should
be completely out of scope in this document, and NPTv6 is an experimental
RFC that we should never recommend. ULAs should *only* be used in parallel
with PA or PI. That isn't an afterthought; that is the basic intention behind
ULAs.

Stepping back slightly in the text:
"In this case, the use of PI space is the best	
option, as it gives the most flexibility in the future.  However,	
some organizations may be unable or unwilling to obtain PI space - in	
this case PA space is the next-best choice."

What size of enterprise are you addressing? Whatever the current RIR policy
is, it remains irresponsible to hand out PI prefixes like candy. Please tune
this language to make it clear that it applies to hundreds or thousands of
large customers, probably not to small/medium enterprises, and definitely
not to millions of SOHO customers, who will inevitably get PA.

Stepping back to the first sentence of the Introduction:

"This document discusses certain choices that arise when designing a
IPv6-only or dual-stack network."

This really needs to specify the classes of customer it is addressing.
You split some of the later material into "ISP" and "Enterprise"
but that (and customers that are not covered) needs to be made clear
at the beginning, and even in the Abstract.

Nit:

"2.4.3.  RIP	
		
   A protocol option described in the table in this section is RIP	
   [RFC2080]."

Don't you mean "*not* described in the table"? And its name is RIPng.

Regards
   Brian