Subject: [6lowpan] #65: Deriving IIDs from Short Addresses

From: "6lowpan issue tracker" <[email-masked]>
Date: Mon, 29 Mar 2010 15:10:25 -0000

#65: Deriving IIDs from Short Addresses
--------------------------------+-------------------------------------------
 Reporter:  jhui@…              |       Owner:  jhui@…           
     Type:  defect              |      Status:  new              
 Priority:  major               |   Milestone:                   
Component:  hc                  |     Version:                   
 Severity:  Active WG Document  |    Keywords:                   
--------------------------------+-------------------------------------------
 One of the issues raised on the ML and in Anaheim is the issue of deriving
 IIDs from IEEE 802.15.4 short addresses.  There was general consensus that
 the PAN ID should never be included in the IID.  As such, I think we now
 have the following two options:

 1) Maintain the RFC 4944 translation (short address -> ethernet address ->
 64-bit IID).  Generated IIDs will be 64 bits in length and of the form
 (0000:00ff:fe00:xxxx), where xxxx is the short address.

 2) Update RFC 4944 translation to (short address -> 17-bit IID).
 Generated IIDs will be 17 bits in length and of the form
 (0000:0000:0001:xxxx), where xxxx is the short address.

 The primary difference between the two options are the lengths of prefixes
 that may be used to generate global addresses.  Option 1 says that
 different PANs must be assigned unique 64-bit prefixes.  Option 2 says
 that different PANs must be assigned unique 111-bit prefixes, but that
 multiple PANs may utilize the same 64-bit prefix.

 I am comfortable with either option, but we need to agree on one that is
 well-defined.  So which would people prefer?  If you have no preference,
 please provide that feedback as well.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/65>
6lowpan <http://tools.ietf.org/6lowpan/>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 29 Mar 2010 08:12:18 -0700

In an effort to update 6lowpan-hc so that we can quickly move it back  
into WGLC, I'd like to close on this issue by the end of the week.   
Please provide your feedback.

--
Jonathan Hui

On Mar 29, 2010, at 8:10 AM, 6lowpan issue tracker wrote:

> -------------------------------- 
> +-------------------------------------------
> -------------------------------- 
> +-------------------------------------------

---

From: "Gilberto Rodrigues" <[email-masked]>
Date: Mon, 29 Mar 2010 16:35:25 +0100

Hi there.

I'd be ok with both options, but the second one seems more promising. 
I think 17 bits for IID is more than enough and you can then put those other
111bits into good use.

Gilberto

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jonathan Hui
Sent: segunda-feira, 29 de Março de 2010 16:12
To: [email-masked]
Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses

--
Jonathan Hui

> #65: Deriving IIDs from Short Addresses

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Mar 2010 17:35:26 +0200

> (0000:0000:0001:xxxx), where xxxx is the short address.

I didn't quite understand from the Discussion in Anaheim what is better about

::1:xxxx

than

::ff:fe00:xxxx

If we can stick to the latter, we don't really have to change 4944.

In favor of preparing a lasting fix for 4944, I would make the following change to -06:

> The reconstituted address is built from the 16-bit address xxxx by 
> 
> 1) computing the address:
> 
> ::ff:fe00:xxxx
> 
> 2) replacing the bits in this address by the bits actually given by the prefix in the context.
> 
> In other words, the prefix in the context overrides the address generated by step 1.
> For example, if 64-bit prefix pppp:pppp:pppp:pppp is given, the result is:
> 
> pppp:pppp:pppp:pppp::ff:fe00:xxxx
> 
> while if a 112-bit prefix nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn is given, the result is:
> 
> nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:xxxx

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 29 Mar 2010 17:45:21 +0200

I like Carsten's proposal because it enables - yet does not force- the
use the 111 bits prefix. There are many places where the /64 is assumed
and it's good to be able to use it when that's a constraint on the
deployment.

Pascal

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carsten Bormann
> Sent: Monday, March 29, 2010 5:35 PM
> To: [email-masked]
> I didn't quite understand from the Discussion in Anaheim what is
better
> about
> In favor of preparing a lasting fix for 4944, I would make the
following change
> to -06:
> > 2) replacing the bits in this address by the bits actually given by
the prefix in
> the context.
> >
> > In other words, the prefix in the context overrides the address
generated
> by step 1.
> > while if a 112-bit prefix nnnn:nnnn:nnnn:nnnn:nnnn:nnnn:nnnn is
given,
> the result is:

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 29 Mar 2010 08:52:39 -0700

Hi Carsten,

I think part of the confusion comes from some of the text in RFC  
4862.  In particular, RFC 4862 seems to indicate that a particular  
link defines a fixed length for IIDs (RFC 4944 currently defines IIDs  
to be 64 bits).  Then RFC 4862 has the following text:

"If the sum of the prefix length and interface identifier length does  
not equal 128 bits, the Prefix Information option MUST be ignored."

And RFC 4944 has text to remind of the above constraint:

"An IPv6 address prefix used for stateless autoconfiguration [RFC4862]  
of an IEEE 802.15.4 interface MUST have a length of 64 bits."

So one question is whether it's possible to utilize a 'variable sized'  
IID to generate global addresses.  We already have 64-bit IIDs when  
generating global addresses from EUI-64s.  It may be a bit strange to  
have two different IID lengths for a 6lowpan link, so defining a 17- 
bit IID already bends rules a bit.  Would it be too much of a stretch  
to say that using a short address, we can generate an IID of length  
between 16 and 64 bits? :)

--
Jonathan Hui

On Mar 29, 2010, at 8:35 AM, Carsten Bormann wrote:

> better about
> following change to -06:
>> the prefix in the context.
>>
>> generated by step 1.
>> given, the result is:

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 29 Mar 2010 16:58:31 +0100

Hello,

> 1) computing the address:

I think what was brought up before was perhaps using some 'fake' PAN-ID in
here.

