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

Hi all,

I've not responded before to all those comments, but I think in general the discussion was very useful and we are about to finish a new version, which we will publish in a few hours.

Thanks to all the contributors!

Regards,
Jordi

-----Mensaje original-----
De: v6ops <v6ops-bounces@ietf.org> en nombre de Brian E Carpenter <brian.e.carpenter@gmail.com>
Fecha: jueves, 30 de agosto de 2018, 22:31
Para: Owen DeLong <owen@delong.com>
CC: IPv6 Operations <v6ops@ietf.org>, "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>
Asunto: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt

    Owen,
    On 2018-08-31 06:34, Owen DeLong wrote:
    > 
    > 
    >> On Aug 29, 2018, at 15:29 , Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >>
    >> Barbara,
    >> On 2018-08-30 00:11, STARK, BARBARA H wrote:
    >>>> 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.
    > 
    > 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.
    > 
    >>> 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.
    > 
    > 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.
    > 
    >>> 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.
    > 
    > 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.

    >>> 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.
    > 
    > Meh… I could live with that.

    OK then ;-)

    Regards
       Brian

    > 
    > Owen
    > 
    > 

    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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.