Subject: RE: Multihoming by IP Layer Address Rewriting (MILAR)

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 15:18:40 -0400

At 15:16 04/09/01, Christian Huitema wrote:
>Game stations, and PC running video-games, obtain
>incoming connectivity by registering their address in a game lobby.

Christian,

        A few special cases != generally.

Ran
[email-masked]

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 13:00:09 -0700 (PDT)

An article (http://www.menandmice.com/6000/61_recent_survey.html) says
78.5% of .com zones are misconfigured, with problems ranging from lame
delegations to non-responding authoritative name servers to incorrect
match between delegation data and zone data.

I don't think that we should create a dependency between routing (even if
it is for multihoming) and DNS that can be hurt by these kinds of
misconfigurations, even if we assume that every internet device is
required (which I think is impossible to do for various reasons,
including non-technical) to be hosted in DNS.

-ramki

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 16:18:34 -0400

>including non-technical) to be hosted in DNS.

        We've already got that dependency.  

        Folks depend on www.cnn.com resolving to the right 
load-balancer's IP address so that routing goes to the right place.  
If DNS is really so broken that it is a crisis right now, then
we should defer multi6 work to fix that first, IMHO.

Ran

---

From: Eric Gauthier <[email-masked]>
Date: Tue, 4 Sep 2001 16:47:42 -0400

> we should defer multi6 work to fix that first, IMHO.

I might be a bit confused here, but it seems that people are talking 
about two different things.

First, when a person (layer 8 application) or application wants to do 
something, they try to attach to that resource.   Somehow, those upper 
layer applications need to ask the lower layers to get a resource
(ie - please connect to IP x.x.x.x on port z).  This seems to be
the DNS side of things where you are determining what that layer
3 address should be.  Second, there is a pure layer 3 issue of how 
do various layer 3 devices build their routing tables.  

So, is the debate right now : do we want the multihoming functionality
to be handled by the upper layer -> layer 3 translation mechanism
or do we want it handled within the routing tables themselves (or
a conbination of the two).

If I've got this right, it seems like this is more of a debate on what 
direction we should take rather than about a specific technology.  Should 
we focus on the translations like, for example, the way Mail service was
implemented by using multiple MX records to handle failover of a service 
to a different IP.  Or, should we handle this solely within layer 3 
like, for example, how site multihoming is done using BGP?

Am I close on this?

Thanks!

Eric :)

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 13:48:39 -0700 (PDT)

> load-balancer's IP address so that routing goes to the right place.

I think it is important to distinguish between performance and
correctness; the load-balancer should just "work", it need not (and,
sometimes, is not) be "optimum".

> we should defer multi6 work to fix that first, IMHO.

While all indications are that the quality of DNS today is bad, it
"works", so people aren't too concerned about it:
http://www.psg.com/~randy/960303.iepg

I think it is the job another working group (dnsop) to make sure it does
not break (this means that it is a good idea to bounce any DNS-based ideas
on the dnsop mailing list).

regards,
-ramki

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 16:56:40 -0400

>on the dnsop mailing list).

OK, so we can go back to assuming the DNS works well enough
and not use the DNS anxieties as the basis for ruling out DNS 
as a component of a possible solution.  

Please note well that I'm not advocating a DNS-only kind of solution.  
I'm trying to keep this WG from closing doors prematurely on *any* 
technical approach that might be shown to work...

Ran

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 4 Sep 2001 14:15:33 -0700 (PDT)

> as a component of a possible solution.

As far as it does not require every IPv6 device
to have DNS entries. In this regard, I fully agree with Christian that we
must be prepared to let those game boxes, IM services, etc. get the benefit of
multihoming even if they don't appear in DNS.

regards,
ramki

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Sep 2001 17:18:25 -0400

At 17:15 04/09/01, you wrote:
>As far as it does not require every IPv6 device to have DNS entries. 
>In this regard, I fully agree with Christian that we must be prepared 
>to let those game boxes, IM services, etc. get the benefit of

I wouldn't be bothered if requiring at least one AAAA/A6 record
to exist was a precondition to multihoming working.  I might even
be comfortable with requiring more than one in DNS, if explained 
as part of a detailed proposal (not sure, but open minded).  Clearly
you and Christian would be bothered and that has been noted.

Even the game boxes or toasters connected via cable modem have DNS 
records -- the cable network operators and dialup operators and 
DSL operators normally assign both forward and reverse DNS records 
to all their users' IP addresses (just to preserve the sanity of the ISP
in troubleshooting things, not because of any more complex motive).
So it isn't something residential users even need to think about
these days.