The reason being RFC4944 disallows the use of the "zero address" in the
fake-48. With no PAN-ID (ie: zero's for the PAN-ID bits), this disallows
short address 0. Using some non-zero PAN-ID would remove that problem.

One could use the 0xFFFF PAN-ID, which would not be accidently considered
valid.

Or we could add a note to hc saying that ::ff:fe00:0 is indeed a valid
address with this scheme. This would be the cleanest solution, I'm not sure
if it's "allowed"?

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carsten Bormann
Sent: March 29, 2010 4:35 PM
To: [email-masked]
Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses

> (0000:0000:0001:xxxx), where xxxx is the short address.

I didn't quite understand from the Discussion in Anaheim what is better
about

::1:xxxx

than

::ff:fe00:xxxx

In favor of preparing a lasting fix for 4944, I would make the following

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Mar 2010 18:03:44 +0200

On Mar 29, 2010, at 17:52, Jonathan Hui wrote:

> 
> Hi Carsten,
> 
> I think part of the confusion comes from some of the text in RFC 4862.  In particular, RFC 4862 seems to indicate that a particular link defines a fixed length for IIDs (RFC 4944 currently defines IIDs to be 64 bits).  Then RFC 4862 has the following text:
> 
> "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored."

Aha!
Note to the ND authors: We don't have to copy that restriction.
(Actually, my text is about the prefix in the context, not the one used for SLAAC; I have always been arguing that the two should be disseminated using the same bits in the PIO/6IO while others thought that this was an unnecessary conflation; this now becomes even more interesting.)

> "An IPv6 address prefix used for stateless autoconfiguration [RFC4862] of an IEEE 802.15.4 interface MUST have a length of 64 bits."

Interesting.
Again, this could be changed (e.g., in ND).

> So one question is whether it's possible to utilize a 'variable sized' IID to generate global addresses.  We already have 64-bit IIDs when generating global addresses from EUI-64s.  It may be a bit strange to have two different IID lengths for a 6lowpan link, so defining a 17-bit IID already bends rules a bit.  Would it be too much of a stretch to say that using a short address, we can generate an IID of length between 16 and 64 bits? :)

That would mesh well with my proposal for HC (but the latter only prepares for any ND fixes needed here).
(In my twisted mind, the IID would still be 64 bits, but part of it would be generated from the prefix.
But that's just me.)

Now I still don't know what would be better about ::1:xxxx -- using this would require the exact same changes to all these items, no?  Except that my proposal also needs the "override" (= use only as many bits of ::ff:fe00:xxxx as you need to fill the prefix) rule.

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 29 Mar 2010 17:19:31 +0100

Hello,

> Except that my proposal also needs the "override" (= use only as many bits
of 
> ::ff:fe00:xxxx as you need to fill the prefix) rule.
>(In my twisted mind, the IID would still be 64 bits, but part of it would
be 
> generated from the prefix.
> But that's just me.)

With the 16-bit IID, it can make sense to just override up to the last 16
bits. But with the 64-bit EUI, unless you are using the full 64-bits there
is no promise the IPv6 address will be unique. The last 16-bits will be the
same among many different EUI64's, and indeed has a chance of being the same
as a 16-bit short address in use by the network.

The ::ff:fe00:xxxx format is helpful as it maps to a restricted EUI-64 type
(http://standards.ieee.org/regauth/oui/tutorials/EUI64.html), so anybody
receiving an IPv6 frame from ::ff:fe00:xxxx can ensure someone else doesn't
happen to have this EUI. 

Thus I think the longer-than-64-bit prefix should only be supported with
16-bit short address only, and the prefix must have the format
::xxff:fexx:0000 .  This ensure that someone cannot pick a prefix that maps
to an EUI-64 space, which could be quite confusing.

This would still work with the "override" idea, in that you generate an IID
of the ff:fe00:xxxx format, and override as many bits as needed. If the
prefix is of that :ff:fexx: format it will maintain the separation from
EUI-64, as you just need that ff:fe in place.

Regards,

  -Colin O'Flynn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carsten Bormann
Sent: March 29, 2010 5:04 PM
To: Jonathan Hui
Cc: [email-masked]
Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses

On Mar 29, 2010, at 17:52, Jonathan Hui wrote:

> 
> Hi Carsten,
> 
> I think part of the confusion comes from some of the text in RFC 4862.  In
particular, RFC 4862 seems to indicate that a particular link defines a
fixed length for IIDs (RFC 4944 currently defines IIDs to be 64 bits).  Then
RFC 4862 has the following text:
> 
> "If the sum of the prefix length and interface identifier length does not
equal 128 bits, the Prefix Information option MUST be ignored."

Aha!
Note to the ND authors: We don't have to copy that restriction.
(Actually, my text is about the prefix in the context, not the one used for
SLAAC; I have always been arguing that the two should be disseminated using
the same bits in the PIO/6IO while others thought that this was an
unnecessary conflation; this now becomes even more interesting.)

> "An IPv6 address prefix used for stateless autoconfiguration [RFC4862] of
an IEEE 802.15.4 interface MUST have a length of 64 bits."

Interesting.

> So one question is whether it's possible to utilize a 'variable sized' IID
to generate global addresses.  We already have 64-bit IIDs when generating
global addresses from EUI-64s.  It may be a bit strange to have two
different IID lengths for a 6lowpan link, so defining a 17-bit IID already
bends rules a bit.  Would it be too much of a stretch to say that using a
short address, we can generate an IID of length between 16 and 64 bits? :)

That would mesh well with my proposal for HC (but the latter only prepares
for any ND fixes needed here).
(In my twisted mind, the IID would still be 64 bits, but part of it would be
generated from the prefix.
But that's just me.)

Now I still don't know what would be better about ::1:xxxx -- using this
would require the exact same changes to all these items, no?  Except that my
proposal also needs the "override" (= use only as many bits of
::ff:fe00:xxxx as you need to fill the prefix) rule.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Mar 2010 18:21:11 +0200

> fake-48.

Does it?

I don't know what

   For either address format, all zero addresses MUST NOT
   be used.

actually means (it doesn't say whether this is about 16-bit, 48-bit or 64-bit addresses).
I think this was meant to exclude :: as the IID, but that may be just my interpretation.

> With no PAN-ID (ie: zero's for the PAN-ID bits), this disallows

Even if fake-48 == '0'*48  is not allowed:
Is losing one out of 32k 16-bit addresses actually a problem?

> One could use the 0xFFFF PAN-ID, which would not be accidently considered

That would be the result of interpreting

   if no PAN ID is known, 16 zero bits may be
   used

as "in non-associated mode, the PAN-ID is known to be 0xFFFF".
We could certainly agree on that, if we want.
That would be a change from current implementation practice, AFAIK.

> address with this scheme. This would be the cleanest solution, I'm not sure

If we really need that 32768th address, we could also do that.

Gruesse, Carsten

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 29 Mar 2010 17:38:41 +0100

A prefix of less than 64 bits would be useful when having a small Public 
Internet -> Ethernet -> 6LowPAN network.  Public prefix's are normally 
allocated in 64 or 48 bit sizes.  When I set up a network like this, I 
needed a public /48 instead of a /64 so that I could have one /64 for 
the Ethernet and one for the 6LowPAN.  In my case, the Ethernet was only 
used between the edge router and the IPv6 router so just had the address 
of these two routers on it.

Setting up a network  in this way would force the use of the 16 bit 
short addresses when using the public Internet.  However, these 
addresses compress better than EUI 64 addresses and so may be a better 
choice anyway.

To avoid confusion between the EUI 64 derived addresses and the short 
address, it may be better to use a /40 (or /48)  rather than a /17 
addressing scheme.  We could then keep the pseudo 48 address with the 
::xxff:fexx: as part of the prefix and so keep the advantage of easily 
identifying EUI64 or short addresses.

I am therefore in favour of the second proposal, using a /17.  However, 
if there are reasons why it would not be possible to use the spare bits 
in this way then I prefer the first proposal of a /64 because it is simpler.

Daniel.

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Mar 2010 18:58:51 +0200

On Mar 29, 2010, at 18:38, Daniel Gavelle wrote:

> public /48 instead of a /64 

I was afraid this argument would come up as soon as we take one step from the strict 8+8 structure of IPv6.

This is not a valid argument.

There is never a good reason to give anyone a /64.
(I'm talking about customer relationships here, of course not about single IPv6 subnets.)

Giving out a /64 in a customer relationship is a form of fraud.
It is akin to renting the door to an apartment separately from the apartment.
Yes, of course you can live perfectly fine in an apartment without a door, so you *can* price-differentiate between apartments without doors and with doors, but renting one without a door is still fraud.

The smallest address range that should ever be given out to anyone is a /56.
/60 may do in a pinch (like the one experienced by free.fr), but that is already stretching it.

Folks, if any of your rollout plans involve handing out /64s to another entity, you have to reconsider.

Sorry for this strong reaction, but any scheme to get multiple subnets out of a /64 runs so fundamentally counter to IPv6 principles that it needs to be quashed quickly and effectively.

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 29 Mar 2010 18:01:41 +0100

Hello,

> I think this was meant to exclude :: as the IID, but that may be just my 

I think this was the intent, as it makes the most sense. The way it's
written though it seems to me like it's disallowing an all-zero 64 or 48-bit
address. The sentence before it specifies:

   The interface identifier is formed from this 48-bit address as per
   the "IPv6 over Ethernet" specification [RFC2464].  However, in the
   resultant interface identifier, the "Universal/Local" (U/L) bit SHALL
   be set to zero in keeping with the fact that this is not a globally
   unique value.  For either address format, all zero addresses MUST NOT
   be used.

So for me "either address format" means the pseudo-48 or the real EUI-64.

> If we really need that 32768th address, we could also do that.

The bigger issue is that short address zero is used as a default coordinator
address in some networks. Thus although it's just another address, it's one
that is likely to come up more than address 8956 for example.

Sure it's easy to not use it. But one person's implementation might use it,
and someone else's might specifically check for it and throw away any
packets with this format. Adding some extra text to clarify would be an
improvement here, as I don't think there is any real problem with using
address fe80::ff:fe00:0 that I can see for example, so we shouldn't
artificially limit that address.

I'd be most in favor of using the PAN-ID of 0x0000 as is currently done, and
just specifying that the IID cannot be ::, but the short address can be 0. 

Regards,
  
  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daniel Gavelle
Sent: March 29, 2010 5:39 PM
To: Jonathan Hui
Cc: [email-masked]
Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses

Daniel.

>>
>> Reporter:  jhui@.              |       Owner:  jhui@.

---

From: Robert Cragie <[email-masked]>
Date: Mon, 29 Mar 2010 10:51:40 -0700

+1

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

---

From: Owen Kirby <[email-masked]>
Date: Mon, 29 Mar 2010 11:38:02 -0700

Regarding option 1:
If the goal is to create a pseudo-EUI64 from the 16-bit address. Should 
be concerned about using Xerox's OUI in the first three octets? The OUI 
is something that got trampled in RFC4944's (short address -> IID) 
conversion. Perhaps an IID of the form ACDE:4800::xxxx would make a 
better IID. The AC-DE-48 in this case is the "private" OUI. We could 
even apply to the IEEE (or is it IANA that handles this?) to reserve an 
OUI specifically for 6LoWPAN IID's so that we know they won't conflict 
with other devices on the PAN.

Regarding option 2:
Is there any concern that 17-bit IID's might conflict with 64-bit EUI's? 
If one device has the short address 0x0000, and the other has the long 
address 00-00-00-00-00-01-00-00, then wouldn't they both wind up using 
the same link-local address FE80::1:0000?

I prefer option 1, since it's easier to tell which address type the IID 
was derived from.

Thanks,
Owen Kirby

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 29 Mar 2010 20:44:17 +0100

Hi Owen,

When creating the IID from a 16-bit, you first generate a fake EUI-48. >From that you generate the IID, which has the format xx:xx:xx:ff:fe:xx:xx:xx

Any EUI-64 with ff:fe or ff:ff in the middle is *not* a valid EUI-64, so Xerox shouldn't be too worried ;-)

Reference: http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 

For option #2: I also agree there are some issues around the prefix. If it always had ff:fexx:xxxx at the end, it would always be obvious you are using 16-bit addresses (assuming you do this with 16-bit addresses only).

Regards.

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Owen Kirby
Sent: March 29, 2010 7:38 PM
To: [email-masked]
Subject: Re: [6lowpan] #65: Deriving IIDs from Short Addresses

Regarding option 1:

Regarding option 2:

Thanks,
Owen Kirby

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 29 Mar 2010 20:36:24 -0700

Hi Colin,

The mapping was really intended for global-scope IEEE addresses.  I  
don't think overlap of locally generated IIDs with other IEEE EUI-64  
addresses is really a concern.  Some examples:

1) The whole purpose of complementing the u/l bit when generating IIDs  
is to make best use of the '::' when typing IPv6 addresses.

2) CGAs don't make any attempt to avoid overlap with existing IEEE  
EUI-64 addresses.

3) DHCPv6 servers can assign whatever they want.

The assumption is that once you have locally managed Interface  
Identifiers, you need to have a mechanism that manages their  
assignment/uniqueness anyway.  Furthermore, there is no requirement  
that IIDs have to be generated from link-layer addresses.  Setting the  
u/l bit to zero ensures that no overlap will occur with global scope  
IEEE EUI-64 addresses.

So to frame the current discussion while attempting to be specific to  
6lowpan-hc:

1) How is an IID generated from an IEEE 802.15.4 short address?  This  
is necessary to fill in bits not covered by the HC prefix and the IEEE  
802.15.4 short address.
- For short addresses, I personally prefer keeping as many contiguous  
zeros as possible to make typing IPv6 addresses simpler.  This may  
seem like a minor nuisance, but the IPv6 addr arch did go through the  
trouble of complementing the u/l bit.

2) If the bits contained by the HC prefix and the IID are greater than  
128 bits, which takes precedence in the overlapping bits?
- I think the prefix must take precedence in case you want to assign  
IPv6 addresses that do not follow the standard IID -> mac address  
mapping.  There currently is no requirement within IPv6 that says the  
two have to map to each other.  But we shouldn't disallow the case  
where some bits of the IID happen to utilize the same value in the  
link-layer address.

--
Jonathan Hui

On Mar 29, 2010, at 9:19 AM, Colin O'Flynn wrote:

> Behalf
>> 4862.  In

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Mar 2010 08:37:56 +0200

On Mar 30, 2010, at 05:36, Jonathan Hui wrote:

> make typing IPv6 addresses simpler

Typing ...::ff:fe00:xxxx is a bit ugly, granted.
If we were designing 4944 from scratch, I would buy that argument.
However, it was agreed in May 2007, and I'd like to see a better argument to change it incompatibly.

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 30 Mar 2010 07:54:06 -0700

> argument to change it incompatibly.

AFAIK, there are only a handful of independent implementations that  
have tested interoperability to this day and even less with the use of  
short addresses.  W.r.t. 6lowpan-hc there was ambiguity over whether  
or not to use the PAN ID in the IID.  It seems that we need to change  
something to better achieve interoperability.  There's already  
consensus to never include the PAN ID in the IID, so an update to  
Section 6 of RFC 4944 is already necessary.

I believe the vast majority of implementors are subscribed to this  
list.  So which of the following options do people prefer?

1) IPv6 addrs that have the form aaaa::ff:fe00:xxxx.

2) IPv6 addrs that have the form aaaa::1:xxxx.

