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

["Rajiv Asati (rajiva)" <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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://www.ietf.org/mailman/listinfo/v6ops