Subject: Re: Transport level multihoming

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 7 Aug 2001 17:57:32 -0700 (PDT)

> Doesn't similar constraints apply to any transport level solution ?
> I am not sure how a transport solution works when one of the
> upstream ISP's link fails. Isn't this one of the requirements ?

I don't think that an end-host level solution without address
translation can work effectively
in a decentralized multi-tier multihoming scenario because the end-hosts'
addresses have to be added/deleted/modified whenever a provider
adds/deletes/changes its providers. Address translation has to be used,
but this will be rendered less effective in the
transport level multihoming case because end-hosts will now have to be
aware of the final routable addresses so that they can advertise them in
the payload, assuming we don't want to change every app at the other
end-point to make it aware of multiple addresses.

A tunneling (or any network-layer)+translation based solution would not
have this problem.

Another problem with the transport-level multihoming is that
the number of failure modes that can be tolerated in a multi-tier
multihoming are decreased. For
example, consider the scenario where a site is dually-multihomed, while
each of the providers are triply multihomed to three different providers
each. The question is---how many addresses do the hosts in the site have?
If it is two, then it means that the site can not tolerate failures in four of
the providers twice removed from it. If it is six, then it means we are
exposing the site to addressing issues not related to it.

A tunneling+translation solution solves this problem cleanly by using only
two (or
as many addresses as there are providers) provider-independent addresses
to the site. The site's immediate providers would independently translate
the addresses to meet their own load-balancing needs without leaking the
site's prefixes. When a failure between the provider and its higher-up
is detected, by creating two tunnels between itself and the higher up via
the two working ISPs, a provider can ensure connection survivability and
can even load-balance failed traffic among the working providers. The
tunnels are only one "level" deep, and are transparent to all others,
including the original site.

thanks,
ramki

>
> thanks
> -mohan
>
> > Date: Tue, 07 Aug 2001 17:01:51 -0500
> > From: Brian E Carpenter <[email-masked]>
> > X-Accept-Language: en,fr
> > MIME-Version: 1.0
> > To: Greg Maxwell <[email-masked]>
> > CC: Ben Black <[email-masked]>, Randy Bush <[email-masked]>, Peter Tattam
> <[email-masked]>, [email-masked]
> > Subject: Re: Transport level multihoming
> > Content-Transfer-Encoding: 7bit
> >
> > Greg Maxwell wrote:
> > >
> > > On Tue, 7 Aug 2001, Brian E Carpenter wrote:
> > >
> > > [snip]
> > > > On the other hand we know that major restructuring of applications isn't
> going
> > > > to happen - that's the real world. So if we have to do work in the
> transport
> > > > layer, the transport layer is going to have to hide most of it below some
> > > > sort of socket API. I can't see any reason in principle why that API
> > > > would have to expose a bunch of addresses, even if it turns out that
> > > > multi6 requires more than one. A "primary" address per host would be
> enough
> > > > to expose to the middleware.
> > >
> > > If the primary address is functional at connection setup time, then, yes
> > > it could learn the other transports from the remote end. However, what do
> > > you do if the primary is down? The only solutions I can think of either
> > > require the applications to rotate the address passed to the API, or
> > > require the transport to consult DNS (what an ugly kludge and layering
> > > violation THAT would be!).
> >
> > There is *always* an abstraction layer above which a single handle identifies
> > the other party in a session (and probably no handle at all identifies
> > "this" end of the session). So whatever layer is the highest layer to
> > be aware of N addresses, there is always a layer above that (conceptually
> > at least) that has a single handle for that set of N addresses.
> >
> > All I am saying is that this abstraction layer may just as well be a socket
> > API, and that single handle may just as well be one of the N addresses - and
> > if you do it that way, you minimise the impact on existing apps layer logic.
> >
> > It's probably sloppy to write as I did of a "primary" address being the
> > handle; it's just an arbitrary choice among the N addresses available.
> > It's the one that gethostbyname (equivalent) chooses to return to you;
> > it might conceal a bunch of others from you below the socket API,
> > and use them as needed for multihoming or whatever other cookery it
> > needs to do.
> >
> >    Brian
> >
>
>
>

