Re: [6lowpan] Fwd: New Version Notification fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00

Samita Chakrabarti <samitac2@gmail.com> Thu, 25 March 2010 01:10 UTC

Return-Path: <samitac2@gmail.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 EDB223A6A42 for <6lowpan@core3.amsl.com>; Wed, 24 Mar 2010 18:10:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.469
X-Spam-Level:
X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 iYrHSwvhGH4o for <6lowpan@core3.amsl.com>; Wed, 24 Mar 2010 18:10:06 -0700 (PDT)
Received: from mail-qy0-f196.google.com (mail-qy0-f196.google.com [209.85.221.196]) by core3.amsl.com (Postfix) with ESMTP id 3E4B73A6A0C for <6lowpan@ietf.org>; Wed, 24 Mar 2010 18:10:05 -0700 (PDT)
Received: by qyk34 with SMTP id 34so2289882qyk.22 for <6lowpan@ietf.org>; Wed, 24 Mar 2010 18:10:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=01QHs3F8s5HmqGUcrzXiRJeVGFmqWl3xulSt3xG1/bM=; b=qs4sABHQxvD0GSBwk0z5vfsaVXybiG0yKTMXrSdl6FhEiSRiY9d51AfHykJ1KVaAJ+ kzL1IMyvdpwYQQH9t25Z+QOLR4gLgQLxjUC0gzlEUmba9jWIi9N7I3NFQd6v3n2fn/Xy gq3YlaX1obkqi1TyDJ6Vp77A29QlhSXNNUf3E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vXPHX2dgE3Pu17hJ+ebsvI4Mmy4uXa0eB8fFUQyjNLaHJuGWPzq7nOylMNHGnd0bvY KXRPzbGX7PhgCehkUcMSuIXtFfCzv6QEKvyGoeoOvnzAMQRlQ5ClQgbOnI/ryatij6dh PKh8fj54TfnqtYO0BbpM+vtEIda4T2xwxndrs=
MIME-Version: 1.0
Received: by 10.229.239.148 with SMTP id kw20mr222759qcb.10.1269479424343; Wed, 24 Mar 2010 18:10:24 -0700 (PDT)
In-Reply-To: <8A977BDC5A7B0E429B0F521E8D6F91EE01A589F8@XMB-AMS-103.cisco.com>
References: <4B8BBE45.4080402@sun.com> <8A977BDC5A7B0E429B0F521E8D6F91EE01A589F8@XMB-AMS-103.cisco.com>
Date: Wed, 24 Mar 2010 18:10:24 -0700
Message-ID: <43b91d371003241810q784c5cfwd8663d136f3c1441@mail.gmail.com>
From: Samita Chakrabarti <samitac2@gmail.com>
To: "Mathilde Durvy (mdurvy)" <mdurvy@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: 6lowpan <6lowpan@ietf.org>
Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00
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: Thu, 25 Mar 2010 01:10:08 -0000

Hi Mathilde,

Thanks for your comments.  Here are some more  responses in addition
to Erik's and Pascal's.
Please see in-line.

On Mon, Mar 22, 2010 at 10:45 AM, Mathilde Durvy (mdurvy)
<mdurvy@cisco.com> wrote:
> Hi Erik, Samita,
>
> Thanks for your draft. This proposal is much closer to what I had in mind
> myself and I feel this is a great step forward!
>

Great to hear that from you!

> I have a few questions / comments:
> - Assumptions: why do you assume that 6LR use RA to configure their global
> addresses while host are allowed to use DHCPv6? In IPv6, routers are
> typically ignoring received RAs... It is not very clear whether your
> proposal allows the case where all addresses (host and 6LR) are assigned
> using DHCPv6. It might also be that in a route-over situation the routing
> protocol itself would take care of distributing well chosen
> prefixes/addresses to allow prefix aggregation in routing tables or routing
> messages.

6LRs are assumed to be dual personalities. In most cases they are
acting as a routers. But indeed they are special as they form global
addresses from prefixes through autoconfiguration and they can also
send RS to their neighbors as they come up.

