I think the minimal extension header you proposed is right, though I'm
still not convinced about breaking larger headers into pieces on 16 byte
boundaries.
geoff
On Mon, 2008-07-07 at 09:10 +0200, Carsten Bormann wrote:
> Hi Jukka,
>
> > unrecognized header
>
> indeed, this would normally be a consideration for an extension
> header, together with a regime for administration of an extension
> number space.
> However, running the full gamut of protocol design considerations
> explicitly wasn't my objective here.
> My assumption was that management of extensions and their semantics
> was part of setting up the network.
>
> Specifically:
>
> > AB=00 ("Mandatory"): If the object is not understood, the entire
> > message containing it MUST be rejected, and an error message sent
> > back.
>
> If that is the objective, you might as well use NALP.
>
> > AB=01 ("Ignore"): If the object is not understood, it MUST be
> > deleted
> > and the rest of the message processed as usual.
>
> This is the assumption here.
>
> > AB=10 ("Forward"): If the object is not understood, it MUST be
> > retained unchanged in any message forwarded as a result of message
> > processing, but not stored locally.
>
> I'm not sure that is needed (or even possible, without imposing way
> more structure on the extension headers).
>
> So my question to the list would be:
> Is the minimal extension header I proposed the right approach or do we
> really have a requirement for the full benefits of extensibility and
> composability that a full-blown extension header approach would bring?
>
> Gruesse, Carsten
>
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
