[ppml] Re: [address-policy-wg] Is the time for conservation over?
owen at delong.com
Mon Oct 27 17:46:23 EST 2003
--On Monday, October 27, 2003 13:01 -0800 Michel Py
<michel at arneill-py.sacramento.ca.us> wrote:
>> Owen DeLong wrote:
>> If I have a box with two /128s assigned to it, how does it
>> know which one corresponds to the provider that is up and
>> routing packets and not to use the one that is down at the
> It's called "magic", don't you know. It just happens, you don't have to
> know how :-)
> This is besides the point anyway. Save for small home/soho like setups,
> the idea of having more than one address per host is not an option.
> Imagine each host can have three addresses: triple firewall config,
> triple access-list config, triple internal routing config, triple
> problems. In large corporations I have talked to, only M$ appears to
> think that multiple addresses per host are a serious option.
But, that appeared to be what people were saying was the solution for
V6 multihoming. I'm just trying to figure out what it takes for V6
to have a reasonable (the router can parse it and route packets)
routing table _AND_ allow reasonable multihoming (at least as good
as what is achievable today). I took the multi-address position from
someones paper on "how to do it" and didn't develop it myself. I
have no religion either way. If there is a single-address way to
do it, I'm all for that. What is it?
>> To me, the whole point of multihoming is reliability. That means,
>> my packets get through as long as at least one provider is up and
>> has reachability to/from the peer I want to talk to.
> That's only one feature of today's multihoming (which is tied to PI
> addresses). The other two being provider independence (because
> renumbering a large network is painful) and global load balancing
> (because transporting traffic from Asia to North America in your own
> network costs money, therefore you are much better off go to the right
> location in the first place).
Renumbering a large network is painful in V4. V6 was supposed to have
pretty much fixed that. If it didn't, V6 needs more development work
until that is fixed. Renumbering is a common occurrence for a variety
of reasons and we should develop tools to make it not painful.
As to GLB, you are not making sense to me. Either you are using ANYCAST
(in the IPv4 sense of the word) where you have an autonomous system that
consists of a (set of) prefix(es) that are replicated in multiple locations
or you are using DNS hackery. Any other form of GLB will still require
some level of redirection. If you are getting redirected on application
setup (HTTP Redirect, for example), then, the end address doesn't matter
much and it doesn't matter how many ASNs are involved, either. That's
not multi-homing, that's topologically diverse hosting. If you're
dealing with anycast, then, since the prefix is the same and topological
metrics control which server gets the request, that's also not "multihoming"
in the traditional sense of the word.
However, in my opinion, multihoming in the traditional sense of the word,
a single AS attached to more than one upstream transit AS, is the harder
of the problems to solve, and, it is not clear to me how this works in
>> Does v6 require me to run a routing protocol on EVERY host
>> in order to do local address selection for sourcing new
> There have been some proposals to the IETF, some of which suggesting
> RIPNG as the routing protocol. Although they never had much momentum
> Lord knows what the IETF can do.
This doesn't bode well for IPv6 being adopted any time soon. It sounds
like there are still many real world operational problems that are
left as an exercise to the implementer.
More information about the ARIN-PPML