Re: AD review of draft-ietf-shim6-proto -- section 5

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi Jari,

there was one remaining issue from this message

El 16/09/2007, a las 20:07, Jari Arkko escribió:
> > > Are generation counters unique per context tag?
> >
> > I don't think this is strictly needed, but i guess in practice they
> > will be in most of the cases, since i doubt there will be more than
> > 2^32 different locator lists.
> > What is needed is to prevent that two locator lists are confused, so
> > generating the locator list generation as described, this is avoided.
> > However, it would be perfectly ok to repeat a number if both ends are
> > certain that there is no confusion (for example the value was used a
> > long time ago and both ends are certain that the value is no  
> > longer in
> > use)
> >
> > so i am not sure what is the best option here... i mean i don't think
> > we need to require using every generation value only once during the
> > lifetime of a context, because it would be hard to enforce  
> > (especially
> > during reboots) One option would be to require uniqueness as long as
> > there are no reboots
> >
> >
> > As it currently described in the document, generation values are
> > increased each time a new locator list is exchanged, so they will not
> > be repeated but there is no problem of repeating when there are
> > reboots, since there is no explicity requirement to avoid repetition,
> > which i think it is the right approach. However, i am not sure how to
> > explain this clearly in terms of uniqueness requirements of the
> > generation values...
>
> Is there any chance of generation counters from two different
> contexts (e.g., forking, re-establishment after reboot) be mixed
> up somehow?

i don't think so because the reboot case is the one i have cosnidered  
above and the forking case is not possible netiher, because the  
update message carries the context tag, which is different for  
different forked instances of a context, so it would actually be  
considered as different contexts (in this case the context confusion  
techniques would prevent mixing two contexts, so they also would  
prevent a case where the context tag and the generation number are  
repeated)


> If not, there's really no problem.

ok, so i will leave it as it is

> I don't recall if you said something anywhere about
> how generation counters are searched; my assumption
> is that you only do that check/search within the
> context. I think it would be good to state that.

the following text is included in the draft:

10.4.  Receiving Update Request messages

...

   Upon the reception of an Update Request message, the host extracts
   the Context Tag from the message.  It then looks for a context which
   has a CT(local) that matches the context tag.

(so, the packet is only processed within the context associated with  
the context tag)

then in the same section it is stated that:

   If the Update message contains a Locator Preference option, then the
   Generation number in the preference option is compared with the peer
   generation number in the context.  If they do not match, then the
   host generates a Shim6 Error Message with Error Code=3 with the
   Pointer field referring to the first octet in the Generation number
   in the Locator Preference option.  In addition, if the number of
   elements in the Locator Preference option does not match the number
   of locators in Ls(peer), then a Shim6 Error Message with Error  
Code=4
   is sent with the Pointer referring to the first octet of the Length
   field in the Locator Preference option.  In both cases of failures,
   no further processing is performed for the Locator Update message.

would this be enough or do you think additional text is needed?

regards, marcelo