[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ULE extension headers
Marie-Jose Montpetit wrote:
I support the adoption of the ID as WG document. I also suggest for
point 5) extension headers in ULE for future services.
I agree with an extension header for future services.
I would propose to do it in an IPv6-style, using some values in the 1-1500 part of next header, to signal the extention header(s). Such headers could then have a fixed and well known begining :
+---+---+---+--// ..... // ----+
| NH | L | extension value |
+---+---+---+--// ..... // ----+
NH : 2 bytes, defines the type of next field which could then be,
a classical ULE payload (0x800 for IPv4 ...) or even another
extension header.
L : length in bytes of the header.
Even some values range could be reseved for that purpose, that would allow implementation to be compatible with still not known extensions. And even that would indicate the behaviour if extension is not known.
exemple :
1280 <= type field < 1304 : optional extension, if not known,
just skip and process next
1304 <= type field < 1408 : critical extension, if not known, stop
processing, drop ULE SNDU, and possibly
report an error to emitter
(if possible, but how ??, usefull ??, ..)
I chose those values as exemple because
- they are in the 1-500 range
- they have a nice bit pattern and can be checked with a single AND
Still about the type field :
I think it would be good to reseve a certain range of these values, for experimental uses, which would garanty that (if respected ;-))) there would be no conflict with due reserved values. 1408 <= type field < 1472 : reseved for experimental purpose, In
operational use, such SNDU MUST be
silently dropped.
All this is very little implementation and keeps the door opened for any future services.
Your thoughts about this ?
Regards.
Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com