RE: Comments on draft-nordmark-multi6-threats-01
Erik Nordmark <[email protected]>
| Newsgroups | gmane.ietf.multi6 |
|---|---|
| Message-ID | <[email protected]> |
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