Hello, What would be the thought about moving this to a new 6lowpan header compression type? As in a new I-D that adds header compression options for ICMPv6 & ND.
Thinking about this again I think it would actually be reasonable. There is a fair amount of wasted space in ICMPv6, without being too clever you could get rid of the reserved fields to give you some extra bytes. Being a little more clever could save you lots of space in situations where you've repeated any information twice, be it IPv6 addresses or L2 addresses. Doing it as a 6lowpan hc would mean it could be evaluated hop-by-hop for forwarded messages, and fields which can no longer be elided are added back in to maintain consistency. You could also trim certain options down where you've padded them to 8-octect lengths, but most of that is just wasted padded. And a little more work than that could give you savings in fields such as type/code where you don't use the entire space given. But you probably wouldn't even care about saving space there compared to the huge savings elsewhere! This would save 6lowpan-nd from having to do anything against RFC4861, and generally keep it clean and easy. It also stops having to do any heavy modifications to 6lowpan-nd, which might get it to RFC status faster. Regards, -Colin PS: I'd be happy to help write such an I-D, this comment was to see if there was support for such an idea, not me trying to be lazy and get other people to do it ;-) -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of 6lowpan issue tracker Sent: July 8, 2010 2:43 PM To: [email protected] Cc: [email protected] Subject: [6lowpan] #82: Space optimization in NS/NA #82: Space optimization in NS/NA --------------------------------+------------------------------------------- Reporter: z...@… | Owner: z...@… Type: enhancement | Status: new Priority: minor | Milestone: Component: nd | Version: Severity: - | Keywords: --------------------------------+------------------------------------------- The worst-case in nd-10 for NS/NA messages is currently: 6LN-6LR NS/NA: 56 bytes 6LR-6LBR NS/NA: 72 bytes This ticket is to conclude whether we need to do anything about this or not. Really only the multihop DAD NS/NA starts to be a problem as its ARO also contains the registration address. Possible solution from Erik to make multihop DAD NS/NA smaller, creating new messages has drawbacks though: We could create a NS' and NA' messages that do not contain the target address and save 16 bytes for the NS/NA registrations. But that means a new pair of message types and less interoperability with 4861. -- Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/82> 6lowpan <http://tools.ietf.org/6lowpan/> _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