In both cases, the prefix and IID is 64 bits.  At this point it's just  
a matter of how many zeros are involved.  It's a minor point, so I  
wouldn't dwell on this issue too long.

--
Jonathan Hui

---

From: Samita Chakrabarti <[email-masked]>
Date: Tue, 30 Mar 2010 19:43:58 -0700

Hi Jonathan,

I would vote for option 1.  [ existing definition in rfc4944  -]

>  (0000:00ff:fe00:xxxx), where xxxx is the short address.

This is simple and easy to understand and compute.  ND assumtion is
that there is one single prefix per 6LoWPAN. If you are talking about
PANs under a 6LowPAN, then I think it is too implementation specific
and we don't need to standardize  it at this point.

So for simplicity and not adding more complexity to ND
autoconfiguration, can we say that
6LoWPAN-unique-prefix::00ff:fe00:xxxx would be the IPv6-address
derived from short address with the above 64-bit IID?

Thanks,
-Samita

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 30 Mar 2010 20:01:44 -0700

Hi Samita,

> I would vote for option 1.  [ existing definition in rfc4944  -]

Just to be clear, option 1 still requires an update to RFC 4944 to  
specify that the PAN ID is no longer used in constructing the IID.   
Minimally, 6lowpan-hc either needs to (i) update Section 6 of RFC 4944  
or (ii) no longer point to RFC 4944 and specify how to reconstruct the  
IID from a short address.  I am fine with either, but if we go with  
the latter, then the 6lowpan-nd document needs to update Section 6 of  
RFC 4944.