---

From: Peter Tattam <[email-masked]>
Date: Wed, 8 Aug 2001 12:07:02 +1000 (EST)

On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote:

> adds/deletes/changes its providers. 

I think I was trying to say was that this seens to me to be the site
renumbering scenario. At the Tokyo meeting, this was discussed and the
following recommendations considered.

1) renumbering would be infrequent and usually highly coordinated.

2) when renumbering occured there would be considerable overlap where both sets
of addresses would be in use at the same time.  This is simply an extended
multihoming scenario with certain prefixes being deprecated.  The overlap
should be long enough to allow deprecated addresses to disappear from the
network.

The issue of management of site renumbering in a multi tier environment does
leave open many management questions.  One throny issue is that higher tiers
would have to inform lower tiers of their intentions and lower tiers would have
no choice in the matter in reality.  How this is perceived by the wider
community is a public relations excercise.  The public has grown accustomed to
the fallacy that once they get some address space, they sort of own it or at
least lease it.  The concept of the address space being fluid is going to take
a lot of reeducation.

I believe a successful solution to multihoming in Ipv6 is to make the address
space fluid enough to facilitate renumbering and transport (site) level
multihoming but sticky enough that it doesn't all fall apart.

The BGP approach takes the address space as a fluid mass and tries to mold it
to the current routable topology.

The site level approach considers the address space as a skeleton upon which
you can apply the flesh of routing.  No matter how you shake it, the skeleton
is rigid as it is based on relatively static allocation policies.

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: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 7 Aug 2001 19:43:00 -0700 (PDT)

> least lease it.  The concept of the address space being fluid is going to take

While I think that renumbering is a technical issue that is non-trivial to
remove because it has wide management implications, I am willing to ignore
this in this context.

But, like I said, it certainly has a great role to play in the amount of
redundancy and availability it provides (if an ISP multihomes to three
providers while it
uses one provider's prefixes for its sites, then I think multihoming is
not being used to its fullest potential). The ISP may also be using its
connectivity bandwidth suboptimally, which I consider another strong
potential problem because the full potential of packet switching is not
being realized.

> is rigid as it is based on relatively static allocation policies.

I am not saying that we should abandon the existing routing architecture.
In fact, we would be exploiting its excellent scaling and
routing properties. All translated addresses would be providing is a
sticky point of reference for a flow around which fault-tolerance through
routing, and scalability through aggregation will be achieved.

thanks,
ramki

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Aug 2001 10:06:14 -0500

Ramakrishna Gummadi wrote:
...
> routing properties. 

Its what?? Haven't you read draft-iab-bgparch-01.txt? We don't have any
scaling left to play with. That's why we are here.

> All translated addresses would be providing is a

We invented IPv6 to avoid the need for address translation and all its
attendant problems. The argument for a multi6 solution at transport level
is to *deal with* the existence of multiple addresses and precisely to avoid
translation. There is an alternative, which is the type of architected
address translation implied by 8+8, GSE etc but please let's avoid painting
ourselves into a corner that requires both transport layer gymnastics and NAT;
that would be a catastrophe.

   Brian

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Wed, 8 Aug 2001 15:59:25 -0700 (PDT)

> that would be a catastrophe.

I think the question is: should multi6 also deal with provider
multihoming? If it should, then address translation like 8+8 would be
required because the multi6 requirements draft says that the architecture
should provide for policy-based multihoming---if untranslated addresses
are used directly by the provider's sites (single- or multi-homed), the
site is pretty much dictating the routing, and load-sharing policies.

If 8+8 or GSE or some such is used, this would preclude a transport-level
or app-level
solution because we don't want routers to modify addresses in the payload
as well. That leaves us only with network-level solutions.

Is there anything wrong in the argument?

thanks,
ramki

---

From: Jim Bound <[email-masked]>
Date: Thu, 9 Aug 2001 01:24:55 -0400 (EDT)

Brian,

