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

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

Hi Brian,

There must a way to define how prefixes are assigned to always allow /48, if needed. If not in rfc6177-bis than in another RFC. We have already one limitation for SLAAC that makes sure every home gets at least one /64. We can add another one, in another RFC, to make sure /48 is given on a demand. That will insure future flexibility in any network and make the prefix assignment non-political process. 

Regards,
Dusan.

> -----Original Message-----
> From: Brian E Carpenter <[e-mail]>
> Sent: Tuesday, August 28, 2018 12:27 AM
> To: Mudric, Dusan (Dusan) <[e-mail]>; Lea Roberts
> <[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
> 
> On 2018-08-28 06:23, Mudric, Dusan (Dusan) wrote:
> > 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?
> 
> Unfortunately we can never say "must" in this context. What ISPs will
> provide
> for what fee is well outside the IETF's competence. As observed on another
> thread, applications need to be agile, even if they work better if such a
> request was granted.
> 
> I'd say that once this update is done, it may be time to revisit
> RFC4084.
> 
> Regards
>     Brian
> 
> >
> > 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=