> and we don't need to standardize  it at this point.

Yes, I agree with the desire of maintaining 64-bit prefixes.

> derived from short address with the above 64-bit IID?

I think the only argument now is whether the 64-bit IID should take  
the form '::ff:fe00:xxxx' or simply '::1:xxxx'.  The latter is easier  
to type IMHO, but I agree it is a minor point.  Either way, we require  
an update to RFC 4944 and 6lowpan-hc.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 31 Mar 2010 15:44:00 +0200

Hi Jonathan:

I tend to favor the FFFE because it's a space where other mechanisms
will not play. For instance, I do not expect any manual configuration to
place an FFFE in the middle of the IID knowing that it's supposed to be
used for EUI padding. If the subnet spans farther than the LoWPAN, I can
imagine a manual configuration on a server or a router somewhere that
could use an address that matches a ::1:xxxx'.  

Cheers,

Pascal

> Behalf Of Jonathan Hui
> Sent: Wednesday, March 31, 2010 5:02 AM
> To: Samita Chakrabarti
> Cc: [email-masked]; [email-masked]; Erik Nordmark
or (ii)
> no longer point to RFC 4944 and specify how to reconstruct the IID
from a
> short address.  I am fine with either, but if we go with the latter,
then the
> 6lowpan-nd document needs to update Section 6 of RFC 4944.
> 
> >> 64-bit IID).  Generated IIDs will be 64 bits in length and of the
> >> form (0000:00ff:fe00:xxxx), where xxxx is the short address.
> >
the form
> '::ff:fe00:xxxx' or simply '::1:xxxx'.  The latter is easier to type
IMHO, but I
> agree it is a minor point.  Either way, we require an update to RFC
4944 and
> 6lowpan-hc.

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 31 Mar 2010 08:36:03 -0700