I am convinced that we can help alleviate the TL issue with SCTP for IPv6.
And get it deployed in 2 years (some of us have started shipping it now as
product not prototype).  Also it is being used for SMS for test UMTS
environments now.  Also I believe SCTP can be used by small memory
footprint devices too for IPv6.

Some of us will go look at a shim for AF_SCTP esp for IPv6 so app that
does ftp  (example app only) can use SCTP without a change in source code.
But part of that work is to see the cost and effect to a vendor library
and sys call code if it can be done in production manner and not break
binary compatibility with IPv4/IPv6 app.  Don't know till we try.  But I
think so.

/jim

---

From: Peter Tattam <[email-masked]>
Date: Thu, 9 Aug 2001 16:55:36 +1000 (EST)

One question.

In a transport level multihoming scenario, should two addresses that differ in
the lower 64 bits (node address part) be considered independent nodes and
handled in the traditional manner with regard to multiple addresses?

Why I ask is that the upper 64 bits of all possible full addresses for a
particular node that is multihomed have particular properties that would be
useful to exploit in transport level multihoming.  If the lower 64 bits is not
identical between multiple addresses, it could lead to inefficiencies in a
compressed representation of the list of IPv6 addresses.  It may also be
important to some layers of any multihoming protocol to consider that addresses
which differ in the lower 64 bits would not being equivalent for the purposes
of multihoming. 

This probably smacks of 8+8 or GSD but I'm just seeking a clarification of what
the current accepted wisdom might be. 

Peter

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 9 Aug 2001 15:57:23 +0859 ()

ramki;

> Is there anything wrong in the argument?

First, you are confusing 8+8 and GSE.

GSE is certainly a variation of 8+8 but is a poor proposal
violating the end to end priciple at leastin two ways.

Secondly, 8+8 (even including GSE) is a proposal that applicaion/transport
identify hosts by lower 8 bytes only.

So, its OK for upper layers if some intermediate entity modify upper
8 bytes of source and/or destination address.

While modification by routers of GSE is not a good idea, modification
of upper 8 bytes of destination addresss can remove tunelling
of some protocol.

							Masataka Ohta

---

From: "Ben Black" <[email-masked]>
Date: Thu, 9 Aug 2001 00:38:11 -0700

> violating the end to end priciple at leastin two ways.

And the currently deployed architecture violates layers by
allowing (forcing?) applications to be aware of network and
transport addresses.  If you eliminate those violations, through
whatever method of indirection, the end to end principle can
be maintained while allowing a wide variety of solutions to
the problem of multihoming.  Religious advocacy of a certain
world view results in paralysis when faced with problems which
challenge that world view.

Ben

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Aug 2001 09:19:30 +0100

> In a transport level multihoming scenario, should two addresses that differ
> in the lower 64 bits (node address part) be considered independent nodes and
> useful to exploit in transport level multihoming.  If the lower 64 bits is
> not identical between multiple addresses, it could lead to inefficiencies in
> a compressed representation of the list of IPv6 addresses.  It may also be
> important to some layers of any multihoming protocol to consider that
> addresses which differ in the lower 64 bits would not being equivalent for
> the purposes of multihoming.

are you asking if the forwarding look-up is longest match on 64 or 128 bits?
i think the latter is mandatory.  we do allow allocation of /128s.

randy

---

From: Greg Maxwell <[email-masked]>
Date: Thu, 9 Aug 2001 08:20:16 -0400 (EDT)

> handled in the traditional manner with regard to multiple addresses?

My opinion is that:

Hosts should consult DNS to get a list of addresses associated with a name
and pass these addresses to the transport API. This set of addresses MAY
or MAY NOT be for a single host.

The transport protocol will then attempt to connect, most likely by trying
to tack up a connection with the first host on the list. The transport
level will communicate the rest of the valid addresses for the hosts.

This allows DNS to continue to round robin separate hosts, as well as
initiating link.

> which differ in the lower 64 bits would not being equivalent for the purposes

I don't believe using the lower 64 bits to identify the host is the
correct solution. For example, what happens when I want to use the
16bits of site networking to perform future-internet-like multihoming
inside my own AS (I probably wouldn't do this because of address
proliferation and because I wouldn't have scaling problems with
traditional multihoming on a local scale)?

