On 6 mrt 2008, at 18:37, Sébastien Barré wrote:
Iljitsch van Beijnum schreef:
Inderdaad!
When packets return, routers don't rewrite the destination address. Then, two things can happen: the packets end up at the host itself, which recognizes the rewriting and from then on, sources packets with the source address that was written in the first packet by the router. Or hosts on the subnet are legacy and won't recognize the rewriting, so a middlebox rewrites the destination address to the unique site local prefix.
This means that it is a requirement to have one of these three options (for packet return) :- All hosts are legacy (and the middlebox always rewrites) - All hosts recognize the rewriting (and the middlebox never rewrites)- some hosts are legacy, other not, but the middlebox must be aware of the state of each host, so that it can selectively rewrite.
Is it right ?
Yes, it is. This is a limitation that exists per-subnet. For each subnet, you would have to choose one of these options.
The host or middlebox can now start shim6 so that if there is a path failure, the session/context can move to a different address.
Isn't there a possibility that a Shim6 context is established by both the middlebox and the host ? Or maybe this can be avoided by synchronizing the heuristics for Shim6 negotiation between the host and the middlebox ?
This is one of the things that must be worked out in a proxy shim6 scheme. I'd say that a smart middlebox would recognize that a host can do shim6 itself and then get out of the way unless it's configured to overrule host-based shim6. In that case it could simply filter packets with the shim protocol in the protocol chain. The reason a proxy may want to do this is that the site administrator desires centralized control of traffic engineering decisions.
The next step would be for hosts to be aware of the proxies and work together in some way. This is obviously an area for further study...