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

[Brian E Carpenter <[e-mail]>]

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=