It seems that there is good enough support for 'ff:fe' that we can  
move forward with that.  Hopefully we won't have any issues with  
stepping on locally-managed Xerox EUI-48s ;)

As discussed before, 6lowpan-hc can no longer simply point to Section  
6 of RFC 4944 since the PAN ID is no longer used.  I see two approaches:

1) 6lowpan-hc updates Section 6 of RFC 4944 to indicate how an IID is  
generated from a 802.15.4 short address.

2) 6lowpan-hc becomes self contained by saying how to expand a  
802.15.4 short address into an IID (note the slightly different choice  
of wording).  An update to RFC 4944 would be left for another draft  
(presumably the ND draft).

I am fine with either, but if someone has strong feelings please speak  
up.

--
Jonathan Hui

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Mar 2010 17:59:09 +0200

> It seems that there is good enough support for 'ff:fe'

(ff:fe00 due to the way this is put in the middle of two 24-bit fields.)

> As discussed before, 6lowpan-hc can no longer simply point to Section 6 of RFC 4944 since the PAN ID is no longer used.  

As far as I can see, HC does not have to change 4944 at all.
HC with the results of this discussion simply is more efficient if the 4944 conditional "if no PAN ID is known, 16 zero bits may be used" is true.

So I see no need for either:

> I see two approaches:
> 
> 1) 6lowpan-hc updates Section 6 of RFC 4944 to indicate how an IID is generated from a 802.15.4 short address.
> 
> 2) 6lowpan-hc becomes self contained by saying how to expand a 802.15.4 short address into an IID (note the slightly different choice of wording).  An update to RFC 4944 would be left for another draft (presumably the ND draft).

