Subject: RE: The state of IPv6 multihoming development

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 22 Oct 2002 19:55:03 +0200

> > The benefit of multi-homing has a price - the only 
  > question is, who's going
  > > to pay the price? Simple fairness demands that it *ought* 
  > to be the entity
  > > which directly benefits. Multiple connectivity-based 
  > addresses do this; the
  > > end-site has to pay the bulk of the cost (in complexity, etc).
  > 
  > So who benefits if Google is multihomed? The user or the server? Or
  > both?

=> Why would Google want to be multihomed? Perhaps
to ensure that they're online 24/7? And why do they
want to do that? Perhaps so that they can maintain/increase
their customer base/profits. If that's why they do it
then it would make sense to make them pay for it.

Hesham

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 22 Oct 2002 18:16:48 -0400

> From: "Craig A. Huegen" <[email-masked]>

    >> there are a number of basically feasible paths you can take to support
    >> *widescale* multi-homing.
    >> First, you can use multiple connectivity-based addresses. .. Second,
    >> you can re-use a mobility mechanism. Third, you could  use a radical
    >> addressing architecture that assigns addresses automatically, based
    >> on actual connectivity topology.

    >> I don't know of any others. Do you?

    > Given those three and those three only 

Hey, I did ask if you know of any others. I'd be very interested in any
additional alternatives you can outline. (Excluding schemes of the form "let
the routing do it", like the existing IPv4 solution, and PI addresses.)

	Noel

---

From: [email-masked] (Sean Doran)
Date: Tue, 22 Oct 2002 23:40:01 +0000 (GMT)

|     >> First, you can use multiple connectivity-based addresses. .. Second,
|     >> you can re-use a mobility mechanism. Third, you could  use a radical
|     >> addressing architecture that assigns addresses automatically, based
|     >> on actual connectivity topology.
|
|     >> I don't know of any others. Do you?
|
|     > Given those three and those three only 
|
| Hey, I did ask if you know of any others. I'd be very interested

Well, you could automatically adjust the topology to match a 
relatively static layout of addresses (so we would call this
address-based connectivity).

Although I imagine this would be done at a layer below that of IP,
I accept that one could see this as a form of mobility mechanism,
or as a means for achieving geographical IP addressing.

Whether moving the mechanisms handling the work of dynamic change
to the topology to a lower layer is as practical as dealing with it
at a higher layer (as in your option one), I could not say.

	Sean.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 22 Oct 2002 17:30:13 -0700

> Sean Doran wrote:
> If there is consensus, we will last call it.

We heard that song a year ago in this highly productive meeting we had
in Salt Lake. What is the excuse for being one MORE year late than we
were a year ago, this time?

Michel.

---

From: [email-masked] (Sean Doran)
Date: Wed, 23 Oct 2002 00:48:32 +0000 (GMT)

| I sincerly apologize - the negative tone was not intended, but rather I wanted
| to express the frustration which I personally have experienced when trying to
| promote IPv6 to groups of IT specialists who have been reluctant to see the
| benefits of IPv6. I am drawing from my own personal experience where I have
| been attacked on this very topic.

I understand.  We all have our moments of frustration and catharsis.
Unfortunately, they tend to be contagious on WG mailing lists, 
thus the vaccination shot from me and Dr. Randy.  :-)

	Sean.

---

From: [email-masked] (Sean Doran)
Date: Wed, 23 Oct 2002 00:57:25 +0000 (GMT)

[broken record alert]

Craig:

| * simple to implement and operate for the enterprise
| * network infrastructure visibility into alternative paths such that
|   policy decisions may be made on paths by the infrastructure, not the
|   host
| * unique, host-aware end-to-end addresses so poorly-written applications
|   (in use in IPv4 today) will work

Great.  Perhaps you can suggest some text that could
be incorporated into the requirements draft, if you
think these points are not already there?  

Even a paragraph or two elaborating each point would be useful.

The WG is here to discuss any text you come up with.

	Sean.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 22 Oct 2002 22:43:33 -0700

Ran,

>> Iljitsch van Beijnum wrote:
>> 4. Work on geographical aggregation, especially by getting
>> an address allocation mechanism that supports this off the
>> ground.

> RJ Atkinson wrote:
> At best, a different term needs to be found other than
> "geographical aggregation".  At worst, this is a bad idea.

How could you voice an opinion about a solution without seing it?

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 22 Oct 2002 22:50:24 -0700

Eliot,

> Eliot Lear wrote:
> More importantly, however, I believe the document is actually
> an impediment to moving forward. One can view the document in
> two ways, and neither is positive. Either the points made in
> the document are so obvious as to not be worth writing down,
> or they are so constraining as to make the resulting solution
> not worth implementing.

