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

["6lowpan issue tracker" <[e-mail]>]

#142: Stephen Farrel's Discuss comments

 ----------------------------------------------------------------------
 DISCUSS:
 ----------------------------------------------------------------------


 #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?

 RESPONSE===>
 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                             |          |           |



 ----------------------------------------------------------------------
 COMMENT:
 ----------------------------------------------------------------------



 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:
 http://datatracker.ietf.org/doc/draft-chakrabarti-nordmark-energy-aware-
 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.

-- 
----------------------------------+-------------------------------------
 Reporter:  samita.chakrabarti@…  |      Owner:  draft-ietf-6lowpan-nd@…
     Type:  defect                |     Status:  new
 Priority:  major                 |  Milestone:  nd-discusses
Component:  nd                    |    Version:
 Severity:  -                     |   Keywords:  nd-18
----------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/6lowpan/trac/ticket/142>
6lowpan <http://tools.ietf.org/6lowpan/>