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

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

Hi Brian and David,

In this document there is already word ‘must’ related to the prefix length:

https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-01#section-2

   Longest Acceptable Prefix (LAP,

   [I-D.carpenter-6man-lap<https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-01#ref-I-D.carpenter-6man-lap>]), whose length is locally determined, e.g.,

   a site or link that uses SLAAC has a LAP of /64 and will not work

   with a longer one.



   SLAAC, and consequently, the LAP is mandatorily a /64.  Future

   technologies, may have a different LAP, which must be used

   accordingly.


Based the analysis in section 3<https://tools.ietf.org/html/draft-palet-v6ops-rfc6177-bis-01#section-3>.  On /48 Assignments to End-Sites, /48 LAP will be required in a near future. That means the wording of the sentence above can be changed to:


   SLAAC, and consequently, the LAP is mandatorily a /64.  Future

   technologies, may have a different LAP, which must be assigned

   when needed (or requested).

otherwise, these technologies will not work and, most likely, won’t be developed because their deployment will be impaired by ISPs LAP assignment.

Regards,
Dusan.

From: David Farmer <[e-mail]>
Sent: Tuesday, August 28, 2018 1:57 PM
To: Mudric, Dusan (Dusan) <[e-mail]>
Cc: Brian E Carpenter <[e-mail]>; Lea Roberts <[e-mail]>; JORDI PALET MARTINEZ <jordi.palet=[e-mail]>; [e-mail]; IPv6 Operations <[e-mail]>
Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt

We had such an RFC it was RFC3177, it wasn't very effective, many disagreed with it and it was ignored. We can say that /48s MUST be given out on request, but there is nothing to enforce that. You have to remember RFCs are voluntary, there is no Internet police. If you think that the IETF can force any network to do anything you misunderstand the system we have. Networks comply because they agree and see an advantage.

However, you can always get IPv6 addresses, even a /48, you might have to go to a different ISP, or an RIR yourself and you may have to route them yourself, which most people are either incapable or unwilling to do.

You might be able to get government regulators to enforce something like that, but be very careful what you ask for. And at least the US that doesn't seem to be going in that kind of regulatory direction.

I agree with Brian's suggestions in a different email, we need to make the case why /48 makes sense and is in an ISP's and their customer's interest. Not dictate a magic number to them.  Homenet is a big part of that, but I'm not sure by itself it's enough.

In most cases, especially when Homenet is not in use /56 seems like plenty of address space for the typical home, even /60 will work in many cases. The message we need to make clear is a single /64 is not good enough.

Thanks.

On Tue, Aug 28, 2018 at 10:06 AM, Mudric, Dusan (Dusan) <[e-mail]<mailto:[e-mail]>> wrote:
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]<mailto:[e-mail]>>
> Sent: Tuesday, August 28, 2018 12:27 AM
> To: Mudric, Dusan (Dusan) <[e-mail]<mailto:[e-mail]>>; Lea Roberts
> <[e-mail]<mailto:[e-mail]>>; JORDI PALET MARTINEZ
> <jordi.palet=[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; IPv6 Operations
> <[e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Lea Roberts
> >> Sent: Thursday, July 19, 2018 2:08 PM
> >> To: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>; JORDI PALET
> >> MARTINEZ <jordi.palet=[e-mail]<mailto:[e-mail]>>
> >> Cc: [e-mail]<mailto:[e-mail]>; IPv6 Operations
> >> <[e-mail]<mailto:[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]<mailto:[e-mail]>> en nombre de Brian E Carpenter
> >> <[e-mail]<mailto:[e-mail]>>
> >>>
> >>> Organizaci?n: University of Auckland
> >>>
> >>> Fecha: domingo, 8 de julio de 2018, 17:43
> >>>
> >>> Para: <[e-mail]<mailto:[e-mail]>>, IPv6 Operations
> >> <[e-mail]<mailto:[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]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=http-3A__3A-5F-5Fwww.consulintel.es&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=MYG8B_mv9hNzzuMtggTwVtpReOXR5DAe3UAZqYARDCk&s=bLZLQx28kpD7wvgAHJDCUDFXXlfaJhFSIRqOYCXfsVI&e=>&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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_v6ops&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=MYG8B_mv9hNzzuMtggTwVtpReOXR5DAe3UAZqYARDCk&s=N8tgHpueGlp2062zgk2CGg2VlInrB5wex8W43-DHcxI&e=>



--
===============================================
David Farmer               Email:[e-mail]<mailto:[e-mail]>
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================