I strongly agree.

> The question then turns to this: should we revisit the
> requirements document, or simply discard it and place effort
> more along the lines of  the note sent by Iljitsch van
> Beijnum?  It's not that the document is completely wrong.
> I just don't want architects to be so bound by it that we
> end up with something less lasting or useful.

If it was called "recommendations" instead of "requirements" it would
then be design guidelines instead of making it impossible to deliver.
This requirements doc is like a letter to Santa Claus.
Dear Santa,
This is what I want for my IPv6 multihoming solution.
[..] it needs to be perfect.

> Let's have the engineering tradeoffs on the table.

It appears that the chairs and some other politically powerful members
prefer the status quo (do I need to post quotes from this very mailing
list)? Please please say yes.

It also appears that the charter says that's what we should have been
doing 18 months ago:
> APR 01 Begin consideration of approaches and proposals that could
> be pursued.

Apparently, some people have trouble reading charters in here.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 22 Oct 2002 22:59:01 -0700

Craig,

> Craig A. Huegen wrote:
> Adoption of IPv6 in enterprises REQUIRES multihoming. It's not a
> "nice-to-have".  Without it, IPv6 in enterprises is limited to
> the labs.  If this means we have to accept some type of PI
> addressing in the near-term, then so be it, with the condition
> that those using it are given time frame <x> to migrate to the
> Ultimate Multihoming Solution in the future.

I have come to agree with this compromise. Reality check: IPv6 does not
exist. It does not exist because I can't get over v6 to www.etrade.com.
I can't get to www.cnn.com. I can't get to www.yahoo.com.

And yes, I can get over v6 to Cisco because I have 6bone tunnels, that's
why I use IPv4.

> As for the original multi-PA multihoming solution, it doesn't
> fly in an enterprise.
> [sniped the reasons]

I agree too. 

> If the goal was to design a theoretical protocol without
> end-user operational considerations that can keep DFZ routing
> tables under 16k prefixes, then we're doing a good job at
> designing multi-homing. If the goal is to gain adoption by and
> reliability for the end users of the IPv6 internet, we're
> failing.

Ditto.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 22 Oct 2002 23:05:46 -0700

From: J. Noel Chiappa [mailto:[email-masked]] 
> So there's another possible solution for people who really
> want to multi-home: use IPv6 Mobility.

This does not address enterprise concerns at all.

Michel.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 23 Oct 2002 14:19:49 -0400

> From: Randy Bush <[email-masked]>

    > perhaps this wg should work on solutions to the routing problems
    > presented

Let me make sure I understand you. You're saying: "let's see if we can
find a working design where multi-homing is supported entirely in the
routing"? I.e. distant host S emits packets with destination address D,
and they can come in to D through a number of different paths?

That would cover what some people call "site multi-homing"; i.e. all the
hosts have a single interface, but the group of hosts has multiple paths
to the network. What about "host multi-homing", where a host has several
different interfaces - would you like to see the same thing there? I.e.
the packets automatically go in which ever interface to D is working?

	Noel

---

From: "Michel Py" <[email-masked]>
Date: Wed, 23 Oct 2002 23:27:52 -0700

Greg,

> Greg Maxwell wrote:
> Contentential boundries are the only ones that make sence..
> Any tighter and there is too much movement and interconnection.
> Contentential bounderies also make sence because they could be
> aligned with the addressing authorties.

You are not the first one to make this argument.

> But.. They don't buy us much.. At best they would reduce
> the routing table by a factor of 4 or so, probably less..

Something of that order. That being said, a factor 4 is 4 years of extra
time developing a better solution. If the better solution does use the
same addressing scheme, it does make sense.

> I believe that any tunnling purposal would be an incomplete
> solution and something of a hack. I really don't think that
> anyone is arguing that such a solution is realistic due to
> it's inelegance. (anyone feel free to correct me)

$100 cash to find a flaw in this one:
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt
(please read the open issues too)

Michel.

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 24 Oct 2002 17:09:42 +0200

> >   > So what's the use then? We don't multihome because we like
  > >   > having many addresses, but to survive failures.
  > 
  > > => That's why I asked: "How much interruption is acceptable?"
  > > What do you mean by survive failure? Is it ok to lose 150 ms
  > > of traffic? Or are you asking for a seamless survival failures
  > > (i.e. zero interruption). Frankly I don't think that a 
  > 100 - 200 ms
  > > interruption is a big deal, considering that this failure is not
  > > something that will happen once a minute.
  > 
  > The shorter the better, but anything under 15 seconds is 
  > good enough,
  > IMO.

