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

[Paul McNary]

Owen

I agree 100% with your statement below!
Longer than a /48. That would eliminate any
concerns I have. /48's could be assigned to each POP
giving basic location information for any downstream.
That is similar to BCP of a /24 for IPv4. If a downstream
business request SWIP that we can accommodate.

Take care
Paul


On 7/20/2017 3:06 PM, Owen DeLong wrote:
> 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 
>> <mailto: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
>>
>>
>> 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
>>> And, to help clarify some confusion, per  6.5.5.3.1  
>>> (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).
>>> Unsubscribe or manage your mailing list subscription at:
>>> http://lists.arin.net/mailman/listinfo/arin-ppml
>>> Please contactinfo 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
>> Please contactinfo 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/de5e295e/attachment.htm>