[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Open question and Critical dependencies
On 27-mrt-05, at 20:21, Dave Crocker wrote:
1. What does "This solution should work whether or not the peer site
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
A slight rewording would probably be a good idea.
2. Why is shim6 limited to IPv6? What is it about the problem space
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
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
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.)