Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
RFC 6775

Note: This ballot was opened for revision 18 and is now closed.

(Jari Arkko) Discuss

Discuss (2012-01-05 for -18)
Thanks for a well written, solid specification for this important task.

I had a few minor things which I wanted to check/discuss before recommending the final approval of this draft. I will ballot Yes when these have been resolved:

1. Has the specification gone through a 6MAN WG review? I think it should, but I cannot recall if this happened.

2. The specification should highlight that in a network envisioned by the specified architecture, link local multicast and link local in general does not necessarily work as expected. This will have implications on zero configuration and other things.

3. This seems odd:

> 6.5.2.  Returning Address Registration Errors
>   Address registration errors are not sent back to the source address
>   of the NS due to a possible risk of L2 address collision.  Instead
>   the NA is sent to the link-local IPv6 address with the IID part
>   derived from the EUI-64 field of the ARO as per [RFC4944].  In
>   particular, this means that the universal/local bit needs to be
>   inverted.  The NA is formatted with a copy of the ARO from the NS,
>   but with the Status field set to indicate the appropriate error.

Packets are sent to L2 addresses, in any case. You need to specify what L2 address you are sending to. And sending to an fe80 address in a situation where a L2 collision is suspected is problematic in any case.

But maybe I'm missing something.

4. The document is imprecise about SEND implications:

>   In some future deployments one might want to use SEcure Neighbor
>   Discovery [RFC3971] [RFC3972].  This is possible with the Address
>   Registration option as sent between hosts and routers, since the
>   address that is being registered is the IPv6 source address of the
>   Neighbor Solicitation and SeND verifies the IPv6 source address of
>   the packet.  Applying SeND to the optional router-to-router
>   communication in this document is out of scope.

The latter is fine, the former is a bit handwavy. What specifically do I have to do in my implementation to support ARO? Nothing? Some new behaviour? Please be explicit.

5. The document should clarify its impacts to ND mechanisms that it does not mention today, such as Optimistic DAD (RFC 4429) or host impacts of router selection (RFC 4191). Are these not usable? Usable as-is? Or something else?
Comment (2012-01-05 for -18)
No email
send info
Sections 5.6 and 5.7 should be more explicit in describing how to send packets to link local destinations (fe80). I believe you have to reverse the procedure in Appendix A of RFC 4291, but it would be good to say that explicitly.

> 5.8.2.  Behavior on Wakeup
>   When a host wakes up from a sleep period it SHOULD maintain its
>   current address registrations that will timeout before the next
>   wakeup. 

"Maintain" seems like the wrong word here. Perhaps use "refresh" or "re-establish" or something along those lines instead. The point is, it is not enough to maintain things on the host side, we need to tell the router too.

> 6.2.  Interface Initialization
>   A router initializes its interface more or less as in [RFC4861].

Say "... interfaces as in [RFC4861]. However, ..."

(Ralph Droms) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2012-01-05 for -18)
No email
send info
I agree with the points that Adrian makes.

(Adrian Farrel) (was Discuss) No Objection

Comment (2012-08-20 for -20)
No email
send info
Thanks for working on my Discuss and Comments.

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-08-27)
No email
send info
Thanks for addressing my discuss points. 

I've left the comments below since I've not had a chance to check 
if they were addressed or not. Feel free to let me know if there's 
anything else to talk about wrt those. (But they're comments so
only if you want to talk about 'em:-)


used to be discuss point #2: 
1.3 - 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. 

I didn't update the comments below for -19

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.

Various places: - What's a non-transitive wireless link?  

Abstract - is a bit awkwardly written, some polish could usefully
be applied.

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.

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

1.4 - I don't know why the following assumption is needed: "A
6LoWPAN is configured to share one or more global IPv6 address
prefixes to enable hosts to move between routers in the 6LoWPAN
without changing their IPv6 addresses." Why is it necessary to say
this?  (The spec would be clearer if that were clear I think.)

1.4 - please don't use the reference as part of the sentence
"[I-D.ietf-6lowpan-hc]" being the one that stood out - surely that
has a name?

1.5 - I can't parse the first sentence.

3.2 - s/required/REQUIRED/g? and is it clear what it means to
"REQUIRE" something of a lowpan? (Rather than a node)

3.3 - "suspects" seems too vague, suggest giving at least one
precise (common) condition, and if necessary saying there may be
others too

3.3. "The registration can fail (an ARO option returned to the host
with a non-zero Status)..." the parenthetic clause isn't clear
there. Suggest splitting the sentence. 

3.4 - What's context dissemination? Maybe needs a forward ref?

3.5 - How does packet loss impact on "successfully registers with"?
(Just wondering.)

4.3 - where is "sequence number arithmetic" defined?

5.3 - What are "theses packets"? Maybe a way to get a few PhDs?
That'd be nice:-)

5.3 - Where is "binary exponential backoff" defined?

5.4.3 - Where is the Default router lifetime defined?

5.5.3 - What does "no more default routers" mean?

5.8.1 - seems wrong to say a host should consider how quickly
topology changes, how'd it know in general? 

6.2 - initialising an interface "more or less" like something is a
vague for a spec.

8.1.2 - "similarly" seems vague

13 - The introductory text here is confusing - what's this section
for really?  Does "deploy" mean "use"? I'd prefer the latter term.

(Brian Haberman) (was Discuss) No Objection

Comment (2012-08-24)
No email
send info
Thanks for addressing these issues.

(Russ Housley) No Objection

Comment (2011-12-31 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  The Gen-ART Review by Richard Barnes on 30-Dec-2011 raised one
  suggestion.  Please consider it:
  > The phrase "transitive link" is unfamiliar to me.  A definition
  > would be helpful.

(Pete Resnick) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2012-01-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Adrian Farrel expressed better than I could my concerns about the complexity of this technology, especially given the target environment.

The phrase "IP-over-foo document" is a bit vague and breezy. Could you at least provide an example of such a document?

(Robert Sparks) No Objection

(Sean Turner) No Objection

Comment (2012-01-05 for -18)
No email
send info
I support Stephen's discusses.