Re: [v6ops] Comments to draft-mlevy-v6ops-auto-v6-allocation-per-asn

[Owen DeLong <[e-mail]>]

On Feb 19, 2013, at 18:16 , Dino Farinacci <[e-mail]> wrote:

> On Feb 19, 2013, at 5:09 PM, Owen DeLong <[e-mail]> wrote:
> 
>>>> I think permanently assigned addresses related to VINS are, in general, a bad idea. I don't see any advantage to tying the semantics of the two systems to each other. If anything, the development of LISP is the result of failing to separate the semantics of end-point addressing from the semantics of topological location. Combining the semantics of end-point addressing and VINs seems even more far-fetched to me.
>>> 
>>> An EID is opaque and not used by the protocol stack just by humans if they choose to look at them. 
>>> 
>> 
>> One of us is misunderstanding the other. My point is that using IPv6 address space to number things that are not IPv6 hosts is, IMHO, a bad idea.
> 
> The automobiles are IPv6 hosts. 

It is unlikely that any network will ever be {all vehicles with VIN is a member of [RANGE]} other than possibly a brief factory test.

Thus, I do not believe it is appropriate to permanently associate a prefix with a collection of vehicles based on their VIN.

> 
>> 
>>>>> (3) What if these auto manufactures don't want to allocate ASN numbers because they will never have any intent to run BGP either in the cars, POPs, data centers?
>>>>> 
>>>> 
>>>> I don't see anything in this draft that would preclude them from using a different source of addressing.
>>>> 
>>>> I confess, to some extent, I wonder if this is a solution in search of a problem.
>>> 
>>> I know there are customers that want to reduce the number of total databases they have to manage at all layers of the stack.
>>> 
>> 
>> All well and good, but I do not support turning IPv6 addresses into the primary key for everything in world anyone wants to identify in any namespace. If that's not what your sentence above means, then I'm afraid I misunderstand your meaning.
> 
> It is none of your business how sites use their addresses. That is the whole point of ID/Locator separation. 
> 
> The EID is opaque to the network but may have meaning to the sites who communicate with each other within that EID-prefix. 
> 

I do not support allocating globally unique prefixes for things that are not networks.

Perhaps that will better explain my position.

I think that overloading the IPv6 prefix space with semantics for arbitrary collections of things is a really bad idea that has tremendous potential to consume vast amounts of addresses while yielding no network benefit in return.

Will it exhaust the IPv6 space immediately, probably not. Could we easily exhaust the ASN space if we start promoting the idea of claiming ASNs to support this? Yeah, we could probably burn 4 billion ASNs that way without too much trouble.


>> Again, I do not support the idea of using IPv6 numbers as a mechanism for identifying anything that isn't an IPv6 host and I do not support tying semantics other than the host end-system identifier for packet delivery to IPv6 addresses. I think that past experience has demonstrated that both of these practices create more problems than they solve.
> 
> See above. Tell me if you still disagree and if so we will have to disagree. This is where IPv6 could be useful. What does IPv6 have that IPv4 doesn't? Really only longer addresses. 
> 

I disagree, but at least I now fully understand what you're trying to inflict on the world.

As to the answer to your other question:

SLAAC
6-lowpan
Improved header structure
Extension headers
Cleaner IPSEC implementation

I'm sure there's more, but I don't want to get too far down yet another orthogonal discussion.

>> 
>>>>>> If any route is announced from this allocation, any prefixes more
>>>>>> specific than the allocated /48 must not be propagated in to the
>>>>>> global IPv6 routing table.  This is to prevent the IPv6 routing table
>>>>> 
>>>>> This is fine authors, but if you are multi-home, it will require each system at the site to possess multiple addresses one from each attached ASN if they do not have their own prefix but get it out of their provider.
>>>>> 
>>>>> If you say that this prefix will never be associated with a provider's attachment point, then I'm okay with that and agree.
>>>>> 
>>>> 
>>>> Either I misunderstand what you are saying, or, you have erred. I'm not sure which.
>>>> 
>>>> If a site uses a /64 from within this /48 to attach to each upstream, the more specific does not need to propagate beyond the immediate upstream router, so it still wouldn't be announced into the global routing table.
>>> 
>>> There is still PI flat routing on the scale of number of sites that use this prefix. That is the point, there is no attempt to improve the route table scaling problem. I'm not saying this draft should, just speaking generally.
>> 
>> I think that concern is entirely orthogonal to this draft. My point is that for every PI
>> prefix that gets advertised from this space, it should represent a PI prefix from RIR
>> space that does not get advertised, so it is a net equivalence in terms of the
>> routing table. Thus, I would anticipate that this draft has no impact on the routing
>> table.
> 
> Okay fine. 
> 
>> OTOH, the whole way we do IDR is broken and we should have fixed it as part
>> of the IPv6 development process. Unfortunately, we (IETF) chose to punt on that and
>> go down all kinds of other less important roads. However, this issue is really
>> not part of the discussion of this draft.
> 
> If locator/ID separation is used then this is helped and you make multi-homing  easier at the same time as making address management in every host. 
> 

At the price of converting every connection into a tunnel with associated MTU penalties.

A better solution (IMHO) would be to have a 32 bit field added to the protocol to contain the destination ASN embedded in the packet header. Unfortunately, this is a major change to every system and would basically be the next protocol version (though at least IPv6 and IPv{N} would be interchangeably compatible with each other except for the MTU issues).

> Look how complicated the home networking proposals are?

Agreed, it's ridiculous. We should, instead, recognize that we dropped the ball in IPv6 design and do something slightly different before the routing table explodes. We have several years beyond IPv6 deployment to address that issue, IMHO. For now, I'd rather focus on actual operational issues related to IPv6 deployment and revisit solving the routing table problem later.

>> I'm not sure what you mean by this. Why would products coming out receive AS Numbers? I think you are pursuing a use case that is not intended under my interpretation of this draft and taking it to extremes that are beyond my comprehension.
> 
> I mean each product would have to build a hex to decimal conversion capability in their UI. 

1.	Libraries already contain these and nobody is hand-coding systems in assembly language any more.
2.	This is seriously not difficult and most products duplicate enough UI components from other products
	that it would rapidly become a boilerplate component in the developer tool kit at each organization if
	it hasn't already.

> 
>> 
>>>>>> 5.  ASN allocation
>>>>>> 
>>>>>> ASNs are allocated by RIRs and this RFC does not handle that arena.
>>>>>> 
>>>>>> ASNs defined as private ASNs MUST NOT use this scheme.  The special
>>>>>> 16-bit ASN 23456 MUST NOT use this scheme.
>>>>> 
>>>>> I would let users do this with private ASes if they want to. Set a local/global bit in your encoding so they can use it. If you don't they will steal ASN numbers which they should not do but will.
>>>> 
>>>> What local/global bit?
>>> 
>>> Add one is the suggestion.
>>> 
>> 
>> I expected that's where you were going. I think 16 bits is already a rather short prefix for this use case. I don't believe that there is a sufficient use case for a local/global bit. If you do, you need to make a better case for it than the above.
> 
> Well explicitly encoding that the intent of the address is local is a good thing IMO. 
> 

Which I believe my suggestion below would cover...

>> 
>> I would propose modifying section 5 of the draft to state, instead of "ASNs MUST NOT use..." that "ASNs MUST NOT advertise..." and that any prefixes within the prefix allocated for this purpose must be considered "LOCAL addresses and given similar semantics to RFC-1918".
> 
> Sounds good. 
> 

Zero bit cost here. 


Owen