Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
draft-ietf-6lowpan-nd-21

[Ballot comment]

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:-)

Stephen.

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
s/minimize/reduce/)

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.

[Ballot discuss]
I have been asked by the shepherding AD to adopt/proxy the DISCUSS issues raised by Jari during his review of previous versions of this document.  While many of his original points were addressed to my satisfaction, I did find two that don't appear to have a resolution.  If there was active discussion on these points, please point me to them for my edification.  To summarize, the following are the points raised in Jari's DISCUSS and my view of them (identified by [BH]):

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

[BH] - This is resolved as the draft has been presented in several face-to-face meetings of the 6MAN WG.

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.

[BH] - Resolved.

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.

[BH] - I do not see any changes in this text in the latest version.  The question that arises is what L2 address is used as the destination when sending this error message (as Jari asked)?  Should there be a test to verify that the EUI-64 contained in the NA does not match the source L2 address of the offending NS?

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.

[BH] - Resolved.  Given that this is discussion in the Security Considerations section, I do not see a need for an in-depth discussion of how to make SeND work in this environment.

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?

[BH] - This still seems to be an open issue.  Was there discussion of how this document impacts these other ND-related RFCs?

[Ballot discuss]
I have updated my Discuss for revision -20. Thanks for the work
so far.

---

> I have added a placeholder to this Discuss to ensure that
> Pascal Thubert's last call comments are resolved (one way
> or the other).

I did not see any further email exchanges attempting resolution
of Pascal's comments. Perhaps they were conducted in private?

---

It appears that my Discuss point below has been resolved simply by deleting the paragraph that described configuration. How does this address the point? It seems simply to hide it?

> Section 3.4 seems to contain a lot of options and sub-options
> with the over-arching assumption that "all 6LRs in a network
> are configured to perform these functions homogeneously." This
> seems like a lot of configuration complexity for very simple
> nodes in an environment where users will not be sophisticated.
> Moreover, it seems highly likely to me that misconfigurations
> will arise and homogeneity will be lost.
>
> The latter suggests that the assumption of homogeneity cannot
> be trusted. You will need to handle (at least at the level of
> fault detection) mixed mode configuration.
>
> The former suggests that you should have some form of automatic
> arbitration (i.e., something more sophisticated than fault
> detection) so that the network can become homogeneous across
> the sub-options.

We had some email exchanges on this point, but didn't reach a
conclusion. I am unable to tell from the new revision whether any
attempt has been made to address this point. To reitterate, the
text says

  It is however assumed that all
  6LRs in a network are configured to perform these functions
  homogeneously.

My point is that this assumption is too great to assure operational
stability. You must either describe how this assumption can be
reinforced (that would require a significant piece of protocol work
that I am not asking you to undertake unless the WG thinks it is
worth it) or you must describe how a misconfiguration is detected,
what reporting is done, and what the consequences are. If you
discover that the consequences of misconfiguration are
destabilisation of the whole network (rather than failure of the
misconfigured node) then you may need to think again because in this
type of network (IMHO) misconfiguration may be frequent and the users
will lack the sophistication to remedy it.

[Ballot discuss]
Updated discuss points for -19. Some are cleared, I'm not sure
of the state for the others and don't immediately see email on
those, (it might be oddly labelled though) so if the authors
could say how they think -19 addresses these points (or why I'm
wrong which is fine if I am) then we can progress these.

#1  - cleared

#2 - cleared, made into a comment

#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.)

#4 cleared

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

#6 cleared

#7 cleared

[Ballot comment]
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
s/minimize/reduce/)

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.

[Ballot discuss]
Updated discuss points for -19. Some are cleared, I'm not sure
of the state for the others and don't immediately see email on
those, (it might be oddly labelled though) so if the authors
could say how they think -19 addresses these points (or why I'm
wrong which is fine if I am) then we can progress these.

#1  - cleared

#2 - cleared, made into a comment

#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.)

#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.)

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

#6 cleared

#7 cleared

[Ballot comment]

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
s/minimize/reduce/)

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.

