Also, don't forget that our job right now is to agree on a precise charter for shim6, and that will include ruling some items out of scope, even if they are needed for the IPv6 Internet as a whole. Let's focus on having a finite menu of precise objectives that can be turned into standards track RFCs...
Brian
Marcelo,
I think that we have a terminology issue here, and i guess that we can benefit from the distinction made by Jari.
One thing is the shim protocol, that as you mentioned is only needed to preserve the established communications and another thing is the output of the shim wg, which can be broader than just the protocol for preserving establishing communications. What i am arguing for is that the shim wg should also provide the mechanisms to establish new communications after an outage in the case that only one of the hosts is upgraded and the other one is just an legacy ipv6 node (i.e. at least point 3 below)
I agree; I think there may be some debate about how generic the mechanism for re-establishing communication should be. In my opinion, such a model is needed for the shim6 protocol to work properly; however, I think we should work on a mechanism that is more optimized for use with shim6 than a completely generic mechanism, or at least that is what our target should be. If we do develope a mechanism that works with or without shim6, than that is a good thing, but I don't think we should have a requirement that this mechanism should work without shim6.
Otoh, even the shim layer will need to establish new communications after an outage, so this mechanism is also needed for the shim to work properly (however, we could envision different mechanisms in the case that both ends support the shim and in the case when one legacy host is involved). also, the ingress filtering compatibility mechanisms are needed for the shim to work.
I agree with this.
John
Regards, marcelo
El 21/01/2005, a las 23:24, Christian Huitema escribió:
I agree that a single host that has SHIM components cannot preserve
established communications (since for this support from
both ends of
the communication is needed). However, if one of the nodes has SHIM components, it may be able to establish new communications after an outage, something that a non
SHIM
host cannot. and this is a great benefit imho
When I look at the components of multi-homing support, I find the following:
1) Support of multiple IPv6 interfaces & corresponding IPv6
addresses
This is standard in most IPv6 stacks. By itself, it allows servers to accept connections over multiple nets. Programming interface is well known (bind to "any", then listen). Can break if egress filtering interferes, but only in some weird cases.
2) Choice of the appropriate address pair when many are available There is a standard spec for "source and dest address selection". It should allow clients to establish connections. However, it relies on "static analysis" of the prefixes, and does not work well if one of the paths is unreliable. Can break if egress-filtering interferes.
3) Better algorithm for address pair selection Essentially, try multiple choices instead of just one. Present in some stacks and some applications. We could do better. Does not necessarily require Shim6. Only a partial solution to egress-filtering.
4) Egress-filtering solution Resolve interaction between "destination based routing" and egress filtering. Different solutions for different types of networks.
5) Detection of rehoming events Quickly detect that connectivity has changed, Could use information from multiple layers Adequate response can be performed at many layers
6) Connection maintenance after rehoming & other event The solution that shim6 addresses...
-- Christian Huitema