Subject: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-11

From: Jonathan Hui <[email-masked]>
Date: Wed, 1 Sep 2010 14:24:44 -0700

By request of the chairs, I have made Dario's suggested change before submission to IESG.

   This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is
   also used to reconstruct any part of an IID not covered by context
   information when only 16 bits are carried in-line (SAC/DAC=10).
-->
   This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is
   also used to reconstruct any part of an IID not covered by context
   information.

--
Jonathan Hui

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: September 1, 2010 2:22:17 PM PDT
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-ietf-6lowpan-hc-11 
> 
> 
> A new version of I-D, draft-ietf-6lowpan-hc-11.txt has been successfully submitted by Jonathan Hui and posted to the IETF repository.
> 
> Filename:	 draft-ietf-6lowpan-hc
> Revision:	 11
> Title:		 Compression Format for IPv6 Datagrams in 6LoWPAN Networks
> Creation_date:	 2010-09-01
> WG ID:		 6lowpan
> Number_of_pages: 23
> 
> Abstract:
> This document specifies an IPv6 header compression format for IPv6
> packet delivery in 6LoWPAN networks.  The compression format relies
> on shared context to allow compression of arbitrary prefixes.  How
> the information is maintained in that shared context is out of scope.
> This document specifies compression of multicast addresses and a
> framework for compressing next headers.  UDP header compression is
> specified within this framework.
> 
> 
> 
> The IETF Secretariat.
> 
>

---

From: "Colin O'Flynn" <[email-masked]>
Date: Wed, 1 Sep 2010 22:33:13 +0100

Hello,

I noticed that -10 also changed the format of the link-local stateless
compression to match the stateful global prefix compression.

Is there a case where you'd want to use the fe80::ff:fe00:XXXX form, where
the XXXX is not the 802.15.4 short address? 

At any rate that change is fine, as it somewhat simplifies the code since
all addressing cases are then the same for the IID.

Regards,

 -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jonathan Hui
Sent: September 1, 2010 10:25 PM
To: 6lowpan 6lowpan
Subject: [6lowpan] Fwd: New Version Notification for
draft-ietf-6lowpan-hc-11

By request of the chairs, I have made Dario's suggested change before
submission to IESG.

--
Jonathan Hui

Begin forwarded message:

> A new version of I-D, draft-ietf-6lowpan-hc-11.txt has been successfully
submitted by Jonathan Hui and posted to the IETF repository.
> specified within this framework.

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

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 1 Sep 2010 14:41:57 -0700

> the XXXX is not the 802.15.4 short address? 

I don't know if there's a use case, but the format doesn't prohibit it.  If XXXX is not derived from the link layer, then you need to carry it in-line (e.g. SAM/DAM='10').

--
Jonathan Hui

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 01 Sep 2010 16:44:33 -0700

I can see four cases where SAM/DAM=2 might be used in stateless 
compression:
1) A manually configured link-local address.
2) A node acting as a proxy for a specific link-local address.
3) A link-local anycast address.
4) A redirect

Perhaps these are unlikely cases, but it's nice to have them covered.

Dario

On 01/09/2010 2:33 PM, Colin O'Flynn wrote:
>> From: IETF I-D Submission Tool<[email-masked]>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 02 Sep 2010 10:21:43 +0100

Hi Jonathan,

It's a minor point and the text is not specifically wrong in hc-11 but 
the following change would make things 100% consistent, in my view.

The link-local prefix is by definition FE80::/64. So the following:

10:  16 bits.  The first 112 bits of the address are elided.
             The value of the first 64 bits is the link-local prefix
             padded with zeros.  The following 64 bits are 0000:00ff:
             fe00:XXXX, where XXXX are the 16 bits carried in-line.

would look better as:

10:  16 bits.  The first 112 bits of the address are elided.
             The value of the first 64 bits is the link-local prefix.
             The following 64 bits are 0000:00ff:fe00:XXXX,
             where XXXX are the 16 bits carried in-line.

as the 'padded with zeros' seems to be a hangover from the previous text 
when it expanded it to a 112-bit prefix.

Change at your discretion. Apologies for not raising this earlier.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: "Colin O'Flynn" <[email-masked]>
Date: Thu, 2 Sep 2010 10:36:28 +0100

Hi Dario,

Great thanks. I had asked as the reasoning for having the fe80::XXXX style
was that you could use it to assign easy-to-type link-local addresses to
nodes. So for example you could assign the address fe80::1 to a node, and
6lowpan could compress that nicely.

In real life I think most of the time we will see auto-configured link-local
addresses anyway, so I think it was also an unlikely case. But I couldn't
think of any fe80::ff:fe00:XXXX uses. So knowing there is a few out there,
even if they are unlikely, was my concern.

The hc-11 draft seems to solve all previous issues I've heard of or run into
during implementation of 6lowpan-hc. Thus I would support this draft's LC
and sending onward to the IETF.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dario Tedeschi
Sent: September 2, 2010 12:45 AM
To: [email-masked]
Subject: Re: [6lowpan] Fwd: New Version Notification for
draft-ietf-6lowpan-hc-11

Dario

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 2 Sep 2010 06:15:20 -0700

Hi Robert,

On Sep 2, 2010, at 2:21 AM, Robert Cragie wrote:

> It's a minor point and the text is not specifically wrong in hc-11 but the following change would make things 100% consistent, in my view.
> 
> as the 'padded with zeros' seems to be a hangover from the previous text when it expanded it to a 112-bit prefix.

As defined in Section 2.4 of RFC4291, the link-local prefix is only 10 bits long:

      Address type         Binary prefix        IPv6 notation   Section
      ------------         -------------        -------------   -------
      Unspecified          00...0  (128 bits)   ::/128          2.5.2
      Loopback             00...1  (128 bits)   ::1/128         2.5.3
      Multicast            11111111             FF00::/8        2.7
      Link-Local unicast   1111111010           FE80::/10       2.5.6

RFC4862 has similar wording in forming a link-local address:

   1.  The left-most 'prefix length' bits of the address are those of
       the link-local prefix.

   2.  The bits in the address to the right of the link-local prefix are
       set to all zeroes.

   3.  If the length of the interface identifier is N bits, the right-
       most N bits of the address are replaced by the interface
       identifier.

So the 'padded with zeros' text isn't a mistake, the well-known link-local prefix needs to be "expanded" from 10 to 64 bits.

--
Jonathan Hui

---

From: Robert Cragie <[email-masked]>
Date: Thu, 02 Sep 2010 15:10:57 +0100

Hi Jonathan,

OK, understood. I was looking in an IPv6 book which stated link local 
prefix as FE80::/64. RFC 4291 Section 2.5.6 also shows it as effectively 
FE80::/64. But I agree the language in RFC 4862 is consistent with hc-11.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064