 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Hi Anthony, Thanks for the quick feedback! See below: On Jul 28, 2008, at 4:39 AM, Anthony Schoofs wrote:
Thanks! It was an initial draft written last minute, so it is missing details as you point out below. I just wanted to get the basic idea out there.Hi Jonathan,I just had a quick look at your draft about Neighbor Discovery and Autoconfiguration for Route-Over 6LoWPAN Networks. It seems very good!
- A general question: as you recall it, either the IEEE EUI-64 or short address combined with the PAN ID may be used to generate an IID, as specified in [RFC4944]. Later you mention that appropriate link-layer address can be regenerated from the IID. When a node from network A receives a packet from network B, how does it know whether the source node has used the short adress or the EUI-64 address to form the IID? I understand that youFrom 6lowpan-bounces at ietf.org Mon Jul 28 04:54:08 2008
Return-Path: <6lowpan-bounces at ietf.org> X-Original-To: 6lowpan-archive at megatron.ietf.org Delivered-To: ietfarch-6lowpan-archive at core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BC73A68C8; Mon, 28 Jul 2008 04:54:08 -0700 (PDT) X-Original-To: 6lowpan at core3.amsl.com Delivered-To: 6lowpan at core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EC1C3A68C8; Mon, 28 Jul 2008 04:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42]
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 AxuSjf5cNvkX; Mon, 28 Jul 2008 04:54:00 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.121.16.71]) by core3.amsl.com (Postfix) with ESMTP id 97B5D3A6880; Mon, 28 Jul 2008 04:54:00 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 510E4AF869; Mon, 28 Jul 2008 04:54:10 -0700 (PDT)X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1])
by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQJZAo9s0zJs; Mon, 28 Jul 2008 04:54:09 -0700 (PDT) Received: from jhui-mac.meeting.ietf.org (unknown [130.129.19.110]) by mail.sf.archrock.com (Postfix) with ESMTP id 4A8B7AF85B; Mon, 28 Jul 2008 04:54:08 -0700 (PDT) Message-Id: <324B87FD-D47C-469D-9FF6-49CB7BF8D9E4 at archrock.com> From: Jonathan Hui <jhui at archrock.com> To: Anthony Schoofs <anthony.schoofs at philips.com> In-Reply-To: <OFD30A812D.CFD4EBFF-ONC1257494.003ECC56-C1257494.003FD0AC at philips.com> Mime-Version: 1.0 (Apple Message framework v926) Date: Mon, 28 Jul 2008 04:54:05 -0700 References: <OFD30A812D.CFD4EBFF-ONC1257494.003ECC56-C1257494.003FD0AC at philips.com> X-Mailer: Apple Mail (2.926) Cc: 6lowpan-bounces at ietf.org, 6lowpan <6lowpan at ietf.org> Subject: Re: [6lowpan] Fwd: New Version Notification for draft-hui-6lowpan-nd-00 X-BeenThere: 6lowpan at 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 at ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/pipermail/6lowpan> List-Post: <mailto:6lowpan at ietf.org> List-Help: <mailto:6lowpan-request at ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lowpan>, <mailto:6lowpan-request at ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============0172415747==" Sender: 6lowpan-bounces at ietf.org Errors-To: 6lowpan-bounces at ietf.org
Hi Anthony, Thanks for the quick feedback! See below: On Jul 28, 2008, at 4:39 AM, Anthony Schoofs wrote: Thanks! It was an initial draft written last minute, so it is missing details as you point out below. I just wanted to get the basic idea out there. The text isn't very clear about this. The assumption is that the u/l-bit in the IID will tell you if it's global or local scope. The former implies an IEEE EUI-64, while the latter implies a short address. The exact implementation of ND will depend on whether or not the link protocol provides a multicast mechanism. If not, sleeping nodes can periodically wake up and send unicast Router Solicitations to routers and router will respond with unicast Router Advertisements. There was a brief statement in the Router Advertisement specification saying that the destination address can be the source address of a received Router Solicitation. This functionality is supported by IPv6 ND, so I'm not inventing anything new here. Mobility is not intended to be out of scope. The Trickle algorithm just says that the transmission period increases over time but that there are one or more triggers that may reset the period back to sock to something small. The exact triggers that reset the transmission period are not constrained by those mentioned in the document. I should make that more clear.
I think I see your point, but I'd also like to hear what you had in mind. For context-based header compression to work, neighboring nodes have to agree on the prefix information for each context. That's why I tried to make sure nodes were consistent rather than not. If you're talking about address autoconfiguration, that's a different story. Just because the 'A' bit is set doesn't mean that a node must configure an IPv6 address using that prefix information. The 'A' bit only indicates that it can, at least that's my interpretation of it. Again. Thanks for the quick feedback. -- Jonathan Hui
|
_______________________________________________ 6lowpan mailing list 6lowpan at ietf.org https://www.ietf.org/mailman/listinfo/6lowpan