Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis
draft-ietf-behave-nat64-discovery-heuristic-17

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

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

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

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

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

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

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.

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/

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