[ppml] Policy Proposal: IPv6 Assignment Size Reduction

[Brian Dickson]

David Williamson wrote:
> On Mon, Oct 22, 2007 at 11:23:21AM -0400, Member Services wrote:
>   
>> ARIN received the following policy proposal. In accordance with the ARIN
>> Internet Resource Policy Evaluation Process, the proposal is being
>> posted to the ARIN Public Policy Mailing List (PPML) and being placed on
>> ARIN's website.
>>
>> Policy Proposal Name: IPv6 Assignment Size Reduction
>>     
>
> I am entirely against this proposal.
>
> As others have noted, this flies in the face of existing IETF standards
> and recommendations.  The vast majority of existing LLA implementations
> expect the /64 boundary to be enforced, and EUI-48 isn't generally
> implemented, while EUI-64 is.  (I'll also note that DHCP6 is still
> primitive, to my mild annoyance.)
>   
Neither this proposal, nor the proposed IETF change, in any way impacts 
use of EUI-64 for Link Local
addressing.

And, the IETF RFCs are *very* specific about not tying any other 
addressing implementations to LLA.
In particular, short-cuts on Interface Identifiers are officially 
scorned, and DAD specifically identifies that
Link Local is not a good enough check. You always have to do DAD - 
because topologies may have
changed.

> Let me expand on that.  End-sites and their efficiency are essentially
> irrelevant to the overall numbering and routing scheme in v6.  Again,
> hosts just don't matter, and all that counts for anything is the number
> of subnets.
>   
No, there are three things that matter, if you are the ISP giving out 
the subnets:
- the number of subnets
- the size of the subnets
- the ability to allocate subnets in a manner that permits internal 
aggregation

It's all relative. If you have a big PA block, then only the *relative* 
size of the end-site assignments
matters. But, it *does* matter, at least, that the relationship between 
PA and end-site size, is
a difference of enough bits to aggregate.

If you have a /12, you would be happy giving out /32's.
But, if you had a /28, you would not be so happy giving out /32's.
If you had a /28, you would be happy giving out /48's.
But if you had a /44, you would not be happy giving out /48's.
(I think you can spot the trend here.)

> We need to stop thinking about how many hosts we
> can squeeze into a network,
Hosts/network is irrelevant. If that was the issue, I would not have 
proposed use of EUI-48 for auto-configuration.
I would have recommended getting rid of auto-configuration.

I think auto-configuration has definite uses.
I do not thing presuming everyone will use it is a good way to set policy.
And I do not think universally using EUI-64 for auto-configuration is 
helpful - which is why I am working on the IETF end of things as well.

> If we collectively get out of v4 mindset, we can do some seriously
> creative things in v6. 
This is not an IPv4 mindset. It is a *CIDR* mindset, something which on 
the routing side has been very helpful.
Not just on the address assignment side of things, but on routing 
aggregation and routing policy, scalability
inside networks as well as outside.

Prior to CIDR, IPv4 routers could not have scaled to handle all the 
prefixes currently announced.
Class C space was 32 /16 equivalents, or ~2M routes.
> Let's not reimpose v4 restrictions on the
> world, which is exactly what this proposal does.  Yes, we're not being
> super efficient with number policy, but that's not what we need at this
> point in time.  If, 50 years from now, we're running low on address
> space, things will certainly change.  It's presumptuous of us to think
> that we know how this is really going to work out over that kind of
> time period, though.
>   
If you read the proposal, you'd realize it has nothing to do with the 
end-site or end-user usage,
prefix count, or anything - it has to do with aggregation on the ISP's 
network, and on DFZ
routing table slots. Aggregation is important to ISP routing table 
slots. Both internal and external
routes eat up slots, which are a precious and largely non-renewable 
resource.
> Again, for clarity, I really really oppose this policy proposal.
>   
I'm all for change, and welcome all comers to change their view, once 
clarification on what
has been proposed is made.

You don't need to tell me, but if you change your mind, the PPML list 
would likely want to hear about it.

Brian