[Ballot discuss]
Updated discuss points for -19. Some are cleared, I'm not sure
of the state for the others and don't immediately see email on
those, (it might be oddly labelled though) so if the authors
could say how they think -19 addresses these points (or why I'm
wrong which is fine if I am) then we can progress these.

#1  - cleared

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

#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.)

#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.)

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

#6 cleared

#7 cleared

[Ballot comment]

I didn't update the comments 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
s/minimize/reduce/)

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.

[Ballot discuss]

Updated discuss points for -19

#1  - cleared

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

#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.)

#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.)

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

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

#7 How can "Using link-layer indication for NUD" be a SHOULD deploy
but only a MAY implement? (Table 2, in section 13.)

[Ballot 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.

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
s/minimize/reduce/)

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.

[Ballot discuss]
#1 1.4 - cleared

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

#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.)

#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.)

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

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

#7 How can "Using link-layer indication for NUD" be a SHOULD deploy
but only a MAY implement? (Table 2, in section 13.)

[Ballot 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.

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
s/minimize/reduce/)

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.

[Ballot discuss]
I have updated my Discuss for revision -19. Thanks for the work
so far.

---

> I have added a placeholder to this Discuss to ensure that
> Pascal Thubert's last call comments are resolved (one way
> or the other).

I did not see any further email exchanges attempting resolution
of Pascal's comments. Perhaps they were conducted in private?

---

> This is a really small Discuss and easily fixed. The way
> that [I-D.ietf-6lowpan-hc] is used in Sections 1.4 and 3
> make it a normative reference.

I see that you have updated the reference to be [RFC6282]. But
you have left the reference as Informative.

---

> Section 3.4 seems to contain a lot of options and sub-options
> with the over-arching assumption that "all 6LRs in a network
> are configured to perform these functions homogeneously." This
> seems like a lot of configuration complexity for very simple
> nodes in an environment where users will not be sophisticated.
> Moreover, it seems highly likely to me that misconfigurations
> will arise and homogeneity will be lost.
>
> The latter suggests that the assumption of homogeneity cannot
> be trusted. You will need to handle (at least at the level of
> fault detection) mixed mode configuration.
>
> The former suggests that you should have some form of automatic
> arbitration (i.e., something more sophisticated than fault
> detection) so that the network can become homogeneous across
> the sub-options.

We had some email exchanges on this point, but didn't reach a
conclusion. I am unable to tell from the new revision whether any
attempt has been made to address this point. To reitterate, the
text says

  It is however assumed that all
  6LRs in a network are configured to perform these functions
  homogeneously.

My point is that this assumption is too great to assure operational
stability. You must either describe how this assumption can be
reinforced (that would require a significant piece of protocol work
that I am not asking you to undertake unless the WG thinks it is
worth it) or you must describe how a misconfiguration is detected,
what reporting is done, and what the consequences are. If you
discover that the consequences of misconfiguration are
destabilisation of the whole network (rather than failure of the
misconfigured node) then you may need to think again because in this
type of network (IMHO) misconfiguration may be frequent and the users
will lack the sophistication to remedy it.

[Ballot comment]
Thanks for working on my Comments.

I note that you have introduced a citation into the Abstract. This
will need to be removed at some stage.

[Ballot comment]
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, ..."

[Ballot discuss]
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?

[Ballot comment]
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?

IANA has questions about draft-ietf-6lowpan-nd-18.txt.

QUESTIONS: What are the registration procedures, range of possible values, and reserved values (if any) for the new Address Registration Option Status Values registry?

ACTION 1:

Upon approval of this document, IANA will register the following IPv6 Neighbor Discovery Option Formats at
http://www.iana.org/assignments/icmpv6-parameters

TBD  Address Registration Option  [RFC-to-be]
TBD  6LoWPAN Context Option  [RFC-to-be]
TBD  Authoritative Border Router Option  [RFC-to-be]

This document requests values 31-33, but values 31 and 32 have already been assigned.


ACTION 2:

Upon approval of this document, IANA will register the following ICMPv6 type Numbers at
http://www.iana.org/assignments/icmpv6-parameters

TBD  Duplicate Address Request  [RFC-to-be]
TBD  Duplicate Address Confirmation  [RFC-to-be]

