Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-10-14
09 (System) Notify list changed from behave-chairs@ietf.org, draft-ietf-behave-v4v6-bih@ietf.org to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Adrian Farrel
2012-02-29
09 (System) RFC published
2012-01-19
09 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2012-01-18
09 (System) IANA Action state changed to No IC
2012-01-18
09 Amy Vezza IESG state changed to Approved-announcement sent
2012-01-18
09 Amy Vezza IESG has approved the document
2012-01-18
09 Amy Vezza Closed "Approve" ballot
2012-01-18
09 Amy Vezza Ballot writeup text changed
2012-01-18
09 David Harrington State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2012-01-18
09 David Harrington Approval announcement text regenerated
2012-01-16
09 Stephen Farrell [Ballot discuss]
-09 solves all my issues, thanks for handling those,
S
2012-01-16
09 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2012-01-16
09 (System) New version available: draft-ietf-behave-v4v6-bih-09.txt
2012-01-06
09 Stephen Farrell
[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, …
[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.
2011-12-29
09 Stephen Farrell [Ballot comment]
2011-12-29
09 Stephen Farrell
[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, …
[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.)
2011-12-22
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-12-22
08 (System) New version available: draft-ietf-behave-v4v6-bih-08.txt
2011-12-16
09 David Harrington
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 …
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?
2011-12-13
09 Stephen Farrell
[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 …
[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.
2011-12-13
09 Stephen Farrell
[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 …
[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.
2011-12-07
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-12-07
07 (System) New version available: draft-ietf-behave-v4v6-bih-07.txt
2011-10-06
09 Cindy Morgan Removed from agenda for telechat
2011-10-06
09 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-10-06
09 Dan Romascanu [Ballot comment]
1. Section 1 uses the term 'DNS synthesis' without defining it.

2. Section 5 deals with ALG considerations but ALG is never expanded
2011-10-06
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
09 Pete Resnick
[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 …
[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.
2011-10-05
09 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
09 David Harrington
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 …
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.
2011-10-05
09 Adrian Farrel [Ballot comment]
Clearing my Discuss having seen an email from the WG Chair to the original IPR holder.
2011-10-05
09 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2011-10-05
09 Adrian Farrel
[Ballot discuss]
Does this document deliberately avoide the IPR disclosed in RFC 2767?
If not, have the people who disclosed IPR in 2767 been …
[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)?
2011-10-05
09 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded
2011-10-05
09 Ralph Droms
[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., …
[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?
2011-10-05
09 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-10-05
09 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-10-04
09 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-10-04
09 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-10-04
09 Russ Housley
[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 …
[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.
2011-10-04
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-10-04
09 Stephen Farrell
[Ballot comment]
- The term "DNS synthesis" is used but not defined here. It
might be worth explaining.

- 2.2, end of 1st para has …
[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?
2011-10-04
09 Stephen Farrell
[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 …
[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?
2011-10-04
09 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-10-03
09 Peter Saint-Andre
[Ballot comment]
The abstract states that this document obsoletes RFC 2767 and RFC 3338. The introduction states that this document updates those RFCs. I …
[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).
2011-10-03
09 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-09-29
09 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-09-23
09 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-09-14
09 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-09-09
09 Amanda Baber We understand that this document doesn't require any IANA actions.
2011-09-02
09 David Harrington Request for Last Call review by TSVDIR is assigned to Fernando Gont
2011-09-02
09 David Harrington Request for Last Call review by TSVDIR is assigned to Fernando Gont
2011-08-31
09 Amy Vezza Last call sent
2011-08-31
09 Amy Vezza
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: …
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.


2011-08-30
09 David Harrington Placed on agenda for telechat - 2011-10-06
2011-08-30
09 David Harrington [Ballot Position Update] New position, Yes, has been recorded for David Harrington
2011-08-30
09 David Harrington Ballot has been issued
2011-08-30
09 David Harrington Created "Approve" ballot
2011-08-30
09 David Harrington Last Call was requested
2011-08-30
09 David Harrington State changed to Last Call Requested from AD Evaluation::AD Followup.
2011-08-30
09 David Harrington Last Call text changed
2011-08-30
09 (System) Ballot writeup text was added
2011-08-30
09 (System) Last call text was added
2011-08-30
09 (System) Ballot approval text was added
2011-08-10
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-08-10
06 (System) New version available: draft-ietf-behave-v4v6-bih-06.txt
2011-08-03
09 David Harrington
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 …
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/
2011-08-03
09 David Harrington
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 …
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/
2011-07-25
09 Cindy Morgan
  (1.a) Who is the Document Shepherd for this document?

Dave Thaler

        Has the
        Document Shepherd personally …
  (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. 
2011-07-25
09 Cindy Morgan Draft added in state Publication Requested
2011-07-25
09 Cindy Morgan [Note]: 'Dave Thaler (dthaler@microsoft.com) is the document shepherd.' added
2011-07-25
05 (System) New version available: draft-ietf-behave-v4v6-bih-05.txt
2011-04-12
04 (System) New version available: draft-ietf-behave-v4v6-bih-04.txt
2011-03-11
03 (System) New version available: draft-ietf-behave-v4v6-bih-03.txt
2011-01-23
02 (System) New version available: draft-ietf-behave-v4v6-bih-02.txt
2010-10-19
01 (System) New version available: draft-ietf-behave-v4v6-bih-01.txt
2010-10-11
00 (System) New version available: draft-ietf-behave-v4v6-bih-00.txt