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

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Mon, 27 Aug 2018 18:23:28 +0000

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 <[email-masked]> On Behalf Of Lea Roberts
> Sent: Thursday, July 19, 2018 2:08 PM
> To: Brian E Carpenter <[email-masked]>; JORDI PALET
> MARTINEZ <jordi.palet=[email-masked]>
> Cc: [email-masked]; IPv6 Operations
> <[email-masked]>
> 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 <[email-masked]> en nombre de Brian E Carpenter
> <[email-masked]>
> >
> > Organizaci?n: University of Auckland
> >
> > Fecha: domingo, 8 de julio de 2018, 17:43
> >
> > Para: <[email-masked]>, IPv6 Operations
> <[email-masked]>
> >
> > 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
> >
> >    [email-masked]
> >
> >    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
> > [email-masked]
> > 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=

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Aug 2018 16:26:58 +1200

> 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…

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

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 28 Aug 2018 15:06:49 +0000

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.

> From: Brian E Carpenter <[email-masked]>
> Sent: Tuesday, August 28, 2018 12:27 AM
> To: Mudric, Dusan (Dusan) <[email-masked]>; Lea Roberts
> <[email-masked]>; JORDI PALET MARTINEZ
> <jordi.palet=[email-masked]>
> > 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?
>

---

From: David Farmer <[email-masked]>
Date: Tue, 28 Aug 2018 12:56:38 -0500

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) <[email-masked]>
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.
>
> > >>> For the next version, I've reduced 50% the length of the 1st
> paragraph.
> > 3rd
> > >>>           may be some applications where assigning only a single
> address
> > may
> > >> be
> > >>>
> > >>>    >    already significantly more address space compared with
> today's
> > IPv4
> > >>>
> > >>>    >    It should be noted that similar arguments apply to the
> management
> > of
> > >>>
> > >>>    >    The authors of this document will like to acknowledge the
> authors
> > of
> > >>>
> > >>>    >>    This document originated from the IETF IPv6 directorate,
> with
> > much
> > >>>
> > >> confidential. The information is intended to be for the exclusive use
> of
> > the
> > >> partially, including attached files, is strictly prohibited and will
> be
> > considered a
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Tue, 28 Aug 2018 18:58:44 +0000

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

   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 <[email-masked]>
Sent: Tuesday, August 28, 2018 1:57 PM
To: Mudric, Dusan (Dusan) <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; Lea Roberts <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>; [email-masked]; IPv6 Operations <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Brian,

Regards,
Dusan.