This document requests values 155 and 156, but value 155 has already been assigned.


ACTION 3:

IANA needs answers to the questions above to create the Address Registration Option Status Values registry at
http://www.iana.org/assignments/icmpv6-parameters

[Ballot discuss]
I have added a placeholder to this Discuss to ensure that Pascal Thubert's last call comments are resolved (one way or the other).

---

This is a really small Discuss and easily fixed. The way that
[I-D.ietf-6lowpan-hc] is used in Sections 1.4 and 3 make it a
normative reference.

---

Section 3.4 seems to contain a lot of options and sub-options with the
over-arching assumption that "all 6LRs in a network are configured to
perform these functions homogeneously." This seems like a lot of
configuration complexity for very simple nodes in an environment where
users will not be sophisticated. Moreover, it seems highly likely to me
that misconfigurations will arise and homogeneity will be lost.

The latter suggests that the assumption of homogeneity cannot be
trusted. You will need to handle (at least at the level of fault
detection) mixed mode configuration.

The former suggests that you should have some form of automatic
arbitration (i.e., something more sophisticated than fault detection) so
that the network can become homogeneous across the sub-options.

---

Table 1 in Section 4.1 demands an IANA action. In Section 12 there is a
brief statement:

  This document also requests IANA to create a new registry for the
  Status values of the Address Registration Option.

This text needs to be beefed up to show:
- which is the owning registry
- what the name of the sub-registry should be
- either a pointer to section 4.1 or (preferably) all of the relevant
  information

---

Section 6.1

  A router SHOULD NOT send Redirect messages in a route-over topology,
  but MAY send Redirect messages in a mesh-under topology.

The use of 2119 language here may be correct, but leaves some holes.

In route-over, under what conditions MAY a router send Redirect
messages?

In mesh-under, what is the normal behavior? Presumably "SHOULD NOT". But
why MAY a Redirect be sent in mesh-under?

---

Section 12

Please remove the following text from the I-D before advancing it to the
RFC Editor

  For the purpose of protocol interoperability testing of this
  specification, the following values are being used temporarily:

  o  TBD1 = 31

  o  TBD2 = 32

  o  TBD3 = 33

  o  TBD4 = 155 XXX

  o  TBD3 = 156 XXX

(There is, in any case, a typo s/TBD3/TBD5/ on the last line)

---

Section 8.2.1

  A node MUST silently discard any received Duplicate Address Request
  and Confirmation messages that do not satisfy all of the following
  validity checks:

I suspect you mean "...message that does not satisfy any of the
following..." Since you have written that only the messages that fail
every one of the checks must be discarded.

[Ballot 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.

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
s/minimize/reduce/)

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.

