Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
draft-ietf-behave-nat64-discovery-heuristic-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2013-11-04
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2013-10-17
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2013-10-08
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2013-10-08
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from IANA |
2013-10-08
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2013-10-04
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-06-10
|
17 | (System) | IANA Action state changed to In Progress from On Hold |
2013-06-10
|
17 | (System) | IANA Action state changed to In Progress from On Hold |
2013-06-04
|
17 | (System) | RFC Editor state changed to IANA from EDIT |
2013-05-31
|
17 | (System) | IANA Action state changed to On Hold from In Progress |
2013-05-31
|
17 | (System) | IANA Action state changed to In Progress from Waiting on ADs |
2013-05-29
|
17 | (System) | IANA Action state changed to Waiting on ADs from Waiting on Authors |
2013-05-29
|
17 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2013-05-21
|
17 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2013-05-21
|
17 | (System) | RFC Editor state changed to EDIT |
2013-05-21
|
17 | (System) | Announcement was received by RFC Editor |
2013-05-21
|
17 | (System) | IANA Action state changed to In Progress |
2013-05-20
|
17 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2013-05-20
|
17 | Amy Vezza | IESG has approved the document |
2013-05-20
|
17 | Amy Vezza | Closed "Approve" ballot |
2013-05-17
|
17 | Amy Vezza | Ballot approval text was generated |
2013-05-17
|
17 | Amy Vezza | Ballot writeup was changed |
2013-05-17
|
17 | Amy Vezza | Ballot writeup was changed |
2013-05-17
|
17 | Martin Stiemerling | State changed to Approved-announcement to be sent from IESG Evaluation::External Party |
2013-04-12
|
17 | Martin Stiemerling | waiting for IANA's feedback. |
2013-04-12
|
17 | Martin Stiemerling | State changed to IESG Evaluation::External Party from IESG Evaluation::AD Followup |
2013-04-04
|
17 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-17.txt |
2013-03-13
|
16 | Cindy Morgan | Shepherding AD changed to Martin Stiemerling |
2013-03-13
|
16 | Martin Stiemerling | [Ballot Position Update] Position for Martin Stiemerling has been changed to Yes from No Objection |
2013-03-12
|
16 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-16.txt |
2013-03-10
|
15 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-15.txt |
2013-03-07
|
14 | Ralph Droms | [Ballot comment] Thanks for adding text regarding registration of special use domain names. |
2013-03-07
|
14 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss |
2013-02-28
|
14 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2013-02-25
|
14 | Stephen Farrell | [Ballot comment] - 3.1.2, step 2: I thought walking the DNS tree like this was frowned upon. I'd be interested in knowing why its ok … [Ballot comment] - 3.1.2, step 2: I thought walking the DNS tree like this was frowned upon. I'd be interested in knowing why its ok in this case to chase CNAME/DNAME but not in other cases. (I'm not objecting, just trying to understand.) - 3.2, "hoping the problem is temporary"? That seems odd. Is it really desirable? - IANA stuff - given that we're moving the special purpose address registries from RFCs to be IANA-only, do any of the allocation requests here need to change? (Or, when do we stop referring to 5735 & 5736 and start referring to the new IANA registry?) |
2013-02-25
|
14 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2013-02-25
|
14 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2013-02-25
|
14 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-14.txt |
2013-02-21
|
13 | Wesley Eddy | State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead |
2013-02-21
|
13 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2013-02-21
|
13 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2013-02-20
|
13 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2013-02-20
|
13 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2013-02-20
|
13 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2013-02-19
|
13 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo |
2013-02-19
|
13 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2013-02-19
|
13 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2013-02-19
|
13 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant |
2013-02-19
|
13 | Ralph Droms | [Ballot discuss] draft-cheshire-dnsext-special-names is currently ready for publication (part of cluster C83). That document defines a template for registration of special use domain names such … [Ballot discuss] draft-cheshire-dnsext-special-names is currently ready for publication (part of cluster C83). That document defines a template for registration of special use domain names such as "ipv4only.arpa" (or whatever name is eventually assigned for this purpose). The IANA considerations section of draft-ietf-behave-nat64-discovery-heuristic should be revised to provide the information required in the template in section 5 of draft-cheshire-dnsext-special-names. Andrew Sullivan has graciously supplied draft text: 1. No, although this is a name in .arpa and therefore is sort of already marked as special. 2. Yes. Any application attempting to perform NAT64 discovery will query the name. 3. Yes, to the extent the API or library is affected by NAT64. 4. No. 5. No. 6. This name has effects for operators of NAT64/DNS64, but otherwise is just another .arpa name. 7. The registry for .arpa is held at IANA, and only IANA needs to take action here. |
2013-02-19
|
13 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded for Ralph Droms |
2013-02-18
|
13 | Russ Housley | [Ballot discuss] This DISCUSS position builds on comments from the Gen-ART Review by Brian Carpenter on 15-Feb-2013. (1) This document says: … [Ballot discuss] This DISCUSS position builds on comments from the Gen-ART Review by Brian Carpenter on 15-Feb-2013. (1) This document says: "A day will come when this tool is no longer needed. At that point the best suited techniques for implementing an exit strategy will be documented." I hope that day comes, and comes soon. That said, the second sentence really does not tell an implementer anything. Why is any strategy other than an "off" switch required? The answer to that question may help an implementer decide what to include in their code. If there are no more IPv4-only services, there will be (observably) no traffic in the NAT64 box. (2) The IANA Considerations in this document says: "The well-known domain name could be, for example, "ipv4only.arpa"." If this is an example, then you cannot refer to it unconditionally earlier in the document. Please make an explicit request to IANA for this exact name. Otherwise, you need to replace all occurrences of ipv4only.arpa by FQDN-TBD and have the RFC Editor insert the IANA-assigned FQDN. (3) The same thing applies to 192.0.0.170 and 192.0.0.171. Either they need to be IP-ADDR-TBD1 and IP-ADDR-TBD2 in the text, or you need an explicit request to IANA. (4) Who populates the DNS with the RRs for ipv4only.arpa? That responsibility needs to be defined. |
2013-02-18
|
13 | Russ Housley | [Ballot comment] The Gen-ART Review by Brian Carpenter on 15-Feb-2013 raises this issue. I have taken the crux of Brian's comment and added … [Ballot comment] The Gen-ART Review by Brian Carpenter on 15-Feb-2013 raises this issue. I have taken the crux of Brian's comment and added by thoughts to it. I do not consider the comment blocking, but I would like the authors to consider it. This document definitely cannot be understood by anyone who has not first understood the NAT64 and DNS64 documents. It might be useful to state this explicitly in the first paragraph. |
2013-02-18
|
13 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley |
2013-02-18
|
13 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2013-02-18
|
13 | Stephen Farrell | [Ballot discuss] I think this is generally ok, but I have two questions to discuss before it goes ahead: (1) 3.1, 3.1.2 and section 7: … [Ballot discuss] I think this is generally ok, but I have two questions to discuss before it goes ahead: (1) 3.1, 3.1.2 and section 7: what "secure channel" do you mean? Where is that specified? Why is it ok to leave this to folklore? In the DANE protocol [1] we added a paragraph that said: "This document does not specify how DNSSEC validation occurs because there are many different proposals for how a client might get validated DNSSEC results, such as from a DNSSEC-aware resolver that is coded in the application, from a trusted DNSSEC resolver on the machine on which the application is running, or from a trusted DNSSEC resolver with which the application is communicating over an authenticated and integrity-protected channel or network. This is described in more detail in Section 7 of [RFC4033]." Would something like that work here? While it is a bit weasel-wordy, I think its better than being as vague as the current draft on this aspect. [1] http://tools.ietf.org/html/rfc6698#section-1.3 (2) 3.1.2, step 3: I can't envisage any sensible way in which the node could query the user. If there is such a way, then I think you really ought describe that (non-normatively) here (or in an appendix) since in the case of web and email PKIs, developers have so far always failed to ask correct and understandable questions of users and that has generated bad user behaviour (to just click on "ok" when asked a stupid question). If nobody can think of a sensible way to query the user, then the MAY here has got to be wrong but since you put it in, I assume you do have ideas for what to ask so this should be easily sorted. |
2013-02-18
|
13 | Stephen Farrell | [Ballot comment] - 3.1.2, step 2: I thought walking the DNS tree like this was frowned upon. I'd be interested in knowing why its ok … [Ballot comment] - 3.1.2, step 2: I thought walking the DNS tree like this was frowned upon. I'd be interested in knowing why its ok in this case to chase CNAME/DNAME but not in other cases. (I'm not objecting, just trying to understand.) - 3.2, "hoping the problem is temporary"? That seems odd. Is it really desirable? - IANA stuff - given that we're moving the special purpose address registries from RFCs to be IANA-only, do any of the allocation requests here need to change? (Or, when do we stop referring to 5735 & 5736 and start referring to the new IANA registry?) |
2013-02-18
|
13 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2013-02-18
|
13 | Wesley Eddy | Ballot has been issued |
2013-02-18
|
13 | Wesley Eddy | [Ballot Position Update] New position, Yes, has been recorded for Wesley Eddy |
2013-02-18
|
13 | Wesley Eddy | Created "Approve" ballot |
2013-02-18
|
13 | Wesley Eddy | Ballot writeup was changed |
2013-02-15
|
13 | Brian Carpenter | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Brian Carpenter. |
2013-02-14
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2013-02-14
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2013-02-05
|
13 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2013-02-01
|
13 | Pearl Liang | IANA has reviewed draft-ietf-behave-nat64-discovery-heuristic-13 and has the following comments: We have questions about some of the actions requested in this document The authors request: "According … IANA has reviewed draft-ietf-behave-nat64-discovery-heuristic-13 and has the following comments: We have questions about some of the actions requested in this document The authors request: "According to procedures described in [RFC3172] this document directs IANA to reserve a second level domain from the .ARPA zone for the well-known domain name. The well-known domain name could be, for example, "ipv4only.arpa". Question -> any addition to .arpa requires IAB approval. The document should have an IAB Considerations section. Also, we wonder what is to be done with the second level name? Will there be any maintenance within the second-level name for the IANA Department? Next, the authors request: "The well-known name needs to map to two different global IPv4 addresses. The addresses are to be taken from the IANA IPv4 Special Purpose Address Registry [RFC5736], from the 192.0.0.0/24 address block, and can be, for example, 192.0.0.170 and 192.0.0.171. The addresses are to be documented to be of global scope, but they do not need to be routable within local or global scopes." Questions and comments -> The IP addresses can be provided, but the authors should provide all the details specified in RFC 5736 or draft-bonica-special-purpose if that has been approved before this goes to the IESG (and presumably IAB). The text in the document suggests that no servers should be operated on those addresses (Sec 3.2.1), so we suspect that routing scope should be "NOT ROUTED" - the authors should clarify this. While the authors have used the word domain, we wonder if the authors really wanted to use the term label, but left domain there for some wriggle room. For instance, do the authors intend that the following added to .ARPA? ipv4only IN A 192.0.0.170 ipv4only IN A 192.0.0.171 We note that .arpa is already signed. We wonder if an A record only label (minus DNSSEC bits) under .ARPA satisfy the authors AND will the IAB allow a non-delegation record in ARPA that isn't glue. These will need to be clarified by the authors. If a domain must be delegated then questions arise (at the IANA department) as to the NS RR set (and operators) for that zone. Do the authors intend that ICANN/IANA alone run those name servers? These clarifications are required to better understand the authors' intent in the IANA Considerations section and in the requests for deliverables in other sections of the current document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. |
2013-01-25
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2013-01-25
|
13 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Carl Wallace |
2013-01-24
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2013-01-24
|
13 | Jean Mahoney | Request for Last Call review by GENART is assigned to Brian Carpenter |
2013-01-22
|
13 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Discovery of the IPv6 Prefix Used … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis) to Proposed Standard The IESG has received a request from the Behavior Engineering for Hindrance Avoidance WG (behave) to consider the following document: - 'Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis' 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 ietf@ietf.org mailing lists by 2013-02-05. 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 describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-behave-nat64-discovery-heuristic/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1795/ |
2013-01-22
|
13 | Amy Vezza | State changed to In Last Call from Last Call Requested |
2013-01-22
|
13 | Amy Vezza | Last call announcement was changed |
2013-01-21
|
13 | Wesley Eddy | Placed on agenda for telechat - 2013-02-21 |
2013-01-21
|
13 | Wesley Eddy | Last call was requested |
2013-01-21
|
13 | Wesley Eddy | Last call announcement was generated |
2013-01-21
|
13 | Wesley Eddy | Ballot approval text was generated |
2013-01-21
|
13 | Wesley Eddy | Ballot writeup was generated |
2013-01-21
|
13 | Wesley Eddy | State changed to Last Call Requested from AD Evaluation |
2013-01-03
|
13 | Wesley Eddy | State changed to AD Evaluation from Publication Requested |
2012-12-21
|
13 | Cindy Morgan | (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? … (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, as indicated in the title page header. This is a specification of behavior. The WG charter says "Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std)", and the WG has consensus on this. (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 document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only domain name "ipv4only.arpa". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. 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? The document specifies a heuristic that is not perfect and so some points were rough, but the constraint for this document was to operate without changes to code (only configuration) in existing networks. Given that constraint, there was strong consensus. Relaxing the constraint would allow one to do better, and that is the focus of a draft recently submitted to the PCP WG. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Jouni Korhonen did a prototype implementation that was presented in the WG but not included in commercial product. Additionally, Cameron Byrne (T-Mobile USA) has a 464XLAT implementation that also implements this draft, as noted at https://sites.google.com/site/tmoipv6/464xlat#TOC-Android-CLAT-on-a-UMTS-IPv6-only-network-with-DNS64-NAT64 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? Andrew Sullivan reviewed the document from a DNS expert point of view and a number of changes were made accordingly. Also note that this specification is informatively referenced by draft-ietf-v6ops-464xlat which is currently in IETF Last Call. Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Dave Thaler (dthaler@microsoft.com) Responsible Area Director: Wes Eddy (wes@mti-systems.com) (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. There were two WGLCs on the document. The WG policy is to only forward if at least 5 "ok"s were given and all issues by the WG raised had consensus. The Document Shepherd: a) Verified that policy was met. Everyone who responded during the 1st WGLC ok'ed the second one, and all new issues were addressed. The document was ok'ed by: Teemu Savolainen [author] Jouni Korhonen [author] Dan Wing [author] Dave Thaler [document shepherd] Cameron Byrne Aaron Yi DING MAWATARI Masataka Stephan Lagerholm Andrew Sullivan Simon Perreault b) Did own review of the document c) Checked idnits (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 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. DNS review was performed (Andrew Sullivan and Mark Andrews had significant comments). Operational review was done by Cameron Byrne and others. OS implementability review was done by Dave Thaler as well as the implementers of the prototypes mentioned under Document Quality above. (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 specific concerns (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? Yes (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. http://datatracker.ietf.org/ipr/1442/ was made on November 3, 2010 when this draft was still an individual submission at revision-00 (draft-savolainen-heuristic-nat64-discovery-00). The WG later chose to adopt the document, and http://datatracker.ietf.org/ipr/1795/ (with FRAND terms) was re-announced to the Behave WG list on June 6, 2012 (http://www.ietf.org/mail-archive/web/behave/current/msg10415.html), just after the beginning of the first WGLC. No issues were raised as a result during either that WGLC or the 2nd WGLC. (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? The WG as a whole understands and agrees with it. Many people commented during the two WGLCs. (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 one threatened an appeal. (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. == There are 6 instances of lines with non-RFC5735-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Above is intentional. This document defines the use of two addresses from the IANA IPv4 Special Purpose Address Registry [RFC5736]. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Above is intentional. This document references the Well-Known IPv6 Prefix defined in RFC 6052. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No relevant formal review criteria. (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 references are to existing 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 change to status of any existing 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 5226). No new registries are created. This document allocates values in two existing registries: 1) Two addresses in the IANA IPv4 Special Purpose Address Registry [RFC5736] 2) A label in the .ARPA zone owned by the IETF. (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 registries. (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. No XML, BNF, or MIB definitions exist so no automated checks were done. Jouni Korhonen verified the sample BIND-style DNS configuration in Appendix A in his setup, using his prefixes. |
2012-12-21
|
13 | Cindy Morgan | Note added 'Document Shepherd: Dave Thaler (dthaler@microsoft.com)' |
2012-12-21
|
13 | Cindy Morgan | Intended Status changed to Proposed Standard |
2012-12-21
|
13 | Cindy Morgan | IESG process started in state Publication Requested |
2012-12-21
|
13 | (System) | Earlier history may be found in the Comment Log for draft-savolainen-heuristic-nat64-discovery |
2012-11-26
|
13 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-13.txt |
2012-11-05
|
12 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-12.txt |
2012-07-30
|
11 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-11.txt |
2012-06-29
|
10 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-10.txt |
2012-06-05
|
(System) | Posted related IPR disclosure: Nokia Corporation's Statement about IPR related to draft-ietf-behave-nat64-discovery-heuristic-09 | |
2012-05-24
|
09 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-09.txt |
2012-05-14
|
08 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-08.txt |
2012-03-13
|
07 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-07.txt |
2012-03-12
|
06 | Teemu Savolainen | New version available: draft-ietf-behave-nat64-discovery-heuristic-06.txt |
2012-01-25
|
05 | (System) | New version available: draft-ietf-behave-nat64-discovery-heuristic-05.txt |
2011-12-20
|
04 | (System) | New version available: draft-ietf-behave-nat64-discovery-heuristic-04.txt |
2011-10-14
|
03 | (System) | New version available: draft-ietf-behave-nat64-discovery-heuristic-03.txt |
2011-07-10
|
02 | (System) | New version available: draft-ietf-behave-nat64-discovery-heuristic-02.txt |
2011-06-20
|
01 | (System) | New version available: draft-ietf-behave-nat64-discovery-heuristic-01.txt |
2011-05-25
|
00 | (System) | New version available: draft-ietf-behave-nat64-discovery-heuristic-00.txt |