Discovering PREF64 in Router Advertisements
draft-ietf-6man-ra-pref64-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-04-17
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-04-13
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-02-26
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2020-01-19
|
09 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'Overtaken by Events' |
2020-01-19
|
09 | Tero Kivinen | Assignment of request for Last Call review by SECDIR to Alan DeKok was marked no-response |
2020-01-13
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2020-01-13
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2020-01-13
|
09 | (System) | IANA Action state changed to In Progress from Waiting on WGC |
2020-01-10
|
09 | (System) | IANA Action state changed to Waiting on WGC from In Progress |
2020-01-10
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2020-01-09
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2020-01-08
|
09 | (System) | RFC Editor state changed to EDIT |
2020-01-08
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2020-01-08
|
09 | (System) | Announcement was received by RFC Editor |
2020-01-08
|
09 | (System) | IANA Action state changed to In Progress |
2020-01-08
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2020-01-08
|
09 | Amy Vezza | IESG has approved the document |
2020-01-08
|
09 | Amy Vezza | Closed "Approve" ballot |
2020-01-08
|
09 | Amy Vezza | Ballot approval text was generated |
2020-01-08
|
09 | Suresh Krishnan | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2019-12-19
|
09 | Amy Vezza | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2019-12-19
|
09 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-12-19
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-12-19
|
09 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-09.txt |
2019-12-19
|
09 | (System) | New version accepted (logged-in submitter: Jen Linkova) |
2019-12-19
|
09 | Jen Linkova | Uploaded new revision |
2019-12-18
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-12-18
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-12-17
|
08 | Adam Roach | [Ballot comment] Thanks for this work! I find the use cases in section 2 quite compelling, and am happy to see a solution that addresses … [Ballot comment] Thanks for this work! I find the use cases in section 2 quite compelling, and am happy to see a solution that addresses them. |
2019-12-17
|
08 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-12-17
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-12-17
|
08 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-12-17
|
08 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-12-17
|
08 | Warren Kumari | [Ballot comment] Like Alexey, I found the Scaled Lifetime section tricky / overly complex - I'm not actually quire sure why the value needs to … [Ballot comment] Like Alexey, I found the Scaled Lifetime section tricky / overly complex - I'm not actually quire sure why the value needs to be scaled by 8 -- the field is 13 bits, which gives ( I think!) a maximum value of 8192. If this were not scaled, it would be 136 minutes (8192/60), or ~2 1/4 hours -- I might be missing something, but surely if you haven't gotten an RA in much less than that, you have some larger set of issues? I think that the complexity would be an easier pill to swallow if there was some justification for the complexity provided. If the text is reworded, I *think* it might make sense to break the explanation out of the main part of the "Option Format" bit, and do something like: "Scaled Lifetime: 13-bit unsigned integer, see Section 5.1" and then put the explanation text in Sec 5.1 - having it in this location makes the text feel "squished" and leads to an attempt to be overly terse. |
2019-12-17
|
08 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-12-16
|
08 | Barry Leiba | [Ballot comment] I just have a couple of editorial comments about Section 4: If the network operator desires to route different parts of … [Ballot comment] I just have a couple of editorial comments about Section 4: If the network operator desires to route different parts of the IPv4 address space to different NAT64 devices, this can be accomplished by routing more specifics of the NAT64 prefix to those devices. What does “more specifics” mean here? I don’t understand the sentence. For example, if the operator is using the RFC1918 address space, e.g. 10.0.0.0/8 internally and would like to route 10.0.0.0/8 through NAT64 device A and the rest of the IPv4 space through NAT64 device B, and the operator's NAT64 prefix is 2001:db8:a:b::/96, then the operator can route 2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/96 to NAT64 B. This sentence is too long and cumbersome, and would benefit from being split (which would also fix some awkward missing commas). How’s this?: NEW For example, suppose an operator is using the RFC1918 address space 10.0.0.0/8 internally. That operator might want to route 10.0.0.0/8 through NAT64 device A, and the rest of the IPv4 space through NAT64 device B. If the operator's NAT64 prefix is 2001:db8:a:b::/96, then the operator can route 2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/96 to NAT64 B. END |
2019-12-16
|
08 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-12-16
|
08 | Benjamin Kaduk | [Ballot comment] Thanks for this well-written document! I just have some fairly minor comments; the most significant one is a request to expound a bit … [Ballot comment] Thanks for this well-written document! I just have some fairly minor comments; the most significant one is a request to expound a bit more in the security considerations section. Section 1 NAT64 [RFC6146] with DNS64 [RFC6147] is a widely-deployed mechanism to provide IPv4 access on IPv6-only networks. In various scenarios, the host must be aware of the NAT64 prefix in use by the network. RFC 6147 sayas that no changes are required to the IPv6 node "for the class of applications that work through NATs". Is it only applications that do not work through NATs that comprise the "various scenarios" mentioned here? (Interestingly, neither of the examples in Section 2 seem to fall nicely into that bucket.) Section 2 * Local DNSSEC validation (DNS64 in stub-resolver mode). As discussed in [RFC6147] section 2, the stub resolver in the host "will try to obtain (real) AAAA RRs, and in case they are not available, the DNS64 function will synthesize AAAA RRs for internal usage." This is required in order to use DNSSEC on a NAT64 network. nit: I think the "this" that is required is "the stub doing the DNS64", not the AAAA synthesis mentioned in the quoted text. * Networks with no DNS64 server. Hosts that support AAAA synthesis and that are aware of the NAT64 prefix in use do not need the network to perform the DNS64 function at all. side note: I'm curious how common it is for a NAT64 network to not provide a DNS64 server, though that probably has no bearing on the contents of this document. Section 3 host. Only one packet (a Router Advertisement) is required to complete the network configuration. This speeds up the process of connecting to a network that supports NAT64/DNS64, and simplifies host implementation by removing the possibility that the host can have an incomplete layer 3 configuration (e.g., IPv6 addresses and prefixes, but no NAT64 prefix). This discussion seems slightly at odds with the premise/assumption in 6146/6147 that hosts will not need to know the NAT64 prefix in order to function (for applications that work through NAT, at least). I don't have any proposed alternative text, though (would just predicating the discussion on having a host that needs/wants the NAT64 prefix suffice?). Section 5 Scaled 13-bit unsigned integer. The maximum time in units of 8 Lifetime seconds over which this NAT64 prefix MAY be used. The value [...] lifetime values which are not divisible by 8. In such cases the router SHOULD round the provided value up to the lesser of nearest integer divisible by 8, or 65528 and divide the result by 8 (or just perform a logical right-shift by 3) and set the Scaled Lifetime field to the resulting value. If nit: I think the lone comma before "or 65528" is misplaced and suggest NEW: % lifetime values which are not divisible by 8. In such cases % the router SHOULD round the provided value up to the lesser % of the nearest integer divisible by 8 and 65528, and divide the % result by 8 (or just perform a logical right-shift by 3) and % set the Scaled Lifetime field to the resulting value. If such a non-zero lifetime value to be divided by 8 (to be subjected to a logical right-shift by 3) is less than 8 then the Scaled Lifetime field SHOULD by default be set to 1. I suggest to s/SHOULD by default/SHOULD/ Highest 96-bit unsigned integer. Contains bits 0 - 95 of the NAT64 96 bits prefix. of the prefix Am I supposed to zero-fill when the prefix length is less than 96 bits? Section 6 When multiple PREF64 were discovered via RA PREF64 Option (the Option presents more than once in a single RA or multiple RAs were received), host behaviour with regards to synthesizing IPv6 addresses from IPv4 addresses SHOULD follow the recommendations given in Section 3 of [RFC7050], limited to the NAT64 prefixes that have non- zero lifetime. This seems to have high overlap with a recommendation from Section 4; could/should the texts be consolidated? Section 7 Section 6.2.7 of [RFC4861] recommends that routers inspect RAs sent by other routers to ensure that all routers onlink advertise the consistent information. Routers SHOULD inspect valid PREF64 options nit: I think s/the consistent information/consistent information/ Section 9 I appreciate the discussion that RAs already need to be protected for normal opration, and that NAT64 prefix delivery, when bundled as an RA option, can take advantage of those mechanisms. Nonetheless, I think it would still be appropriate to mention (either inline or by reference) the scope of risk/breakage possible when an incorrect NAT64 prefix (or length) is used. |
2019-12-16
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-12-16
|
08 | Éric Vyncke | [Ballot comment] Jen, Lorenzo, Thank you for the work put into this short and clear document and let's hope for implementations. Answers/actions to my COMMENTs … [Ballot comment] Jen, Lorenzo, Thank you for the work put into this short and clear document and let's hope for implementations. Answers/actions to my COMMENTs below will be welcomed, even if those COMMENTs are not blocking. Regards, -éric == COMMENTS == -- Section 5 -- I find this "scaled lifetime" field overspecified with respect to the router vendor requirements (perhaps a bias of mine ;-)). Define MaxRtrAdvInterval as "MaxRtrAdvInterval" in RFC 4861 ? -- Section 6 -- The text "the host receives multiple RAs with different PREF64 prefixes on one or multiple interfaces" is not followed by any guidance on how to use PREF64 received on different interfaces. Perhaps worth mentioning here also PvD and requiring to use a PREF64 received on an interface (or PvD) only with interface/next hop/DNS of this interface (or PvD). |
2019-12-16
|
08 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-12-16
|
08 | Alexey Melnikov | [Ballot comment] I found this document to be well written, but I have one small comment: In Section 5: Lifetime seconds over which this … [Ballot comment] I found this document to be well written, but I have one small comment: In Section 5: Lifetime seconds over which this NAT64 prefix MAY be used. The value of the Scaled Lifetime field SHOULD by default be set to the lesser of 3 x MaxRtrAdvInterval divided by 8, or 8191. The receiver MUST multiply the Scaled Lifetime value by 8 (for example, by logical left shift) to calculate the maximum time in seconds the prefix MAY be used. Lifetime of 0 indicates that the prefix SHOULD NOT be used anymore. Router vendors SHOULD allow administrators to specify non-zero lifetime values which are not divisible by 8. In such cases the router SHOULD round the provided value up to the lesser of nearest integer divisible by 8, or 65528 and divide the result by 8 (or just perform a logical right-shift by 3) and set the Scaled Lifetime field to the resulting value. If such a non-zero lifetime value to be divided by 8 (to be subjected to a logical right-shift by 3) is less than 8 then the Scaled Lifetime field SHOULD by default be set to 1. I found this description to be unclear. You are first saying to round the value up, but then your last sentence looks like a special case, where it is not supposed to be according to my understanding of the meaning of "round up". I suggest this text needs more work. |
2019-12-16
|
08 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-12-12
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-12-11
|
08 | Suresh Krishnan | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-12-11
|
08 | Ines Robles | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Ines Robles. Sent review to list. |
2019-12-10
|
08 | Mirja Kühlewind | [Ballot comment] Minor comment/question: Section 6 discusses Handling of Multiple NAT64 Prefixes, however, it does not really discussion any consequences of using the "wrong" prefix. … [Ballot comment] Minor comment/question: Section 6 discusses Handling of Multiple NAT64 Prefixes, however, it does not really discussion any consequences of using the "wrong" prefix. Maybe you can say more about that...? |
2019-12-10
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-12-02
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2019-12-01
|
08 | Cindy Morgan | Placed on agenda for telechat - 2019-12-19 |
2019-11-29
|
08 | Suresh Krishnan | Ballot has been issued |
2019-11-29
|
08 | Suresh Krishnan | [Ballot Position Update] New position, Yes, has been recorded for Suresh Krishnan |
2019-11-29
|
08 | Suresh Krishnan | Created "Approve" ballot |
2019-11-29
|
08 | Suresh Krishnan | Ballot writeup was changed |
2019-11-27
|
08 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2019-11-27
|
08 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-08.txt |
2019-11-27
|
08 | (System) | New version accepted (logged-in submitter: Jen Linkova) |
2019-11-27
|
08 | Jen Linkova | Uploaded new revision |
2019-11-27
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-11-26
|
07 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ines Robles |
2019-11-26
|
07 | Min Ye | Request for Last Call review by RTGDIR is assigned to Ines Robles |
2019-11-26
|
07 | Min Ye | Assignment of request for Last Call review by RTGDIR to Jon Mitchell was marked no-response |
2019-11-25
|
07 | Zitao Wang | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Zitao Wang. Sent review to list. |
2019-11-18
|
07 | Min Ye | Request for Last Call review by RTGDIR is assigned to Jon Mitchell |
2019-11-18
|
07 | Min Ye | Request for Last Call review by RTGDIR is assigned to Jon Mitchell |
2019-11-18
|
07 | Min Ye | Assignment of request for Last Call review by RTGDIR to Victoria Pritchard was marked no-response |
2019-11-14
|
07 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2019-11-14
|
07 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-6man-ra-pref64-07. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-6man-ra-pref64-07. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that upon approval of this document, there is a single action to be completed. In the IPv6 Neighbor Discovery Option Formats registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at https://www.iana.org/assignments/icmpv6-parameters/ a single new registration will be made: Type: [ TBD ] Description: PREF64 option Reference: [ RFC-to-be ] 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, Amanda Baber Lead IANA Services Specialist |
2019-11-14
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
2019-11-14
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Zitao Wang |
2019-11-08
|
07 | Joel Halpern | Request for Last Call review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list. |
2019-11-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2019-11-08
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Joel Halpern |
2019-11-07
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2019-11-07
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Alan DeKok |
2019-11-06
|
07 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2019-11-06
|
07 | Min Ye | Request for Last Call review by RTGDIR is assigned to Victoria Pritchard |
2019-11-06
|
07 | Alvaro Retana | Requested Last Call review by RTGDIR |
2019-11-05
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-11-05
|
07 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-11-27): From: The IESG To: IETF-Announce CC: ipv6@ietf.org, bob.hinden@gmail.com, Bob Hinden , draft-ietf-6man-ra-pref64@ietf.org, … The following Last Call announcement was sent out (ends 2019-11-27): From: The IESG To: IETF-Announce CC: ipv6@ietf.org, bob.hinden@gmail.com, Bob Hinden , draft-ietf-6man-ra-pref64@ietf.org, suresh@kaloom.com, 6man-chairs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Discovering PREF64 in Router Advertisements) to Proposed Standard The IESG has received a request from the IPv6 Maintenance WG (6man) to consider the following document: - 'Discovering PREF64 in Router Advertisements' as 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 last-call@ietf.org mailing lists by 2019-11-27. 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 This document specifies a Neighbor Discovery option to be used in Router Advertisements to communicate NAT64 prefixes to hosts. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-11-05
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-11-04
|
07 | Suresh Krishnan | Last call was requested |
2019-11-04
|
07 | Suresh Krishnan | Ballot approval text was generated |
2019-11-04
|
07 | Suresh Krishnan | Ballot writeup was generated |
2019-11-04
|
07 | Suresh Krishnan | IESG state changed to Last Call Requested from AD Evaluation |
2019-11-04
|
07 | Suresh Krishnan | Last call announcement was changed |
2019-11-03
|
07 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-07.txt |
2019-11-03
|
07 | (System) | New version accepted (logged-in submitter: Jen Linkova) |
2019-11-03
|
07 | Jen Linkova | Uploaded new revision |
2019-10-25
|
06 | Suresh Krishnan | IESG state changed to AD Evaluation from Publication Requested |
2019-10-04
|
06 | Bob Hinden | Title : Discovering PREF64 in Router Advertisements Authors : Lorenzo Colitti … Title : Discovering PREF64 in Router Advertisements Authors : Lorenzo Colitti Jen Linkova Filename : draft-ietf-6man-ra-pref64-06.txt Pages : 10 Date : 2019-10-03 (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? Standards track RFC, Proposed Standard. It defining a new IPv6 router advertisement option, this is the correct status. It is noted in the header. (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. NAT64 [RFC6146] with DNS64 [RFC6147] is a widely-deployed mechanism to provide IPv4 access on IPv6-only networks. In various scenarios, the host must be aware of the NAT64 prefix in use by the network. This document specifies a Router Advertisement [RFC4861] option to communicate the NAT64 prefix to hosts. 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? This document had good w.g. review, was discussed at several face to face 6man sessions and on the list. The chairs also did individual reviews. These reviews resulted in a simplified version of the RA options that is defined in this draft. 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? No known implementations. Issues raised in reviews have been resolved in current draft. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Bob Hinden Area Director: 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. Document Shepard did a review of the document that raised a few issues such as old text that hadn't been removed and a number of editorial changes. These issue have been fixed in the current draft. Document is ready to advance. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. No. The document is creating a new RA option. (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. No issues to raise. (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? Both authors has confirmed this. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures. (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? Strong w.g. consensus. (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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No IDnits errors or warnings. Summary is: Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? All normative references are RFCs. (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. No. (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. No changes to other RFCs. (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 8126). IANA registries are clearly identified and what IANA is being asked to do is clear and appropriate. (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. No new IANA registries are created. (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. N/A |
2019-10-04
|
06 | Bob Hinden | Responsible AD changed to Suresh Krishnan |
2019-10-04
|
06 | Bob Hinden | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-10-04
|
06 | Bob Hinden | IESG state changed to Publication Requested from I-D Exists |
2019-10-04
|
06 | Bob Hinden | IESG process started in state Publication Requested |
2019-10-04
|
06 | Bob Hinden | Changed consensus to Yes from Unknown |
2019-10-04
|
06 | Bob Hinden | Intended Status changed to Proposed Standard from None |
2019-10-04
|
06 | Bob Hinden | Title : Discovering PREF64 in Router Advertisements Authors : Lorenzo Colitti … Title : Discovering PREF64 in Router Advertisements Authors : Lorenzo Colitti Jen Linkova Filename : draft-ietf-6man-ra-pref64-06.txt Pages : 10 Date : 2019-10-03 (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? Standards track RFC, Proposed Standard. It defining a new IPv6 router advertisement option, this is the correct status. It is noted in the header. (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. NAT64 [RFC6146] with DNS64 [RFC6147] is a widely-deployed mechanism to provide IPv4 access on IPv6-only networks. In various scenarios, the host must be aware of the NAT64 prefix in use by the network. This document specifies a Router Advertisement [RFC4861] option to communicate the NAT64 prefix to hosts. 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? This document had good w.g. review, was discussed at several face to face 6man sessions and on the list. The chairs also did individual reviews. These reviews resulted in a simplified version of the RA options that is defined in this draft. 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? No known implementations. Issues raised in reviews have been resolved in current draft. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Bob Hinden Area Director: 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. Document Shepard did a review of the document that raised a few issues such as old text that hadn't been removed and a number of editorial changes. These issue have been fixed in the current draft. Document is ready to advance. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (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. No. The document is creating a new RA option. (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. No issues to raise. (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? Both authors has confirmed this. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures. (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? Strong w.g. consensus. (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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No IDnits errors or warnings. Summary is: Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? All normative references are RFCs. (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. No. (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. No changes to other RFCs. (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 8126). IANA registries are clearly identified and what IANA is being asked to do is clear and appropriate. (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. No new IANA registries are created. (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. N/A |
2019-10-03
|
06 | Bob Hinden | Notification list changed to Bob Hinden <bob.hinden@gmail.com> |
2019-10-03
|
06 | Bob Hinden | Document shepherd changed to Bob Hinden |
2019-10-03
|
06 | Bob Hinden | Tag Revised I-D Needed - Issue raised by WG cleared. |
2019-10-03
|
06 | Bob Hinden | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2019-10-03
|
06 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-06.txt |
2019-10-03
|
06 | (System) | New version approved |
2019-10-03
|
06 | (System) | Request for posting confirmation emailed to previous authors: Lorenzo Colitti , Jen Linkova |
2019-10-03
|
06 | Jen Linkova | Uploaded new revision |
2019-09-30
|
05 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-05.txt |
2019-09-30
|
05 | (System) | New version approved |
2019-09-30
|
05 | (System) | Request for posting confirmation emailed to previous authors: Lorenzo Colitti , Jen Linkova |
2019-09-30
|
05 | Jen Linkova | Uploaded new revision |
2019-09-05
|
04 | Ole Trøan | Tag Revised I-D Needed - Issue raised by WG set. |
2019-08-11
|
04 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-04.txt |
2019-08-11
|
04 | (System) | New version approved |
2019-08-11
|
04 | (System) | Request for posting confirmation emailed to previous authors: Lorenzo Colitti , Jen Linkova |
2019-08-11
|
04 | Jen Linkova | Uploaded new revision |
2019-07-25
|
03 | Ole Trøan | IETF WG state changed to In WG Last Call from WG Document |
2019-07-25
|
03 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-03.txt |
2019-07-25
|
03 | (System) | New version approved |
2019-07-25
|
03 | (System) | Request for posting confirmation emailed to previous authors: Lorenzo Colitti , Jen Linkova |
2019-07-25
|
03 | Jen Linkova | Uploaded new revision |
2019-07-23
|
02 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-02.txt |
2019-07-23
|
02 | (System) | New version approved |
2019-07-23
|
02 | (System) | Request for posting confirmation emailed to previous authors: Lorenzo Colitti , Jen Linkova |
2019-07-23
|
02 | Jen Linkova | Uploaded new revision |
2019-06-28
|
01 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-01.txt |
2019-06-28
|
01 | (System) | New version approved |
2019-06-28
|
01 | (System) | Request for posting confirmation emailed to previous authors: Erik Kline , Lorenzo Colitti , Jen Linkova , 6man-chairs@ietf.org |
2019-06-28
|
01 | Jen Linkova | Uploaded new revision |
2019-03-25
|
00 | Ole Trøan | This document now replaces draft-pref64folks-6man-ra-pref64 instead of None |
2019-03-24
|
00 | Jen Linkova | New version available: draft-ietf-6man-ra-pref64-00.txt |
2019-03-24
|
00 | (System) | WG -00 approved |
2019-03-24
|
00 | Jen Linkova | Set submitter to "Jen Linkova ", replaces to (none) and sent approval email to group chairs: 6man-chairs@ietf.org |
2019-03-24
|
00 | Jen Linkova | Uploaded new revision |