Subject: [6lowpan] #82: Space optimization in NS/NA

From: "6lowpan issue tracker" <[email-masked]>
Date: Thu, 08 Jul 2010 13:42:57 -0000

#82: Space optimization in NS/NA
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  zach@…            
     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/>

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 8 Jul 2010 15:23:50 +0100

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-masked] [mailto:[email-masked]] On Behalf Of 6lowpan issue tracker
Sent: July 8, 2010 2:43 PM
To: [email-masked]
Cc: [email-masked]
Subject: [6lowpan] #82: Space optimization in NS/NA

 6LN-6LR NS/NA: 56 bytes
 6LR-6LBR NS/NA: 72 bytes

_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan