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

From: Ron Bonica <[email-masked]>
Date: Mon, 27 Aug 2018 14:20:44 +0000

Folks,

Each week between now and IETF 103, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-palet-v6ops-rfc6177-bis.

                                      Fred and Ron

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Aug 2018 17:11:23 +1200

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

---

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

>    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 <[email-masked]> On Behalf Of Brian E Carpenter
> Sent: Tuesday, August 28, 2018 1:11 AM
> To: Ron Bonica <[email-masked]>; [email-masked]
> Subject: Re: [v6ops] draft-palet-v6ops-rfc6177-bis
> 
> Hi,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> 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=

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 28 Aug 2018 22:02:32 +0000

This draft should provide a definition for the end-site. Is it a connectivity device such as a home GW/router or consumption device such as a mobile tablet or ...? Answer is all of the above. 

This draft should also explicitly cover cellular/mobile devices that currently get limited to /64, since they could also qualify as end-site. 

Cheers,
Rajiv Asati

> On Aug 28, 2018, at 1:11 AM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> https://www.ietf.org/mailman/listinfo/v6ops