[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-shim6-proto-06 : Context confusion
Hi Sebastien,
sorry for the long delay and thank you for your feedback
i think you raise an interesting point here....
below...
El 08/11/2006, a las 14:27, Sébastien Barré escribió:
Hi,
I think that in the previous mail, I had not well in mind the fact
that the only way for a host to have multiple own context tags is to
first drop one context, then create a new one with the same context
tag, so that in any case, there is only one possible context for the
context tag, with still the possibility of having packets arriving to
the newly created context, but addressed to the dropped context.
With this in mind, I understand better the interest of having
non-overlapping locators sets. This way we can work as if the two (or
more) locator sets were corresponding to different machines.
But in this case the following sentence should probably be adapted a
bit (section 7.6):
----
The confusion can be detected when I2/I2bis/R2 is received since we
require that those messages MUST include a sufficiently large set of
locators in a Locator List option that the peer can determine whether
or not two contexts have the same host as the peer by comparing if
there is any common locators in Ls(peer).
----
Now, we could consider the case of a single host with multiple
disjoint locator sets being seen by its pair as multiple hosts. This
is without problem except a little subtlety. Here is the adapted
example of the previous mail :
----
1. host A has two contexts with host B, one with the set of locators
<A1,B1/B2> and CTx, the other with <A2,B3/B4> and CTy.
this situation is not supported in the current spec
in section 7.6. Context confusion it is stated that:
The confusion can be detected when I2/I2bis/R2 is received since we
require that those messages MUST include a sufficiently large set of
locators in a Locator List option that the peer can determine whether
or not two contexts have the same host as the peer by comparing if
there is any common locators in Ls(peer).
since B1/B2 is disjoint with B3/B4, this would be not complying with
the aforementioned MUST in the draft
However, i think it is a valid question whether we should or not
support this type of configuration...
I mean, this means that all pair of locator sets of all shim6 contexts
of a host must be non disjoint
In other words, that if we take all the possible pairs of locators sets
of existing contexts in a host, all of these must be non disjoint.
So, a scenario where a host B has 4 addresses B1,B2,B3,B4, it is not
possible that B establishes a context with B1,B2 and another context
with B3,B4, since they would be disjoint.
I may agree that this is an overkill and that we should lift this
limitation
An option to support this situation would be as you mention below, to
include the locator pair besides the context tag in the processing of
the incoming payload packets.
However, this by itself it is not enough to completely remove the need
for the limitation above.
The limitation above is oriented to prevent the case of host merging.
This is the case when two contexts initially have disjoint contexts and
then through an update message, a locator is added to one of the
context, resulting in a non disjoint locator set with an existing
context.
consider the following case
the context A1,B1/B2 is created and B assigns CTx to this context
B looses the context
The context A2,B3/B4 is created and B reuses CTx
As you mention, this can be addressed if we add the locator pair and
the context tag to process payload packets.
Now what happen if B add locator B1 to the second context and A adds A1
to the second context?
the result is that A will have two contexts:
A1,B1/B2 and
A1,A2,B1/B3/B4 both with the same CT(peer)=CTx, so when A sends packets
with the first context, they will flow with addresses A1,B1 and context
CTx, fiting the second context and we have the problem again.
So as i see it, there are two different scenarios that are not
supported today and that we can update the spec to support:
- scenario 1: i call it virtual hosts. the supported feature here is to
support the case of establishing context with the same peer with
disjoint locator sets. For instance the scenario above where host A has
locators A1 and A2 and host B has locators B1, B2, B3, B4 and to be
able to estbalish two contexts A1,B1/B2 and another context with
A2,B3/B4. In this case A and B would have something like two virtual
hosts and they cannot merge. i.e. it is not possible that B adds B1 to
the second context
-scenario 2: host merging. In this case it is possible that B adds B1
to the second context
In order to support scenario 1, we would need to process incoming
payload packets considering both the context tag and the locator pair
and we would need to soften the MUST included above to soemthing like:
If two context have disjoint locator sets at the moment of the context
establishemnt, then they must always be disjoint. We need to phrase
this very precisely, in order to be able to cope with loosing contexts
and so on. (another way to describe it would be to include a section
about virtual hosts, meaning that it is possible to support virtual
hosts as long as they don't merge)
In order to support scenario 2 we need to modify quite a few things in
the spec. In particular what do we do when the hosts merge through an
UPDATe message and what do we do with the resulting contexts if they
have the same context tag allocated. This would be quite hard to
support. One option would be to renogotiate the context tag, but this
would be quite complex. the other option would be to refuse the update
messge, but we woud need to define a message to reject an UPDATe
message.
So, imho, we may consider supporting the first case of virtual hosts
(it would imply some rewriting of the spec though) but i don't think
that it would be good idea to support the second case, of merging
hosts....
opinions?
Regards, marcelo
2. After some time, host B drops the first context.
3. Now he wants to create another one : <A1,B3/B4> with CTx.
----
When A receives the I2 message from B, it is not able (as should be)
to detect that it is speaking with the same host, as the locator sets
are disjoint. As a consequence, the context in A with CT(peer)=CTx
will not be discarded. We are now in the situation of A possibly
sending packets to both the discarded context <A1,B1/B2> and the newly
created one <A1, B3/B4>, using CTx in both cases.
IMHO, this can be detected by B, and should be stated in the draft as
another case of confusion detection (in fact both confusion and
context loss detection). For this to be done, section 12.1 could be
slightly changed, to say that a receiver MUST NOT assume that a packet
with the shim6 payload extension header and a context tag matching
with a context is really attached to the context. Rather, to verify
this, the source locator must be checked against Ls(peer) :
o if the source locator is included in Ls(peer), usual translation is
done.
o if the source locator is not included in Ls(peer), then probably
this packet belongs to an old, dropped context, and an R1bis message
MUST be sent in this case, in order to recover the previously
discarded context (in my example <A1,B1/B2>).
I hope this proposal is clearer and more realistic than the one
described in my previous mail.
Thanks for any comment,
Sébastien.