[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: about Wedgelayer 3.5 / Fat IP approaches


El 28/06/2004, a las 1:51, Erik Nordmark escribió:

Among the multiple approaches that have been included within the
Wedgelayer 3.5 / Fat IP class, we can find very different mechanisms
imho. I I think that additional discussion is needed to understand
which one of the different approaches (not particular solution, but
general approach) would better fulfill our needs. the goal of this
message is then, to provide my opinion of some of the benefits and
limitations of each approach in order to foster discussion of this
topic.

So, as is see it the approaches included within the Wedgelayer 3.5 /
Fat IP class use the following types of ULP identifiers:
- 128 bit long CBIDs (HIP, SIM)
- CGAs (cb64)
- Locators (i.e. the use a locators as the ULP id) (NOID, ODT)
- ephemeral ids (WIMP, MAST?)


What I'm about to write might make things more confusing, but hopefully
also more clear.

I think conceptually we are using identifiers for two different purposes,
but in many (not all) cases the same bit strings serve both purposes.
1. A handle passed to the applications that can be used for things like
- comparisons
- callbacks and referrals


I would add initial contact to this list. I mean, an initiator must have a stable string to properly indicated the other endpoint of the communication.

2. A thing used inside the multi6 (sub)layer as part of preventing redirection
attacks.


This would be essentially what pbk deals with, i guess

Would it be correct to say that the applications have to be aware of the string used for #1 but it is not required that apps are aware of the string used for #2?

(i am highlighting the *internal* of the #2)

A current case where they are not the same is in the (now expired) cb64 draft,
where the application sees a 128-bit handle with IP address semantics,
but the multi6 layer uses the 64 last bits as a hash of a public key.
In Santa Monica after the meeting Jukka Ylitalo brought up another interesting
thing to try; using NOID-style AIDs with WIMP ephemeral IDs underneath.
(Sounds a bit complex to me, but well worth exploring to further our
understanding in this space.)

this would mean that you would use hash chains values for #2 and regular ip addresses for #1?



Furthermore, we definitely need to be concerned about #1 for existing
applications. But it migth also make sense to think about applications
that have been modified to be multi6-aware.

For instance, calling the getpeername() API might return what is essentially
a designated locator for the peer, which provides support for unmodified
applications. But we could decide to crate getpeerid() and getpeerlocators()
which would return more information to modified applications.
This might mean that unmodified applications would receive limited
support for callbacks and referrals when a locator becomes unreachable,
but the modified applications would be robust against such failures.


Another case, imho would be to consider a non multi6 aware application running on a multi6 aware host.
In this case, the multi6 layer could provide enhanced services and preserve connectivity even if the locator used on the refferral or call back becomes unreachable.
So i guess that we can have 4 cases:
a- non multi6 aware app running on a non multi6 aware host: in this case a locator must be used for refferals
b- non multi6 aware app running on a multi6 aware host: in this case the app will pass the 128 bit string that it is using to the other end. So the multi6 layer has to be capable to obtain the locator set form this 128 bit string i.e. we need an id to locator mapping mechanism
c- multi6 aware app running on a non multi6 aware host: the app could pass both the id and the locator set, We don't need nothing more than upgrading all the apps :-)
d- multi6 aware app running on a multi6 aware host: both solutions work fine

imho, an appealing approach would be one that uses valid locators as ids, in order to support a) and since we are using locaotrs, we can use the reverse DNs to provide the mapping system needed for b)

regards, marcelo

Erik