Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption")

[Owen DeLong <owen () delong com>]

Yes… This is a problem the ARIN board needs to fix post haste, but that’s not justification, that’s cost.

Owen

> On Oct 2, 2015, at 06:45 , Mike Hammett <nanog () ics-il net> wrote:
>
> I may be able to justify it to ARIN, but I can't make a quadrupling of ARIN's fees justifiable to me. 
>
>
>
>
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
>
>
>
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
>
>
> ----- Original Message -----
>
> From: "Mel Beckman" <mel () beckman org> 
> To: "Mike Hammett" <nanog () ics-il net> 
> Cc: "nanog group" <nanog () nanog org> 
> Sent: Friday, October 2, 2015 8:35:41 AM 
> Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption") 
>
>
> Every provider gets a /32, according to ARIN. 
>
>
> IPv6 - INITIAL ALLOCATIONS 
> Type of Resource Request Criteria to Receive Resource 
>       ISP Initial Allocation 
> /32 minimum allocation 
> (/36 upon request) 
> NRPM 6.5.1    
>
>    * Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries, or 
>    * Qualify for an IPv4 ISP allocation under current policy, or 
>    * Intend to immediately multi-home, or 
>    * Provide a reasonable technical justification, including a plan showing projected assignments for one, two, and 
> five year periods, with a minimum of 50 assignments within five years 
>
>
>       IPv6 Multiple Discrete Networks 
> /32 minimum allocation 
> (/36 upon request) 
> NRPM 6.11     
>
>    * be a single entity and not a consortium of smaller independent entities 
>
> -mel via cell 
>
> On Oct 2, 2015, at 4:15 AM, Mike Hammett < nanog () ics-il net > wrote: 
>
>
>
>
> Not all providers are large enough to justify a /32. 
>
>
>
>
> ----- 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
>
>
>
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
>
>
> ----- Original Message ----- 
>
> From: "Philip Dorr" < tagno25 () gmail com > 
> To: "Rob McEwen" < rob () invaluement com > 
> Cc: "nanog group" < nanog () nanog org > 
> Sent: Thursday, October 1, 2015 11:14:35 PM 
> Subject: Re: How to wish you hadn't forced ipv6 adoption (was "How to force rapid ipv6 adoption") 
>
> On Thu, Oct 1, 2015 at 10:58 PM, Rob McEwen < rob () invaluement com > wrote: 
>
> <blockquote>
> On 10/1/2015 11:44 PM, Mark Andrews wrote: 
>
>
>
> <blockquote>
>
> <blockquote>
>
>
> </blockquote>
>
> </blockquote>
>
> <blockquote>
>
> <blockquote>
> IPv6 really isn't much different to IPv4. You use sites /48's 
>
> </blockquote>
>
> </blockquote>
>
> <blockquote>
>
> <blockquote>
> rather than addresses /32's (which are effectively sites). ISP's 
>
> </blockquote>
>
> </blockquote>
>
> <blockquote>
>
> <blockquote>
> still need to justify their address space allocations to RIR's so 
>
> </blockquote>
>
> </blockquote>
>
> <blockquote>
>
> <blockquote>
> their isn't infinite numbers of sites that a spammer can get. 
>
> </blockquote>
>
> </blockquote>
>
> <blockquote>
>
>
> </blockquote>
>
> <blockquote>
>
>
> </blockquote>
>
> <blockquote>
> A /48 can be subdivided into 65K subnets. That is 65 *THOUSAND*... not the 
>
> </blockquote>
>
> <blockquote>
> 256 IPs that one gets with an IPv4 /24 block. So if a somewhat legit hoster 
>
> </blockquote>
>
> <blockquote>
> assigns various /64s to DIFFERENT customers of theirs... that is a lot of 
>
> </blockquote>
>
> <blockquote>
> collateral damage that would be caused by listing at the /48 level, should 
>
> </blockquote>
>
> <blockquote>
> just one customer be a bad-apple spammer, or just one legit customer have a 
>
> </blockquote>
>
> <blockquote>
> compromised system one day. 
>
> </blockquote>
>
> As a provider (ISP or Hosting), you should hand the customers at a 
> minimum a /56, if not a /48. The provider should have at a minimum a 
> /32. If the provider is only giving their customers a /64, then they 
> deserve all the pain they receive. 
>
>
> </blockquote>