Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)
draft-ietf-behave-v4v6-bih-09

[Ballot discuss]
-08 is nearly there, though I didn't see any mail (quicker to
resolve stuff that way usually), just a new I-D again.

Anyway, thanks for adding the definitions, but I think one
more change is needed: I think you need to remove the
sentence that the "Real IPv4 address is opposite to synthetic
IPv4 address." That just adds confusion since its not really
the case.

[Ballot discuss]
-08 is nearly there, though I didn't see any mail (quicker to
resolve stuff that way usually), just a new I-D again.

Anyway, thanks for adding the definitions, but I think one
more change is needed: I think you need to remove the
sentence that the "Real IPv4 address is opposite to synthetic
IPv4 address." That just adds confusion since its not really
the case.

I also note that you've added a RECOMMENDED (for the
socket API) and a timeout of 300ms that were not in the
previous version. Are those really changes or is it just
the diff tool making it appear as such? If those are real
changes, did the WG and AD agree with them? (Its
very late in the process for substantive changes like
that to be made.)

State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup.
draft-ietf-behave-v4v6-bih-07 continues to use the term "real"
address, without defining what a "real" address is. If you insist on
using the term, then please provide a definition for it.

There are a number of comments from the IESG. These SHOULD be
addressed.

In section 8, can you use sentences rather than just phrases, to
explain the chnages a bit more than the current text does?

You refer to rfc1918 addresses as private addresses. I think there may
be more than one range of addresses that could be considered private;
can you change from using private to using rfc1918 addresses to be
more specific where appropriate?

[Ballot comment]
- The term "DNS synthesis" is used but not defined here. It
might be worth explaining. I see you've made a change there
but am not sure that's made it super clear.

[Ballot discuss]
Part of my discuss on -06 said:

"- 2.3 says "If there is a real IPv4 address available..." but doesn't
say what is meant by "real" nor "available"- is it that an A record
was returned with a non-1918 address that is contactable or what?
Note - I'm not asking for any particular definition, just that
these terms be well-defined here."

Can you explain (in a mail) how the changes made in -07 address
this point and Pete Resnick's related comment?

Its just not quite clear to me, I'm not saying that the changes don't
address the issue.

[Ballot comment]
2.3 - I agree with Stephen's DISCUSS: MUST the ENR wait for an explicit negative response on the A record lookup, or can it synthesize from the AAAA in other circumstances? Probably best to explicitly say so. I guess I'd like to hear specifically what "only IPv6 addresses are available" means.

State changed to IESG Evaluation::Revised ID Needed from Waiting for AD Go-Ahead.
to handle the editorial comments from the IESG and the Gen-ART review.

To handle the creation of an IANA registry for MPA codes and error codes.

[Ballot discuss]
Does this document deliberately avoide the IPR disclosed in RFC 2767?
If not, have the people who disclosed IPR in 2767 been invited to comment on whether they have IPR in this document (for example, through a third party declaration or by email)?

[Ballot comment]
Thanks to the authors for a well-written, easily understandable document.

Assuming that this recommendation in section 2.3 (which I think appears elsewhere; e.g., in section 2.3.2) is a general recommendation:

  Hence the socket API layer option is RECOMMENDED.

it might be helpful to emphasize the recommendation by repeating it somewhere up front in the Introduction.

In section 2.3.4, why would availability of an IPv4 interface case BIH to shut down?

[Ballot comment]
The Gen-ART Review by  Wassim Haddad on 3-October-2011 raised this
  concern, and it needs to be resolved.

  Please clarify the connection to the two obsoleted (RFCs 2767 & 3338).
  - The document states that it "obsoletes" them in the title page
    header and the abstract.
  - The document states that it "updates" them in the Introduction.
  - The document says that it is a "direct update to and directly
    derivative" from them in section 1.1.
  - The document says that it "combines and obsoletes" them in
    section 8.
  Please be clear that this document draws from the material in these
  RFCs, and that it obsoletes them.

[Ballot comment]
- The term "DNS synthesis" is used but not defined here. It
might be worth explaining.

- 2.2, end of 1st para has a lowercase "should" - is that meant
to be a 2119 SHOULD or not?

- 7.3 refers to "port translation" but I didn't see any discussion
of ports here - is the text there correct?

[Ballot discuss]
- 2.3 says "If there is a real IPv4 address available..." but doesn't
say what is meant by "real" nor "available"- is it that an A record
was returned with a non-1918 address that is contactable or what?
Note - I'm not asking for any particular definition, just that
these terms be well-defined here.

- 2.3.2 says the "main resolver of a host running BIH SHOULD NOT
perform validation of A records" - I think you don't mean that
that resolver should never validate A records (e.g. while BIH is
not running) so clarifying that might be good e.g. by saying
"While running BIH, the main resolver of the host SHOULD NOT
perform validation of A records. While not running BIH, that
resolver can use DNSSEC in the same way that any other resolver
can." or something like that.

