[arin-ppml] [arin-announce] [Fwd: Policy Proposal 103: Change IPv6 Allocation Process]

Michael Sinatra michael at rancid.berkeley.edu
Tue Nov 10 01:08:07 EST 2009


On 11/09/09 13:08, Seth Mattinen wrote:
> Member Services wrote:
>> Q. Why allocate the /48's from a pool only for /48's, /32's from a /32
>> pool, etc.? Why not allocate from just one pool?
>>
>> A. If all assignments in a particular pool are /32 then any route in
>> the /32 pool which is longer than /32 is a traffic engineering (TE)
>> route. As a router operator you can filter and discard TE routes if
>> you find they give you insufficient benefit. The routes you filter
>> don't cost you any money; only the routes you keep carry a price tag.
>>
> 
> Hallelujah, I dislike TE with a passion.
> 
> Overall I like this policy. I agree that the utilization concept should
> be abandoned for IPv6 and there's nothing inherently wrong with classful
> addressing other than there simply wasn't enough space to go around
> under IPv4.

I have to say that this policy is kind of refreshing, in that it
attempts to do away with IPv4-style thinking.

In IPv4, we have to worry about conservation of IP addresses.

In IPv6, we should be worrying about conservation of IP address
*allocations/assignments*.  The policy recognizes that both allocations
(from ARIN) and assignments (from LIRs) can cause routing table bloat.

IPv6 allocation strategies have been unspokenly classful since their
inception.  ("You mean I have to give you a /56 on your home network
just because you need two subnets?  Or even a /48??")  It's time to call
a spade a spade and acknowledge that we really are going (sort of) back
to classful addressing.

And we need to come to terms with the fact that massive aggregation just
isn't a viable strategy for IPv6 adoption in today's internet.  Give
multihomed organizations the one prefix that they will have for the
lifetime of IPv6 and be done with it.

I'd definitely like to see more debate, but I think the AC should give a
close look to this proposal.

michael




More information about the ARIN-PPML mailing list