Instead, I would say:

Note: This form of compression only addresses the case where instead of a PAN ID, 16 zero bits are used according to section 6 of RFC 4944.  This case appears to be the common implementation practice for RFC 4944.  If, however, a PAN ID is used, only the case SAM=01/DAM=01 can be used to obtain some compression.

Gruesse, Carsten

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 31 Mar 2010 09:12:05 -0700

> (ff:fe00 due to the way this is put in the middle of two 24-bit  

Of course the fully expanded version of the IID would be  
0000:00ff:fe00:xxxx.

>> As discussed before, 6lowpan-hc can no longer simply point to  
>> Section 6 of RFC 4944 since the PAN ID is no longer used.
>
> HC with the results of this discussion simply is more efficient if  
> the 4944 conditional "if no PAN ID is known, 16 zero bits may be  
> used" is true.

 From prior discussions on the list, the result of 802.15.4-2003 is  
that the PAN ID is always known so the case where no PAN ID is known  
is never true.

>> 1) 6lowpan-hc updates Section 6 of RFC 4944 to indicate how an IID  
>> is generated from a 802.15.4 short address.
>>
>> 802.15.4 short address into an IID (note the slightly different  
>> choice of wording).  An update to RFC 4944 would be left for  
>> another draft (presumably the ND draft).
>
> Instead, I would say:
>
> Note: This form of compression only addresses the case where instead  
> of a PAN ID, 16 zero bits are used according to section 6 of RFC  
> 4944.  This case appears to be the common implementation practice  
> for RFC 4944.  If, however, a PAN ID is used, only the case SAM=01/ 
> DAM=01 can be used to obtain some compression.

Unclear whether setting the PAN ID to zero is the common  
implementation practice.  This issue came about due to  
interoperability concerns.  The conclusion from that thread was that  
the PAN ID is always known and so you should never assume zero for  
those bits.  Of course, that spawned additional concerns about the use  
of PAN ID in the first place, leading to where we are today.

At this point, I would prefer to include a short section within  
6lowpan-hc that simply says how to reform the IID from an IEEE  
802.15.4 short or extended address to make the HC draft self contained  
and decouple it from RFC 4944.

--
Jonathan Hui