Subject: RE: Comments on draft-nordmark-multi6-threats-01

From: "Fleischman, Eric" <[email-masked]>
Date: Thu, 10 Jun 2004 14:17:38 -0700

Erik,

>      identifier  - an IP layer identifier for an IP layer endpoint
>                    (stack name in [NSRG]).  <snip>

I am bothered by this definition. The way I read it, it implies that an IP layer endpoint is the protocol stack. That is true of every protocol system that I know (including OSI) except for the Internet protocol suite. For the Internet protocol suite, the IP layer endpoint is a network interface. 

Here is where the difference is manifest: for OSI and other protocols with a NSAP (network service access point -- i.e., a stack interface at the network layer), every network interface on that device has the same network layer address. However, for the Internet protocol suite, every network interface has a different IP address. This is why you need to eliminate the text "(stack name in [NSRG])" from your definition.

BTW: has multi6 actually considered redefining IP addresses to actually become stack interfaces at the IP layer? If you have, I think that you may agree with me that most/many of the *node* multihoming problems go away.

--Eric

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 11 Jun 2004 18:28:30 -0700 (PDT)

Eric,

Noel already clarified how the terminology and concepts hang together.
Here is my perspective on the last part of your email

> BTW: has multi6 actually considered redefining IP addresses to actually
> become stack interfaces at the IP layer? If you have, I think that you may
> agree with me that most/many of the *node* multihoming problems go away.

Most (all?) proposals keep IP addresses as currently defined as names
for interfaces; we tend to call these locators.
(Some proposals might view the locator as only being one component of the
existing IP address.)
So IP addresses as we know them don't change from how they are allocated and
used in routing etc.

The proposals define some new IP layer identifier, and there is a wide
range of these (a 128 bit hash of a public key, a shorter hash,
a fqdn, a set of locators with any locator being an alias for the set, ...).

While the problem statement is about site multihoming, the definitions of
the identifier and mechanisms that I've seen can handle identifier->locator
relationships where the locators are on the same interface (e.g. with
different /48 prefixes) as well as on different interfaces.
So at that mechanistic level the proposals handle host multihoming
as well as site multihoming.

I haven't looked carefully is there are other issues that make solving
host multihoming difficult in some proposals. There might be issues
around how the identifiers are allocated that might make it hard
from an adminstrative or scaling perspective to have a single host
connected to e.g. a DSL and a cable ISP, to get a single identifier
allocated for itself. I honestly don't know if there is, so this part
is speculation.
I and Pekka Nikander (and perhaps others) have looked a bit at the feasibility
of building a system where a HIP HIT (perhaps with some added internal
structure) can be looked up, and I think it is very hard to make this scale
even if the scale is limited to sites, and it becomes extremely hard to make
such a thing scale to every host in a future Internet.
So I don't think we fully understand the scaling issues of the allocation and
lookup aspects of the identifiers so clearly say that all the approaches to a
solution can scale up to handle host multihoming.

But clearly it is desirable to be able to handle host as well as site
multihoming.

  Erik