Re: [v6ops] draft-palet-v6ops-rfc6177-bis

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

>    Current RIR policies still allow using /48, but leave the decision in the
>    hands of the ISP

Decision like this should not be in anybody's hands. /48 should be given automatically, when needed.

Dusan

> -----Original Message-----
> From: v6ops <[e-mail]> On Behalf Of Brian E Carpenter
> Sent: Tuesday, August 28, 2018 1:11 AM
> To: Ron Bonica <[e-mail]>; [e-mail]
> Subject: Re: [v6ops] draft-palet-v6ops-rfc6177-bis
> 
> Hi,
> 
> I fully support this draft. Here are a few (minor) wording issues
> and some nits.
> 
> Issues:
> -------
> >    [RFC3177] called for a default end-site IPv6 assignment size of /48.
> >    Subsequently, the Regional Internet Registries (RIRs) developed and
> >    adopted IPv6 address assignment and allocation policies consistent
> >    with those recommendations, and it triggered the development of
> >    [RFC6177].  However, some of the RIRs, have later on updated those
> >    policies, which still allow using /48, but leave the decision in the
> >    hands of the ISP, or even, in some cases, encourage the assignment of
> >    smaller (e.g., /56) blocks to residential end-sites, while keeping
> >    /48 for business.
> 
> I don't think that is accurate. Actually there was push-back *from*
> the RIRs against the wording of 3177, because some ISPs did not wish
> to be consistent with it. Here's another version:
> 
>    [RFC3177] called for a default end-site IPv6 assignment size of /48.
>    Subsequently, the Regional Internet Registries (RIRs) developed and
>    adopted IPv6 address assignment and allocation policies consistent
>    with ISP practices, and this triggered the development of [RFC6177].
>    Current RIR policies still allow using /48, but leave the decision in the
>    hands of the ISP, or even, in some cases, endorse the assignment of
>    smaller (e.g., /56) blocks to residential end-sites, while keeping
>    /48 for business.
> 
> >    This raises the question of a possible misinterpretation of [RFC6177]
> >    by at least 1/3rd of the operational community and consequently, the
> >    need to revisit it.
> 
> No, I don't think there's any misinterpretation. I think it's quite
> clear (as in my previous comment) that this is exactly why the ISP
> community pushed for RFC6177. I think we should phrase this a bit
> differently.
> 
>    This raises the question of over-zealous interpretation of [RFC6177]
>    by at least one third of the ISP community and consequently, the
>    need to revisit it.
> 
> >    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 certainty that even home sites
> >    will grow to support multiple subnets going forward.  Hence, it is
> >    strongly intended that even home sites be given a big number of
> >    subnets worth of space, by default.  Hence, this document still
> >    recommends giving home sites significantly many more than a single
> >    /64.
> 
> I think a reference to RFC7368 and RFC7788 would be useful here, to make
> it clear that this is not guesswork. (Note that HNCP is mentioned later,
> so there is a little repetition in the argument.)
> 
> Nits:
> -----
> 
> > Abstract
> >
> >   The Regional Internet Registries (RIRs) policies, have different
> Delete the comma
> 
> >   requires an ever-increasing availability of subnets at the end-site
> >   and so, policy should reflect that assignment of a single subnet is
> 
> NEW
>    requires an ever-increasing availability of subnets at the end-site,
>    so policy should reflect that the assignment of a single subnet is
> 
> I see a number of other minor syntax and punctuation nits in the
> text, but I'm afraid I'm going to leave those for the copy-editor.
> 
> Regards,
>      Brian
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwICAg&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Yd3D
> j3oVG2HTAJSudmciO1QwxdBm5v8tty3i7nRVEE8&s=MyBUglnUbBkNpooKN-
> YKnbJrsKVzg92HOWY-ZK_4RMU&e=