[ppml] IPv6 PI Assignment Survey

[Owen DeLong]

Glad to see your comments, Marla.  I make an attempt at addressing
your feedback inline.  Initially, I was just going to send this to
you, but, I realized similar confusion might affect other PPML
subscribers, so, I sent this to the list.


--On April 7, 2006 2:09:02 PM -0700 "Azinger, Marla"
<marla_azinger at eli.net> wrote:

> Thank you for doing this survey set up.  Its a great way to get feed back
> and clarify what the issues are.
> 
> I did the survey, but I have a few reservations about the question asked.
> I put my concerns below each question of the survey I have "input" on.
> 
># 5. I support the requirement that an organization must be multihomed to
># qualify for an IPv6 PI assignment. 
> 
> "My point of hesitation on this is that how can we require this when we
> dont have a multihome solution.  Yes, I know you can do it just like v4
> but policy doesnt support that.  So I say "agree" if we can change policy
> to support current technical abilities".
> 
The intent behind this question is to evaluate what people think we
should change the policy to.  In other words, if you support having
a PI IPv6 policy, should it include a multihoming requirement.
Essentially, we're asking "Should we change policy to support current
technical requirements."  As such, I hope you answered yes.

># 8. I support the requirement to assign IPv6 PI address space from a
># seperate super block. 
>  
> "My point of hesitation here is the whole reason for seperating the super
> block.  If I interpret this correctly, we are doing this so that PI
> assignments are allowed to deaggregate within the super block.  I dont
> see this as a fair practice due to the fact with current policy anyone
> else outside of this PI superblock that uses the regular v6 block arnt
> allowed to deagregate thus multihome.  So this rule would only allow PI
> assignements the ability to deagregate and multihome.
> 
Actually, the purpose for this is to allow providers who don't want
to carry these PI routes to filter them without affecting ISP-based
routes.  Further, since PI allocations might be longer prefixes (/48)
than ISP allocations (/32), it might be desirable to have a unique
block to support different filter sets.  Theoretically, the purpose
behind having ISPs get a /32 is to prevent the need for them to
deaggregate.  The purpose behind having PI is to allow organizations
to multihome without needing PA blocks.  Obviously, most organizations
don't need an entire ISP worth of network space.  A deaggregated LIR
should be 2 (or more) LIRs.

> 13. I support the requirement to specify a reserved block in an IPv6 PI
> address policy. 
> 
> "sorry, havnt followed the chain of emails enough to know if you are
> talking about ARIN publicly announcing what Super block is to be reserved
> for this use or when an ARIN Member requesting the next contiguous block
> to be reserved for futer request"
> 
Basically whether we should do sparse allocation in the PI range so that
an organization which receives a /48 and later needs a /47 could simply
be assigned the next consecutive /48 such that it aggregated into a /47.
Further, how sparse should this be?  /48, /47.../44?...

> 
> 15. I support the assignment of additional /48 subnets to organizations
> with multiple assigned ASNs. 
> 
> "The way policy is right now I agree with this.  But would it possibly be
> better to reduce the size to a /44 and change policy?"
> 
/44 would be increasing the size while reducing the prefix length.  However,
the question here is more about whether the number of ASNs you possess
should be counted as a factor in the amount of address space you can
justify.

> 16. I support the assignment of multiple /48s per organization. 
> 
> "Yes, given there is technical need demanding this or usage justified"
> 
Yes... Those two factors are common to both policies provisions for
additional space and I don't think anyone has suggested that additional
/48s should be provided without justification.

Hope that clarifies things for you.  Just in the interest of full
disclosure, I didn't write the survey, but, I did write one of the
two policy proposals that the survey addresses.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20060407/9b498913/attachment.sig>