Jonathan Hui a écrit :
On Apr 8, 2009, at 8:06 AM, Pascal Thubert (pthubert) wrote:
AH, ESP and MH no?
Bit 4 does not have to be forced to 0 so we could actually support these
by making the type 3 bits.
Jonathan, what do you think?
Sounds good to me. So maybe we should expand to the following:
0: Hop-by-Hop Options
1: Routing
2: Fragment
3: Destination Options
4: Encap Security Payload
5: Authentication Header
6: Mobility Header
7: Reserved
It covers extension headers defined in rfc2460 "IPv6 spec" and rfc3775
"Mobile IPv6". They're intertwinned at
http://www.iana.org/assignments/protocol-numbers/
Method should consider that DO may appear twice, but same type. (DO1 and
DO2, and no more). Also, if there's a jumbogram hop-by-hop extension
header the total length of the packet comes from that hbh option (and
not from the base header).
In addition, there's ongoing work about a new generic extension header,
GIEH: draft-krishnan-ipv6-exthdr-06 which may or may not fly. If it
flies, IANA is going to assign a new type for it.
And there may also be this CGA extension header
draft-dong-savi-cga-header-00.txt. Or HIP extension headers
draft-nikander-hip-hiccups-01.
What about changing the meaning of the Length field in the
Authentication and Mobility headers?
I am not sure what you mean by changing the meaning? Do you mean to
change the way 6lowpan Header Compression interprets these Length
fields? Or the way e.g. rfc2460 "IPv6" should be modified?
Authentication header is a bit
different since it specifies 4-octet units.
Do we have a good header for type 7? :-)
I guess type 7 being there is a potentially good way to say we don't
know now all the extension headers (but maybe later we will).
It should probably be longer than 1bit.
What do others think?
I am also interested in other opinions.
Alex
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
