Re: about Wedgelayer 3.5 / Fat IP approaches

[Erik Nordmark <Erik.Nordmark@sun.com>]

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

Agreed.

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

Yes, whether DH type pbks or hash chains - just different flavors
of constructing a purpose-built secure channel.

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

Yes.
There are even some APIs, such as the Java ones, that allow the applications
to be unaware of even #1 by having the applications only operate using FQDNs,
but I suspect that many/most applications which do callbacks and referrals 
need to be aware of #1.

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

Yes.

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

That was what I meant by "existing applications" above; existing application s
on non-multi6 aware hosts would just speak IPv6 as currently defined.

> 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

It is actually more constrained than that since other instances of
the application might be running on non-multi6 aware hosts.
So the conservative approach would be to always hand an IP address/locator
to unmodified applications, that way the application can use it
for callbacks and referrals without any constraints on which hosts the
different instances of the app is running.

> 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 :-)

But this would require that the application contain the logic to discover
the ID and locators for its peers, whereas when running on a multi6-aware host
the application could leave that task to the host (libraries etc).
So it adds complexity to do this in the application, and there doesn't
seem to be much benefit because the non-multi6-aware host would not be
capable to make TCP connections survive a locator change etc.

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

Yes, if the solution is going to rely on the reverse DNS for other purposes
this makes sense. But if the solution doesn't, then we shouldn't require
that the reverse DNS be maintained IMHO. It would be fine to take
advantage of it for more robust referrals and callbacks, but not assume it
will be there.

  Erik