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

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

On 31-okt-2005, at 11:54, marcelo bagnulo braun wrote:
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
Well, if we can provide unmodified applications on shim-capable hosts with this functionality that would be very good. There are several advantages to using the shim here, including better opportunities for security and traffic engineering, although it would of course be nice if we could have the same functionality when one host doesn't 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
We don't have to change our current thinking for sessions where the initially chosen ULIDs are reachable: only when those turn out unreachable, we need to do additional work.
The main problems here are detecting that the initial ULID/locator pair doesn't work before we have any shim state we can use, and finding additional locators. HBA should allow us to make certain that these locators belong to the initially chosen ULID. However, it's possible that people publish AAAA records for different hosts that provide the same service so the HBA check would presumably not work then. So either we need something independent of AAAA records, or limit ourselves to the case where the AAAA addresses are part of the same HBA set.
Still, I'm not too worried about this, finding locators can be improved later.
BTW, being able to do the shim before communication starts also provides a good path towards something we'll want in the future: disjunct ULID/locator sets. Having a mechanism in place that allows using non-IPv6 ULIDs in the future would also help here. 


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?


Obviously not repair the failure using the shim...
So either use the "second shim" approach or hope that the application does the right thing.
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,
In my experience hosts try different source addresses in round robin fashion. I don't know if this is in accordance with RFC 3484 or not, maybe there is a longest match rule in there somewhere. But if so, that's a mistake as this example shows: it would make the host consistently choose a non-working address.
(Note that even with round robin things may not work because the application won't try often enough to arrive at a working address pair. However, when the user makes the application retry eventually it should work.)
- 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,
You are assuming that an application that does an explicit bind() for outgoing sessions also retries. I don't think this is generally the case. For instance, the BIND named allows the user to set the source address which is useful because then other nameds know from which addresses they can expect sessions.
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)
Yes, this is useful, but don't expect that application writers will all start doing this.
- 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)


Seems reasonable.

But again, I don't think this is a full scale solution to the problem.