Subject: RE: The state of IPv6 multihoming development

From: "Tony Li" <[email-masked]>
Date: Sat, 26 Oct 2002 20:47:33 -0700

|   > |   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.
|   
|   Unless I'm mistaken nobody here has proposed a solution 
|   that has this
|   problem.

Unless I'm the one that's mistaken, the original complaint was that
changing bits (and specifically -- the locator) at the border router
would break applications that carry full addresses around in them.

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

Ok, if apps (or the underlying transport) can use more than one address, 
then that implies that the host has to make a decision about WHICH address
to use, which is what Craig was objecting to in the first place.  If the
host has to decide, then it's making a routing decision and it certainly
shouldn't have enough information to make that decision.

Thus, the suggestion is to push the decision to the border router and 
move the policy information there.  The host still specifies the end
system identifier, but the border router then determines the locator.

Tony

---

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

Tony Li wrote:
> ...
> then that implies that the host has to make a decision about 
> WHICH address to use, which is what Craig was objecting to in 
> the first place.  If the host has to decide, then it's making 
> a routing decision and it certainly shouldn't have enough 
> information to make that decision.

I know Craig said the host is making a routing decision, but it isn't.
Even if it tried it could be overruled by the routers for the outbound
packets. The only thing the host can decide that might even come close
to a routing decision is the address that the remote node will use to
talk back toward it. This is not a routing decision, but for those who
are into fine-grained TE, it might be considered a policy decision. 

Even if the origin node chooses an address that is overwritten by a
border router, there is absolutely nothing the origin AS can do to
enforce/influence the routing policy of the foreign network manager. As
the packet gets closer, there might be an opportunity to create a
localized gravity well, but only if there is no filtering going on
between the providers. Since the origin network can't enforce reverse
path routing decisions, the idea that the origin host is making any kind
of routing decision is completely bogus. 

Tony

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 27 Oct 2002 09:50:25 +0100 (CET)

> would break applications that carry full addresses around in them.

How can this be a problem if the bits are changed back later?

> shouldn't have enough information to make that decision.

That's why it would be good if this functionality can be moved outside
the end host to a place where this information is available.

If this is done on the host, this host must select two addresses: the
source address and the destination address. If we assume the source
address must match the outgoing ISP, there are two ways to handle this:

1. The host selects a source address, and the routers choose the right
   ISP to match the source address.
2. The host selects a source address, and the routers don't care and
   route as per the destination address so the packet is filtered if the
   host selected the "wrong" source address.

1. would seem to provide better functionality. However, if the ISP the
host implicitly selects by its choice of source address is unable to
deliver the packet, the host must jump to another source address, just
like it should if it selects the wrong source address in the case of 2.
So for the host, the solutions are really equivalent and the choice
should depend on the needs of the routers rather than the needs of the
host.

Then there is the destination address. If all destination addresses are
routed/routable over the same ISP (which would alway be the case in
source address handling mechanism 1. and a good percentage of the time
in mechanism 2.) the host has no reason to prefer one over the other, so
if the other end requests the use of another destination address, there
is no reason to deny this request. Note that in the presence of source
address mechanism 1. you'd have four rather than two functional paths in
the following topology:

    A---C
   / \ / \
src   +   dst
   \ / \ /
    B---D

src -> A -> C -> dst
src -> A -> D -> dst
src -> B -> C -> dst
src -> B -> D -> dst

can all be used.

> system identifier, but the border router then determines the locator.

That would be one way to do it. The (border) router could also
communicate its preferences back to the host. Either by dropping enough
packets to force a rehoming event, or by sending back a message or
some such. The host could set the router alert option for the negotation
packets and the router could inspect these and let its preferences be
known.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 27 Oct 2002 18:51:22 +0859 ()

Tony;

> system identifier, but the border router then determines the locator.

What a stupid suggestion.

It makes the border router the single point of failure totally
destroying the benefit of multihoming.

If you try to have multiple border routers with complex redundancy
protocol, there always is simple failure mode of the protocol.

> If the

Hosts, of course, are the only intelligent entities of the Internet,
must make as much decision as possible and should have all the
information.

Never say IPv6 global routing table is to large.

							Masataka Ohta

---

From: "Craig A. Huegen" <[email-masked]>
Date: Mon, 28 Oct 2002 11:01:48 -0600 (Central Standard Time)