Or a more obvious example: The 8+8 limits the minimum network that can
separately multihome to /64. On the IPv4 internet, people complain that
some providers filter their deaggregated /24 announcements!

I would have to see some pretty compelling optimizations for a change
which would effectively exclude all small institutions from multihoming.

---

From: Jim Bound <[email-masked]>
Date: Thu, 9 Aug 2001 08:47:32 -0400 (EDT)

Hi Peter,

> handled in the traditional manner with regard to multiple addresses?

Good question.  I would say yes but SCTP would permit one to treat them as
the same node yet different links (interfaces).  But I think we need to
think hard about the question and all the matrix of answers.

> which differ in the lower 64 bits would not being equivalent for the purposes

Hmmmm... I am not sure we can assume this on the lower 64 bits...I need to
dream on that...Excellent question.

/jim

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 09 Aug 2001 09:30:32 -0400

At 08:20 09/08/01, Greg Maxwell wrote:
>correct solution. 

The existence of the Privacy Address Configuration specification
for IPv6 means that the low-order 64-bits CAN NOT uniquely identify
a host.  Prior to then, using the low-order 64-bits (as proposed
by original 8+8/GSE) might have worked.  That approach cannot work
given the current state of specs.  Note well that the "privacy
extension" spec (sic) is being widely implemented and deployed in
end-systems (e.g. Windows XP).

Now one could postulate a different identifer that could be used
in things like Protocol Control Blocks to bind session state
and identity (in lieu of using IP addresses as at present).  There
would need to be some ability to map to/from that identifier to
other kinds of identifiers (perhaps IP Addresses, FQDNs) for 
this to be deployable, as near as I can tell.  There is some work
within the IRTF NSRG examining the possibility of adding such
identifiers to the Internet Architecture, but that's research
not engineering for now.

Ran
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Aug 2001 17:22:06 +0200

In your previous mail you wrote:

=> this is not fully true: HIP escaped from IRTF and just proposes
this kind of new namespace.

Regards

[email-masked]

PS: the five bullets in the HIP TODO list are:
 - key exchange
 - mobility
 - NAT traversal
 - home multihoming
 - site multihoming
So HIP is something we have to look at!

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Aug 2001 10:27:24 -0500

Given that privacy considerations will force us to accept pseudo-random lower 
64 bits, I don't think we can assume much of anything about those bits from
the viewpoint of host identity.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Aug 2001 10:35:31 -0500

> site is pretty much dictating the routing, and load-sharing policies.

I think that's a complete non sequitur. The fact that the multihoming needs
to be under policy control doesn't imply anything of the kind. It simply
implies that the multihoming decision point must be configurable by some
policy management system. It's quite orthogonal to the rest of the
solution; the range of possible policies will be determined by the solution.

> as well. That leaves us only with network-level solutions.

Yes, I think the 8+8/GSE class of solutions do indeed hide the multihoming
decision point from transport and applications, although there might still
be some indirect influence via address selection. For example if DNS returns
two AAAA records, one of which is a provider-based address like today and the
other is a GSEbis address, which one the transport layer chooses to use
would have significant effect on multihoming.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 09 Aug 2001 08:29:23 -0700

Ran,

>end-systems (e.g. Windows XP).

IPv6 nodes can have long lived 64 bit interface identifiers (usually 
created from hardware tokens) and temporary interface identifiers per 
RFC3041.  Most implementations will support both types as they serve 
different purposes.  There is a bit in the interface identifier that 
indicates whether it is a global or local identifier.  As you point out the 
global identifiers could be used with an 8+8/GSE type scheme, while the 
temporary addresses would be harder to use.

>identifiers to the Internet Architecture, but that's research

Based on our experience with global IPv6 interface identifiers, I suspect 
that any new scheme using global identifiers will have to deal with privacy 
issues to allow for anonymous communication.

Bob

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 09 Aug 2001 13:25:08 -0400

At 11:27 09/08/01, Brian E Carpenter wrote:
>Given that privacy considerations will force us to accept 
>pseudo-random lower 64 bits, I don't think we can assume 
>much of anything about those bits from the viewpoint of host identity.