[Ballot 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.

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

#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.)

#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.)

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

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

#7 How can "Using link-layer indication for NUD" be a SHOULD deploy
but only a MAY implement? (Table 2, in section 13.)

[Ballot comment]
A strict reading of one sentence in the Abstract may be misleading...

  The traditional IPv6 link concept and heavy use of multicast
  make the protocol inefficient and sometimes impractical in a low
  power and lossy network.

This reads as though it is IPv6 that is inefficient/impractical. Maybe

NEW
  The traditional IPv6 link concept and heavy use of multicast
  make the Neighbor Discovery protocol inefficient and sometimes
  impractical in a low power and lossy network.
END

---

"LoWPAN" is not yet in the RFC Editor's registry of "well-known"
acronyms indicated by an asterix at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
(Actually, it is not on that page at all!)

You may want to encourage your AD to lobby for it to be added. In the
meantime, please expand it on first use (by adding it in the first
sentence of the Abstract, and by expanding it in the second sentence of
the Introduction).

A reference to a wider and more detailed definition of a 6LoWPAN might
also be helpful.

---

The language in section 1.2 describing the differences between mesh-
under and route-over introduces some ambiguity by slightly careless
use of language. The problem arises from trying to distinguish between
routing (at the IP layer) and link-layer routing. Similarly by saying
that in mesh-under all "hosts" are on the same link, yet that forwarding
is handled by a link-layer mesh routing protocol.

I don't think there is anything here that is unusual to people familiar
with layered networking. You might make the text crystal clear by
explaining the existence of layers and then refering always to "links in
the IP layer" and "routing in the Ethernet layer".

While a lot of my gripe is my own sensitivity to mesh-under being
proposed for environments where IP routing is more appropriate, I do
think you may add value to the document by some clarification in this
section.

Similarly, a little more tightness in Section 2 might help. For example,
a 6LR is defined as a router in a 6LoWPAN that can communicate with
another router in the 6LoWPAN. This doesn't really say very much. What
is routed? What is the ocnnectivity between the 6LRs?

(By the way, I am not sure that the term "host" adds any clarity. For
example...

  In both types of configurations, hosts do not take part in routing
  and forwarding packets and they act as simple IPv6 hosts.

...where you say that a host acts as a host!)

---

Section 1.3 uses RFC 2119 language before the boilerplate is introduced
in Section 2.

---

Two of the bullets in Section 1.4 appear to have a minor contradiction.
Viz.

  o  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.

  o  Since the 6LoWPAN shares one single prefix throughout the network,
      mobility of nodes within the LoWPAN is transparent.  Inter-LoWPAN
      mobility is out-of-scope of this document.

"one or more...prefixes" vs. "one single prefix"

---

The bit numbering on the figure in Section 4.4. is misaligned.

---

Should the timers and thresholds in Section 5.3 be configurable?


Which of the constants in Section 9 needs to be configurable?

Should Section 5.3 have a forward-pointer to Section 9?

---

Section 6.2 is woolly for a specification.

"More or less" ?
"might want to" ?

---

Several times (e.g. 6.5.5, and particularly Section 8) you say
"optionally". You might want to consider using RFC 2119 language.

---

Section 11 talks of rejecting DAC and DAR messages in some potential
security violations. Do you mean "reject" or "discard"?

---

I think Section 13 is a fine idea. However, the only text in the
Section says...

  This section discusses a guideline of new features for implementation
  and deployment.

Would it be possible to add a little more interprettation of the tables?

By the way, I find my interpretation of the tables give rise to a few
questions...

If a feature is marked as "SHOULD" deploy, how would that be possible
unless implementations "MUST" implement?

If a feature "MUST NOT" be deployed, does it matter whether the
implementation includes the option?

[Ballot discuss]
This is a really small Discuss and easily fixed. The way that
[I-D.ietf-6lowpan-hc] is used in Sections 1.4 and 3 make it a
normative reference.

---

Section 3.4 seems to contain a lot of options and sub-options with the
over-arching assumption that "all 6LRs in a network are configured to
perform these functions homogeneously." This seems like a lot of
configuration complexity for very simple nodes in an environment where
users will not be sophisticated. Moreover, it seems highly likely to me
that misconfigurations will arise and homogeneity will be lost.

The latter suggests that the assumption of homogeneity cannot be
trusted. You will need to handle (at least at the level of fault
detection) mixed mode configuration.

The former suggests that you should have some form of automatic
arbitration (i.e., something more sophisticated than fault detection) so
that the network can become homogeneous across the sub-options.

---

Table 1 in Section 4.1 demands an IANA action. In Section 12 there is a
brief statement:

  This document also requests IANA to create a new registry for the
  Status values of the Address Registration Option.

This text needs to be beefed up to show:
- which is the owning registry
- what the name of the sub-registry should be
- either a pointer to section 4.1 or (preferably) all of the relevant
  information

---

Section 6.1

  A router SHOULD NOT send Redirect messages in a route-over topology,
  but MAY send Redirect messages in a mesh-under topology.

The use of 2119 language here may be correct, but leaves some holes.

In route-over, under what conditions MAY a router send Redirect
messages?

In mesh-under, what is the normal behavior? Presumably "SHOULD NOT". But
why MAY a Redirect be sent in mesh-under?

---

Section 12

Please remove the following text from the I-D before advancing it to the
RFC Editor

  For the purpose of protocol interoperability testing of this
  specification, the following values are being used temporarily:

  o  TBD1 = 31

  o  TBD2 = 32

  o  TBD3 = 33

  o  TBD4 = 155 XXX

  o  TBD3 = 156 XXX

(There is, in any case, a typo s/TBD3/TBD5/ on the last line)

---

Section 8.2.1

  A node MUST silently discard any received Duplicate Address Request
  and Confirmation messages that do not satisfy all of the following
  validity checks:

I suspect you mean "...message that does not satisfy any of the
following..." Since you have written that only the messages that fail
every one of the checks must be discarded.

[Ballot comment]
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.

[Ballot comment]
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.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC: <6lowpan@lists.ietf.org>
Reply-To: ietf@ietf.org
Subject: Last Call:  (Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN)) to Proposed Standard