> are into fine-grained TE, it might be considered a policy decision.

There's a significant difference between being able to override normal
path selection via significant manual policy configuration and performing
path selection as a normal path of course.

As an example, www.cisco.com may have addresses of 2001:420:9c3b:1::2 and
2003:602:b1cd:1::2.

client.example.com selects 2001:420:9c3b:1::2.  example.com's routing
infrastructure doesn't know of the alternate path (if 2003:602:b1cd:1::2
were used as the destination IP address). Sure, example.com *could* put in
a policy to look for packets to 2001:420:9c3b::/48 and force it down a
different path, but it's completely manual and example.com's border has
absolutely no visibility of this.  Instead, example.com is most likely to
hand the packets for 2001:420:9c3b::/48 to its best path to 2001:420::/32,
the provider aggregate, unless manually overridden.  The infrastructure
has no way to evaluate an alternate path.

What's most important here is that the routing infrastructure has
absolutely no visibility that the destination 2001:420:9c3b:1::2 has an
alternate path, to the address 2003:602:b1cd:1::2.

/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: "Craig A. Huegen" <[email-masked]>
Date: Mon, 28 Oct 2002 13:39:39 -0600 (Central Standard Time)

On Sat, 26 Oct 2002, Tony Hain wrote:

> [...]

Remember that simplicity is key for both providers and enterprises.  The
more exceptions that you need to configure in the routers, the higher the
cost.  What you're suggesting is that it's operationally feasible to
overrule many individual /48's for each end-user to push it down a
different path, which requires significant research and configuration for
each given end-user.

The IPv4 BGP model is much better at this because policy can be applied to
paths, not individual /48's for end-users.  This can range from a specific
end-user to aggregated paths from a specific end-provider to a large group
of paths from multiple providers -- it's not limited to overrides for
specific end-users.

Here's an example:

        P1---
         |   \
         |    \
CC1-----P2-----CP1
   \     |    /
    \    |   /
   SP1--P3---

CC1 = content consumer
CP1 = content provider
P1,P2,P3 = tier 1 provider
SP1 = sub-tier-1 (resale) provider

P1 allocated 2001:42c::/32
P2 allocated 2001:445::/32
P3 allocated 2001:49c::/32

SP1 allocated 2001:49c:100::/40

CC1 allocated 2001:445:b1c::/48 (P2), 2001:49c:18f::/48 (SP1/P3)
CP1 allocated 2001:42c:91cb::/48 (P1), 2001:445:8cb1::/48 (P2), 2001:49c:10c::/48 (P3)

host1.CC1 has addresses:
2001:0445:0b1c:005a::1f
2001:049c:018f:005a::1f

host1.CC1 sends DNS lookup for www.cp1, gets back:
2001:042c:91cb:0001::5
2001:0445:8cb1:0001::5
2001:049c:010c:0001::5

Using address selection rules proposed, host1.CC1 selects SA of
2001:049c:018f:005a::1f.  host1.CC1 selects DA of 2001:049c:010c:0001::5.

Assuming default routing (remember, keep it simple and keep exceptions to
an absolute minimum), traffic from host1.CC1 to www.CP1 will go via SP1
to P3 to CP1 (destination address follows P3's /32 aggregate).  Traffic
from www.CP1 to host1.CC1 will go via P3 to SP1 to CC1.  This is more
likely to be a suboptimal path, given more organizational hops.

The host's selection of source and destination addresses has selected the
paths, and the network infrastructure has no visibility whatsoever that
packets to host www.CP1 has an alternate path via P2.

The only way that the network operator of network CC1 can send this traffic
down a better path (P2) is to perform research on paths to CP1, identify
a better path, configure a manual entry to hijack traffic
going to 2001:049c:010c::/48 and send it down P2.  Now imagine doing this
for thousands of destination AS's.

A previous suggestion has been to withhold the 2001:049c:018f:005a prefix
from being a valid source address for host1.CC1; however, this isn't
reasonable as there may be many best paths from host1.CC1 to other networks
via SP1.

I'll admit that BGP isn't a perfect solution - but it at least allows the
network operator to have better, easier control over sets of paths (say,
generally preferring P2, or de-preferring SP1/P3) as opposed to making
individual, per-end-user policy specifications.

---