Biggest mistake for IPv6: It's not backwards compatible, developers admit

[John Payne]

On Mar 31, 2009, at 12:22 PM, Fred Baker wrote:

>
> On Mar 31, 2009, at 5:05 AM, John Payne wrote:
>
>>> And hence I raise my question. There are a number of alternatives  
>>> on the table today that give one both multihoming and ISP  
>>> independence. Who has given them five minutes though before  
>>> rejecting them out of hand?
>>
>> What alternative gives you multi-homing and leaves the traffic  
>> engineering[*] in the hands of the network team and not the end- 
>> users or server folk?
>
>
> On Mar 30, 2009, at 10:32 AM, Fred Baker wrote:
>> As I see it, there are six major proposals on the table.
>>  - provider-independent addressing (aka PI)
>>  - provider-dependent addressing (aka PA)
>>  - provider-dependent addressing with multiple prefix overlays in  
>> multihomed networks (shim6)
>>  - private addressing with NAT, converting to provider-dependent  
>> addressing at a DMZ
>>  - private addressing with Network Prefix Translation (GSE)
>>  - exchange-based addressing (aka Metropolitan addressing)
>
>
> With PI, you can do what you do today with PI.

Yup, except you have to listen to the shim6 proponents screaming about  
the size of the routing table.

> With PA, you can do what you do today with provider-allocated  
> addresses.

Not really.... in IPv4 land, people can and do deaggregate PA space,  
treating it as PI.  Whether that's the right thing or not doesn't  
matter.
First hit issues.


> With shim6, you can do what you do today with provider-allocated  
> addresses. It, however, depends on the end system's choice of a  
> source and destination address (they are provider-allocated, but the  
> end system may have multiple addresses from multiple providers) to  
> determine which ISPs the traffic will transit, which is I think what  
> you are concerned about.

That's part of it.... the end system is not the place to be making  
routing decisions.   Other issues surround the first hit.

> With NAT, you can do what you do today.

First hit issues

> With GSE, the edge network (not the host, the administration of the  
> network the host is using) is in control of the edge network  
> routing, and to the ISP that the edge network chooses it looks/works  
> just like PA, because it is.

GSE I haven't paid much attention to because I was told it was  
dead :)   LISP is somewhat interesting

> Exchange-based addressing is something where the routing issues are  
> not all worked out, so I have to insert a caveat here in that  
> regard. But one would expect it to work much like today's routing  
> with the exception that the sender's contracts in effect select the  
> transit ISP.
>
> Your complaint, as I understand it, is with shim6, and speaking for  
> myself I agree with your concern. From the perspective of the  
> network, the rest devolve to PA, and you can manage routing the way  
> you do with PA. Not that I am asking you to be happy with today's  
> routing protocols, but I view them as a separate question.
>
> Traffic engineering can be improved, no doubt. Personally, I would  
> like to see that handled via a new routing protocol, one that  
> explicitly addresses the issue. Why? Because it is a routing  
> problem. But coming back to the question I have been responding to  
> in this thread, the solutions on the table all address the issue of  
> the allocation of addresses for multihoming, with the exception of PI.

I multihome 2 different sets of sites.

1) User-centric
2) Server-centric

My argument that the path selection must be done at the site level and  
not at the host applies to both.

NAT is an option for the user-centric sites for sure.   However,  
neither NAT, nor shim6, nor PA (non-deagg'd) deal well with the server- 
centric sites when one of the links is down.  Waiting for TCP timeouts  
on the first SYN isn't an acceptable model.