Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
draft-ietf-6lo-rfc6775-update-21
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2018-11-13
|
21 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2018-11-05
|
21 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-10-23
|
21 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2018-10-10
|
21 | (System) | RFC Editor state changed to AUTH from EDIT |
2018-09-04
|
21 | (System) | RFC Editor state changed to EDIT from AUTH |
2018-08-31
|
21 | (System) | RFC Editor state changed to AUTH from EDIT |
2018-08-22
|
21 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-08-22
|
21 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2018-08-22
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-08-20
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-08-20
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-08-20
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-08-20
|
21 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2018-08-17
|
21 | (System) | IANA Action state changed to Waiting on Authors |
2018-08-16
|
21 | (System) | RFC Editor state changed to EDIT |
2018-08-16
|
21 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-08-16
|
21 | (System) | Announcement was received by RFC Editor |
2018-08-16
|
21 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-08-16
|
21 | Cindy Morgan | IESG has approved the document |
2018-08-16
|
21 | Cindy Morgan | Closed "Approve" ballot |
2018-08-16
|
21 | Cindy Morgan | Ballot approval text was generated |
2018-08-16
|
21 | Suresh Krishnan | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2018-06-19
|
21 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-21.txt |
2018-06-19
|
21 | (System) | New version approved |
2018-06-19
|
21 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-06-19
|
21 | Pascal Thubert | Uploaded new revision |
2018-06-06
|
20 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-20.txt |
2018-06-06
|
20 | (System) | New version approved |
2018-06-06
|
20 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-06-06
|
20 | Pascal Thubert | Uploaded new revision |
2018-05-07
|
19 | Gunter Van de Velde | Closed request for Last Call review by OPSDIR with state 'Team Will not Review Version' |
2018-04-23
|
19 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-19.txt |
2018-04-23
|
19 | (System) | New version approved |
2018-04-23
|
19 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-04-23
|
19 | Pascal Thubert | Uploaded new revision |
2018-04-19
|
19 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. |
2018-04-06
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-04-06
|
18 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-18.txt |
2018-04-06
|
18 | (System) | New version approved |
2018-04-06
|
18 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-04-06
|
18 | Pascal Thubert | Uploaded new revision |
2018-04-05
|
17 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2018-04-05
|
17 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-04-05
|
17 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-04-04
|
17 | Eric Rescorla | [Ballot comment] I found this document quite challenging to read. It would be very helpful if it started with a description of the failings of … [Ballot comment] I found this document quite challenging to read. It would be very helpful if it started with a description of the failings of 6775 and a brief overview of how it solves those. At the risk of self-citing, the techniques of RFC 4101 might be helpful here. In addition, I recognize that some of the guarantees here depend on draft-ietf-6lo-ap-nd. I have not yet thoroughly reviewed that document, but it is not yet clear to me precisely what guarantees it in fact provides. This specification introduces the Extended Address Registration Option (EARO) based on the ARO as defined [RFC6775]. A 'T' flag is Can you describe here the problem that ARO has that this solves? that this specification avoids the Duplicate Address message flow for Link-Local Addresses in a Route-Over [RFC6606] topology. This sentence is not really maximally clear. Why does it avoid it? o The address that is being registered with an NS with an EARO is now the Target Address, as opposed to the Source Address as This would read better, I think if you said "The address that is being registered is set to the target address in the NS containing the EARO,as opposed to..." denoting a ROVR size of 128, 192 and 256 bits respectively. Status: 8-bit unsigned integer. Indicates the status of a It took me a minute to realize that this is the length of the *entire* option and so it's 1 larger than the length of the ROVR. Some text might help here. registration of a particular IPv6 Address and it cannot be used to correlate registrations of different addresses. "cannot" doesn't seem quite right. I.e., if you use the same EUI-64, someone could use it for that. Perhaps you mean "must not" rightmost bit and place the result in the EDAR message to maintain compatibility. This way, the support of DAD is preserved. Is there a reason for the rightmost bits? I see that https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06 uses the leftmost bits for Crypto-ID. Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the Registered Address using a cryptographic ROVR. I'm a little unsure how to read this text. It seems like the techniques you are discussing are about whether a node behaves incorrectly, but 6775 says that the first trust model of 3756 applies, and *that* says: A model where all authenticated nodes trust each other to behave correctly at the IP layer and not to send any ND or RD messages that contain false information. This model is thought to represent a situation where the nodes are under a single administration and form a closed or semi-closed group. A corporate intranet is a good example. So in that setting why do you need ownership guarantees? Is this just belt and suspenders? address, but a stronger identification (e.g., by security credentials) is RECOMMENDED. When that maximum is reached, the router should use a Least-Recently-Used (LRU) algorithm to clean What would these security credentials be? |
2018-04-04
|
17 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-04-04
|
17 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2018-04-04
|
17 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-04-04
|
17 | Alissa Cooper | [Ballot comment] Thanks for the thoughtful privacy considerations in this document. |
2018-04-04
|
17 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-04-04
|
17 | Mirja Kühlewind | [Ballot comment] I believe this document would have been easier to read for me if section 6 would have been before section 4; however, I … [Ballot comment] I believe this document would have been easier to read for me if section 6 would have been before section 4; however, I guess that's a matter of taste. On the TID in section 6.1: Should this field be zero if the T flag is not set? I guess you should at least say that the field should be ignored if the T flag is not set. |
2018-04-04
|
17 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-04-04
|
17 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2018-04-04
|
17 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-04-03
|
17 | Ben Campbell | |
2018-04-03
|
17 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-04-03
|
17 | Peter Yee | Request for Telechat review by GENART Completed: Ready. Reviewer: Peter Yee. Sent review to list. |
2018-04-03
|
17 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from No Record |
2018-04-03
|
17 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-04-03
|
17 | Benjamin Kaduk | [Ballot comment] Section 6.1 has: Registration Ownership Verifier (ROVR): Enables the correlation between multiple attempts … [Ballot comment] Section 6.1 has: Registration Ownership Verifier (ROVR): Enables the correlation between multiple attempts to register a same IPv6 Address. This can be a unique ID of the Registering Node, such as the EUI-64 address of an interface. This can also be a token obtained with cryptographic methods and used as proof of ownership of the registration. [...] I understand that the actual crypto is (currently) in draft-ietf-6lo-ap-nd, but from the point of view of this document, the ROVR token (or "crypto-ID" in the terminology of 6lo-ap-nd) behaves as a bearer token. That is, I include it with my EARO and my registration request is authenticated and associated with that "identity"; there is not anything in this document that ties the crypto-ID to the EARO. From a very quick read of the other document, it sounds like the 6LR can optionally request validation that the 6LN using the crypto-ID actually has control of the associated private key, and is expected to do so on the first exchange, and so arguably the transport key+LLA are what associates the crypto-ID with the EARO. The conclusion from the above would be that this sort of ROVR is not itself proof of ownership of anything, so it might be better to have text like "this can also be a token obtained with cryptographic methods which can be used in additional protocol exchanges to associate a cryptographic identity (key) with this registration". In several places in section 7 it is indicated that implementations that support this spec should always use the new data structures even when talking to RFC6775-only peers; this generally seems fine due to the way that reserved fields are used. I was not entirely sure if the same holds for the use of new status codes in the EARO, though -- do things work out okay if (e.g.) "Moved" or "Removed" are interpreted as a generic error? In general the Security and Privacy Considerations seem well thought-out (in the model where Layer-2 security is already in place), thank you! (Key distribution remains a hard problem, of course, and sharing such keys across groups does reduce the security properties of the system, but this is not the right place to go into detail on such issues.) One final nit: what is the "port" involved in the Binding? It does not sound like it is an IP port... |
2018-04-03
|
17 | Benjamin Kaduk | Ballot comment text updated for Benjamin Kaduk |
2018-04-03
|
17 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-17.txt |
2018-04-03
|
17 | (System) | New version approved |
2018-04-03
|
17 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-04-03
|
17 | Pascal Thubert | Uploaded new revision |
2018-04-03
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-04-02
|
16 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-04-02
|
16 | Warren Kumari | [Ballot comment] Thank you for a very readable document - this is not a simple process, but the document was clear and understandable. Also, thank … [Ballot comment] Thank you for a very readable document - this is not a simple process, but the document was clear and understandable. Also, thank you for addressing Jürgen Schönwälder's OpsDir comments (I have not personally checked that each was incorporated, but the authors said that they would, and I'm trusting them). Issues: "In IPv6 ND [RFC4861], a router needs enough storage to hold NCEs for all the addresses to which it can currently forward packets." -- I do not believe that this is correct and am not quite sure how to fix it. Can you point where in RFC4861 it says this? I'd agree that *to be efficient* a router should have enough space to hold an NCE for all locally attached subnets, but a constrained device *could* presumably age out and relearn old entries. Apart from that somewhat pathological case, if I'm a router and get a transit packet (not for a directly connected interface), I don't need to have a neighbor entry for it (otherwise "core" routers would need to build NCEs for every IP on the Internet :-P). Perhaps "for all directly connected subnets." or "for all directly connected addresses to which it can currently forward packets."? I'm somewhat uncomfortable with the uppercase MUST in: "A network administrator MUST deploy updated 6LR/6LBRs to support the number and type of devices in their network, ..." Having an uppercase MUST driving operators' design decisions stuff feels weird. I'd be perfectly fine with something like "In order to deploy this, network administrators MUST..." or "Network Administrators need to ensure that 6LR/6LBRs support the number and..." Nits: Section 4.2.1. Comparing TID values "In order to keep this document self-contained and yet compatible, the text below is an exact copy from section 7.2. "Sequence Counter Operation" of [RFC6550]."" I think that it would be helpful to delimit the copied text (perhaps by indenting it) -- it was unclear to me where the copied text started and ended, and so I had to go read RFC6550 (which kind of defeats the purpose of copying it). Section 4.3. Registration Ownership Verifier "An RFC6775-only will confuse the name-spaces," Missing a word - perhaps "device", "6LoWPAN Router" or "implementation"? Section 7.3. RFC6775-only 6LoWPAN Router "But if RFC6775-only and updated 6LRs coexist temporarily in a network, then it makes sense for an administrator to install a policy that allows so, and the capability to install such a policy should be configurable in a 6LBR though it is out of scope for this document." s/that allows so/that allows this/ -- readability (purely a nit). Section Appendix B. Requirements (Not Normative) "This section lists requirements that were discussed discussed by the 6lo WG..." I guess that they were discussed at length? :-P Section B.1. Requirements Related to Mobility " Due to the unstable nature of LLN links, even in an LLN of immobile nodes a 6LN may change" s/of immobile nodes a/of immobile nodes, a/ (add comma -- also a nitty nit). |
2018-04-02
|
16 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2018-04-01
|
16 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-04-01
|
16 | Suresh Krishnan | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) 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 specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies. Working Group Summary There has been plenty of discussion about these extensions in the working group. This document started in Oct. 2016 as an individual submission, but ideas were discussed even previous to that, including a requirements document (draft-thubert-6lo-rfc6775-update-reqs) which fed into this document, 6775bis. There have been 10 revisions based on implementation experience. Initially, it was a controversial document since it affects how IPv6 ND works in certain networks. This prompted some concern from IPv6 folks (e.g., Lorenzo Colitti) concerned that these modifications were not generally applicable to all link layers or situations. In response, the authors made changes to clarify the scope of the extensions. Section 2, in particular was modified as a result of these debates and exchanges. Document Quality These extensions have been implemented in open source (OpenWSN, Cisco IOS) and has been tested in 6TiSCH/6lo ETSI Plugtest. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Gabriel Montenegro AD: Suresh Krishnan (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document and identified several editorial issues, but these should not block IESG review and can be addressed as part of IETF LC and IESG comments. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has received in-depth reviews. No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This documents will benefit from operational and privacy review, but nothing beyond the normal. (6) Describe any specific concerns or issues that the Document Shepherd has 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. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Authors have confirmed that they have no knowledge of relevant IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure. (9) 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? At this point, it is solid. There was a point when it was very controversial as noted above. (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. == Outdated reference: A later version (-05) exists of draft-ietf-6lo-backbone-router-04 == Outdated reference: A later version (-09) exists of draft-ietf-6lo-nfc-08 == Outdated reference: draft-ietf-bier-architecture has been published as RFC 8279 Note: there are also two ignorable warnings about non-existent references which do exist. Idnits just does not expect to find them in an "Exernal Informative References" section. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes (14) 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 plan for their completion? Not applicable. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Only RFC8126 (Guidance IANA Considerations), which shouldn't be an issue. Alternatively, this could be moved to informational. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Per the header of the document: "Updates: 6775 (if approved) " (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Looks good. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Nothing new under expert review. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2018-04-01
|
16 | Suresh Krishnan | Ballot has been issued |
2018-04-01
|
16 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2018-04-01
|
16 | Suresh Krishnan | Created "Approve" ballot |
2018-04-01
|
16 | Suresh Krishnan | Ballot writeup was changed |
2018-03-22
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2018-03-22
|
16 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2018-03-19
|
16 | Dave Thaler | Request for Early review by IOTDIR Completed: Almost Ready. Reviewer: Dave Thaler. Sent review to list. |
2018-03-19
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-03-19
|
16 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-16.txt |
2018-03-19
|
16 | (System) | New version approved |
2018-03-19
|
16 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-03-19
|
16 | Pascal Thubert | Uploaded new revision |
2018-03-08
|
15 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2018-03-08
|
15 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2018-03-07
|
15 | Peter Yee | Request for Telechat review by GENART Completed: Ready with Issues. Reviewer: Peter Yee. Sent review to list. |
2018-03-06
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-03-05
|
15 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-03-05
|
15 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-6lo-rfc6775-update-11. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-6lo-rfc6775-update-11. If any part of this review is inaccurate, please let us know. The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Services Operator understands that, upon approval of this document, there are five actions which we must complete. First, a new registry is to be created called the ARO Flags registry. The new reistry will be located in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at: https://www.iana.org/assignments/icmpv6-parameters/ the new registry will be managed via IETF Review as defined by RFC 8126. There are eight bits in the registry and there are initial registrations as follows: ARO Status Description Refernce -------+-----------------------------+--------------- 0 - 6 Unassigned 7 "T" Flag [ RFC-to-be ] Second, a new subregistry of the ICMPv6 "Code" Fields registry also on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at: https://www.iana.org/assignments/icmpv6-parameters/ The new subregistry is for Duplicate Address Request and is as follows: Type 157 - Duplicate Address Request Registration Procedure: Standards Action or IESG Approval Reference: [ RFC-to-be ] Code Name Reference --------+------------------------+---------------- 0 Original DAR message RFC 6775 1 Extended DAR message [ RFC-to-be ] Third, a new subregistry of the ICMPv6 "Code" Fields registry also on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at: https://www.iana.org/assignments/icmpv6-parameters/ The new subregistry is for Duplicate Address Confirmation and is as follows: Type 158 - Duplicate Address Confirmation Registration Procedure: Standards Action or IESG Approval Reference: [ RFC-to-be ] Code Name Reference --------+------------------------+---------------- 0 Original DAC message RFC 6775 1 Extended DAC message [ RFC-to-be ] Fourth, in the Address Registration Option Status Values registry also on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at: https://www.iana.org/assignments/icmpv6-parameters/ a series of new registrations will be made as follows: +------------+------------------------------------+----------------+ | ARO Status | Description | Reference | +------------+------------------------------------+----------------+ | 3 | Moved | [ RFC-to-be ] | | | | | | 4 | Removed | [ RFC-to-be ] | | | | | | 5 | Validation Requested | [ RFC-to-be ] | | | | | | 6 | Duplicate Source Address | [ RFC-to-be ] | | | | | | 7 | Invalid Source Address | [ RFC-to-be ] | | | | | | 8 | Registered Address topologically | [ RFC-to-be ] | | | incorrect | | | | | | | 9 | 6LBR registry saturated | [ RFC-to-be ] | | | | | | 10 | Validation Failed | [ RFC-to-be ] | +------------+------------------------------------+----------------+ Fifth, in the 6LoWPAN capability Bits registry also on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at: https://www.iana.org/assignments/icmpv6-parameters/ a series of new registrations will be made as follows: +-----------------+----------------------+----------------+ | Capability Bit | Description | Document | +-----------------+----------------------+----------------+ | 11 | 6LR capable (L bit) | [ RFC-to-be ] | | | | | | 12 | 6LBR capable (B bit) | [ RFC-to-be ] | | | | | | 13 | 6BBR capable (P bit) | [ RFC-to-be ] | | | | | | 14 | EARO support (E bit) | [ RFC-to-be ] | +-----------------+----------------------+----------------+ IANA Question --> Are there any other places on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at: https://www.iana.org/assignments/icmpv6-parameters/ where the references should be changed from RFC 6775 to [ RFC-to-be ]? The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-03-04
|
15 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-15.txt |
2018-03-04
|
15 | (System) | New version approved |
2018-03-04
|
15 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-03-04
|
15 | Pascal Thubert | Uploaded new revision |
2018-03-02
|
14 | Thomas Watteyne | Added to session: interim-2018-6tisch-03 |
2018-02-24
|
14 | Adrian Farrel | Request for Telechat review by RTGDIR Completed: Has Issues. Reviewer: Adrian Farrel. |
2018-02-23
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2018-02-23
|
14 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jürgen Schönwälder |
2018-02-23
|
14 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-14.txt |
2018-02-23
|
14 | (System) | New version approved |
2018-02-23
|
14 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-02-23
|
14 | Pascal Thubert | Uploaded new revision |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Adrian Farrel |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Adrian Farrel |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to John Drake |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to John Drake |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Papadimitriou Dimitri |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Papadimitriou Dimitri |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Dhruv Dhody |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Dhruv Dhody |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Bruno Decraene |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Bruno Decraene |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Mach Chen |
2018-02-22
|
13 | Min Ye | Request for Telechat review by RTGDIR is assigned to Mach Chen |
2018-02-22
|
13 | Alvaro Retana | Requested Telechat review by RTGDIR |
2018-02-22
|
13 | Tero Kivinen | Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Chris Lonvick. |
2018-02-22
|
13 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-13.txt |
2018-02-22
|
13 | (System) | New version approved |
2018-02-22
|
12 | Suresh Krishnan | Telechat date has been changed to 2018-04-05 from 2018-03-08 |
2018-02-22
|
13 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-02-22
|
13 | Pascal Thubert | Uploaded new revision |
2018-02-21
|
12 | Jürgen Schönwälder | Request for Telechat review by OPSDIR Completed: Has Issues. Reviewer: Jürgen Schönwälder. Sent review to list. |
2018-02-21
|
12 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-12.txt |
2018-02-21
|
12 | (System) | New version approved |
2018-02-21
|
12 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2018-02-21
|
12 | Pascal Thubert | Uploaded new revision |
2018-02-20
|
11 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-02-20
|
11 | Amy Vezza | instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification updates RFC 6775 - 6LoWPAN … instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the backbone routers performing proxy Neighbor Discovery in a low power network. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6lo-rfc6775-update/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-02-20
|
11 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-02-20
|
11 | Suresh Krishnan | Last call was requested |
2018-02-20
|
11 | Suresh Krishnan | Last call announcement was generated |
2018-02-20
|
11 | Suresh Krishnan | Ballot approval text was generated |
2018-02-20
|
11 | Suresh Krishnan | Ballot writeup was generated |
2018-02-20
|
11 | Suresh Krishnan | IESG state changed to Last Call Requested from AD Evaluation |
2018-02-16
|
11 | Tim Chown | Request for Early review by INTDIR Completed: Almost Ready. Reviewer: Tim Chown. Sent review to list. |
2018-02-15
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2018-02-15
|
11 | Jean Mahoney | Request for Telechat review by GENART is assigned to Peter Yee |
2018-02-15
|
11 | Ari Keränen | Request for Early review by IOTDIR is assigned to Dave Thaler |
2018-02-15
|
11 | Ari Keränen | Request for Early review by IOTDIR is assigned to Dave Thaler |
2018-02-08
|
11 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2018-02-08
|
11 | Tero Kivinen | Request for Telechat review by SECDIR is assigned to Chris Lonvick |
2018-02-05
|
11 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder |
2018-02-05
|
11 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Jürgen Schönwälder |
2018-02-05
|
11 | Suresh Krishnan | Placed on agenda for telechat - 2018-03-08 |
2018-02-01
|
11 | Bernie Volz | Request for Early review by INTDIR is assigned to Tim Chown |
2018-02-01
|
11 | Bernie Volz | Request for Early review by INTDIR is assigned to Tim Chown |
2018-01-31
|
11 | Suresh Krishnan | Requested Early review by IOTDIR |
2018-01-31
|
11 | Suresh Krishnan | Requested Early review by INTDIR |
2018-01-29
|
11 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2018-01-16
|
11 | Gabriel Montenegro | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard (2) 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 Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There has been plenty of discussion about these extensions in the working group. This document started in Oct. 2016 as an individual submission, but ideas were discussed even previous to that, including a requirements document (draft-thubert-6lo-rfc6775-update-reqs) which fed into this document, 6775bis. There have been 10 revisions based on implementation experience. Initially, it was a controversial document since it affects how IPv6 ND works in certain networks. This prompted some concern from IPv6 folks (e.g., Lorenzo Colitti) concerned that these modifications were not generally applicable to all link layers or situations. In response, the authors made changes to clarify the scope of the extensions. Section 2, in particular was modified as a result of these debates and exchanges. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? These extensions have been implemented in open source (OpenWSN, Cisco IOS) and has been tested in 6TiSCH/6lo ETSI Plugtest. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Shepherd: Gabriel Montenegro AD: Suresh Krishnan (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. I have reviewed the document and identified several editorial issues, but these should not block IESG review and can be addressed as part of IETF LC and IESG comments. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? This document has received in-depth reviews. No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. This documents will benefit from operational and privacy review, but nothing beyond the normal. (6) Describe any specific concerns or issues that the Document Shepherd has 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. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Authors have confirmed that they have no knowledge of relevant IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No disclosure. (9) 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? At this point, it is solid. There was a point when it was very controversial as noted above. (10) 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 publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. == Outdated reference: A later version (-05) exists of draft-ietf-6lo-backbone-router-04 == Outdated reference: A later version (-09) exists of draft-ietf-6lo-nfc-08 == Outdated reference: draft-ietf-bier-architecture has been published as RFC 8279 Note: there are also two ignorable warnings about non-existent references which do exist. Idnits just does not expect to find them in an "Exernal Informative References" section. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. Not applicable. (13) Have all references within this document been identified as either normative or informative? Yes (14) 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 plan for their completion? Not applicable. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Only RFC8126 (Guidance IANA Considerations), which shouldn't be an issue. Alternatively, this could be moved to informational. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. Per the header of the document: "Updates: 6775 (if approved) " (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). Looks good. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. Nothing new under expert review. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. Not applicable. |
2018-01-16
|
11 | Gabriel Montenegro | Responsible AD changed to Suresh Krishnan |
2018-01-16
|
11 | Gabriel Montenegro | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2018-01-16
|
11 | Gabriel Montenegro | IESG state changed to Publication Requested |
2018-01-16
|
11 | Gabriel Montenegro | IESG process started in state Publication Requested |
2018-01-16
|
11 | Gabriel Montenegro | Changed document writeup |
2017-12-15
|
11 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-11.txt |
2017-12-15
|
11 | (System) | New version approved |
2017-12-15
|
11 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Charles Perkins , Samita Chakrabarti |
2017-12-15
|
11 | Pascal Thubert | Uploaded new revision |
2017-10-13
|
10 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-10.txt |
2017-10-13
|
10 | (System) | New version approved |
2017-10-13
|
10 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , 6lo-chairs@ietf.org, Samita Chakrabarti |
2017-10-13
|
10 | Pascal Thubert | Uploaded new revision |
2017-09-20
|
09 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-09.txt |
2017-09-20
|
09 | (System) | New version approved |
2017-09-20
|
09 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Samita Chakrabarti |
2017-09-20
|
09 | Pascal Thubert | Uploaded new revision |
2017-09-20
|
08 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-08.txt |
2017-09-20
|
08 | (System) | New version approved |
2017-09-20
|
08 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Samita Chakrabarti |
2017-09-20
|
08 | Pascal Thubert | Uploaded new revision |
2017-07-28
|
07 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-07.txt |
2017-07-28
|
07 | (System) | New version approved |
2017-07-28
|
07 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Samita Chakrabarti |
2017-07-28
|
07 | Pascal Thubert | Uploaded new revision |
2017-06-27
|
06 | Gabriel Montenegro | Changed consensus to Yes from Unknown |
2017-06-27
|
06 | Gabriel Montenegro | Intended Status changed to Proposed Standard from None |
2017-06-27
|
06 | Gabriel Montenegro | IETF WG state changed to In WG Last Call from WG Document |
2017-06-21
|
06 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-06.txt |
2017-06-21
|
06 | (System) | New version approved |
2017-06-21
|
06 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Samita Chakrabarti |
2017-06-21
|
06 | Pascal Thubert | Uploaded new revision |
2017-05-12
|
05 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-05.txt |
2017-05-12
|
05 | (System) | New version approved |
2017-05-12
|
05 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Samita Chakrabarti |
2017-05-12
|
05 | Pascal Thubert | Uploaded new revision |
2017-05-01
|
04 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-04.txt |
2017-05-01
|
04 | (System) | New version approved |
2017-05-01
|
04 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Samita Chakrabarti |
2017-05-01
|
04 | Pascal Thubert | Uploaded new revision |
2017-04-27
|
03 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-03.txt |
2017-04-27
|
03 | (System) | New version approved |
2017-04-27
|
03 | (System) | Request for posting confirmation emailed to previous authors: Erik Nordmark , Pascal Thubert , Samita Chakrabarti |
2017-04-27
|
03 | Pascal Thubert | Uploaded new revision |
2017-04-07
|
02 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-02.txt |
2017-04-07
|
02 | (System) | New version approved |
2017-04-07
|
02 | (System) | Request for posting confirmation emailed to previous authors: Pascal Thubert , 6lo-chairs@ietf.org, Erik Nordmark , Samita Chakrabarti |
2017-04-07
|
02 | Pascal Thubert | Uploaded new revision |
2017-01-11
|
01 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-01.txt |
2017-01-11
|
01 | (System) | New version approved |
2017-01-11
|
01 | (System) | Request for posting confirmation emailed to previous authors: "Erik Nordmark" , "Pascal Thubert" , 6lo-chairs@ietf.org, "Samita Chakrabarti" |
2017-01-11
|
01 | Pascal Thubert | Uploaded new revision |
2016-12-23
|
00 | Gabriel Montenegro | This document now replaces draft-thubert-6lo-rfc6775-update instead of None |
2016-12-23
|
00 | Gabriel Montenegro | Notification list changed to "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com> |
2016-12-23
|
00 | Gabriel Montenegro | Document shepherd changed to Gabriel Montenegro |
2016-12-23
|
00 | Pascal Thubert | New version available: draft-ietf-6lo-rfc6775-update-00.txt |
2016-12-23
|
00 | (System) | WG -00 approved |
2016-12-23
|
00 | Pascal Thubert | Set submitter to "Pascal Thubert ", replaces to (none) and sent approval email to group chairs: 6lo-chairs@ietf.org |
2016-12-23
|
00 | Pascal Thubert | Uploaded new revision |