Re: Open question and Critical dependencies

[Brian E Carpenter <brc@zurich.ibm.com>]

Iljitsch van Beijnum wrote:
> 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.

And possibly also to the address selection mechanisms prior to
exit router selection. Clearly, the double-ended stateful part of
the shim cannot work when only one end knows about it.

> A slight rewording would probably be a good idea.

Yes

> > 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.

Exactly. IPv4 doesn't have the features we need to make shim6 viable.

> 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?

If someone is foolish enough to install IPv6 NAT they will be able to
use that to support old-fashioned NAT-based multihoming. We started
multi6, and we are continuing shim6, precisely as one of the main ways
to make NAT unnecessary. So actually, we simply don't care if shim6
fails through NAT.

> > 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.)

Well yes. If IPv6 isn't widely adopted, or IPv6 NAT gets deployed,
it will all have been a big waste of time. There's no news there.

   Brian