[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6

[Owen DeLong]

This makes the best case I can imagine for why setting the boundary at /56 is a bad idea and we should not be considering anything longer than /48.

Owen

> On Jul 17, 2017, at 15:40 , Paul McNary <pmcnary at cameron.net> wrote:
> 
> Leif
> If I understand your question:
> 
> Originally /48 to anyone was the BCP for future efficiency.
> I can change my BCP to /56.
> /48 is my preference, however, which is the BGP boundary.
> Otherwise I have little issue with choice "b" if forced.
> 
> I would prefer to give my residential users a /48 for the future but a /56
> could work, just a pain. Again rDNS could be a problem.
> 
> Do AS's use ARIN reverse DNS for size smaller than /48?
> If rDNS will not work worldwide except with /48 advertising, 
> I think that should be the SWIP boundary.
> I know for a while some AS's required /32.
> I think that has finally changed.
> However ARIN's assignment web page indicates we should be 
> SWIP'ing /29's on IPv4 by policy or risk ARIN action.
> 
> Thank you
> Paul McNary
> pmcnary at cameron.net <mailto:pmcnary at cameron.net>
> 
> On 7/17/2017 5:09 PM, Leif Sawyer wrote:
>> Shepherd of the draft policy chiming in.
>>  
>> Thanks for the lively discussion, everybody.   There's certainly a lot to think about here.
>>  
>> Just as a reminder to folk, the current policy under question is located here:
>> https://www.arin.net/policy/nrpm.html#six551 <https://www.arin.net/policy/nrpm.html#six551>
>>  
>> And, to help clarify some confusion, per  6.5.5.3.1  (https://www.arin.net/policy/nrpm.html#six5531 <https://www.arin.net/policy/nrpm.html#six5531>)
>> residential customers "holding/64 and larger blocks"   may use censored data,  i.e.  "Private Customer/Residence"
>> in lieu of actual names and street addresses.
>>  
>> --
>>  
>> With that said,  I have a couple of questions to ask, based on potential rewrites that are brewing.
>>  
>> First:    Assuming a preference for /56  (based on PPML feedback)  for the moment,   which is the more
>> preferential rewrite of the opening sentence of 6.5.5.1?
>>  
>> a)      Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. 
>> 
>> 
>> b)      Each static IPv6 assignment containing a /55 or more addresses, or subdelegation of any size that will be individually announced, shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. 
>>  
>>  
>> Second:   Given your specific choice of A or B,  are you preferentially inclined to choose the provided bit-boundary, or "/48"
>>  
>> Third:  If none of these options are palatable, do you have a proposed approach?
>>  
>>  
>>  
>> Thanks,
>>  
>>   Leif Sawyer
>> Advisory Council
>>  
>> 
>> 
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
>> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net <mailto:ARIN-PPML at arin.net>).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml <http://lists.arin.net/mailman/listinfo/arin-ppml>
> Please contact info at arin.net <mailto:info at arin.net> if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170720/797fe127/attachment.htm>