Re: A new spin on multihoming: multihoming classes.

[Iljitsch van Beijnum <iljitsch@muada.com>]

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.

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

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

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

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

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

Iljitsch van Beijnum