Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt

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

Hi,

Thanks for this draft.

> Abstract

This needs to be shorter. Three paragraphs is too much.

> ... policy should reflect that assignment of a single subnet is
> no longer appropriate unless the recipient explicitly agrees to the
> limitations implied by such an assignment.

I *strongly* suggest deleting the "unless" clause. It leaves a
loophole, and it could easily be hidden in shrink-wrap terms
and conditions so that a subscriber would agree without even
knowing about it. Reduce this simply to:

   ... policy should reflect that assignment of a single subnet is
   never appropriate.

> 1.  Introduction
...
>    1.  It is extremely discouraged that /128s be given out.  While there
>        may be some cases where assigning only a single address may be
>        justified, a site, by definition, implies multiple subnets and
>        multiple devices.

I find this a bit weak. Try:

   1.  It is extremely discouraged that /128s be given out.  While there
       may be some applications where assigning only a single address may be
       tolerated, a site, by definition, implies multiple subnets and
       multiple devices. Also, a /128 prevents any form of privacy-based
       addressing.

>    4.  This revision has been created to more clearly assert the
>        requirement to ensure that address assignments to end-sites
>        provide a sufficiently big number of subnets (/64 on classic
>        networks) to each end-site, taking under consideration the end-
>        site's future expected needs, new deployment expectations and new
>        protocol requirements, among others.  Once all these are
>        considered, it seems unlikely that a single subnet (/64) or even
>        a small number of them should be assigned, unless very clearly
>        justified and agreed to by the end-site.

The "unless" clause is dangerous because of shrink-wrap terms and 
conditions. I suggest deleting it.

> 2.  Considerations Regarding the Prefix Length
...
>    This consideration should be noticed, across this document, in the
>    sense that end-sites usually have subnets that use, by default,
>    SLAAC, and consequently, the LAP is mandatorily a /64.  Other
>    technologies, may have a different LAP, which must be used
>    accordingly.

I suggest s/Other/Future/ since /64 prevails everywhere today.

> 3.  On /48 Assignments to End-Sites
...
>    An important
>    goal in IPv6 is to significantly change the default and minimal end
>    site assignment, from "a single address" to "multiple networks" and
>    to ensure that end-sites can easily obtain address space.

I suggest adding something like this:

As the operational costs of carrier-grade NAT and address+port sharing
have shown, availability of multiple addresses and prefixes to end sites
that need them will be a considerable saving to their ISPs.

>    It might be tempting to give home sites a single /64, since that is
>    already significantly more address space compared with today's IPv4
>    practice.  However, this precludes the expectation that even home
>    sites will grow to support multiple subnets going forward.  Hence, it

s/expectation/certainty/

...
>    A key goal of the recommendations in [RFC3177] is to
>    ensure that upon renumbering, one does not have to deal with
>    renumbering into a smaller subnet size.

Perhaps add:

In particular this would apply to any site that switches to
an ISP that provides a longer prefix.

>    It should be noted that similar arguments apply to the management of
>    zone files in the DNS.  In particular, managing the reverse
>    (ip6.arpa) tree is simplified when all links are numbered using the
>    same subnet ids

s/numbered/renumbered/

...
>    years, and we don't recover back the /48's, we will be able to use
>    IPv6 addressing space for over 100.000 years.

Perhaps add:

This document does not advocate careless use of address space, but
there is objectively no reason to be restrictve.

...
>    Today typically, a home has already a considerable number of possible
>    subnets (a common CE has 4 LAN ports, 2 WiFi radios which support
>    several SSIDs each one, VoIP subnet, IPTV subnet, additional VLANs) 
>    and if downstream routers are used, there is a need for further
>    subnets.  This means that in a short term, assigning a /60 (16
>    subnets), it is already a really bad decision, as it may enforce IPv6
>    NAT between the main CE and downstream routers.

I suggest deleting "as it may enforce IPv6 NAT between the main CE and
downstream routers". Firstly it puts NAT into the reader's mind. Secondly,
it isn't the only solution - IIDs shorter than 64 could also be implemented.

> 4.  Impact on IPv6 Standards

I propose to simply delete this section.

Firstly, RFC3056 is deprecated so it's irrelevant today.
Secondly, the argument about ULAs (RFC4193) doesn't hold up.
ULAs are like any other /48 prefix - if you are forced to
renumber into a longer prefix, you lose some subnet bits.
That is already covered in the middle of section 3 (the
"key goal" sentence quoted above).

> 6.  Security Considerations
> 
>    This document has no known security implications.

Really? More prefix space offers more potential for scanning
attacks. More prefix space also allows the use of slightly
randomized prefixes and/or prefix-per host.

Also of course, a /128 would prevent any form of privacy-based
addressing.

> 8.  Acknowledgements
> 
>    The authors of this document will like to acknowledge the authors of
>    previous versions (Thomas Narten and Geoff Huston)

RFC3177 was signed by the whole IAB and IESG seated in 2001, and its
Acknowledgements read:

>>    This document originated from the IETF IPv6 directorate, with much
>>    input from the IAB and IESG.  The original text forming the basis of
>>    this document was contributed by Fred Baker and Brian Carpenter.
>>    Allison Mankin and Thomas Narten merged the original contributions
>>    into a single document, and Alain Durand edited the document through
>>    its final stages.

Regards
    Brian