- 2.4 refers to section 4.3 for private addresses to use - shouldn't
that be referring to section 4.4?

[Ballot comment]
The abstract states that this document obsoletes RFC 2767 and RFC 3338. The introduction states that this document updates those RFCs. I think the introduction might need to be changed.

Given that RFC 2767 was informational and RFC 3338 was experimental, it might be helpful to summarize the results of the experiment (e.g., implementation and deployment experience).

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Dual Stack Hosts Using "Bump-in-the-Host" (BIH)) to Proposed Standard


The IESG has received a request from the Behavior Engineering for
Hindrance Avoidance WG (behave) to consider the following document:
- 'Dual Stack Hosts Using "Bump-in-the-Host" (BIH)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-09-14. 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


  Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
  translation mechanism that allows a class of IPv4-only applications
  that work through NATs to communicate with IPv6-only peers.  The host
  on which applications are running may be connected to IPv6-only or
  dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
  applications think they are talking with IPv4 peers by local
  synthesis of IPv4 addresses.  This draft obsoletes RFC 2767 and RFC
  3338.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-behave-v4v6-bih/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from Publication Requested.
AD review of draft-ietf-behave-v4v6-bih-05

The abstract or section 1.1 should explain WHY a successor is needed.

2.1 refers to Appendix B; there is no appendix B.

Typically appendices are used for non-normative content, but this appendix lists functions that MUST be intercepted (according to 2.1). This would probably be better placed in the main part of the document.

2.1 says the APIs MUST be intercepted; the Appendix says they SHOULD be intercepted. Which is it?

2.2 says "Protocol translation SHOULD NOT be performed for IPv4 packets sent to the IPv4 address range used by local synthesis and for which a mapping table entry does not exist. The implementation SHOULD attempt to route such packets via IPv4 interfaces instead." Why should and not MUST? Is should, what ar ethe valid exceptions to the recommended practice?

2.3 "returns a proper answer" => returns an answer

2.3 RECOMMENDS the socket API layer option. When is it approrpiate to use the other option?

in 2.3 "In either implementation option, if there is a real IPv4 address available, the ENR SHOULD NOT synthesize IPv4 addresses. By default an ENR implementation MUST NOT synthesize IPv4 addresses when real IPv4 addresses exist." Why only should not? What is the valid exception to a MUST NOT? (is this discussed elsewhere in the document?)

2.3.1 what is a martian address? reference?

overuse of "essentially"; this is typicallty not needed where it is used. "essentially the same" => similar

in 2.3.2 "The ENR can support DNSSEC as any resolver on a host." I don't understand this sentence.

in 2.3.2, the main resolver MUST use the CD bit; what are the operational implications of doing this?

in 2.3.2, are DNS questions the same as DNS queries?

in 2.3.2, I don't like the wording in "In order to properly support DNSSEC, the ENR SHOULD be implemented at the socket API level. If the socket API level implementation is not possible, DNSSEC support SHOULD be provided by other means." Properly support is not a technical phrase;  do you mean to be compliant to dnssec? Do you mean to secure the DNS environment? 

If the socket API is not implemented, why isn't DNSSEC support MUST be provided by other means? If an implementation does not provide dnssec support by other means, then what happens to the security properties of the trusted environment? would not doing this create a vulnerability?

in 4.4, why is the primary address space /30, whereas the other address spaces are /20s?

in 7, "The security considerations of BIH mostly relies on that of [RFC6146]." Do you mean "the security considerations found in 6146 apply, with the following additional considerations specific to BIH"?

in 7, it says "the differences are due to ..." - the differences between what and what? Do you mean between 6146 and this document? If so, simply discuss the considerations for this document. Doing this as a comparison to the other document is a bit confusing, and would really require the reader to have both documents open and to do a diff to understand your text.

s/In the socket-layer implementation approach, the differences are due to the address translation occurring at the API and not in the network layer. That is, since the mechanism/When the implementation/

in 7, "So BIH should employ the same sort of protection techniques as NAT64 [RFC6146] does." I am not sure which protections you refer to here. I think it would be better to point to specific relevant solutions in 6146. The only mention of denial of service is in section 1.2.3. Is that the protection you mean?

in 9, s/The author thanks/The authors thank/

AD review of draft-ietf-behave-v4v6-bih-05

The abstract or section 1.1 should explain WHY a successor is needed.

2.1 refers to Appendix B; there is no appendix B.

Typically appendices are used for non-normative content, but this appendix lists functions that MUST be intercepted (according to 2.1). This would probably be better placed in the main part of the document.

2.1 says the APIs MUST be intercepted; the Appendix says they SHOULD be intercepted. Which is it?

2.2 says "Protocol translation SHOULD NOT be performed for IPv4 packets sent to the IPv4 address range used by local synthesis and for which a mapping table entry does not exist. The implementation SHOULD attempt to route such packets via IPv4 interfaces instead." Why should and not MUST? Is should, what ar ethe valid exceptions to the recommended practice?

