Re: Open question and Critical dependencies

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 27-mrt-05, at 20:21, Dave Crocker wrote:

> 1. What does "This solution should work whether or not the peer site 
> supports
> the shim6 protocol" mean in the draft charter and how can it succeed?

What Geoff wrote is:

"Solutions for site exit router selection that works when each ISP uses 
ingress filtering, i.e. when the chosen site exit needs to be related 
to the source address chosen by the host. This solution should work 
whether or not the peer site supports the shim6 protocol."

I'm pretty sure "this solution" in this sentence refers to site exit 
router selection, which is necessary to get around ingress filtering by 
ISPs.

A slight rewording would probably be a good idea.

> 2. Why is shim6 limited to IPv6?  What is it about the problem space 
> and/or
> the solution space that is required to exclude IPv4?

There are many answers to this question.

First of all, the multi6 wg was formed because the way multihoming is 
done in IPv4 won't scale to the levels presumed necessary in IPv6. So 
the problem is assumed to not exist in IPv4 as people can get portable 
address space and announce it to multiple ISPs today. (Ok, it doesn't 
scale in IPv4 either... But it seems to work for now.)

Then there is the issue that with any multiaddress solution you're 
going to burn IPv4 addresses at least twice as fast as by single homing 
or PI/BGP multihoming, and we don't even have enough IPv4 addresses to 
give every person on the planet a single one.

Also, IPv6 has some features that come in handy for solving the 
problem. For instance, HBA or CGA which are proposed to secure the 
address agility, put cryptographic information in the bottom half of 
the IPv6 address, and there are / have been some ideas about using the 
flow label.

Last but not least, IPv4 is hampered with lots of ballast in the form 
of overzealous firewalls, different kinds of NATs and old 
implementations and all kinds of unwise assumptions that something as 
radical as this stands a rather small chance of being deployable in the 
current IPv4 internet. (See ECN and path MTU discovery.) Presumably, 
these issues won't be quite as bad in IPv6 because there is less old 
crap and bad habits.

> 3. What happens to shim6 if it must operate through a NAT?

Same as anything that must operate through a NAT: that problem is 
either solved by the NAT builder or suffered by the NAT user.

NAT in IPv6 is a very bad idea, both because NAT is a very bad idea in 
and of itself, but also because NAT in IPv6 immediately kills one of 
the main advantages of IPv6 and of course if you're going to use NAT 
anyway, why bother adopting IPv6?

> Items 2 & 3 establish critical dependencies on the wide-scale adoption 
> of IPv6
> and the elimination of NATs.

Since the former implies the latter (at least right now, but hopefully 
also for time to come) and for the short-to-medium term there is no 
multihoming problem in IPv4, this doesn't pose a problem. (Other than 
the possibility that we're wasting our time, which is a risk that 
everyone will have to weigh for themselves.)