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

[Paul Jakma <paul@clubi.ie>]

On Mon, 31 Oct 2005, marcelo bagnulo braun wrote:

> El 31/10/2005, a las 2:28, Paul Jakma escribi�> thanks
Sorry ;).

> Because:
> First, you cannot assume that all hosts support the shim
OK.

> 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
OK. I'm not sure why that's implied though. The shim could start off 
with a NULL mapping (whatever the default source is, as decided by 
plain old SAS, probably routing policy). Given shim is to be able to 
interject later on if required.. Also, if the application hasn't 
bound to any specific address, then the shim can very easily put in 
whatever address it wants to..
I.e. If the default source doesn't work, shim6 kicks in and /then/ 
*shim* can do source-address probing.
Handy side-effect of only introducing these complications when 
there's actually a problem, hence the 99% of connections which get 
setup when things are working normally don't have to be encumbered 
with source-probing by all applications..
> 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?
I must have missed a lot of developments in the direction shim in the 
last month or two. I don't understand at all now. I had thought the 
intention was that shim could 'kick in', e.g. by opportunistically 
sending the first packet on without any shim6 setup (or minimal 
setup), was the impression I had from some other discussions.
You seem to be exploring a way to get some of the benefits of shim 
without ever having a shim involved at all, is that right?
> 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?
I'm confused now. I thought the whole point was for shim6 to solve 
that 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)
IOW, achieve the goals of shim but in the applications rather than in 
a shim IP<->output layer in the IP implementation?
I'd agree that's the most sensible way to implement this, in a 
perfect world. But of course has pretty big deployment barrier, the 
entire reason for this WG in the first place. It could be done with 
some standardised APIs (which are not the remit of the IETF to 
specify, but some nice API work has been documented in informational 
RFCs).
Or have I completely missed the point? (again ;) ).

> - 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,
I would suggest doing it in the application (preferably in a nice 
widely available library) would be best.
> 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.
Right, and it has the best view of its state.

> Now do this still make no sense to you?
It makes sense.

I'm wondering about the motivation though, i.e. wrt the shim6 
IP-intermediary-layer approach, which I /thought/ was what ye were 
going with. ;) I'm confused on that point. The point that started 
this sub-thread was Geoff's summary of the design decisions, where 
this SAS by way of RFC3484 is to be the way for initial location:
"1.  The specification for initial contact will use RFC3484, as modified by
     this draft in terms of source address ordering."

I still don't get why, if the intention is for this to be used /with/ 
shim6, this responsibility has to be punted to either the application 
or to some algorithm which currently is stateless.
Ie, why not let the modifications to SAS be specified as part of 
Shim6, in a context of "acting on behalf of the application" rather 
than "affecting the protocol".
Shim can simply act as the "agent" and implement the required SAS. It 
needn't imply anything else of Shim, particularly the protocol side. 
(ie, whether it must set things up in advance).
> If so, could you suggest approaches to deal with the problem and 
> the imposed constraints?
I'm afraid not, just suggesting that keeping the problem confined 
within shim6 (and any cousins, MIP, whatever) will be /less/ of a 
problem than the proposal of complicating SAS a lot for /all/ cases.
regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
It's been a business doing pleasure with you.