Subject: RE: The state of IPv6 multihoming development

From: "Tony Li" <[email-masked]>
Date: Sat, 26 Oct 2002 00:04:06 -0700

|   > Would you feel this way if you could simply maintain the prefixes
|   > in the border gateway?
|   
|   No.  The open concern then becomes that of applications that carry
|   addresses in the payload -- would border routers require a 
|   knowledge base
|   of applications to translate a la IPv4 NAT?

So we're going to institutionalize support for layering violations?
This doesn't seem right.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 26 Oct 2002 09:55:52 +0200 (CEST)

> So we're going to institutionalize support for layering violations?

Unless I'm mistaken nobody here has proposed a solution that has this
problem. If/when addresses are changed somewhere, they are either
changed back later, or the destination is aware of the relationship
between the old and new address. In other words: any address that an
application communicates to the other end remains valid. Reachable is
another question... Apps should consider using more than one address.

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 26 Oct 2002 21:23:35 -0700

Iljitsch van Beijnum wrote:
> ...
> Unless I'm mistaken nobody here has proposed a solution that 
> has this problem. If/when addresses are changed somewhere, 
> they are either changed back later, 

Through a complex mechanism that scales worse than inter-domain
multicast. Since that has proven to be a real deployment challenge, why
do we think magic translator protocols are going to be any better?

Tony

> or the destination is 
> aware of the relationship between the old and new address. In 
> other words: any address that an application communicates to 
> the other end remains valid. Reachable is another question... 
> Apps should consider using more than one address.
> 
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Oct 2002 10:01:21 +0100 (CET)

> do we think magic translator protocols are going to be any better?

I don't see any relationship with interdomain multicast, so the fact
that this has been hard to deploy in the past (and unless I'm mistaken
the scalability problems have now been largely solved) doesn't say
anything about translation mechanisms.

Anything that happens in end-hosts should scale well. Moving the
functionality to a different box outside, but still close to, the
end-hosts should also scale as long as it's possible to deploy an
arbitrary number of those boxes = no hard state. Content delivery
systems often use complex NAT setups to balance the load and provide
redundancy. Since what we're proposing here is simpler than NAT, I see
no reason why it wouldn't work or scale.

And if for the truly huge networks this solution isn't viable, they can
always use IPv4-style multihoming. (But they'd still need to implement
all of this in order to be able to talk to others who use multi-address
multihoming.)

Iljitsch

---

From: "Craig A. Huegen" <[email-masked]>
Date: Sun, 27 Oct 2002 17:12:01 -0600 (Central Standard Time)

> So we're going to institutionalize support for layering violations?

I would like for the answer to be "no".  At the same time, there is the
question of existing applications.  Will H.323 be completely re-written?

/cah

---
Craig A. Huegen, Chief Network Architect      C i s c o  S y s t e m s
IT Transport, Network Technology & Design           ||        ||
Cisco Systems, Inc., 400 East Tasman Drive          ||        ||
San Jose, CA  95134, (408) 526-8104                ||||      ||||
email: [email-masked]       CCIE #2100      ..:||||||:..:||||||:..

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 27 Oct 2002 18:22:49 -0800

Iljitsch van Beijnum wrote:
> I don't see any relationship with interdomain multicast, so 
> the fact that this has been hard to deploy in the past (and 
> unless I'm mistaken the scalability problems have now been 
> largely solved) doesn't say anything about translation mechanisms.

Passing around state between administrative entities is always a trust
problem.

> 
> Anything that happens in end-hosts should scale well. Moving 
> the functionality to a different box outside, but still close 
> to, the end-hosts should also scale as long as it's possible 
> to deploy an arbitrary number of those boxes = no hard state. 

As long as all participants are the same adminstrative entity, scaling
is not a serious problem.

> Content delivery systems often use complex NAT setups to 
> balance the load and provide redundancy. Since what we're 
> proposing here is simpler than NAT, I see no reason why it 
> wouldn't work or scale.

But those content systems are run by a single entity. When multiple
parties are involved, the translation is done at a higher layer.

> 
> And if for the truly huge networks this solution isn't 
> viable, they can always use IPv4-style multihoming. (But 
> they'd still need to implement all of this in order to be 
> able to talk to others who use multi-address
> multihoming.)

We will end up with a system that looks like IPv4 muti-homing to the
sites that want that, but scales better for the service providers.
Anything less on either front is a non-starter.

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Oct 2002 11:11:32 +0100 (CET)

> Passing around state between administrative entities is always a trust

I don't think we are doing that here, unless you count the fact that the
administrative domains where each endpoint is located contain state that
must match that in the other, but this is normal TCP behavior.

Compare to NAT: usually, both the NAT box and the host sitting behind it
are part of the same administrative domain, or there is another reason
there is implicit trust. (For instance, the NAT box is located at a
service provider and you pay your service provider to be trustworthy to
some degree.)

Obviously, having the multihoming functionality in a potentially hostile
box isn't going to fly.

> Anything less on either front is a non-starter.

Truly huge in this context would be fortune 500 or something like that.

For smaller, but still reasonably large sites, having the multihoming
functionality in each host is still too much headache, that's why I
think it's important to be able to offload the necessary processing to a
relatively small number of boxes at the edges of the network. To the
internal network this will look like traditional IPv4-style multihoming,
to the service providers it looks like single homing. The only downside
is that the other end has to implement something similar. That's why we
also need to have it in the host stacks, even for hosts that don't
multihome themselves.

---

From: "Michael H. Lambert" <[email-masked]>
Date: Mon, 28 Oct 2002 09:01:07 -0500

--On Monday, 28 October 2002 11:11 +0100 Iljitsch van Beijnum 
<[email-masked]> wrote:

[...]

> also need to have it in the host stacks, even for hosts that don't

Can these boxes (which in essence are multihoming policy servers) exist 
only at the edge of the enterprise network, or do they have to live at each 
level of the internal routing hierarchy?  A host with interfaces on 
multiple subnets has to make the same decisions about address selection 
when reaching an internal destination as when reaching an external one.  I 
guess the implication is that a solution which is routing-protocol agnostic 
is more scalable than one which isn't.

Michael

+-----------------------------------------------------------------------+
| Michael H. Lambert, Network Engineer           Phone: +1 412 268-4960 |
| Pittsburgh Supercomputing Center               FAX:   +1 412 268-8200 |
| 4400 Fifth Avenue, Pittsburgh, PA  15213       [email-masked]        |
+-----------------------------------------------------------------------+

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 30 Oct 2002 12:13:54 -0800

Iljitsch van Beijnum wrote:
> ... The only 
> downside is that the other end has to implement something 
> similar. 

And you need a protocol to pass around the translation mappings to the
other end so they can undo it. When the other end is a foreign network,
why should they trust or accept the origin site?

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Oct 2002 21:38:02 +0100 (CET)

> why should they trust or accept the origin site?

If the level of trust is zero to begin with, there should be no problem
extending this "trust" so a third party.

However, there may be some unexpected cases. For instance, an untrusted
host tries to bind a trusted address to the connection and then inherits
the higher level of trust. I'm sure we can work all of this out when
there is something concrete on the table.