2.3 "returns a proper answer" => returns an answer

2.3 RECOMMENDS the socket API layer option. When is it approrpiate to use the other option?

in 2.3 "In either implementation option, if there is a real IPv4 address available, the ENR SHOULD NOT synthesize IPv4 addresses. By default an ENR implementation MUST NOT synthesize IPv4 addresses when real IPv4 addresses exist." Why only should not? What is the valid exception to a MUST NOT? (is this discussed elsewhere in the document?)

2.3.1 what is a martian address? reference?

overuse of "essentially"; this is typicallty not needed where it is used. "essentially the same" => similar

in 2.3.2 "The ENR can support DNSSEC as any resolver on a host." I don't understand this sentence.

in 2.3.2, the main resolver MUST use the CD bit; what are the operational implications of doing this?

in 2.3.2, are DNS questions the same as DNS queries?

in 2.3.2, I don't like the wording in "In order to properly support DNSSEC, the ENR SHOULD be implemented at the socket API level. If the socket API level implementation is not possible, DNSSEC support SHOULD be provided by other means." Properly support is not a technical phrase;  do you mean to be compliant to dnssec? Do you mean to secure the DNS environment? 

If the socket API is not implemented, why isn't DNSSEC support MUST be provided by other means? If an implementation does not provide dnssec support by other means, then what happens to the security properties of the trusted environment? would not doing this create a vulnerability?

in 4.4, why is the primary address space /30, whereas the other address spaces are /20s?

in 7, "The security considerations of BIH mostly relies on that of [RFC6146]." Do you mean "the security considerations found in 6146 apply, with the following additional considerations specific to BIH"?

in 7, it says "the differences are due to ..." - the differences between what and what? Do you mean between 6146 and this document? If so, simply discuss the considerations for this document. Doing this as a comparison to the other document is a bit confusing, and would really require the reader to have both documents open and to do a diff to understand your text.

s/In the socket-layer implementation approach, the differences are due to the address translation occurring at the API and not in the network layer. That is, since the mechanism/When the implementation/

in 7, "So BIH should employ the same sort of protection techniques as NAT64 [RFC6146] does." I am not sure which protections you refer to here. I think it would be better to point to specific relevant solutions in 6146. The only mention of denial of service is in section 1.2.3. Is that the protection you mean?

in 9, s/The author thanks/The authors thank/

  (1.a) Who is the Document Shepherd for this document?

Dave Thaler

        Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Yes.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

No concerns.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns.  (DNSSEC impact was evaluated by DNS folks as with DNS64.
The recommended option is compatible with DNSSEC.  The not-recommended
option has the same issues as DNS64 implemented in a host.)

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.

        Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No IPR disclosures have been filed specifically on this document.
However this document incorporates and obsoletes RFC 2767 and RFC 3338,
which are alternative ways to solve the same scenario.

While RFC 3338 has no IPR disclosures filed, RFC 2767 does:
  https://datatracker.ietf.org/ipr/903/
Since the present document incorporates the ideas from RFC 2767,
one might expect a similar disclosure to be filed in the future.

The present document does not, however, mandate (or even recommend)
the RFC 2767-like implementation option.  In fact, for the name
synthesis part, it recommends the other option, and for the data
translation portion, no recommendation is made either way.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The WG as a whole understands the document.  It represents the
strong concurrence of the main proponents of the document, with
others having no objections.  The primary point of earlier contention
was with respect to whether this NAT46-in-a-host could be placed behind
a NAT64 and achieve NAT464.  The WG consensus was that that case
should be disallowed, and the present document reflects that
consensus.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough.

Yes (all uses of special-use IPv4 addresses such as loopback and
RFC 1918 addresses are intentional, so those warnings should be ignored).

        Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

No such reviews are needed.

  (1.h) Has the document split its references into normative and
        informative?

Yes.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

No downward references.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

IANA section exists and there are no actions for IANA.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

No such sections exist.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

  Technical Summary
        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.

Bump-In-the-Host (BIH) is a host-based IPv4 to IPv6 protocol
translation mechanism that allows a class of IPv4-only applications
that work through NATs to communicate with IPv6-only peers.  The host
on which applications are running may be connected to IPv6-only or
dual-stack access networks.  BIH hides IPv6 and makes the IPv4-only
applications think they are talking with IPv4 peers by local
synthesis of IPv4 addresses.

  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 primary point of earlier contention was with respect to whether
this NAT46-in-a-host could be placed behind a NAT64 and achieve NAT464.
The WG consensus was that that case should be disallowed, and the
present document reflects that consensus.

  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?

This document obsoletes two previous RFCs on implementation, and
updates them based on implementation experience.  At least one
implementation is in progress for the new document, and others
are expected.