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

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Brian,



Thanks a lot for commenting and sorry the late answer ... too busy last weeks.



Comments in-line below (subjected to my co-author agreement), basically, agree with all your inputs, except a couple of points.



Thanks!



Regards,

Jordi

 

 



-----Mensaje original-----

De: v6ops <[e-mail]> en nombre de Brian E Carpenter <[e-mail]>

Organización: University of Auckland

Fecha: domingo, 8 de julio de 2018, 17:43

Para: <[e-mail]>, IPv6 Operations <[e-mail]>

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



    Hi,

    

    Thanks for this draft.

    

    > Abstract

    

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



For the next version, I've reduced 50% the length of the 1st paragraph. 3rd paragraph, I recall is mandatory (IDNits).



    

    > ... 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.



Agreed and done.



    

    > 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.



Agreed!    



    >    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.



Agreed!

    

    > 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.



Agreed!

    

    > 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.



Agreed!

    

    >    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/



Agreed!

    

    ....

    >    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.



Agreed!

    

    >    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/



Agreed!

    

    ....

    >    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.



Agreed!

    

    ....

    >    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.



Agreed!

    

    > 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).





I recall we deprecated the 6to4 anycast, but not 6to4, in fact 6to4 to 6to4 traffic is still useful for peer to peer.

    

    > 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.



I've introduced new text on those points.

    

    > 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.

 

Agreed!

   

    Regards

        Brian

    

    _______________________________________________

    v6ops mailing list

    [e-mail]

    https://www.ietf.org/mailman/listinfo/v6ops

    




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.