IPv6-to-IPv6 Network Prefix Translation
draft-mrw-nat66-16

[Ballot comment]
I would strongly suggest this change, or words to that effect:

OLD:
  Note that, for reasons discussed in [RFC2993] and Section 5, the IETF
  does not generally recommend the use of Network Address Translation
  technology.

  This has several ramifications:
NEW:
  Note that, for reasons discussed in [RFC2993] and Section 5, the IETF
  does not generally recommend the use of Network Address Translation
  technology for IPv6. Where Network Address Translation is implemented,
  however, this specification provides a mechanism that has less architectural
  problems than merely implementing a traditional IPv4 NAT in an IPv6
  environment. Some problems remain, however, and the reader should consult
  Section 5, [RFC4864], and [RFC5902], for the implications and approaches
  that help avoid all types of NATs.

  The stateless approach described in this document has several ramifications:

[Ballot comment]
I think that it would be useful to the reader to add some text
into section 2.6 saying something like

"The outgoing checksum correction is achieved by making a
change to a 16 bit section of the source address that is not
used for routing in the external network. Due to the nature of
checksum arithmetic, when the corresponding  correction is
applied to the same bits of destination address of the inbound
packet, the DA is returned to the correct internal value."


STUN, TURN, ICE should have references

[Ballot comment]
I think that it would be useful to the reader to add some text into section 2.6 saying something like

"The outgoing checksum correction is achieved by making a change to a 16 bit section of the source
address that is not used for routing in the external network. Due to the nature of checksum arithmetic, when the
corresponding  correction is applied to the same bits of destination address of the inbound packet, the DA is returned to the correct internal value."


STUN, TURN, ICE should have references

[Ballot discuss]
When I had discussed AD sponsoring this document or taking this document through the IETF, we discussed adding a fairly significant warning at the beginning to say that the IETF does not recommend doing IPv6 NATs. There is some material in this document about this, but I'd like to see a more prominent note.

[Ballot discuss]
This document is well written and easy to read. I have a concern however, and want to discuss this before approving publication.

1) In the main document, there is no mention of GSE.
Appendix A explains that the approach used in the main document is actually a type of GSE address architecture.
The reference for GSE points to an expired 1997 Internet-Draft that describes an addressing approach that is an alternative to the addressing approach "currently" used in IPv6 (in 1997).
I assume the "current" addressing approach is the one that actually achieved IETF consensus in 1997, and today, and that this alternate approach was rejected, and hence did not go forward.

The appendix argues "why GSE" and puts forth the benefits of this addressing approach, from the standpoint of the RIR community. It strikes me that this motivation should be documented in the main body of the draft, not just an appendix. I would also like a bit better feeling for who "they" are in the text. Does "they" represent everybody in the RIR community? or are there factioins of the RIR community that seriously oppose this approach?

In addition, the appendix does not explain why the "current" approach was adopted and the GSE alternative was not. The ipngwg apparently did not accept this proposal, but that consensus decision doesn't seem to be documented (or it doesn't jump out at me if it is in the text somewhere).

My conclusion is that this draft describes a proposal very similar to one that was rejected in 1997, and has apparently remained rejected in the IPv6 community ever since. Why is this a reasonable contribution at this time, if it hasn't been accepted in the past 14 years?

I checked the History looking for a proto writeup to see whether there was significant dissent with this document from a working group or expert review, but since this is not a WG document, apparently no writeup was provided.
I note that this document used to have a filename draft-mrw-behave-nat66, and now only has draft-mrw-nat66. Was this proposal presented in behave and rejected?
I note that there was significant discussion on the nat66 list, but I don't see any writeup about the community feedback here, since there is no document shepherd writeup.

There is no IESG ballot writeup for this draft.
Can we at least get an IESG ballot writeup and/or proto writeup summarizing the community feedback to this proposal?

2) This is experimental. It would help if this document discussed the operational impact of deploying this experimental proposal in production networks and/or the Internet.

[Ballot discuss]
The purpose of this discuss is to confirm that there are no undocumented issues associated with the use prefix bits in the range 64 to 127 to fix up the checksum. These are surely real network addresses elsewhere in the net, and therefore may be destinations addresses of packets passing through the translator.

Section 4.3 states that a node MUST support hairpinning. Does it need to say that it MUST NOT do internal route optimization?

Does an internal router placed between a host and the translator correctly route packets in this translated range?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (IPv6-to-IPv6 Network Prefix Translation) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'IPv6-to-IPv6 Network Prefix Translation'
  as an Experimental RFC

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-03-02. 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-mrw-nat66/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-mrw-nat66/

Abstract

  This document describes a stateless, transport-agnostic IPv6-to-IPv6
  Network Prefix Translation (NPTv6) function that provides the address
  independence benefit associated with IPv4-to-IPv4 NAT (NAT44), and in
  addition provides a 1:1 relationship between addresses in the
  "inside" and "outside" prefixes, preserving end to end reachability
  at the network layer.