Precisely so.  And they aren't merely pseudo-random, but
instead pseudo-random with *high probability* of many duplicates,
at least with the current specifications.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 09 Aug 2001 13:30:02 -0400

At 11:29 09/08/01, Bob Hinden wrote:
>IPv6 nodes can have long lived 64 bit interface identifiers (usually created from hardware tokens) and temporary interface identifiers per RFC3041.  Most implementations will support both types as they serve different purposes.  There is a bit in the interface identifier that indicates whether it is a global or local identifier.  As you point out the global identifiers could be used with an 8+8/GSE type scheme, while the temporary addresses would be harder to use.

Given that WindowsXP is shipping with the local identifier and
with a change in the local identifier with every Nth new IP session
(for single digit value of N), the majority of the end systems will
be using duplicative local-use-only 64-bit identifiers.  I'm told
that this is controlled only by a registry knob, meaning few will
know how to disable the default and fewer will actually make that
change.

For an 8+8/GSE-like schema, all systems need to have probabilistically
unique identifiers.  The current privacy spec guarantees that requirement
won't be met with the low-order bits of the IPv6 unicast address.

This isn't good or bad, just reality.  So folks looking into 
8+8/GSE-like schemas need to find/create an alternate identity space 
for things like PCBs.  This necessarily adds to the complexity
of such approaches versus the prior world order.

>Based on our experience with global IPv6 interface identifiers, I suspect that any new scheme using global identifiers will have to deal with privacy issues to allow for anonymous communication.

As near as I can tell, there is no conflict between a requirement
for a probabilistically unique ID and anonymous communication
-- it simply needs to be accounted for during design of the 
identifier to be used.

Ran

---

From: Steve Deering <[email-masked]>
Date: Thu, 9 Aug 2001 16:10:40 -0700

>won't be met with the low-order bits of the IPv6 unicast address.

The low-order 64 bits of an IPv6 "privacy" address *is* probabilistically
unique, given that it's a pseudo-randomly-generated 64-bit number.
How low does the probability of collision have to be for your purposes?

>for things like PCBs.

Or find/create an alternate locator space (e.g., in an encapsulating
IPv6 or other kind of header), and treat the 128-bit end-to-end IPv6
address as the globally-unique identifier.

Steve

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 09 Aug 2001 19:32:27 -0400

>unique, given that it's a pseudo-randomly-generated 64-bit number.

We disagree on the math here.  My analysis, based in part on discussions
with some folks who have running code for hosts, is that the low-order 
bits in the "privacy" case will probably collide frequently. 
In particular, approaches that use the MAC of the NIC card as seed
will usually generate visibly more collisions than those that start 
with an appropriate number of Heisenberg-quality random bits (RFC-1750).
The former appears to be a common approach, the latter very uncommon.
Along similar lines, a common issue with IPsec implementations is
that most folks don't understand randomness issues and how to 
implement them properly (despite RFC-1750's specific advice).

As I noted earlier, this isn't a criticism or anything necessarily bad,
it is merely the reality of the situation we have on the ground.
Folks need to design accordingly.

>How low does the probability of collision have to be for your purposes?

Very low.  Not zero.  For example, one could live with collisions with
the same frequency that one would happen to get two different NIC cards
with the same burned-in MAC address (e.g. due to factory error).

Ran
[email-masked]

---

From: Peter Tattam <[email-masked]>
Date: Fri, 10 Aug 2001 12:06:11 +1000 (EST)

> which would effectively exclude all small institutions from multihoming.

I am not precluding this.  Perhaps I should expand the argument to relax the
restriction on the 64 bit boundary and say that if a site is multihomed with N
upper bits, can we consider that if the lower 128-N bits are the same, they can
be considered the same node address.  Anything else is another address.

Peter

---

From: Peter Tattam <[email-masked]>
Date: Fri, 10 Aug 2001 12:09:57 +1000 (EST)

I am not talking about identifiying hosts.  A host may have more than one
address per interface and be chosen arbitrarily.  I am merely referring to the
identity properties of the lower 128-N bits (where N is typically 64) for the
lifetime of a connection.

Peter

---

From: Peter Tattam <[email-masked]>
Date: Fri, 10 Aug 2001 12:16:38 +1000 (EST)

I was attempting to only referr to the short lived identity properties of such
identifiers for the purposes of multihoming over the lifetime of a connection.

The privacy debate, while important, should not necessarily be relevant to the
discussion I was attempting to promote.

Peter

---

From: Peter Tattam <[email-masked]>
Date: Fri, 10 Aug 2001 12:17:59 +1000 (EST)

> at least with the current specifications.

Let us hope that duplicate discovery works properly then :)

