Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
draft-ietf-6lowpan-nd-21
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-29
|
21 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2012-08-29
|
21 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2012-08-28
|
21 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-08-27
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2012-08-27
|
21 | (System) | IANA Action state changed to In Progress |
2012-08-27
|
21 | Amy Vezza | State changed to Approved-announcement sent from IESG Evaluation::AD Followup |
2012-08-27
|
21 | Amy Vezza | IESG has approved the document |
2012-08-27
|
21 | Amy Vezza | Closed "Approve" ballot |
2012-08-27
|
21 | Amy Vezza | Ballot approval text was generated |
2012-08-27
|
21 | Amy Vezza | Ballot writeup was changed |
2012-08-27
|
21 | Stephen Farrell | [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 … [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. |
2012-08-27
|
21 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2012-08-24
|
21 | Brian Haberman | [Ballot comment] Thanks for addressing these issues. |
2012-08-24
|
21 | Brian Haberman | [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from Discuss |
2012-08-24
|
21 | Zach Shelby | New version available: draft-ietf-6lowpan-nd-21.txt |
2012-08-21
|
20 | Brian Haberman | [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 … [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? |
2012-08-21
|
20 | Brian Haberman | [Ballot Position Update] New position, Discuss, has been recorded for Brian Haberman |
2012-08-20
|
20 | Adrian Farrel | [Ballot comment] Thanks for working on my Discuss and Comments. |
2012-08-20
|
20 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss |
2012-08-20
|
20 | Adrian Farrel | [Ballot discuss] I have updated my Discuss for revision -20. Thanks for the work so far. --- > I have added a placeholder to this … [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. |
2012-08-20
|
20 | Adrian Farrel | [Ballot comment] Thanks for working on my Comments. |
2012-08-20
|
20 | Adrian Farrel | Ballot comment and discuss text updated for Adrian Farrel |
2012-08-19
|
20 | Zach Shelby | New version available: draft-ietf-6lowpan-nd-20.txt |
2012-08-06
|
19 | Stephen Farrell | [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 … [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 |
2012-08-06
|
19 | Stephen Farrell | [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 … [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. |
2012-08-06
|
19 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-08-06
|
19 | Stephen Farrell | [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 … [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 |
2012-08-06
|
19 | Stephen Farrell | [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 … [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. |
2012-08-06
|
19 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-07-21
|
19 | Stephen Farrell | [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 … [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 |
2012-07-21
|
19 | Stephen Farrell | [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 … [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. |
2012-07-21
|
19 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-07-21
|
19 | Stephen Farrell | [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 … [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.) |
2012-07-21
|
19 | Stephen Farrell | [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 … [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. |
2012-07-21
|
19 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-07-21
|
19 | Stephen Farrell | [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, … [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.) |
2012-07-21
|
19 | Stephen Farrell | [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 … [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. |
2012-07-21
|
19 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-07-17
|
19 | Adrian Farrel | [Ballot discuss] I have updated my Discuss for revision -19. Thanks for the work so far. --- > I have added a placeholder to this … [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. |
2012-07-17
|
19 | Adrian Farrel | [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 … [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. |
2012-07-17
|
19 | Adrian Farrel | Ballot comment and discuss text updated for Adrian Farrel |
2012-07-16
|
19 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-16
|
19 | Zach Shelby | New version available: draft-ietf-6lowpan-nd-19.txt |
2012-01-05
|
18 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Donald Eastlake. |
2012-01-05
|
18 | Cindy Morgan | Removed from agenda for telechat |
2012-01-05
|
18 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation. |
2012-01-05
|
18 | Jari Arkko | [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 … [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, ..." |
2012-01-05
|
18 | Jari Arkko | [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 … [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? |
2012-01-05
|
18 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded |
2012-01-05
|
18 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-05
|
18 | Sean Turner | [Ballot comment] I support Stephen's discusses. |
2012-01-05
|
18 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-05
|
18 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-05
|
18 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-05
|
18 | Stewart Bryant | [Ballot comment] I agree with the points that Adrian makes. |
2012-01-05
|
18 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-04
|
18 | Ralph Droms | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
2012-01-04
|
18 | Peter Saint-Andre | [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 … [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? |
2012-01-04
|
18 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
2012-01-04
|
18 | Amanda Baber | 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 … 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 |
2012-01-04
|
18 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
2012-01-03
|
18 | Adrian Farrel | [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). … [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. |
2012-01-02
|
18 | Stephen Farrell | [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 … [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. |
2012-01-02
|
18 | Stephen Farrell | [Ballot discuss] #1 1.4 - "it is assumed that 6LRs register with all the 6LBRs." is ambiguous - does it mean each 6LR registers with … [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.) |
2012-01-02
|
18 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
2012-01-02
|
18 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
2011-12-31
|
18 | Adrian Farrel | [Ballot comment] A strict reading of one sentence in the Abstract may be misleading... The traditional IPv6 link concept and heavy use of multicast … [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? |
2011-12-31
|
18 | Adrian Farrel | [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 … [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. |
2011-12-31
|
18 | Adrian Farrel | [Ballot Position Update] New position, Discuss, has been recorded |
2011-12-31
|
18 | Russ Housley | [Ballot comment] The Gen-ART Review by Richard Barnes on 30-Dec-2011 raised one suggestion. Please consider it: > > The phrase "transitive link" … [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. |
2011-12-31
|
18 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
2011-12-31
|
18 | Russ Housley | [Ballot comment] The Gen-ART Review by Richard Barnes on 30-Dec-2011 raised one suggestion. Please consider it: > > The phrase "transitive link" … [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. |
2011-12-28
|
18 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
2011-12-28
|
18 | Ralph Droms | Ballot has been issued |
2011-12-28
|
18 | Ralph Droms | Created "Approve" ballot |
2011-12-21
|
18 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2011-12-21
|
18 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2011-12-21
|
18 | David Harrington | Request for Last Call review by TSVDIR is assigned to Rolf Winter |
2011-12-21
|
18 | David Harrington | Request for Last Call review by TSVDIR is assigned to Rolf Winter |
2011-12-16
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Richard Barnes |
2011-12-16
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Richard Barnes |
2011-12-16
|
18 | Amy Vezza | Last call sent |
2011-12-16
|
18 | Amy Vezza | 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: < … 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. |
2011-12-16
|
18 | Ralph Droms | Placed on agenda for telechat - 2012-01-05 |
2011-12-16
|
18 | Ralph Droms | Last Call was requested |
2011-12-16
|
18 | (System) | Ballot writeup text was added |
2011-12-16
|
18 | (System) | Last call text was added |
2011-12-16
|
18 | Ralph Droms | State changed to Last Call Requested from Publication Requested. |
2011-12-16
|
18 | Ralph Droms | Last Call text changed |
2011-12-16
|
18 | Ralph Droms | Ballot writeup text changed |
2011-10-26
|
18 | Cindy Morgan | 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 … 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. |
2011-10-26
|
18 | Cindy Morgan | Draft added in state Publication Requested |
2011-10-26
|
18 | Cindy Morgan | [Note]: 'Carsten Bormann (cabo@tzi.org) is the document shepherd.' added |
2011-10-24
|
18 | (System) | New version available: draft-ietf-6lowpan-nd-18.txt |
2011-06-13
|
17 | (System) | New version available: draft-ietf-6lowpan-nd-17.txt |
2011-05-24
|
16 | (System) | New version available: draft-ietf-6lowpan-nd-16.txt |
2010-12-17
|
15 | (System) | New version available: draft-ietf-6lowpan-nd-15.txt |
2010-10-25
|
14 | (System) | New version available: draft-ietf-6lowpan-nd-14.txt |
2010-09-15
|
13 | (System) | New version available: draft-ietf-6lowpan-nd-13.txt |
2010-08-02
|
12 | (System) | New version available: draft-ietf-6lowpan-nd-12.txt |
2010-07-12
|
11 | (System) | New version available: draft-ietf-6lowpan-nd-11.txt |
2010-06-17
|
10 | (System) | New version available: draft-ietf-6lowpan-nd-10.txt |
2010-04-27
|
09 | (System) | New version available: draft-ietf-6lowpan-nd-09.txt |
2010-02-01
|
08 | (System) | New version available: draft-ietf-6lowpan-nd-08.txt |
2009-10-26
|
07 | (System) | New version available: draft-ietf-6lowpan-nd-07.txt |
2009-09-21
|
06 | (System) | New version available: draft-ietf-6lowpan-nd-06.txt |
2009-09-02
|
05 | (System) | New version available: draft-ietf-6lowpan-nd-05.txt |
2009-07-12
|
04 | (System) | New version available: draft-ietf-6lowpan-nd-04.txt |
2009-05-27
|
03 | (System) | New version available: draft-ietf-6lowpan-nd-03.txt |
2009-03-09
|
02 | (System) | New version available: draft-ietf-6lowpan-nd-02.txt |
2009-02-23
|
01 | (System) | New version available: draft-ietf-6lowpan-nd-01.txt |
2008-11-19
|
00 | (System) | New version available: draft-ietf-6lowpan-nd-00.txt |