Ran

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Sep 2001 00:22:28 +0200 (CEST)

> about two different things.

Just two? We're making progress.  :-)

> do various layer 3 devices build their routing tables.

I think I'm the one who inadvertently opened this can of worms, so let me
explain where it all came from.

My proposal is to let layer 3 rewrite destination addresses in some cases,
so that both higher layers and other layer 3 entities can go about their
business as usual and there is still scalable multihoming.

There is one caveat, though: you need to know what the new destination
address should be. Obviously, this information can't come from the routing
table, since keeping the routing table small is exactly the problem we're
trying to solve. Also, receiving alternate addresses from the remote host
is problematic if all you have is a primary address that is unreachable.

So using the DNS seemed like logical choice. PTR records would get a
neighbor, something like AP (alternative prefix). That way, a host
can find out the way the address should be rewritten without too much
trouble.

Earlier I said the regular way of using multiple AAAA records would
suffice to enable a host to connect to another host when a path is broken,
but this is problematic. A host could do this, since it can decide to
break off TCP session establishment if it's getting nowhere and try to
start one to another address without seeming to break off the session to
the application.

But a router would not be able to do that on behalf of a host without a
full NAT implementation, and I think we should avoid introducing that much
state in routers. Finding a AP record and rewriting the destination
addresses for all packets to the original address (prefix) is much
cleaner.

> like, for example, how site multihoming is done using BGP?

Any consensus on BGP changes is a long way off (or has been carefully
hidden) so I guess we have to solve the problem, or at least lessen the
impact, elsewhere. There are basically three choices:

- application
- transport
- IP

Changing applications is next to impossible: there are too many of them.
(Unfortunately, the socket API doesn't hide the layer 3 addresses so
applications need to be changed for IPv6 as well. We can all see how fast
this is happening.)

Changing transport protocols is hard: there are many of them and changing
them imposes changes on the applications as well and repeating the same
steps for each session is somewhat wasteful of resources. And not all
transport protocol lend themselves equally well for this.

Changing IP processing seems doable, at least compared to the
alternatives.

So: what do we change in IP? There are several drafts and not-so-drafty
proposals. They all have stronger and weaker points, and most of them seem
to gravitate towards some kind of address rewriting scheme.

Maybe we should come up with some more specific requirements for multiple
addresses / address rewriting solutions. Or we can just wait and see who
is the first to produce code.  :-)

Iljitsch van Beijnum

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 5 Sep 2001 02:39:00 +0200

> to gravitate towards some kind of address rewriting scheme.

Perhaps we can try to collect strong points from different proposals :-)

IMO Preserving Active TCP sessions on Multi-homed IPv6 Networks (PATS from
now on) and LIN6 are both very interesting proposals.

However, PATS  is not transparent to TCP layer and above what introduces the
transport address concept and brings some problems (IPsec, TCP pseudo header
calculation and others as mentioned in the draft). This issue is solved in
LIN6 making address translation at IP level and making it transparent for
TCP, so that for TCP (and IPSec) only one address is used.

In the other hand, LIN6 uses a complex mechanism (designed for mobile
environement) for mapping different addresses (for defining the address
set), while PATS provide a simpler solution (IP prefixes option and perhaps
DNS info) to define the address set.

Wouldn?t be posible to merge them into one and obtain the best of the two
worlds?

Regards, marcelo

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 5 Sep 2001 17:56:53 -0700

> business as usual and there is still scalable multihoming.

Question, how does the receiver know it is supposed to replace 
the dst, and which of its possible dst addresses to replace it 
with? In other words, how can it tell the difference between
a rewritten packet to address B vs. a second connection from 
that src that happened to be load-balanced to address B?

If it doesn't put back the original layer 3 will know.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Sep 2001 09:13:27 +0200 (CEST)

> that src that happened to be load-balanced to address B?

That is a problem. A host could sort through the list of transport layer
connections to see if the source address and ports match any of those and
see which destination address is expected for that connection.

However, a "proxy address rewriting device" would not be able to do this
without keeping track of all transport layer connections of all the hosts
it's rewriting for, which is something I think should be avoided.

So the solution I propose is to have specific alternative addresses for
each regular address. The alternative addresses would be known to the rest
of the world and to the host as such, and not be used for regular
communication.

Suppose a host has two interfaces that connect to two different address
ranges. It would then have four addresses:

