Re: [6lowpan] #142: Stephen Farrel's Discuss comments

Stephen Farrell <> Tue, 29 May 2012 11:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4FA6421F87DE for <>; Tue, 29 May 2012 04:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.399
X-Spam-Status: No, score=-100.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MANGLED_NAIL=2.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TuQ3ogeiCzEg for <>; Tue, 29 May 2012 04:09:31 -0700 (PDT)
Received: from ( [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by (Postfix) with ESMTP id F200721F87D6 for <>; Tue, 29 May 2012 04:09:30 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B4A3171472; Tue, 29 May 2012 12:09:29 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338289768; bh=tKnpA69OcT2JTk SnDZLSptao7nkODR+7sGEwXjG+DTg=; b=0uZLarGizox6TRIqR+ISlR8Vnlt75W zytwTnQz8Rjm9kxEzWZjsBFsZk/lpLY+YlD7akAFVeKYDC4lACDH5o24coR8Z9AM geQu5FfKx2AHrEq3aztj6jttDlSarZwJgSyqN5QZAX8iz1fvnstyXZz6U4aufoKa ZUIIAmCt/zbRkYwyd5bQSFwo0K7rIBlOBWYtNOwUXc3IQpEDlRivpS9HeWYVV2B9 Uii5PIvzDSoNZUHoZ8zFL3AUwC9Svk/eMM42HC2CMnMIY85XmkWRez1S6UeC2wSD c8m+aXxDGKeT/OuR37XG5UPXaBXSY6v77QDPePV8akS+77KuwctvVLIg==
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10027) with ESMTP id Pc9xZDqLEmUg; Tue, 29 May 2012 12:09:28 +0100 (IST)
Received: from [IPv6:2001:770:10:203:746a:67db:b7ac:1c60] (unknown [IPv6:2001:770:10:203:746a:67db:b7ac:1c60]) by (Postfix) with ESMTPSA id 95E2C171479; Tue, 29 May 2012 12:09:25 +0100 (IST)
Message-ID: <>
Date: Tue, 29 May 2012 12:09:25 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Wed, 30 May 2012 08:06:55 -0700
Cc: 6lowpan issue tracker <>,
Subject: Re: [6lowpan] #142: Stephen Farrel's Discuss comments
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 May 2012 11:09:32 -0000


Those changes look good or at least good enough
to shoot out a new rev and I can clear down all
or almost all of my discuss points.


On 05/29/2012 03:16 AM, 6lowpan issue tracker wrote:
> #142: Stephen Farrel's Discuss comments
>  ----------------------------------------------------------------------
>  ----------------------------------------------------------------------
>  #1 1.4 - "it is assumed that 6LRs register with all the 6LBRs." is
>  ambiguous - does it mean each 6LR registers with some 6LBR or s/each/all/
>  or s/some/all/ or both? Assuming that all 6LRs are registered with all
>  6LBRs would seem to be too difficult and unwise so I think this needs
>  fixing.
>  RESPONSE==> ‘each 6LR to register with all the configured 6LBR in the
>  6LowPAN’. This is the intended meaning. We will also flag this with
>  6lowpan wg.
>  #2 1.4 - Why would probabilistic uniqueness of non-EUI-64-derived
>  addresses not be sufficient in some networks? If it is, then the "must be
>  either assigned or checked" seems wrong.
>  RESPONSE===> We are consistent with RFC 4862 section 5.4. It is
>  recommended that non-EUI-64 addresses should be checked for uniqueness if
>  they are not assigned by a reliable entity.
>  #3 3.2 - Does this mean that if I can pretend to be a router I can force
>  (some) nodes to change their addresses? If so, why is that not mentioned
>  as an attack in the security considerations?  (If IP-address based node
>  reputation ever evolved for nodes like these then this would be serious
>  attack - misbehave as addr1, pretend to be a DHCP server and then force
>  addr1 on some other innocent node.)
>  RESPONSE====> Same security consideration as RFC 4862 applies. We will
>  update the first line of security consideration section to refer to RFC
>  4862 to address this comment. Thus it will say:
>  "The security considerations of IPv6 Neighbor Discovery [RFC4861] and
>  [RFC4862] apply"
>  #4 3.3 - How long is a sleeping node expected to say awake when sending a
>  registration message? Is that long enough to get an error saying its
>  chosen address is in use already? If not, then what prevents that node
>  constantly re-awakening and using the duplicate address (or many identical
>  such nodes doing that all the time)?
>  (Saying "A host retransmits...until..." later in that section isn't clear
>  enough really - there's no 2119 language there at all so I don't know if
>  that's a MUST or MAY.)
>  RESPONSE===> We will make a change in the document to make the optional
>  behaviors as default (MUST) in order to address Adrian Farrell's comment.
>  The draft provides some default recommendations in section 9 and details
>  behavior are described in section 5.5.  Section 3.3 is an overview section
>  - here we only wanted to give a high-level overview of the protocol.
>  #5 8.1.4 - Is the last sentence here really optional, (everything in
>  section 8 should be optional, right?) or is that behaviour meant to apply
>  to all cases? If the latter, it really ought be in 4.2 shouldn't it? Also
>  there are two 6CO's mentioned there, but its not clear to me at what point
>  the 2nd is sent (T+5 presumably?)
>  RESPONSE===> As per Adrian Farell's comments we are revisitng the optional
>  behavior sections to make them mandatory by default to reduce confusion
>  and interoperability issues in the deployment. If 6CO is used, it should
>  be in the same prefix advertisemnt. ND-19 should address this comment.
>  #6 What does "expects" mean in the security considerations?
>  (Section 11, 2nd para.) That's not 2119 language. Are you saying this
>  protocol MUST NOT be used if layer 2 security isn't sufficiently strong or
>  is missing? If not, then what?
>  Suggested new text for the 2nd paragraph in security section:
>  This specification assumes that the link layer is sufficiently
>  protected, for instance using MAC sublayer cryptography.  Thus, its
>  threat model is no different from that of IPv6 Neighbor Discovery [RFC
>  4861]. The trust model #1, in section 3 of SEND [RFC3756] applies here.
>  However, any future 6LoWPAN security protocol that applies to Neighbor
>  Discovery for 6LoWPAN protocol, is out of scope of this document.
>  #7 How can "Using link-layer indication for NUD" be a SHOULD deploy but
>  only a MAY implement? (Table 2, in section 13.)
>  RESPONSE====>
>  Indeed, there is no reference of 'link-layer indication' in the body of
>  the document, but we listed in the table for a suggestion to the
>  implementors. We can either take that text out completely from the table
>  or update the table as :
>  | 5.1       | Re-direct Message Acceptance    | MUST NOT | MUST NOT  |
>  |            |                                 |          |           |
>  |           |Joining Solicited Node           | N/A      | N/A       | |
>  Other     | Multicast                       |          |           |
>  |Recommend- | Joining all-node Multicast      | MUST     | MUST      |
>  | ations    | Using link-layer indication for | MAY      | MAY       |
>  |           | NUD                             |          |           |
>  ----------------------------------------------------------------------
>  ----------------------------------------------------------------------
>  General - The logic as to why mesh-under and route-over are the most
>  important topologies is not explained here and I don't see why its most
>  valuable to tackle this problem in a topology-specific manner.  It's also
>  a shame that 1.3 needs to have all nodes implementing this to get any
>  benefit and that each node must be part of only one network. (The latter
>  is particularly unfortunate given that sleeping node wake times might
>  cause such a condition over time.) However, this is maybe not actually a
>  problem since the protocol doesn't seem to be really specific to those
>  topologies - is that right? If so, then I'd suggest weakening the language
>  to say that e.g. the authors or WG are more interested in those
>  topologies, but that the protocol might work in other contexts too.
>  RESPONSE====> 6lowpan working group mainly targets IEEE802.15.4 or similar
>  lowpower networks and topologies. The mesh and route-over topologies came
>  from that concept.
>  We agree, that in the introduction section, we can change the text to say
>  that the protocol might work in other contexts. In fact BTLE and BACNET
>  are two other networks which are considering this protocol.
>  The homogeneous nature of nodes are needed in this solution as this
>  document does not address operations with existing nodes. A generic
>  solution in ipv6 network is being addressed and developed in:
>  nd/
>  Various places: - What's a non-transitive wireless link?
>  RESPONSE=====>  non-transitive link is defined in RFC 4861
>  Non-transitive reachability means packets from A reach B, and
>                      packets from B reach C, but packets from A don't
>                      reach C.)  Many radio links exhibit these.
>  Abstract - is a bit awkwardly written, some polish could usefully be
>  applied.
>  RESPONSE====> Will be fixed. Others also commented the same.
>  1.1 - I don't get the relevance of the "primarily two types" of lowpan
>  topology on p5. Only the last sentence of that paragraph seems relevant or
>  necessary. Similarly with section 1.2 which, other than introducing
>  terminology seems unnecessary.
>  RESPONSE===> 6lowpan wg is interested in these two types of topologies as
>  these two are defined in IEEE 802.15.4.
>  1.3 - A number of the goals say "optimize" - is that meant to mean
>  "improve" or "make the best"? In the latter, case, that would seem to
>  require more work, e.g. to be able to compare approaches via metrics or
>  something. Since I don't think that's really needed, I'd say
>  s/optimize/improve/g would be more correct. (Similarly for
>  s/minimize/reduce/)
>  RESPONSE===> We will try to make this change in the document when
>  applicable. The goal of optimization is improvement.