-----Original Message-----
From: owner-shim6@psg.com [mailto:owner-shim6@psg.com] On
Behalf Of Brian E Carpenter
Sent: Monday, March 28, 2005 6:20 AM
To: Iljitsch van Beijnum
Cc: Dave Crocker; shim6
Subject: Re: Open question and Critical dependencies
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