Peter

---

From: Peter Tattam <[email-masked]>
Date: Fri, 10 Aug 2001 12:43:50 +1000 (EST)

> i think the latter is mandatory.  we do allow allocation of /128s.

No, I'm not.  See other references.  The main relevance is towards efficient
representation of lists of multihomed addresses.  Having the last 128-N bits of
address identical between items in that list may be important.

Peter

---

From: Peter Tattam <[email-masked]>
Date: Fri, 10 Aug 2001 12:49:47 +1000 (EST)

> Let us hope that duplicate discovery works properly then :)

The issue of duplicates rings an alarm bell with me.  Duplicate detection
is likely to be complicated by a transport layer solution to multihoming as
each multihomed address will require DAD.  

Should a unique site level address guarantee no duplicates on all other
prefixes? 

Peter

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 10 Aug 2001 14:21:29 +0859 ()

Randy;

> i think the latter is mandatory.  we do allow allocation of /128s.

Can't backbone routers assume 48 bit look-up for best effort unicast
forwarding?

Though who want to sell value-added (such as MPLS) routers may
disagree, it is important for low-cost high-speed Internet.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 10 Aug 2001 14:42:05 +0859 ()

Ben;

> transport addresses.

That's no layer violation.

Or, are you saying TCP violates layer, because it is aware
of not only port numbers but also internetworking layer addresses?

Then, please tell me how to fix it.

> If you eliminate those violations, through

The modification is to let applications handle (often merely pass them
to TCP) multiple addresses, which some applications are already
doing.

						Masaaka Ohta

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Aug 2001 07:55:05 +0100

>> are you asking if the forwarding look-up is longest match on 64 or 128
>> bits?  i think the latter is mandatory.  we do allow allocation of /128s.

given the current addressing and routing model, i don't think so

> disagree, it is important for low-cost high-speed Internet.

i suspect the days of forwarding lookup speed problems are past us

randy

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 10 Aug 2001 16:31:13 +0859 ()

Randy;

> given the current addressing and routing model, i don't think so

Are you saying there is no fixed boundary at /48 even in the
backbone?

Then, it may affect multi6 proposals.

> i suspect the days of forwarding lookup speed problems are past us

I'm afraind you are assuming maximum router speed as slow as 10Gps.

						Masataka Ohta

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Aug 2001 08:43:41 +0100

> Are you saying there is no fixed boundary at /48 even in the

yes, that is what i am saying.  the /48 boundary is soft, and is only for
fp=001.  we should not hard code the equivalent of A/B/C in routers again.

> I'm afraind you are assuming maximum router speed as slow as 10Gps.

no i am not.  i am presuming that the forwarding lookup will continue to
keep up with line speeds.

randy

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Fri, 10 Aug 2001 03:40:23 -0400

>Can't backbone routers assume 48 bit look-up for best effort unicast

no

>disagree, it is important for low-cost high-speed Internet.

that would be nice. 
but the cost of being able to do long (/32 and /128) lookups
is in the noise compared to the costs of all the other stuff, 
such as the somewhat shorter lookups (eg /24 or /48), high
speed optics (lasers etc), buffer memories, internal
switch fabrics, boards, and so on. 

Frank Kastenholz

---

From: "Kastenholz, Frank" <[email-masked]>
Date: Fri, 10 Aug 2001 04:05:39 -0400

>Then, it may affect multi6 proposals.

