Re: A new spin on multihoming: multihoming classes.

[Daniel Senie <dts@senie.com>]

At 10:41 AM 9/9/01, Iljitsch van Beijnum wrote:
>On Sun, 9 Sep 2001, Daniel Senie wrote:
>
> > >If we're going to do MAMH, we need three things:
>
> > >1. initial address discovery: DNS already does this
> > >2. address negotiation: mobile IP already does this
> > >3. failover: this we don't have
>
>Hm, I might have another one: sending traffic with a source address from
>ISP A over a link to ISP B can be a problem.

Especially if folks are doing ingress filtering. Proper address selection 
(and figuring out how to decide) is the hardest part of this to do in 
hosts, unless the hosts have a lot of information pushed to them.


> > 4. a separate IP address prefix for each pipe from a site to the Internet,
> > all of equal size.
>
> > This point seems to be missing from the discussion. While with IPv6 we like
> > to think of sizing as infinite, we are busy dividing that space by 2 or 3
> > to account for a large percentage of sites multihoming. That might be OK,
> > or it might not.
>
>That's one or two bits out of 128. Considering that 16 bits are wasted in
>the IEEE -> EUI-64 conversion, I don't see the problem in IPv6.

Though the use of MAC address is now an optional thing, due to privacy 
concerns. Yes, there's a large block of addresses. The concern is that we 
not give away too many bits for one thing or another. We also have the 
issue that all providers to a site will need to supply prefixes that 
essentially match (i.e. same sizes from each, so that things overlay 
cleanly). The RIRs would need to adjust their policies to permit this.


>In IPv4, things are different, of course. Still, a single host could have
>several addresses if this serves an important function, I think.

It does, but would 2 or 3 different upstreams each provide a block of 
addresses large enough for a web server farm? At what point is the 
consumption of addresses considered more expensive than handing the site an 
AS number, and allowing them to advertise their blocks?


> > This issue also raises some concerns in terms of whether the RIRs are
> > willing to play along.
>
>They might not like all of this, but for the opposite reason: when just a
>hand full of ISPs need address space and AS numbers, that means less work
>for them.
>
> > Clearly in an IPv4 world, assigning additional prefixes of equal size to a
> > site is not going to go over well,
>
>Agree.
>
> > >Not a strict requirement, but it would be very helpful to have a choice
> > >whether the end hosts or a proxy/router/NAT-like box does the necessary
> > >multi-address multihoming processing.
>
> > There are multi-ported NAT Boxes on the market today which provide a flavor
> > of multihoming with IPv4. This approach, with one-to-one NAT, can provide
> > some level of service today to make a site "multihomed" in an IPv4 world.
> > Note, however, the consumption of address space.
>
>Aren't current sessions still lost with current NAT?

With a Multi-homed NAT solution, it's possible to have sessions load 
balanced, as the box doing the NAT is a router connected to all possible 
exits. The box can decide which link to connect out on, and thus outbound 
connections are cleanly load balanced (and the returning packets for those 
links will follow the same path back in). For inbound traffic to a site, 
load balancers (e.g. DNS tricks and such) permit balancing between the 
various links. The two functions can be handled by the same equipment, so 
that line utilization can be managed for each link.

One of my concerns is that these boxes (available today) will look more 
attractive to many people than a migration to IPv6. Indeed, if a site can 
get multiple providers to supply enough address space, then for many cases 
this is an efficient and cost-effective way to get into multihoming. 
Certainly such boxes could be made to play in the IPv6 space as well, or do 
6to4 in the course of their work.


> > This may be a tradeoff we're willing to make. I have not seen anyone
> > mention it in the arguments made here, which concerns me. As a community
> > and standards body, we have not always done a good job of considering
> > future impacts of standards promoted.
>
>You are right, we should pay attention to this. Michel Py talks about this
>in section 6.2.4 of his draft.
>
> > Are the DNS servers magically in a place where THEY are better connected?
> > Arguably with this multi-connected site, the DNS servers could appear to be
> > on separate networks, thus well protected. However, the time to find a
> > responsive DNS server would have to be added to the other access times.
>
>That would be a good reason to incorporate this in the current DNS, since
>we already have to wait for the name to address translation. If the other
>information is then returned as well, this would save time.

Other than packet size limitations with DNS over UDP, or overhead if 
everything spills over to TCP.


> > Further the TTLs on the DNS data would need to be short, to reflect the
> > changing nature of the data that you want to present.
>
>I do not propose to store data that needs to be changed often in the DNS.

Unfortunately, one of the things this type of multihoming lends itself to 
is load balancing manipulation. By altering the order of the addresses in 
responses (i.e. doing something other than round robin) is a pretty 
effective way of altering balancing. Setting TTLs very low makes this 
possible. If we go down this path, people WILL be setting their TTLs very 
low. Some will argue for ignoring the TTLs and caching longer, but that'll 
create significant problems for many applications, and likely increase 
support costs in the long run.


>Iljitsch van Beijnum

-----------------------------------------------------------------
Daniel Senie                                        dts@senie.com
Amaranth Networks Inc.                    http://www.amaranth.com