As for DHCPv6-pd, nd-simple does not do DHCP prefix delegation. It
simply relays the prefixes to neighbors since the 6lowpan contains
same prefix throughut. Multiple prefixes are possible - but they are
same throughout the 6lowpan.

This draft however does not discuss DHCPv6 address assignment and it
is left to a separate draft. nd-simple only discusses address
autoconfiguration.

If DHCPv6 relay/server is used then all addresses could be assigned by
the DHCP server when the DHCP-server would know that it has to use the
same prefix for all addresses over a 6lowpan.  It is not written in
the draft and we think the DHCP-related draft would cover that.

>> - Section 7.3: I feel like you are underestimating the role that the routing
> protocol might play. If you take the example of what RPL is defining, an
> IPv6 host could very well be a RPL leaf node, in which case it might
> discover its default router by listening to DIO messages, and send DAO to
> 'register'. In addition, if the 6LR are RPL routers that use DHCPv6 or
> another scheme for address allocation, RS/RA might be completely disabled.
> What do you think?

The same logic applies to regular IPv6 network. IPv6 ND cannot and
should not depend on a particular routing protocol behavior that is
running on the nodes.

Note that the concept of 6LoWPAN link(route-over) is a bit different
than regular IPv6-link.  Not all 6lowPAN networks will run RPL or
routing protocols and yet they need to communicate without static
configuration.

> - Section 7.3: Reading your description, is it correct to say that hosts
> perform NUD and address resolution for their default router? (of course the
> number of messages is reduced by the heavy use of the SLLA option). Do you
> also use NS/NA to perform NUD and address resolution between 6LR?
> - Section 7.3: ND uses already upper-layer protocol feedback. Would you
> consider to extend it to include lower layer feedback?
>
> To summarize my comments, I would like to understand a bit better how you
> envision the operation of nd-simple when a routing protocol such as RPL is
> used on top of it.
>

I'd think RPL will do p2mp, mp2p or p2p routing within a 6LoWPAN .
6LRs may act as hosts as well, as they have aquired their global
prefixes. 6LRs will also know how to forward packets to 6LBRs when the
destination addresses are not resolved by RPL'ed routes.

Thanks,
-Samita

> -----Original Message-----
> From: 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] On Behalf
> Of Erik Nordmark
> Sent: lundi, 1. mars 2010 05:17
> To: 6lowpan
> Subject: [6lowpan] Fwd: New Version Notification
> fordraft-chakrabarti-6lowpan-ipv6-nd-simple-00
>
>
> Samita and I have tried to capture a minimal set of ND optimizations in this
> draft.
>
>    Erik
>
>
> -------- Original Message --------
>
> A new version of I-D, draft-chakrabarti-6lowpan-ipv6-nd-simple-00.txt
> has been successfuly submitted by Erik Nordmark and posted to the IETF
> repository.
>
> Filename:        draft-chakrabarti-6lowpan-ipv6-nd-simple
> Revision:        00
> Title:           IPv6 LoWPAN Neighbor Discovery and Addressing Choices
> Creation_date:   2010-03-01
> WG ID:           Independent Submission
> Number_of_pages: 16
>
> Abstract:
> IETF 6LoWPAN working group defines IPv6 over low-power personal area network
> (IEEE 802.15.4).  IEEE 802.15.4 and other low-power wireless networks have
> limited or no usage of broadcast or multicast signaling due to energy
> conservation.  Besides the wireless nodes may not strictly follow
> traditional concept of IP subnet and IP-links while connecting nodes and
> routers.  This document describes simple optimizations to IPv6 Neighbor
> Discovery protocol(RFC4861), and addressing mechanisms that are useful for
> small scale 6LoWPAN networks in star and mesh topologies.
>
> The optimizations include reducing the amount of Neighbor Discovery
> multicast traffic and allowing for a single subnet to span multiple routers
> in a "route-over" topology.
>
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
>
> _______________________________________________
> 6lowpan mailing list
> 6lowpan@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowpan
>
>