A::1	; real address in address block A
A::2	; alternative address for B::2
B::1	; alternative address for A::1
B::2	; real address in address block B

If we're going to use the DNS to discover the alternative addresses, this
would be the forward zone:

host	IN	AAAA	A::1
host	IN	AAAA	B::2

The reversed zone for A:

1	IN	PTR	host.domain.
	IN	AP	B::1
2	IN	PTR	host.domain.

Iljitsch van Beijnum

---

From: Mattias Pettersson <[email-masked]>
Date: Thu, 06 Sep 2001 15:58:26 +0200

> Wouldn?t be posible to merge them into one and obtain the best of the two

I would like you to consider Homeless Mobile IPv6
<draft-nikander-mobileip-homelessv6-01.txt> as well. It tries to solve
mobility and multihoming in one attempt somewhere around layer 3.5.

/Mattias

---

From: Peter Tattam <[email-masked]>
Date: Fri, 7 Sep 2001 00:38:39 +1000 (EST)

> I would like you to consider Homeless Mobile IPv6

Complete with soup kitchen?  :)

Peter
--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 6 Sep 2001 20:08:49 +0200 (CEST)

> mobility and multihoming in one attempt somewhere around layer 3.5.

Looks good. A few questions:

- what happens when an address suddenly fails and is no longer reachable?

- what happens if TCP tries to set up a connection but the address it
  chooses doesn't respond (and there is another address that works
  available)?

- would it be possible to offload homeless mobile ipv6 processing on some
  kind of "mobile proxy" so hosts that do not support the protocol can use
  it anyway?

---

From: Mattias Pettersson <[email-masked]>
Date: Mon, 17 Sep 2001 16:10:01 +0200

Late reply...

>   chooses doesn't respond (and there is another address that works

As long as there are multiple addresses available the sending node is
free to select any of them as destination address.

I guess an ICMP error message or an upper layer lack of progress signal
would cause a bad address to either be removed or lowered in priority.
Similar ideas are used in Mobile IPv6 today. That would apply to both of
your questions.

In addition, in the first case, the peer can send packets to the node in
question and the source address of those packets would indicate a new
better destination address to use.

>   kind of "mobile proxy" so hosts that do not support the protocol can use

That's an alternative to look at. Otherwise, the Homeless protocol is
backwards compatible wrt Mobile IPv6, so that all that is required is
standard correspondent node behaviour, which is mandatory for all IPv6
nodes anyway.

/Mattias

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Sep 2001 19:59:37 +0200 (CEST)

> Similar ideas are used in Mobile IPv6 today. That would apply to both of

Yes, but what does the user experience? I can do round robin DNS for two
IP numbers for a website and since you can still connect 50% of the time
when one address fails, this could be considered a solution. Users
won't like it, though.

Having a connection setup attempt fail so it has to be retried at the
application level is not good enough.

Iljitsch van Beijnum

---

From: Mattias Pettersson <[email-masked]>
Date: Tue, 18 Sep 2001 11:32:02 +0200

> application level is not good enough.

I agree that the user can't accept that. But what do other proposals do
(we are talking about connection setup)?

Send TCP SYN to multiple peer addresses? The peer would ignore multiple
attempts. I think that was mentioned before.

We need mechanisms that will provide the first address of the peer that
has a high probability of being reachable. I don't know if DNS can
reflect that fast enough. The draft mentions SIP, and such mechanisms
that are based on registering are good if the peer knows which of its
addresses are reachable and which are not.

The draft assumes that we can't read too much stability into the IP
addresses of a node. Addresses come and go. As long as you have a
session established between two nodes then they can inform each other of
address changes. On the other hand, when trying to establish a
connection to a node we need fast location management, and that may be
something new but not within the scope of this draft.

/Mattias

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 27 Sep 2001 17:36:37 +0200 (CEST)

> has a high probability of being reachable.

Since replicating this information regardless of whether it will be used
or not (such as is current practice with BGP) does not scale, the only
solution to this is to have the host try. Optionally, the information
gathered this way could be stored/shared for further use.

> I don't know if DNS can reflect that fast enough.
> The draft mentions SIP, and such mechanisms

Which is certainly not something we can rely on...

So this means either pinging the host to find a working address before the
TCP setup, or just trying the TCP setup and retry it transparently if it
fails or takes too long.

> address changes.

But I'm not sure if mobile IP does in a way that is robust enough for our
purposes.

Iljitsch van Beijnum