IETF Logo Mail Archive

Re: [6lowpan] 6lowpan 16-bit PAN-ID Field

Richard Kelsey <richard.kelsey@ember.com> Fri, 05 March 2010 14:54 UTC

Return-Path: <richard.kelsey@ember.com>
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 289C23A89FC for <6lowpan@core3.amsl.com>; Fri, 5 Mar 2010 06:54:50 -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 Zzg5gnPbZ5nW for <6lowpan@core3.amsl.com>; Fri, 5 Mar 2010 06:54:49 -0800 (PST)
Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 4E5293A6AD0 for <6lowpan@ietf.org>; Fri, 5 Mar 2010 06:54:49 -0800 (PST)
Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 09:57:29 -0500
Date: Fri, 05 Mar 2010 09:39:04 -0500
Message-Id: <87ocj26dfb.fsf@kelsey-ws.hq.ember.com>
To: Colin O'Flynn <coflynn@newae.com>
In-reply-to: <004d01cabbee$574e4bc0$05eae340$@com> (coflynn@newae.com)
From: Richard Kelsey <richard.kelsey@ember.com>
References: <004d01cabbee$574e4bc0$05eae340$@com>
X-OriginalArrivalTime: 05 Mar 2010 14:57:29.0434 (UTC) FILETIME=[2D37CBA0:01CABC74]
Cc: 6lowpan@ietf.org
Subject: Re: [6lowpan] 6lowpan 16-bit PAN-ID Field
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: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6lowpan>
List-Post: <mailto:6lowpan@ietf.org>
List-Help: <mailto:6lowpan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2010 14:54:50 -0000

> From: "Colin O'Flynn" <coflynn@newae.com>
> Date: Thu, 4 Mar 2010 22:59:22 -0000
> 
> RFC4944 has the quote:
> 
> First, the left-most 32 bits are formed by concatenating 16 zero bits to the
> 16-bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be
> used).  This produces a 32-bit field as follows:
> 
> How does a receiving node know if zero's have been used there to recreate
> the IP addresses? Unless I'm missing something, this seems to be a ambiguous
> case. It seems unlikely a node will know it's short address but not PAN-ID.

I am not sure what to make of this either.  The PAN ID
may change if a PAN ID conflict is detected, in which
case it would be a nuisance if all of the interface IDs
had to change.  To me, the only time where it might make
sense to to use the PAN ID in the interface ID would be
if a lowpan was spread across multiple PANs that did not
coordinate 16-bit address assignment.  Even in that case,
it would be better to use a 'symbolic' PAN ID in the
interface IDs, to avoid the need to change later.

In a lowpan With only a single PAN ID it makes much more
sense to use zeros and avoid problems if the PAN ID has to
change.
                          -Richard Kelsey

v2.23.0 | Report a Bug | By Email