=> ok, thanks. 15 seconds is eternity for MIPv6, I don't
think meeting this time restriction is an issue. 

  > > => I'm confused. Why would a home Agent become unreachable??
  > > You seem to assume that the HA must be located in the
  > > upstream provider's network (that's the only interpretation
  > > I can think of for your statement above). The HA can be located
  > > in the mutlihomed enterprise.
  > 
  > Ah, I see now. I'm not sure where exactly I envisioned the 
  > home agent,
  > but I didn't consider moving it to a place that is 
  > multihomed through
  > separate means. Still, we'd need a good solution for all 
  > the home agents
  > (at least this will lessen the problem a good deal) and 
  > having a single
  > point of failure somewhere isn't optimal.

=> Sure, but corporate networks are full of them :). 
This is an important problem to solve IMHO, whether
it should be done in this WG is a different discussion. 

Hesham

---

From: "Michel Py" <[email-masked]>
Date: Thu, 24 Oct 2002 09:15:52 -0700

> Randy Bush wrote:
> as i am not aware of anyone filtering v6 announcements
> at the moment (well, other than maybe at /48 or something),
> perhaps this wg should work on solutions to the routing
> problems presented and assume that, if reasonable aggregation
> is one of those goals and is met, that the isps will act
> rationally.

I and lots of other people filter at /35, soon to be /32 for the 2001::
space and at /24 or /32 (depending on the range) for the 3ffe:: space.
Which is perfectly in line with the whole idea of aggregation.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Thu, 24 Oct 2002 08:38:18 -0700

Tony,

> Tony Hain wrote:
> Is it the most efficient use of address space? No, and the
> document recognizes there is a clear trade-off being made
> between simplicity and efficiency. Are there other ways to
> achieve the listed goals? Probably, and when I see something
> that looks more operationally viable I will back off. 

I agree with your ideas, and they were a major contributor to this:
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt

I suggest you accept the fact that the chances of getting the /4 you
need are zero. As I said before, I would be the strongest supporter of
your scheme if it stood a chance.

Michel.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 24 Oct 2002 12:31:02 -0400

> From: "Michel Py" <[email-masked]>

    >> If you have a host which is multi-homed to widely spaced
    >> points in the topology, there's unlikely to be a routing-based
    >> solution, i.e. one where that host has only one address.

    > I totally disagree

I'd be interested to hear what your reason is for thinking that this
statement is incorrect.

    > Would you be more specific about why you find this unlikely, and
    > what you call "widely spaced" (which I read as "from different PA
    > blocks).

Addresses are a symptom of the problem, not the cause.

By "widely spaced ... in the [connectivity] topology", I mean just that: the
host H is connected to the Internet in two places, which are far apart in the
connectivity graph. I.e. the shortest path between the two connection points
(not through the host) is long.
E.g. suppose this host is connectes to two local ISP's L1 and L2. Further
suppose these are connected to upstream larger ISP's U1 and U2
(respectively). Further suppose that U1 and U2 don't peer near the points
where the local ISP's connect to them. All hardly unlikely, but you've
probably got at a 15-hop path, or something.

No matter *what* kind of address you give the host (be it connectivity-based,
or "provider-independent"), if one of the interfaces is down, the routing
table at the midpoint of the path (i.e. where incoming traffic is going to
have to decide which way to go, "left" or "right") is going to have to have a
currently correct entry *for this specific host* if the traffic is going to
get there. In other words, you have to have host routes, propogated over a
wide scope (back to a major top-level ISP peering point, in the example
above). This is not feasible.

That's why I say "addresses are a symptom of the problem, not the cause",
because the problem is the same no matter what kind of addressing scheme you
are using.

    > There is a difference between the solution itself using multiple
    > addresses and each host using multiple addresses. If each host has to
    > use multiple addresses, I regret to report that Craig's statement is
    > not an opinion, but a fact. Any people that disagree with this and that
    > actually have renumbered a 1000+ subnet enterprise network, please
    > speak up

Who's talking about (manually, I assume) renumbering a 1000+ subnet network?
IPv6 hosts get the high bits of the globally-unique addresses from their
routers, right? Why is it so hard/insecure to get two (or more) instead of
one?

	Noel

---

From: "Michel Py" <[email-masked]>
Date: Thu, 24 Oct 2002 13:13:45 -0700

> Rob Rockell wrote:
> So we are back to square one, based on this
> document...?

I don't think so. This document is for routing. There is nothing that
says that multihoming should be limited to routing, although it is clear
that part of the solution will more than likely be a routing solution.

Michel.

---

From: "Tony Li" <[email-masked]>
Date: Sun, 27 Oct 2002 16:37:59 -0800