There may be a fixed /48 boundary.
But a router vendor can not assume that
there is one -- it could change next week...
And given that the edit-compile-debug loop of
ASICs is measured in months, not minutes, 
we need to assume the worst case.

Frank Kastenholz

---

From: Mattias Pettersson <[email-masked]>
Date: Fri, 10 Aug 2001 11:36:19 +0200

> So HIP is something we have to look at!

Francis, I agree. What is the consensus on supporting large progressive
steps like HIP?

/Mattias

---

From: Jim Bound <[email-masked]>
Date: Fri, 10 Aug 2001 06:07:34 -0400 (EDT)

Brian/Ran,

I agree.  Forgot about the privacy exts...

thx

/jim

---

From: Jim Bound <[email-masked]>
Date: Fri, 10 Aug 2001 06:10:28 -0400 (EDT)

Bob,

I thought about where your coming from after Ran/Brian's mail.  But I
don't think we can say this works if public EUIs are used but not with
Temp addrs.  I don't think that will fly with the operators as that is yet
more to manage with yet another "if case".

/jim

---

From: Greg Maxwell <[email-masked]>
Date: Fri, 10 Aug 2001 11:45:52 -0400 (EDT)

> keep up with line speeds.

Whatever cases there are that can be made about strange fast optical
switching technology, comparing 128 bits is within the same order of
magnitude as comparing 48 bits, so it's unlikely to be an issue.

Back on topic: The way multihoming is done will have a much more profound
impact on how much work routers have to do.

---

From: Tony Li <[email-masked]>
Date: Fri, 10 Aug 2001 11:34:42 -0700

| Then, please tell me how to fix it.

The way to fix it is to add another layer of indirection.  Almost all
applications do not care about the address of the other end of the
connection.  They start out with a hostname and actually have to work quite
hard to resolve the hostname, get an address and then make a connection to
that address.

The hostname serves as a unique identifier which carries the semantics that
the application cares about and does not carry more specific semantics that
the application does not and should not care about.

This would allow lower layers to change addresses on a connection in a
manner that is transparent to the application.

Tony

p.s. I've always wanted to ask the BSD architects how they would change the
sockets API if they had it to do over again.

---

From: Geoff Huston <[email-masked]>
Date: Mon, 13 Aug 2001 07:44:13 +1000

>Francis, I agree. What is the consensus on supporting large progressive

Obviously it depends nf the architecture you want to follow - As I 
understand it HIP is a persistent identity algorithm at the application 
layer. It you want to following the architectural model that multi-homing 
at the end point implies a change of address _that the application is aware 
of_ then either you need  some part of the address to remain constant (low 
order n bits) or you need some other exchanged token to denote identity. 
Its not obvious to me that you need both mechanisms simultaneously.

Geoff

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 10:45:29 +0200 (CEST)

> restriction on the 64 bit boundary and say that if a site is multihomed with
> N upper bits, can we consider that if the lower 128-N bits are the same,
> they can be considered the same node address.  Anything else is another
> address.

Peter,

what benefits can we derive from such a restriction?
Is it just implementation ease? (being able to compress the memory
representation of the list of addresses and being able to make more
efficient lookups against the list?)

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 10:35:36 +0200 (CEST)

> end-systems (e.g. Windows XP).

... and others are contemplating using the low-order 64 bits 
to solve authorization issues for "redirect" (as in mobile ip binding
updates) as in the SUCV draft.
However, this doesn't make things any worse than with the "privacy extensions"
RFC. But it is more of a technical argument than a perception argument
for using the low-order 64 bits.

> and identity (in lieu of using IP addresses as at present).

The transport multihoming, SCTP, and GxSE seem to all be based on
the identifier being a *set of* IP addresses, where the set is
determined when the communcation is initiated. 
I think this is a very interesting space to continue to explore
to understand the differences between the ideas/proposals.
Such approaches would need a separate mechanism for handling renumbering
of long-lived connections since that would require securely changing the set.
(But my gut feel is that whatever secure solution we are confortable
for Mobile IPv6 binding updates effectively "redirecting" traffic, can
be applied to changes in the set of addresses identifying the connection.)

