From alexandru.petrescu@gmail.com Wed Dec 16 13:14:00 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60BE3A6A88 for <6lowpan@core3.amsl.com>; Wed, 16 Dec 2009 13:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdgG1RpnLyu2 for <6lowpan@core3.amsl.com>; Wed, 16 Dec 2009 13:13:56 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 8DC833A6A56 for <6lowpan@ietf.org>; Wed, 16 Dec 2009 13:13:53 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 21E5BD48196; Wed, 16 Dec 2009 22:13:36 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id E9A79D4806C; Wed, 16 Dec 2009 22:13:33 +0100 (CET) Message-ID: <4B294D7A.1040801@gmail.com> Date: Wed, 16 Dec 2009 22:13:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: daniel.gavelle@jennic.com References: <4B0F9D66.2020706@jennic.com> In-Reply-To: <4B0F9D66.2020706@jennic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091216-0, 16/12/2009), Outbound message X-Antivirus-Status: Clean Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboards X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 21:14:00 -0000 Daniel Gavelle a écrit : > I agree with the recent proposal to remove the mandatory requirement for > a whiteboard and duplicate address detection. > > However, 16 bit 802.15.4 addresses are a very useful optimisation. > Assigning these in a standard way is important in the absence of a > whiteboard. One option may be to use DHCPv6. However, the DHCPv6 > packet sizes are quite large and so some sort of DHCPv6 message > compression would be useful. Extended LowPANs would also be useful in > some applications. > > If the whiteboard and DAD are removed, I would like the issues of 16 bit > address assignment and extended LowPANs Excuse me, sorry, but are the other non-16bit addresses (48bit) ever assigned by DHCP? I doubt IETF could spec a means to assign MAC addresses... Thanks, Alex to still be addressed by an RFC > within the IETF 6LowPAN group, rather than having several different non > interoperable implementations. > > From coflynn@newae.com Wed Dec 16 15:49:36 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD883A6860 for <6lowpan@core3.amsl.com>; Wed, 16 Dec 2009 15:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNglZ2qxn+uD for <6lowpan@core3.amsl.com>; Wed, 16 Dec 2009 15:49:36 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id D06173A635F for <6lowpan@ietf.org>; Wed, 16 Dec 2009 15:49:35 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1NL3cO-0007rl-3n; Wed, 16 Dec 2009 18:49:20 -0500 From: "Colin O'Flynn" To: "'Alexandru Petrescu'" , References: <4B0F9D66.2020706@jennic.com> <4B294D7A.1040801@gmail.com> In-Reply-To: <4B294D7A.1040801@gmail.com> Date: Wed, 16 Dec 2009 23:49:07 -0000 Message-ID: <010601ca7eaa$5df9ea00$19edbe00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acp+lK3SG2kesKDFQ0qvsqtMvJDXvAAE9/xw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboards X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2009 23:49:37 -0000 Hello, > Excuse me, sorry, but are the other non-16bit addresses (48bit) ever=20 > assigned by DHCP? There's at least two options I know of for this: #1 Add another 6lowpan-nd specific extension to DHCPv6 to add a simple link-layer address option #2 Nodes could assign their own short addresses. Nodes power on and autoconfigure a IPv6 address based on the 64-bit MAC address. With this = they then do the DHCP dance, and get another address. Nodes check if this = address can be used to assign their own short address. Aka: the IPv6 address it assigns matches the prefix, the PAN-ID, etc.=20 Thus nodes 'figure out' if a certain short address will make their IPv6 address compressible.=20 Regards, -Colin -----Original Message----- From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On = Behalf Of Alexandru Petrescu Sent: December 16, 2009 9:14 PM To: daniel.gavelle@jennic.com Cc: 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboards Daniel Gavelle a =E9crit : > I agree with the recent proposal to remove the mandatory requirement = for=20 > a whiteboard and duplicate address detection. >=20 > However, 16 bit 802.15.4 addresses are a very useful optimisation.=20 > Assigning these in a standard way is important in the absence of a=20 > whiteboard. One option may be to use DHCPv6. However, the DHCPv6=20 > packet sizes are quite large and so some sort of DHCPv6 message=20 > compression would be useful. Extended LowPANs would also be useful in=20 > some applications. >=20 > If the whiteboard and DAD are removed, I would like the issues of 16 = bit=20 > address assignment and extended LowPANs Excuse me, sorry, but are the other non-16bit addresses (48bit) ever=20 assigned by DHCP? I doubt IETF could spec a means to assign MAC addresses... Thanks, Alex to still be addressed by an RFC > within the IETF 6LowPAN group, rather than having several different = non=20 > interoperable implementations. >=20 >=20 _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan From alexandru.petrescu@gmail.com Thu Dec 17 10:41:21 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D67428C14B for <6lowpan@core3.amsl.com>; Thu, 17 Dec 2009 10:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scfY1KXmpARM for <6lowpan@core3.amsl.com>; Thu, 17 Dec 2009 10:41:20 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 2327128C14F for <6lowpan@ietf.org>; Thu, 17 Dec 2009 10:41:19 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nBHIf4k4018520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 17 Dec 2009 19:41:04 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nBHIf39Q026171; Thu, 17 Dec 2009 19:41:03 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nBHIf3cL000636; Thu, 17 Dec 2009 19:41:03 +0100 Message-ID: <4B2A7B3F.4070609@gmail.com> Date: Thu, 17 Dec 2009 19:41:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Colin O'Flynn" References: <4B0F9D66.2020706@jennic.com> <4B294D7A.1040801@gmail.com> <010601ca7eaa$5df9ea00$19edbe00$@com> In-Reply-To: <010601ca7eaa$5df9ea00$19edbe00$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 6lowpan@ietf.org, daniel.gavelle@jennic.com Subject: Re: [6lowpan] Whiteboards X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:41:21 -0000 Colin O'Flynn a écrit : > Hello, > >> Excuse me, sorry, but are the other non-16bit addresses (48bit) >> ever assigned by DHCP? > > There's at least two options I know of for this: > > #1 Add another 6lowpan-nd specific extension to DHCPv6 to add a > simple link-layer address option Hmm... makes some sense, what would it look like? (rfc4944 defines such an option for ND). What would it be used for and how? > #2 Nodes could assign their own short addresses. Nodes power on and > autoconfigure a IPv6 address based on the 64-bit MAC address. You mean the "EUI-64 Identifier"? (it's not an address, it's an identifier). Is there such a thing as a 64bit MAC address? > With this they then do the DHCP dance, and get another address. Sounds as forming an IPv6 link-local address in order to do DHCP dance prior to obtain a global IPv6 address. (yes, in IPv4 one could say that the node uses its MAC address while doing the DHCP initial dance and the unspecified IPv4 address 0.0.0.0, but in IPv6 the unspecified addresses (search " :: " in rfc3315) are not used DHCPv6 in the initial DHCPv6 dance, but the link-local addresses are). Forming an IPv6 link-local address based on the 16bit short MAC address - ok, using on RFC4944. And then do DAD on this IPv6 link-local address, because the EUI-64 identifier based on the 16bit short MAC address is not guaranteed global, has that g bit unset. > Nodes check if this address can be used to assign their own short > address. Yes, usually they do DAD to make sure their IPv6 link-local address is unique within that link. But don't rely on the IP address uniqueness to conclude that the MAC address corresponding to that IP address is unique. > Aka: the IPv6 address it assigns matches the prefix, the PAN-ID, etc. > Sorry can't follow this. Which prefix? Which PAN-ID? > Thus nodes 'figure out' if a certain short address will make their > IPv6 address compressible. Do IP nodes care whether their MAC address (the short MAC address included) is unique? I don't think so. I think IP nodes care only whether their IP address is unique. Also, it is completely unclear to me what kind of layer does 6LoWPAN deal with - is it IP? Is it MAC? Alex > > Regards, > > -Colin > > > > -----Original Message----- From: 6lowpan-bounces@ietf.org > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: December 16, 2009 9:14 PM To: daniel.gavelle@jennic.com Cc: > 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboards > > Daniel Gavelle a écrit : >> I agree with the recent proposal to remove the mandatory >> requirement for a whiteboard and duplicate address detection. >> >> However, 16 bit 802.15.4 addresses are a very useful optimisation. >> Assigning these in a standard way is important in the absence of a >> whiteboard. One option may be to use DHCPv6. However, the DHCPv6 >> packet sizes are quite large and so some sort of DHCPv6 message >> compression would be useful. Extended LowPANs would also be useful >> in some applications. >> >> If the whiteboard and DAD are removed, I would like the issues of >> 16 bit address assignment and extended LowPANs > > Excuse me, sorry, but are the other non-16bit addresses (48bit) ever > assigned by DHCP? > > I doubt IETF could spec a means to assign MAC addresses... > > Thanks, > > Alex > > > to still be addressed by an RFC >> within the IETF 6LowPAN group, rather than having several different >> non interoperable implementations. >> >> > > _______________________________________________ 6lowpan mailing list > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan > > From alexandru.petrescu@gmail.com Thu Dec 17 10:51:12 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E293A69CF for <6lowpan@core3.amsl.com>; Thu, 17 Dec 2009 10:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ26ReCk6CO4 for <6lowpan@core3.amsl.com>; Thu, 17 Dec 2009 10:51:11 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 9CBFB3A69CC for <6lowpan@ietf.org>; Thu, 17 Dec 2009 10:51:11 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nBHIoumt027652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <6lowpan@ietf.org>; Thu, 17 Dec 2009 19:50:56 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nBHIotAW026886 for <6lowpan@ietf.org>; Thu, 17 Dec 2009 19:50:56 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nBHIottp027450 for <6lowpan@ietf.org>; Thu, 17 Dec 2009 19:50:55 +0100 Message-ID: <4B2A7D8F.4080004@gmail.com> Date: Thu, 17 Dec 2009 19:50:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: 6lowpan <6lowpan@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6lowpan] RFC4944 about EUI-64 "addresses"? X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 18:51:13 -0000 6LoWPANners, I believe I have another complain about the RFC 4944. Yes, we are not modifying RFC4944 neither here nor now. However, I have been referred to it several times while discussing the current WG items. For example, in private and in public I have been told that RFC 4944 says "EUI-64 address". Or, I am used to EUI-64 being not an address but an identifier. RFC 2464 mentions it as an "EUI-64 identifier", or "Interface Identifier". It never calls it an "EUI-64 address". RFC 4944 mentions it as an "EUI-64 address" in some places: rfc4944: > All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short > addresses (Section 3 and Section 12) are also possible. [...] > Length: This is the length of this option (including the type and > length fields) in units of 8 octets. The value of this field is 2 if > using EUI-64 addresses, or 1 if using 16-bit short addresses. It's very difficult to understand it ok. I am used for an address to be unique, otherwise it's not very good. But an identifier is not necessarily unique, it's good, and it has that g bit to distinguish it being unique or not. Now that you read up to here, also understand my complain about RFC 4944 reading "short address". Instead, I would like it to say "short MAC address" throughout. This would have saved me much misunderstandings in many discussions in 6LoWPAN and RoLL. Thank you, Alex From coflynn@newae.com Thu Dec 17 11:41:25 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206BB3A6A0B for <6lowpan@core3.amsl.com>; Thu, 17 Dec 2009 11:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncnk-naJkW7a for <6lowpan@core3.amsl.com>; Thu, 17 Dec 2009 11:41:24 -0800 (PST) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id BB56E3A68E3 for <6lowpan@ietf.org>; Thu, 17 Dec 2009 11:41:23 -0800 (PST) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1NLMDj-0000K1-Aa; Thu, 17 Dec 2009 14:41:07 -0500 From: "Colin O'Flynn" To: "'Alexandru Petrescu'" References: <4B0F9D66.2020706@jennic.com> <4B294D7A.1040801@gmail.com> <010601ca7eaa$5df9ea00$19edbe00$@com> <4B2A7B3F.4070609@gmail.com> In-Reply-To: <4B2A7B3F.4070609@gmail.com> Date: Thu, 17 Dec 2009 19:40:54 -0000 Message-ID: <001e01ca7f50$db358730$91a09590$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp/SPGGCjgvIBG2Tgmfg4zTIt1jMwABJ1Vw Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: 6lowpan@ietf.org, daniel.gavelle@jennic.com Subject: Re: [6lowpan] Whiteboards X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 19:41:25 -0000 Hello, > What would it be used for and how? The initial version of 6lowpan-nd added this idea in. See http://tools.ietf.org/html/draft-hui-6lowpan-nd-00=20 > You mean the "EUI-64 Identifier"? (it's not an address,=20 > it's an > identifier). Is there such a thing as a 64bit MAC=20 The 802.15.4 Address (aka: MAC address) is guaranteed to be unique by = IEEE 802.15.4-2006, at least everywhere within the PAN.=20 Nodes can use either 64-bit or 16-bit addressing. When nodes power up = they are preprogrammed with a 64-bit IEEE MAC address they use to = communicate. They then may be assigned a shorter 16-bit address, which they can use = to save some bytes. However the 64-bit address still remains valid, and the node can be addresses by it. Nor do you need to do this 16-bit addressing. You can keep just using = 64-bit addressing and skip assigning 16-bit addresses.=20 The idea is almost very node in the world could be programmed with a different 64-bit MAC address. Hence you could bring two nodes together = and be sure there was no address collision. But with 16-bit MAC addressing = you are much more likely to get a collision, hence why the 16-bit addresses = are assigned dynamically by the network. The network assures no two nodes = are assigned the same 16-bit address. > Sounds as forming an IPv6 link-local address in order to=20 > do DHCP dance > prior to obtain a global IPv6 address. =20 Basically yes! The node has to do this anyway, as a node using 6LoWPAN = will bring up minimum of two valid unicast addresses: Link-local based on 64-bit 802.15.4 Address Global based on 64-bit 802.15.4 Address If the node can use short addressing, you add two more: Link-local based on 16-bit 802.15.4 Address Global based on 16-bit 802.15.4 Address >Sorry can't follow this. Which prefix? Which PAN-ID? I mean when the node joins a network, it knows that network's PAN-ID. = Let's say it's running on 0xBAAD. From the RS/RA it also knows the prefix, or maybe even DHCP tells the node. Say it's dead:beef:cafe:0::/64 . Hence = if the node is assigned the following address: Dead:Beef:cafe:0:b8ad:00ff:fe00:0005 The node can derive that that address becomes 6LoWPAN compressible if it = has the 802.15.4 short address '5'.=20 > Do IP nodes care whether their MAC address (the short MAC > address > included) is unique? =20 Well they have to be, as specified by IEEE 802.15.4. How you decide they = are unique is part of the discussion. Sure you could run a full 802.15.4 = MAC, followed by a full 6LoWPAN layer, followed by a full IPv6 stack. It = would work and make a nice block diagram for a paper. But you'd be wasting tons of code space and transmission time. >6LoWPAN deal with - is it IP? Is it MAC? Both isn't it? I mean I think the whole point is that you need to = 'break' the nice clean divisions between layers when it comes to constrained devices. After all: "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Regards, -Colin -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: December 17, 2009 6:41 PM To: Colin O'Flynn Cc: 'Alexandru Petrescu'; daniel.gavelle@jennic.com; 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboards Colin O'Flynn a =E9crit : > Hello, >=20 >> Excuse me, sorry, but are the other non-16bit addresses (48bit) >> ever assigned by DHCP? >=20 > There's at least two options I know of for this: >=20 > #1 Add another 6lowpan-nd specific extension to DHCPv6 to add a > simple link-layer address option Hmm... makes some sense, what would it look like? (rfc4944 defines such an option for ND). What would it be used for and how? > #2 Nodes could assign their own short addresses. Nodes power on and=20 > autoconfigure a IPv6 address based on the 64-bit MAC address. You mean the "EUI-64 Identifier"? (it's not an address, it's an identifier). Is there such a thing as a 64bit MAC address? > With this they then do the DHCP dance, and get another address. Sounds as forming an IPv6 link-local address in order to do DHCP dance prior to obtain a global IPv6 address. (yes, in IPv4 one could say that the node uses its MAC address while doing the DHCP initial dance and the unspecified IPv4 address 0.0.0.0, but in IPv6 the unspecified addresses (search " :: " in rfc3315) are not used DHCPv6 in the initial DHCPv6 dance, but the link-local addresses are). Forming an IPv6 link-local address based on the 16bit short MAC address - ok, using on RFC4944. And then do DAD on this IPv6 link-local address, because the EUI-64 identifier based on the 16bit short MAC address is not guaranteed global, has that g bit unset. > Nodes check if this address can be used to assign their own short > address. Yes, usually they do DAD to make sure their IPv6 link-local address is unique within that link. But don't rely on the IP address uniqueness to conclude that the MAC address corresponding to that IP address is unique. > Aka: the IPv6 address it assigns matches the prefix, the PAN-ID, etc. >=20 Sorry can't follow this. Which prefix? Which PAN-ID? > Thus nodes 'figure out' if a certain short address will make their > IPv6 address compressible. Do IP nodes care whether their MAC address (the short MAC address included) is unique? I don't think so. I think IP nodes care only whether their IP address is unique. Also, it is completely unclear to me what kind of layer does 6LoWPAN deal with - is it IP? Is it MAC? Alex >=20 > Regards, >=20 > -Colin >=20 >=20 >=20 > -----Original Message----- From: 6lowpan-bounces@ietf.org > [mailto:6lowpan-bounces@ietf.org] On Behalf Of Alexandru Petrescu=20 > Sent: December 16, 2009 9:14 PM To: daniel.gavelle@jennic.com Cc: > 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboards >=20 > Daniel Gavelle a =E9crit : >> I agree with the recent proposal to remove the mandatory >> requirement for a whiteboard and duplicate address detection. >>=20 >> However, 16 bit 802.15.4 addresses are a very useful optimisation. >> Assigning these in a standard way is important in the absence of a >> whiteboard. One option may be to use DHCPv6. However, the DHCPv6 >> packet sizes are quite large and so some sort of DHCPv6 message=20 >> compression would be useful. Extended LowPANs would also be useful >> in some applications. >>=20 >> If the whiteboard and DAD are removed, I would like the issues of >> 16 bit address assignment and extended LowPANs >=20 > Excuse me, sorry, but are the other non-16bit addresses (48bit) ever > assigned by DHCP? >=20 > I doubt IETF could spec a means to assign MAC addresses... >=20 > Thanks, >=20 > Alex >=20 >=20 > to still be addressed by an RFC >> within the IETF 6LowPAN group, rather than having several different >> non interoperable implementations. >>=20 >>=20 >=20 > _______________________________________________ 6lowpan mailing list=20 > 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >=20 >=20 From alexandru.petrescu@gmail.com Thu Dec 17 14:27:54 2009 Return-Path: X-Original-To: 6lowpan@core3.amsl.com Delivered-To: 6lowpan@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3BB53A6857 for <6lowpan@core3.amsl.com>; Thu, 17 Dec 2009 14:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2zmuA0Btf9j for <6lowpan@core3.amsl.com>; Thu, 17 Dec 2009 14:27:53 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id CB3F63A68EC for <6lowpan@ietf.org>; Thu, 17 Dec 2009 14:27:51 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 32248D48136; Thu, 17 Dec 2009 23:27:31 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id D1282D48037; Thu, 17 Dec 2009 23:27:28 +0100 (CET) Message-ID: <4B2AB04B.2060807@gmail.com> Date: Thu, 17 Dec 2009 23:27:23 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Colin O'Flynn References: <4B0F9D66.2020706@jennic.com> <4B294D7A.1040801@gmail.com> <010601ca7eaa$5df9ea00$19edbe00$@com> <4B2A7B3F.4070609@gmail.com> <001e01ca7f50$db358730$91a09590$@com> In-Reply-To: <001e01ca7f50$db358730$91a09590$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091217-0, 17/12/2009), Outbound message X-Antivirus-Status: Clean Cc: 6lowpan@ietf.org, daniel.gavelle@jennic.com Subject: Re: [6lowpan] Whiteboards X-BeenThere: 6lowpan@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working group discussion for IPv6 over LowPan networks <6lowpan.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 22:27:55 -0000 Colin O'Flynn a écrit : > Hello, > >> What would it be used for and how? > > The initial version of 6lowpan-nd added this idea in. See > http://tools.ietf.org/html/draft-hui-6lowpan-nd-00 > >> You mean the "EUI-64 Identifier"? (it's not an address, >> it's an >> identifier). Is there such a thing as a 64bit MAC > > The 802.15.4 Address (aka: MAC address) is guaranteed to be unique by IEEE > 802.15.4-2006, at least everywhere within the PAN. > > Nodes can use either 64-bit or 16-bit addressing. Ok, and these are their MAC addresses. > When nodes power up they > are preprogrammed with a 64-bit IEEE MAC address they use to communicate. > They then may be assigned a shorter 16-bit address, which they can use to > save some bytes. Ok - for this assignment, I don't think ND nor DHCP is necessary. Let other MAC-based mechanism assign MAC addresses. > However the 64-bit address still remains valid, and the > node can be addresses by it. Well this is wonderful. It's a great help for forming IP addresses and ensure their uniqueness on the link and further. > Nor do you need to do this 16-bit addressing. You can keep just using 64-bit > addressing and skip assigning 16-bit addresses. > > The idea is almost very node in the world could be programmed with a > different 64-bit MAC address. Hence you could bring two nodes together and > be sure there was no address collision. But with 16-bit MAC addressing you > are much more likely to get a collision, hence why the 16-bit addresses are > assigned dynamically by the network. WEll, I agree, but who is the network who assigns these 16-bit addresses? I guess it is a MAC-based mechanism(?) I don't think IP mechanisms are needed to assign 16-bit MAC addresses. I mean I have never seen an IP-based mechanism which assigns MAC addresses to nodes. The closest I could think of is PPPv6, but that is "negotiation" of an Interface ID, and not assignment of an IP address. PPP negotiates an Interface ID, and then each node self-forms an IPv6 address from that IID. The IPv6 address is not delivered to the end node by some server. > The network assures no two nodes are > assigned the same 16-bit address. Do you call "network" some MAC-based and MAC-specific mechanism? I call network an IP network. BEcause a network covers several types of MACs whereas the "network" term used above seems to be a 802.15.4-only weave of threads, if I can say so. > >> Sounds as forming an IPv6 link-local address in order to >> do DHCP dance >> prior to obtain a global IPv6 address. > > Basically yes! The node has to do this anyway, as a node using 6LoWPAN will > bring up minimum of two valid unicast addresses: > > Link-local based on 64-bit 802.15.4 Address > Global based on 64-bit 802.15.4 Address > > If the node can use short addressing, you add two more: > > Link-local based on 16-bit 802.15.4 Address > Global based on 16-bit 802.15.4 Address > >> Sorry can't follow this. Which prefix? Which PAN-ID? > > I mean when the node joins a network, it knows that network's PAN-ID. I suspect we have a terminology issue on the use of the term network... > Let's > say it's running on 0xBAAD. From the RS/RA it also knows the prefix, or > maybe even DHCP tells the node. Ok, only the RA tells the prefix, DHCP doesn't, not currently. > Say it's dead:beef:cafe:0::/64 . Hence if > the node is assigned the following address: > > Dead:Beef:cafe:0:b8ad:00ff:fe00:0005 > > > The node can derive that that address becomes 6LoWPAN compressible if it has > the 802.15.4 short address '5'. Sorry, which address becomes compressible? The IPv6 address? Or the MAC address? I am very reluctant to accept that an IP address is compressible. Compress it and you no longer talk to anyone on the Internet. DO you care connecting this to the Internet? Could I ping a 6lowpan node without relying on converting various addresses? The dumb network? Can I traceroute through a 6lowpan please (increasing packet size, getting ICMP errors, etc.)? Or will I see a 6lowpan subnet as some completely invisible network, no traceroute, not Path MTU discovery, no reuse of routing protocols, all within one single hop... >> Do IP nodes care whether their MAC address (the short MAC address >> included) is unique? > > Well they have to be, as specified by IEEE 802.15.4. Well, up to now, I haven't seen anywhere IP to care or to try to make some MAC address unique... If 802.15.4 wants their MAC addresses unique, then let 802.15.4 define uniqueness mechanisms for MAC addresses. All IP can do is - at most - signal to the user that some MAC address is _probably_ (not even sure) not unique... and refuse to configure an IP address based on it. But IP can't try to form a unique _MAC_ address. > How you decide they are > unique is part of the discussion. I think IP shouldn't ever decide whether some MAC address is unique or not. It could signal this to an operator, some risk of collision. But it shouldn't make strong statements about uniqueness of some MAC addresses. Simply it can't know and that is good. Keep layers separated. > Sure you could run a full 802.15.4 MAC, > followed by a full 6LoWPAN layer, followed by a full IPv6 stack. It would > work and make a nice block diagram for a paper. Hmm... I sense the ironic referral to diagram on paper. But I think more of the interface between ip6_output, dev_xmit and ndev_t struct... it's there it stays there don't change it. > But you'd be wasting tons of code space and transmission time. Hmm... or you could try to cross between layers... danger danger danger... many times danger.... don't do that... it's a slippery slope, people have tried it (cross-layer designs, link-layer indicators for fast handovers, more), it's a rathole, what else can I say... >> 6LoWPAN deal with - is it IP? Is it MAC? > > Both isn't it? I mean I think the whole point is that you need to 'break' > the nice clean divisions between layers when it comes to constrained > devices. After all: > "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" Right. I am not sure DHCP mechanism assigning a MAC address should be part of this. Sorry, my statements may read too strong, and I may need to read more than write... but the compressible IP addresses make not much sense to me, sorry. Yours, Alex > > Regards, > > -Colin > > > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > Sent: December 17, 2009 6:41 PM > To: Colin O'Flynn > Cc: 'Alexandru Petrescu'; daniel.gavelle@jennic.com; 6lowpan@ietf.org > Subject: Re: [6lowpan] Whiteboards > > Colin O'Flynn a écrit : >> Hello, >> >>> Excuse me, sorry, but are the other non-16bit addresses (48bit) >>> ever assigned by DHCP? >> There's at least two options I know of for this: >> >> #1 Add another 6lowpan-nd specific extension to DHCPv6 to add a >> simple link-layer address option > > Hmm... makes some sense, what would it look like? (rfc4944 defines such > an option for ND). > > What would it be used for and how? > >> #2 Nodes could assign their own short addresses. Nodes power on and >> autoconfigure a IPv6 address based on the 64-bit MAC address. > > You mean the "EUI-64 Identifier"? (it's not an address, it's an > identifier). Is there such a thing as a 64bit MAC address? > >> With this they then do the DHCP dance, and get another address. > > Sounds as forming an IPv6 link-local address in order to do DHCP dance > prior to obtain a global IPv6 address. (yes, in IPv4 one could say that > the node uses its MAC address while doing the DHCP initial dance and the > unspecified IPv4 address 0.0.0.0, but in IPv6 the unspecified addresses > (search " :: " in rfc3315) are not used DHCPv6 in the initial DHCPv6 > dance, but the link-local addresses are). > > Forming an IPv6 link-local address based on the 16bit short MAC address > - ok, using on RFC4944. And then do DAD on this IPv6 link-local > address, because the EUI-64 identifier based on the 16bit short MAC > address is not guaranteed global, has that g bit unset. > >> Nodes check if this address can be used to assign their own short >> address. > > Yes, usually they do DAD to make sure their IPv6 link-local address is > unique within that link. > > But don't rely on the IP address uniqueness to conclude that the MAC > address corresponding to that IP address is unique. > >> Aka: the IPv6 address it assigns matches the prefix, the PAN-ID, etc. >> > Sorry can't follow this. Which prefix? Which PAN-ID? > >> Thus nodes 'figure out' if a certain short address will make their >> IPv6 address compressible. > > Do IP nodes care whether their MAC address (the short MAC address > included) is unique? I don't think so. I think IP nodes care only > whether their IP address is unique. > > Also, it is completely unclear to me what kind of layer does 6LoWPAN > deal with - is it IP? Is it MAC? > > Alex > > >> Regards, >> >> -Colin >> >> >> >> -----Original Message----- From: 6lowpan-bounces@ietf.org >> [mailto:6lowpan-bounces@ietf.org] On Behalf Of Alexandru Petrescu >> Sent: December 16, 2009 9:14 PM To: daniel.gavelle@jennic.com Cc: >> 6lowpan@ietf.org Subject: Re: [6lowpan] Whiteboards >> >> Daniel Gavelle a écrit : >>> I agree with the recent proposal to remove the mandatory >>> requirement for a whiteboard and duplicate address detection. >>> >>> However, 16 bit 802.15.4 addresses are a very useful optimisation. >>> Assigning these in a standard way is important in the absence of a >>> whiteboard. One option may be to use DHCPv6. However, the DHCPv6 >>> packet sizes are quite large and so some sort of DHCPv6 message >>> compression would be useful. Extended LowPANs would also be useful >>> in some applications. >>> >>> If the whiteboard and DAD are removed, I would like the issues of >>> 16 bit address assignment and extended LowPANs >> Excuse me, sorry, but are the other non-16bit addresses (48bit) ever >> assigned by DHCP? >> >> I doubt IETF could spec a means to assign MAC addresses... >> >> Thanks, >> >> Alex >> >> >> to still be addressed by an RFC >>> within the IETF 6LowPAN group, rather than having several different >>> non interoperable implementations. >>> >>> >> _______________________________________________ 6lowpan mailing list >> 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan >> >> > > > >