[arin-ppml] Opposed to 2010-9 and 2010-12
In message <015201cb6bfd$97e9a200$c7bce600$@net>, "Tony Hain" writes:
> This entire thread is basically hot air swirling after more hot air......
> While more traffic is good, this noise is a waste of everyone's time.
> 1) The 6rd policy needs to be really simple and easy to get NOW.
> 2) Assuring it goes away at some point requires appropriate
> feedback to drive people away from it as soon as they can move.
> Satisfying both of those should be easy. Establish a policy that says anyone
> with IPv4 can get an IPv6 prefix between /16 & /24 as they see fit, then set
> a proportional fee schedule with a *substantial* escalation factor over
> You don't need sunset clauses in the policy, and you don't need to
> complicate things by obsessing about 'waste'. What you do need is a policy
> that enables deployment TODAY. For those that need 6rd because they didn't
> get their act together to enable a dual-stack infrastructure, there is a
> cost to that delay, and the cost continues to grow until they get past their
> legacy equipment.
> The hardest part of that approach is that the fee for a provider that is
> offering dual-stack /48 to each customer should be substantially less than a
> 6rd deployment offering /60. It is not ARIN's role to define end product
> offerings, so differentiating the fee schedule for 2 ISPs requesting a /28
> based on how they plan to use it is probably out of the question. That said,
> financial backpressure will be much more effective than any proscriptive
> language that makes it past ppml. We just need to make sure that there are
> no unintended consequences related to consumer network innovation due to big
> players opting for blocks that are too small.
I would suggest that ARIN allocate space per IPv4 /8 that address
space has been allocated from. That's a /32 per /8 that contains
allocation instead of a /24. For manual configuration you would
look at the first octet of your IPv4 address and pick the associated
6rd prefix. This is still very wasteful but no where near as
wasteful as handing out /24's.
For CMCS (Comcast Cable Communications) they would the have 10 blocks
of space and 10 6rd prefixes. Do you think Comcast's network
engineers can cope with 10 6rd prefixes? I sure do.
(NET-24-0-0-0-1) 18.104.22.168 - 22.214.171.124
(NET-24-16-0-0-1) 126.96.36.199 - 188.8.131.52
(NET-24-189-152-0-1) 184.108.40.206 - 220.127.116.11
(NET-24-228-96-0-1) 18.104.22.168 - 22.214.171.124
(NET-67-160-0-0-1) 126.96.36.199 - 188.8.131.52
(NET-67-85-60-0-1) 184.108.40.206 - 220.127.116.11
(NET-68-32-0-0-1) 18.104.22.168 - 22.214.171.124
(NET-68-80-0-0-1) 126.96.36.199 - 188.8.131.52
(NET-69-136-0-0-1) 184.108.40.206 - 220.127.116.11
(NET-69-240-0-0-1) 18.104.22.168 - 22.214.171.124
(NET-71-192-0-0-1) 126.96.36.199 - 188.8.131.52
(NET-71-224-0-0-1) 184.108.40.206 - 220.127.116.11
(NET-74-88-112-0-1) 18.104.22.168 - 22.214.171.124
(NET-74-88-96-0-1) 126.96.36.199 - 188.8.131.52
(NET-76-16-0-0-1) 184.108.40.206 - 220.127.116.11
(NET-76-96-0-0-1) 18.104.22.168 - 22.214.171.124
(NET-98-192-0-0-1) 126.96.36.199 - 188.8.131.52
(NET-107-0-0-0-1) 184.108.40.206 - 220.127.116.11
(NET-174-48-0-0-1) 18.104.22.168 - 22.214.171.124
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org