[ppml] IPv6 Assignment Guidelines, Straw Man #2

[Leo Bicknell]

In a message written on Fri, Aug 17, 2007 at 07:33:47PM +0100, Jeroen Massar wrote:
> The /56 is perfect for residential sites aka Joe Average HomeUser.
> The /48 should IMHO be provided to 'businesses' and other such
> organizations.

In a message written on Fri, Aug 17, 2007 at 05:24:01PM -0400, Steve Bertrand wrote:
> > I can live with a two-tiered scheme in which all consumer
> > homes have a /56 and all non-consumer sites have a /48 because sites
> > rarely will switch categories.
> 
> I support the previous statement. Clean and easy.

In a message written on Sat, Aug 18, 2007 at 03:10:07PM -0700, David Conrad wrote:
> Given the IETF mandate for /64s for subnets, number of PCs is  
> irrelevant.  I don't have a strong opinion about /48s to every  
> customer as I can see arguments on both sides.  It would be easier  
> for everybody and (assuming RIR to ISP allocations become more  
> rational) I don't have concerns about running out of /48s.  However,  
> pragmatically speaking, I also don't see home users ever subnetting  
> to a significant level, so it doesn't make a lot of sense to me to  
> throw a potential of 64K subnets at them.  As such the "/56 for home  
> users - /48 for enterperise" split seems a reasonable compromise.

In a message written on Fri, Aug 17, 2007 at 09:12:34PM -0700, Scott Leibrand wrote:
> As expressed by others, I oppose this policy proposal as written, 
> because I believe current guidelines are sufficient.  ISPs should be 
> free to delegate a /48 or /56 to users, as appropriate for their 
> situation.  I believe that any justification, including convenience, 
> should be sufficient to allow allocation of a /48 instead of a smaller 
> subnet.

In a message written on Fri, Aug 17, 2007 at 11:35:56PM -0500, Stephen Sprunk wrote:
> Agreed.  Current policy allows LIRs to assign either, and there should be no 
> penalty for LIRs that choose to use either /56s or /48s.  There is no 
> shortage of anything but routing slots in IPv6.

In a message written on Sat, Aug 18, 2007 at 09:41:40AM -1000, Antonio Querubin wrote:
> This adds unnecessary granularity to the assignment guidelines as well as 
> perpetuates administrative complexity for LIRs.  The /56 recommendation 
> for 'small' sites was a welcome addition when it came but adding 2 more 
> levels doesn't really add much value.  Let's keep it simple.

In a message written on Mon, Aug 20, 2007 at 11:15:39AM +0100, michael.dillon at bt.com wrote:
> If clearer guidance is needed, then we could simply add language such
> as:
> 
> /56 for small sites such as consumer subscribers and private homes which
> are expected to need only a few subnets over the next 5 years.

The feedback is pretty clear, and so I'd like to offer up a straw
man for a potentially better proposal.  It's quite clear people
want a simple rule, and want a /48 to be allowed.

For reference, the existing policy is at
http://www.arin.net/policy/nrpm.html#six54

Looking at the comments and considering the section following as
well (6.5.4.2) I've combined them both into a single policy.  While
I find it unlikely ISP's will have customers wanting more than a
/48 of PA space, the current policy states that such cases will be
reviewed by the RIR without giving any criteria for how they should
be reviewed, leaving both staff and the ISP with no guidance.  Should
such a larger block be needed it seemed logical to me to apply the
same criteria as if the End Site came to ARIN for their own PI or
PA block.

]    7. Policy statement:
] 
] Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1
] with the following text:
] 
] LIR's may assign up to a /48 to an End Site.  End Sites requiring
] more address space than a /48 may be assigned a larger block provided
] the utilization inside that block meets an HD Ratio of 0.94.
] 
]    8. Rationale:
] 
] The existing section 6.5.4.1 does not provide clear guidance on how
] large of a prefix to allocate to a site.  This makes it difficult
] for LIR's to know they are in compliance with the rules, and makes
] it harder for ARIN staff to evaluate requests per the communities
] wishes.

Would this straw man proposal get more support?  Does it provide
clearer guidance?

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070820/b8b7c157/attachment.sig>