|   On Sat, 26 Oct 2002, Tony Li wrote:
|   
|   > So we're going to institutionalize support for layering 
|   violations?
|   > This doesn't seem right.
|   
|   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?

I have no idea.  If folks decide not to do some kind of modification
to support IPv6, they're going to have problems as soon as they try
to put 128 bits in a 32 bit entry.  ;-)

In my mind, the correct thing to do is to change it so that the
host identifier can go there, but keep the locator out of the 
upper layers.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Mon, 28 Oct 2002 00:14:30 -0800

|   If the multihoming processing is done outside the host, 
|   then packets all
|   packets must be presented to the host with the identifiers 
|   as the source
|   and destinations addresses. If this is done inside the host 
|   then this
|   isn't strictly required, but it is likely the transport 
|   layer will want
|   to see just the identifiers so the IP layer will have to 
|   reconstitute
|   those.

Fair enough, but if we go down the GSE direction, the packet has
the identifier in it already when it arrives at the host and the
identifier is never modified in flight.  In my book, that gives us 
the desired end-to-end connectivity.

|   > The host should select the identifier, both for itself and for the
|   > destination.  The border router selects the locators for both the
|   > source and the destination.  This allows the border 
|   router to implement
|   > policy in a reasonable way.
|   
|   Agree. However, do we want to involve a border router in the locator
|   discovery process?

If you want to address Craig's concern about being able to affect locator
policy for the entire enterprise in a scalable way, you kinda have to.  

|   The basic idea is simple: the IP addresses the transport layer uses
|   become the identifiers of a session. In transit, these identifiers
|   may/must be replaced by locators, but they identifiers are restored
|   before the packet reaches the transport layer at the other end.

Yes, but if you do wholesale identifier replacement, then you get into
trouble with protocols carrying identifiers around above the network layer.

A nice way of fixing this is to establish the principle that locators
are never carried around above the network layer, only the identifier.

|   Discovery is hard to do, but if we can solve the associated 
|   problems it
|   provides a much stronger mechanism because then a host can have a
|   single, portable identifier. It would be good if we could provide an
|   upgrade path from negotiation to discovery.

I have to agree. I prefer discovery as well.

Tony

---

From: "Michel Py" <[email-masked]>
Date: Mon, 28 Oct 2002 08:16:35 -0800

> Michael Lambert wrote:
> Can these boxes (which in essence are multihoming policy
> servers) exist only at the edge of the enterprise network,

Yes.

> or do they have to live at each level of the internal
> routing hierarchy?

No.

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

That's the point, precisely: These boxes would enable hosts on the
internal network to have only one address.

> I guess the implication is that a solution which is
> routing-protocol agnostic is more scalable than one
> which isn't.

At the host level, definitely. At the router level, there is a fine line
between agnosticism and awareness, as there are tremendous advantages
for the box that makes the multihoming decisions to know the network
topology.

Michel.

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 30 Oct 2002 23:07:47 +0100

> >   > If the level of trust is zero to begin with, there should
  > >   > be no problem extending this "trust" so a third party.
  > 
  > > => Is this an argument for global PKI? Presumably
  > > this protocol would work between arbitray sites?
  > 
  > No, this is an argument for not building elaborate security 
  > mechanisms
  > when there is nothing to secure. 

=> Hmm, see below, now I have a _lot_ of questions :) 

If someone who I don't 
  > know visits my
  > web site 

=> Why do you assume you don't know this someone? 

or connects to my mail server, and then halfway through the
  > session the connection is transferred to another IP addres, 
  > why would I
  > care? 

=> Because:
- The new source address (that you'll reply to) could be someone 
else that will accuse you of bombing them
- Your server might be offering secure internet banking and 
suddenly it's not so secure
- You might be a popular server and all of a sudden people
can't reach you because their traffic is diverted to a victim.
Maybe the victim will become popular :) 

I'm pretty sure there are more reasons.

The only time this is dangerous would be when I 
  > communicate with a
  > trusted host but if this trusted host tells me it has 
  > another address
  > then presumably, I should trust this information as well. 

=> Yes but how did you establish that trust? 
The identifier used is the key problem here. 
[email-masked] tells you nothing about 
whether I can divert traffic from 3ffe::1 to ABCD::1. 
This is the exact problem we had in MIPv6.

Obviously
  > things are different when someone at an address I don't 
  > know tells me
  > she is a trusted host. Then she has to present credentials.

=> Careful how you pick "credentials".

  > No, but that doesn't mean we have to start with this part.  :-)
  > 

=> oh no, it's MIPv6 all over again :) trust me if you
don't start thinking about this early on it won't be fun later !

Hesham