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

Re: Second shim



marcelo bagnulo braun wrote:

In scenario 1, the ULID and the locator used for the communication need to be the same since the peer does not support the translation, so, using a different ULID that the locator used would break things. In this case, what we need would be the upgraded RFC3484 which would allow to cycle through different source addresses.
However, i would like to note some part of RFC3484:

   The application might also specify a source address
   with bind(), but often the source address is left unspecified.
   Therefore the network layer does often choose a source address from
   several alternatives.
...
   Separately, the IPv6 network layer will use the source address
   selection algorithm when an application or upper-layer has not
   specified a source address.

So this basically says that in very common scenarios, is actually the IP layer that selects the source address. In this case, then it would be possible to build additional mechanisms within the IP layer that when a packet with unspecified source address is received, it tries different source addresses and uses the one that seems to be working (we still need to understand what does "seems to be working means though..)

While the IP layer might select it, and this might be helpful for UDP, the TCP case works different in practice. TCP ends up asking the IP layer for which source address to use as part of TCP creating the tcb, which is done before the SYN packet is sent out.

So while the application didn't specify it, and a "shim" or some new connect-by-name API can cycle through, it still will be a bit inefficient if you let TCP try things (for a single <source, dest>) and timing out before trying the next one.

   Erik