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