Has the NSRG explored using sets of IP addresses as the indentifiers?
Or are they focused on the issues of inventing a new name space?

  Erik

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Aug 2001 17:17:38 +0200

=> low overhead (i.e. BAKE, SUCV) proposals won't apply (no home agent),
higher overhead (i.e. IKE, HIP) proposals provide the required security
level but rely on a global PKI... I really don't know what is the worst:
to accept MITM attacks or to wait for DNSSEC?

=> obviously HIP & co follows the second (a new name space with crypto
properties which give opportunistic modes for security).

Regards

---

From: Shane Kerr <[email-masked]>
Date: Wed, 15 Aug 2001 17:32:30 +0200

On 2001-08-15 17:17:38 +0200, Francis Dupont wrote:
>    
> => low overhead (i.e. BAKE, SUCV) proposals won't apply (no home
> agent), higher overhead (i.e. IKE, HIP) proposals provide the required
> security level but rely on a global PKI... I really don't know what is
> the worst: to accept MITM attacks or to wait for DNSSEC?

MITM seems like a problem that multi6 doesn't have to solve.  If a
"gang-of-IP's" protocol is used, as long as it doesn't preclude host
authentication for users/admins/hosts/protocols that care about it, then
solving the problems of redundacy and load sharing seem like the thing
to worry about.

I think most businesses today would be happy with an anonymous
end-to-end connection since they rely on web certs for their only
authentication in the current Internet.  I'm not saying this is a good
thing, but again, not one that multi6 needs to address.

-- 
Shane

---

From: Francis Dupont <[email-masked]>
Date: Wed, 15 Aug 2001 19:18:17 +0200

> the worst: to accept MITM attacks or to wait for DNSSEC?
   
   MITM seems like a problem that multi6 doesn't have to solve.

=> yes and no, look at below.

   If a "gang-of-IP's" protocol is used, as long as it doesn't preclude host
   authentication for users/admins/hosts/protocols that care about it, then
   solving the problems of redundacy and load sharing seem like the thing
   to worry about.
   
=> this is the point and this is not so easy. Today IPsec (i.e.
security in the network layer) and any "gang-of-IP's" protocol
(as we can see with address based mobility protocols like MIPv6)
are fighting together with very bad consequences:
 - a lot of crypto stuff already done for IPsec will be redone
   (a real concern if we'd like to get correct crypto)
 - people will make bad assumptions about security level
 - IPsec will remain "orthogonal" and it use expensive
Summary: people won't pay the extra cost for IPsec when a high security
level will be needed. What we need is integration of some IPsec
basic mechanisms into the "gang-of-IP's" protocol in order to provide
reliable security with for a minimal extra cost (i.e. in the key management
only) the optional & high security level given by IPsec.

   end-to-end connection

=> this will be the job of "opportunistic" modes.

   since they rely on web certs for their only authentication in the
   current Internet. I'm not saying this is a good
   thing, but again, not one that multi6 needs to address.
   
=> I'd like to get both some flexibility for multi6/mipv6/... and
security levels required by policies. I don't want to get only one
or to do things (like tunneling) twice. It seemed there were many
conflicts between multihoming/mobility and security areas but HIP
has shown the things are changing!

Regards

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 16 Aug 2001 17:49:18 +0859 ()

Randy;

> fp=001.  we should not hard code the equivalent of A/B/C in routers again.

Then, is multihoming proposal using a particular addressing
structure acceptable?

I guess an idea initiaed multi6 BoF was, though broken, the case.

> keep up with line speeds.

The problem is that, due to the difficulties of high bandwidth low
latency inter-chip communication, routing engine core will be on a
single chip, capacity of which is, for the time being, limited.

						Masataka Ohta

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Aug 2001 17:15:21 +0200 (CEST)

>     => low overhead (i.e. BAKE, SUCV) proposals won't apply (no home agent),

While there is not an agent per se, there is a notion of a home which is the 
previous set of prefixes. In a sense each node is its own home agent.
Thus the ability to use return routability as an authorization check for
e.g. BAKE can be used to handle attacks from attackers that are not on
the path. 

  Erik