The IESG has received a request from the IPv6 over Low power WPAN WG
(6lowpan) to consider the following document:
- 'Neighbor Discovery Optimization for Low Power and Lossy Networks
  (6LoWPAN)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The IETF 6LoWPAN working group defines IPv6 over Low-power Wireless
  Personal Area Networks such as IEEE 802.15.4.  This and other similar
  link technologies have limited or no usage of multicast signaling due
  to energy conservation.  In addition, the wireless network may not
  strictly follow traditional concept of IP subnets and IP links.  IPv6
  Neighbor Discovery was not designed for non-transitive wireless
  links.  The traditional IPv6 link concept and heavy use of multicast
  make the protocol inefficient and sometimes impractical in a low
  power and lossy network.  This document describes simple
  optimizations to IPv6 Neighbor Discovery, addressing mechanisms and
  duplicate address detection for 6LoWPAN and similar networks.  The
  document, thus updates RFC 4944 to specify the use of the
  optimizations defined here.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6lowpan-nd/


No IPR declarations have been submitted directly on this I-D.

Request for publication of draft-ietf-6lowpan-nd-18.txt

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The Document Shepherd is 6LoWPAN WG co-chair Carsten Bormann
(cabo@tzi.org).  He has personally reviewed the document and believes
that it is ready for forwarding to the IESG for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document is one of the core output documents of the 6LoWPAN WG.
It has received wide review as well as extensive interop testing in
ZigBee IP and IPSO events.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No -- there are no concerns that the documents require additional
broader review.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The document is the result of a "reboot" of its development process,
in which a number of simplifications have been made by striking
potential requirements that earlier versions (pre -09) attempted to
address.  As it stands, it now represents a strong WG consensus.
No IPR disclosures have been made.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is strong working group consensus behind this document. It is
the result of several years of work that has been validated by
extensive implementation effort.  A significant number of WG members
have commented on the technical substance and language of the
specification.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

The shepherd is not aware of any discontent related to the specification.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The shepherd has verified to the best of his ability that there are no
ID nits in this draft (with one exception: The document still
references RFC6282 in its Internet-Draft form -- easily fixed at the
RFC editor stage or earlier).

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The Document Shepherd believes all references are appropriately split.
There are no down-references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA considerations are quite important to this document and
appear to be correct.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

There are no such sections.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

This document specifies optimizations for the IPv6 Neighbor Discovery
protocol that facilitate its use in 6LoWPAN networks with sleeping
nodes, reducing the reliance on subnet-wide multicast and making the
protocol more robust to high packet loss rates.  A mechanism for
Duplicate Address Detection is provided that operates in the presence
of sleeping nodes.  In addition, the document extends ND to support
the dissemination of the shared context that the 6LoWPAN-HC
compression format (RFC 6282) relies on to allow compression of
arbitrary prefixes in a 6LoWPAN.

    Working Group Summary

This document represents the consensus of the 6LoWPAN community to
update RFC 4944 by making the present specification an integral part
of 6LoWPAN.  There has been strong consensus that the present
optimization of the IPv6 Neighbor Discovery protocol is sufficiently
important to justify this significant change.

    Document Quality

The document is a product of the 6LoWPAN working group and has been
reviewed in detail by a significant number of 6LoWPAN working group
members.  The principal content of the document has been technically
stable for about a year, during which certain fringe cases were
identified by implementers and addressed in minor updates to the
specification.  The specification has been picked up widely in the
6LoWPAN community and has been subject to extensive interoperability
testing in vendor organizations such as ZigBee and IPSO.