RFC3484bis (was Re: Design decisions made at the interim SHIM6 WG meeting

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Paul,

El 31/10/2005, a las 2:28, Paul Jakma escribió:

> I don't think either approach makes sense :).

thanks

> Is there any good reason why this retry/source-select state can not be 
> kept inside the shim6 layer? The remit of shim6 is after all to handle 
> this stuff transparently.

Because:
First, you cannot assume that all hosts support the shim
Second, even if they do, such approach would imply that the shim 
negotiation is made upfront i.e. that the shim session is established 
before the communication starts, which is completelly opposed to 
current deferred context approach that is being followed throughout the 
shim6 design

So, we need to deal with the following situation:



             /-- ( A ) ---(      )
   X (site X)             ( IPv6 ) ---(C)---(site Y)Y
             \-- ( B ) ---(      )


Where, host X supports multihoming features, something like an rfc3484 
bis and event the shim if you want, but host Y does NOT support the 
shim.
Suppose now that ISPA fails, what do you do?
If you base your solution in the shim, then if hostX can not 
communicate with host Y using the shim.
If you don't let X use the shim, then how does it selects the source 
address?
If you use current rfc 3484 you are stuck in a single source address, 
so in case host X selects ISPA address as source address, he won't be 
able to communicate.
How do you solve this problem?

What i can think of is:
- For those apps that want to select the source address (i.e. they use 
bind()) you let them take care of the problem, since it seems they know 
what they are doing, since they are in fact already taking an explicit 
decision to set the source address. In this case, the app is the one 
performing the retrial, so the modification needed for rfc3484bis is 
just to guide the apps on how to retry. This basically means two thing: 
1. rfc3484bis should state that apps need to retry using different 
source addresses when they are available. 2. the available source 
addresses associated to a destiantion address can be provided by 
rfc3484bis to the app in the form of an ordered list, so that the app 
has some guidance of which addresses to try first (similar to what is 
done with destination address by current rfc3484)

- For those apps that do not select the source address, there are two 
options:
  - In the case of TCP, we can allow the rfc3484bis to tell the socket 
to
    retry when a connect() is made. This means that the 3-way handshake
    is retried with different source addresses until it is completed
  - In the UDP case, the situation is more difficult, because we don't
    have signaling packets to try with. In this case, i would suggest
    that rfc3484bis only keep some track of which source addresses
    seems not to be working with a given destiantion address, so that
    if the app retries, a different source address is tried( and we
    are not stuck with the same source address, as it is the current
    situation)


This is what i can think as possible solutions to this problem.
It implies modifications to the apps in the case that is the app the 
one in charge of retrial, but this seems to be in line with the fact 
that it is the app the one that is selecting the source address i.e. 
the app is involved to a certain degree in this selection.

Now do this still make no sense to you?
If so, could you suggest approaches to deal with the problem and the 
imposed constraints?

Regards, marcelo


> regards,
> --
> Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
> Fortune:
> I have the simplest tastes.  I am always satisfied with the best.
> 		-- Oscar Wilde