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

["Mudric, Dusan (Dusan)" <[e-mail]>]

Section 4.
"   b.  An end-user should be able to receive any prefix length up to /48
       simply by asking."

Can  this be defined in a way to make sure that new applications and devices will always work at end sites without a need for asking ISPs for extra address space? Otherwise, the end-user might not get what he/she asks for, without paying for the "higher grade" service. Can the definition impose up to /48 LAP when needed at end sites? For example, can an application request a home router to request an ISP for /48 prefix and, when requested, ISP must grant it?

Regards,
Dusan Mudric.

> -----Original Message-----
> From: v6ops <[e-mail]> On Behalf Of Lea Roberts
> Sent: Thursday, July 19, 2018 2:08 PM
> To: Brian E Carpenter <[e-mail]>; JORDI PALET
> MARTINEZ <jordi.palet=[e-mail]>
> Cc: [e-mail]; IPv6 Operations
> <[e-mail]>
> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt
> 
> hi Brian and Jordi -
> 
> excellent comments and I agree also.
> 
> thank you!!
> /Lea
> 
> On Thu, 19 Jul 2018, JORDI PALET MARTINEZ wrote:
> 
> > 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://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIDaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=-
> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=iEq1tUDbeQL4f3SLM
> f1-xihjJYT0KAAN_BWTl9-779c&e=
> >
> >
> >
> >
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.consulintel.es&d=DwIDaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3
> Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=-
> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=GMRLdItF8yKbUdE9
> NuXE-U48uk7OHNuEijym9jhE--s&e=
> > 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.
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIDaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=-
> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=iEq1tUDbeQL4f3SLM
> f1-xihjJYT0KAAN_BWTl9-779c&e=