Hi Richard,
Defining NHCs for each extension header allows the use of LOWPAN_NHC when those extension headers are present, saving up to 6 bytes. Note that the current proposal for supporting extension headers only replaces the Next Header field with the NHC encoding - so no additional bytes are added in the worst case.
If we change the meaning of the Length field from 8-octet units to 1- octet units, then we save up to 7 bytes per extension header.
The 7 extension headers listed are the only IPv6 extension headers that I am aware of, though, in my last email, I did solicit the WG for other headers lurking out there in case I missed them.
-- Jonathan Hui On Apr 8, 2009, at 10:45 AM, Richard Kelsey wrote:
From: Jonathan Hui <[email protected]> Date: Wed, 8 Apr 2009 09:57:48 -0700 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 I have lost the thread a bit here. How many bytes do we save by having an NHC identifier for a particular extension header type? It seems likely that the marginal advantage of adding each new NHC identifier is decreasing. Why pick these seven in particular? -Richard Kelsey
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
