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

Re: multi6-functional-dec and re-homing



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

john.loughney@nokia.com wrote:
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