Subject: [6lowpan] Re: MultiHop Format document issues

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 20 Oct 2005 16:10:54 -0700 (PDT)

Hi Gabe,

Thanks for the update. See below.

> Here's another preliminary version of the doc:
> 
> 
http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00b.h
tm
http://www.geocities.com/gabriel_montenegro_2000/draft-ietf-6lowpan-format-00b.t
xt
> 
> Please look it over, specially as related to the changes:
> 

I'll  do. But will not have time before the draft cut-off deadline.

> > Are we re-thinking of IPv6-address format ( the low 64bit part) as well ?
> > fe80:0:0:<pan-id>::<16bit-addr>?
> 
> ah, i see. you're talking about the interface identifier (IID) format based on
> the link-layer address. yes, that's one of the things that an ip-over-foo
> is expected to specify. we already did for the 64-bit format. for the
> 16-bit 15.4 link-layer format, your suggestion is the simplest, yes.
> we're already suggesting adding a <pan-id> to a /48 to obtain a prefix 
identifier
> so this would play into that as well. but for IIDs we can actually mandate
> the above format. going through the draft and adding support for short bit
> addresses is still on the TODO list, hopefully we can do it before the 
cut-off.

great! Thanks.

> > Currently it says 'Final destination field' - I suppose, it's going to 
change
> > to 'Final Destination header' or alike?
> > If we add source link-layer address as well, then I'd really like to see
> > a suggestion for header compression in case of 64bit addresses, even though
> > IETF charter may not allow to specify IEEE address format. Do you think, it
> > might be something that should be brought up at the IEEE meetings?
> 
> not sure what you mean here.

I was thinking of using some formating scheme in 64bit address format-
especially in the higher 48bit part - a crude example: <higher 32bit 
format>:<16bit-otherid><16bit hardware-id>. Having a formatting scheme
may help compressing the 64bit address into a 32bit address - thus
we can accomodate both originator and final destination address into the
64bit address space.

-Samita

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

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 20 Oct 2005 16:39:21 -0700 (PDT)

> we can accomodate both originator and final destination address into the

wouldn't want to go there:

- this is IEEE's turf (the above would be an alternate format the the EUI-64
  which already includes 24 bits for company_id)
- ignoring the top bits (presumably company id) means we can have collisions
  if we only look at the bottom bits (these bottom bits are only required to 
  be unique within a given company_id space
- presumably, the IEEE went for EUI-64 instead of the typical EUI-48 precisely
  because with 15.4 devices one expects so many of them. cutting back on the number
  of bits we have to tell them apart (from 64 to 32 per address 
  if I understand your proposal) defeats that purpose
- there's an existing alternative: use short 16-bit addresses as specified by 
  15.4.

-gabriel