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

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

Hi Jordi,

draft-ietf-v6ops-ipv6rtr-reqs, section 5.2, defines:
"routers designed to run IPv6 should
   support the following addressing conventions:
   o  The default prefix length on any interface other than a loopback
      should be a /64"

May be a new bullet can be added to make sure a router asking for /48 or /56 prefix will get it. Otherwise, it will not be possible to do SLAAC subnetting. Current standards don't allow SLAAC for prefixes longer than /64. Or, if the default prefix length is /48 or /56, the issue of not getting a shorter prefix from ISPs will be solved. Personally, I don't like wasting the address space. You stated the same in the Introduction, bullet 3. From that perspective, it would be better to start small and be able to grow, on as needed bases, without being blocked by ISPs. So, till we have a standard for SLAACs with prefixes longer than /64, it should be always possible to get /48 or /56 prefix, when needed, without any limitations. At the moment I don't see how that can be enforced without settings some defaults to /48 or /56 (not popular approach).

Regards,
Dusan.

> -----Original Message-----
> From: JORDI PALET MARTINEZ <[e-mail]>
> Sent: Wednesday, July 3, 2019 7:03 AM
> To: Brian E Carpenter <[e-mail]>; 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
> 
> Hi all,
> 
> I've been too busy to tackle a new version of this document, but now
> working on it.
> 
> My recall on this, please correct me if I'm wrong (Brian, Mudric), is that you
> believe that:
> 
> 1) We should define end-site in the document?
> 
> 2) End-sites must be able to request a longer prefix if needed and the ISP
> must grant it?
> 
> Anything I may be missing?
> 
> Regards,
> Jordi
> @jordipalet
> 
> 
> 
> El 28/8/18 6:27, "v6ops en nombre de Brian E Carpenter" <v6ops-
> [e-mail] en nombre de [e-mail]> escribió:
> 
>     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=
> 
>     _______________________________________________
>     v6ops mailing list
>     [e-mail]
>     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIFaQ&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=rzAc
> KPhTqXxGVQd-
> 3DoZlMutejQ5CWoImJNuCub7j0s&s=eUE0LS0GCy7rETlpmjDcvzkZeVTV4tBW
> NnFai4MeJT4&e=
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__www.theipv6company.com&d=DwIFaQ&c=BFpWQw8bsuKpl1SgiZH64Q
> &r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=rzAcKPhTqXxG
> VQd-
> 3DoZlMutejQ5CWoImJNuCub7j0s&s=Y1UJwTVJV8MiA6O7TnkI_7TJJ9SZJX6iX
> GCG8fkAG_0&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.
> 
>