> From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
> To: Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>>; Lea Roberts
> <[email-masked]<mailto:[email-masked]>>; JORDI PALET MARTINEZ
> <jordi.palet=[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; IPv6 Operations
> <[email-masked]<mailto:[email-masked]>>
> >> From: v6ops <[email-masked]<mailto:[email-masked]>> On Behalf Of Lea Roberts
> >> To: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; JORDI PALET
> >> MARTINEZ <jordi.palet=[email-masked]<mailto:[email-masked]>>
> >> Cc: [email-masked]<mailto:[email-masked]>; IPv6 Operations
> >> <[email-masked]<mailto:[email-masked]>>
> >>> De: v6ops <[email-masked]<mailto:[email-masked]>> en nombre de Brian E Carpenter
> >> <[email-masked]<mailto:[email-masked]>>
> >>>
> >>> Para: <[email-masked]<mailto:[email-masked]>>, IPv6 Operations
> >> <[email-masked]<mailto:[email-masked]>>
> >>>
> >>>    [email-masked]<mailto:[email-masked]>
> >>>
> 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
> >>> [email-masked]<mailto:[email-masked]>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
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:[email-masked]<mailto:[email-masked]>

---

From: Fred Baker <[email-masked]>
Date: Tue, 28 Aug 2018 15:32:55 -0700

> 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 g…

My understanding, no hats and potentially incorrect, is that any ISP I know of will respond to a DHCPv6 IA_PD with a prefix at least as large as requested, up to /48.

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: David Farmer <[email-masked]>
Date: Tue, 28 Aug 2018 19:04:01 -0500

On Tue, Aug 28, 2018 at 5:32 PM, Fred Baker <[email-masked]>
wrote:

> > 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.
>
> My understanding, no hats and potentially incorrect, is that any ISP I
> know of will respond to a DHCPv6 IA_PD with a prefix at least as large as
> requested, up to /48.
>

Fred, the statement you are making I believe is true for many or most ISP's
providing IPv6 today, but not all. However, way too many ISPs are still not
yet providing IPv6. Further, many of the early IPv6 capable CPE or terminal
devices only ask for a /64 and can't be told otherwise. So when I look at
the current state of things, I'm both optimistic and pessimistic at the
same time.

Dusan, it's not as simple as the ISP are not providing /48s, as Fred says
many, if not most, doing IPv6 are, a big part of the issue is too many CPEs
only ask for a /64, and don't allow a different option. But from the
perspective of a normal end-user they are being limited, and who is at
fault is complicated.  There is plenty of blame to go around for everyone,
the ISPs, the CPE manufacturers, the IETF, and even a little for the
end-users themselves.

RFC7084;
   WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
           router the size of the prefix it requires.  If so, it MUST
           ask for a prefix large enough to assign one /64 for each of
           its interfaces, rounded up to the nearest nibble, and SHOULD
           be configurable to ask for more.

I think at least part of the problem is a common one, too many inexpensive
CPE do not implement optional features. Because both ISP's and end-users
have economic incentives to use inexpensive CPE, this creates an incentive
for CPE manufacturers to make inexpensive CPE do not implement optional
features.  Around and around we go.

It is a complicated systemic failure mode we have going here.

Maybe we need "MUST be configurable to ask for more.", which is the IETF's
fault!

Thanks.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 29 Aug 2018 12:11:34 +0000

> My understanding, no hats and potentially incorrect, is that any ISP I know of
> will respond to a DHCPv6 IA_PD with a prefix at least as large as requested,
> up to /48.

I don't think this is correct. Of course, any provider using 6rd won't respond to DHCPv6 at all. I'm aware of a lot of 6rd out there.
Wireless LTE providers don't tend to support DHCPv6, either. The /64 advertised by the RA in an LTE environment is all the LTE UE will get. That includes the case where the LTE UE is supporting a fixed wireless installation.
For ISPs that support DHCPv6, it may or may not be the case. I've heard several say they do, but I'm not aware of a survey of all ISPs that would tell me how prevalent it is.

BTW, I disagree with the abstract's statement that the "policy should reflect that assignment of a single subnet is never appropriate." I do not believe this takes into consideration the fact that it would be tremendously expensive for some ISPs to replace their current equipment when those current equipment vendors are being slow about supporting certain features. Cost is always an appropriate consideration. It also does not take into account CE routers that only request a single /64. I think it's inappropriate for IETF to be trying to dictate what is and isn't "appropriate". Recommending a best current practice is fine. But that's not the same as saying something is "never appropriate".

Barbara

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 29 Aug 2018 15:01:47 +0000

Hi David,

>Maybe we need "MUST be configurable to ask for more.", which is the IETF's fault!

I believe this the right approach. We cannot have IPv6 network where device and application vendors need first to go around the world and negotiate with all ISPs to provide /48, before they start building new products that require /48. The network MUST be flexible, by default.

Thanks,
Dusan.

From: David Farmer <[email-masked]>
Sent: Tuesday, August 28, 2018 8:04 PM
To: Fred Baker <[email-masked]>
Cc: Mudric, Dusan (Dusan) <[email-masked]>; [email-masked]; IPv6 Operations <[email-masked]>; JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt

On Tue, Aug 28, 2018 at 5:32 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:

Fred, the statement you are making I believe is true for many or most ISP's providing IPv6 today, but not all. However, way too many ISPs are still not yet providing IPv6. Further, many of the early IPv6 capable CPE or terminal devices only ask for a /64 and can't be told otherwise. So when I look at the current state of things, I'm both optimistic and pessimistic at the same time.
Dusan, it's not as simple as the ISP are not providing /48s, as Fred says many, if not most, doing IPv6 are, a big part of the issue is too many CPEs only ask for a /64, and don't allow a different option. But from the perspective of a normal end-user they are being limited, and who is at fault is complicated.  There is plenty of blame to go around for everyone, the ISPs, the CPE manufacturers, the IETF, and even a little for the end-users themselves.

RFC7084;

I think at least part of the problem is a common one, too many inexpensive CPE do not implement optional features. Because both ISP's and end-users have economic incentives to use inexpensive CPE, this creates an incentive for CPE manufacturers to make inexpensive CPE do not implement optional features.  Around and around we go.

Maybe we need "MUST be configurable to ask for more.", which is the IETF's fault!

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2018 10:29:15 +1200

Barbara,
On 2018-08-30 00:11, STARK, BARBARA H wrote:
> BTW, I disagree with the abstract's statement that the "policy should reflect that assignment of a single subnet is never appropriate." I do not believe this takes into consideration the fact that it would be tremendously expensive for some ISPs to replace their current equipment when those current equipment vendors are being slow about supporting certain features. Cost is always an appropriate consideration. 

I disagree. Yes, of course cost is always a consideration, but that doesn't
make a lower case "should" inappropriate.

> It also does not take into account CE routers that only request a single /64. 

That's irrelevant. The customer might have bought such a router, but the
next customer along might have bought a full homenet-supporting CE.

> I think it's inappropriate for IETF to be trying to dictate what is and isn't "appropriate". Recommending a best current practice is fine. But that's not the same as saying something is "never appropriate".

Let's say "never recommended" then.

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Aug 2018 11:34:05 -0700

> On Aug 29, 2018, at 15:29 , Brian E Carpenter <[email-masked]> wrote:
> 
> Barbara,

I can guarantee you that it’s false in a big way (unfortunately). Comcast’s victims (or customers, depending on your perspective), for example, cannot get a /48 no matter what.

IIRC, they will allow a business customer to get up to a /56 and residential customers are limited to a /60.

I believe they have or are in the process of resolving issues they previously had where if you requested larger than they would allow, they simply didn’t give you anything at all… Not even a DENIED response.

I wish they would fix this. When I discussed the matter last with JJMB, his response was “we don’t feel that’s reasonable… If we were to do that, we’d have to ask ARIN for a /12.”

My response was “duh!! You guys probably should have a /12. It’s permitted under existing policy. So what’s the issue?” He simply shook his head and walked away.

I’m guessing this will eventually be like Verizon’s resistance to routing /48s. The v4think will eventually get sorted out, but likely persist for some time first.

> make a lower case "should" inappropriate.

I feel that there are actually cases where single-subnet assignment is perfectly reasonable. They are limited and should be determined by the customer, not the service provider, IMHO, but I also believe that all of these decisions really are outside the purview of the IETF. The IETF should be mandating that the standards for the equipment and the protocol enable the service provider and the customer to handle multiple subnets. Specifying operational behavior beyond that which is necessary to enable the needed functionality is scope creep that we should try to avoid.

> next customer along might have bought a full homenet-supporting CE.

That’s irrelevant. The protocol should enable the service provider and customer to support either environment. We can make operational best practice recommendations to offer more than one subnet, but beyond that, we’re looking at the IETF putting its nose where it doesn’t belong, IMHO.

> Let's say "never recommended" then.

Meh… I could live with that.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 31 Aug 2018 08:30:40 +1200

Owen,
On 2018-08-31 06:34, Owen DeLong wrote:
> That’s irrelevant. The protocol should enable the service provider and customer to support either environment.

That's what I meant. If some customers only request a /64, and others request
a /48 (because they happened to buy different CE boxes), either should work.

> We can make operational best practice recommendations to offer more than one subnet, but beyond that, we’re looking at the IETF putting its nose where it doesn’t belong, IMHO.

I think the IETF can say "/56 is inadequate for some customers. /48 is adequate
for most customers." Of course, we can't dictate terms to ISPs, and neither
can the RIRs.

> Meh… I could live with that.

OK then ;-)

Regards
   Brian