Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for Stewart Bryant
2012-08-22
16 (System) post-migration administrative database adjustment to the Yes position for Jari Arkko
2012-08-22
16 (System) post-migration administrative database adjustment to the No Objection position for David Harrington
2011-05-31
16 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-04-26
16 (System) New version available: draft-mrw-nat66-16.txt
2011-04-25
16 (System) IANA Action state changed to No IC from In Progress
2011-04-25
16 (System) IANA Action state changed to In Progress
2011-04-25
16 Amy Vezza IESG state changed to Approved-announcement sent
2011-04-25
16 Amy Vezza IESG has approved the document
2011-04-25
16 Amy Vezza Closed "Approve" ballot
2011-04-25
16 Amy Vezza Approval announcement text regenerated
2011-04-25
16 Amy Vezza Ballot writeup text changed
2011-04-24
15 (System) New version available: draft-mrw-nat66-15.txt
2011-04-24
16 Ron Bonica State changed to Approved-announcement sent from Approved-announcement to be sent.
2011-04-24
16 Ron Bonica State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup.
2011-04-24
16 Ron Bonica Ballot writeup text changed
2011-04-24
16 Jari Arkko
[Ballot comment]
I would strongly suggest this change, or words to that effect:

OLD:
  Note that, for reasons discussed in [RFC2993] and …
[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:
2011-04-24
16 Jari Arkko [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss
2011-04-21
14 (System) New version available: draft-mrw-nat66-14.txt
2011-04-21
13 (System) New version available: draft-mrw-nat66-13.txt
2011-03-21
16 Stewart Bryant
[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 …
[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
2011-03-21
16 Stewart Bryant
[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 …
[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
2011-03-21
16 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2011-03-17
16 David Harrington [Ballot comment]
I cleared
2011-03-17
16 David Harrington [Ballot discuss]
I cleared
2011-03-17
16 David Harrington [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss
2011-03-17
16 Cindy Morgan Removed from agenda for telechat
2011-03-17
16 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-03-17
16 Jari Arkko
[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 …
[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.
2011-03-17
16 Jari Arkko [Ballot Position Update] New position, Discuss, has been recorded
2011-03-17
16 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-03-17
16 David Harrington
[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) …
[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.
2011-03-17
16 David Harrington [Ballot Position Update] New position, Discuss, has been recorded
2011-03-17
16 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-03-17
16 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-03-16
16 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-03-16
16 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-03-15
16 Stewart Bryant [Ballot comment]
STUN, TURN, ICE should have references
2011-03-15
16 Stewart Bryant
[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 …
[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?
2011-03-15
16 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded
2011-03-14
16 Ron Bonica [Ballot Position Update] New position, Yes, has been recorded for Ronald Bonica
2011-03-14
16 Ron Bonica Ballot has been issued
2011-03-14
16 Ron Bonica Created "Approve" ballot
2011-03-13
12 (System) New version available: draft-mrw-nat66-12.txt
2011-03-13
11 (System) New version available: draft-mrw-nat66-11.txt
2011-03-10
16 Wesley Eddy Request for Last Call review by TSVDIR Completed. Reviewer: Allison Mankin.
2011-03-10
10 (System) New version available: draft-mrw-nat66-10.txt
2011-03-02
16 Ron Bonica State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-03-02
16 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-03-01
09 (System) New version available: draft-mrw-nat66-09.txt
2011-03-01
16 Amy Vezza Telechat date has been changed to 2011-03-17 from 2011-03-03
2011-03-01
16 Amy Vezza Status Date has been changed to None from 2011-02-02
2011-02-28
08 (System) New version available: draft-mrw-nat66-08.txt
2011-02-25
16 Amanda Baber We understand that this document does not require any IANA actions.
2011-02-24
16 David Harrington Request for Last Call review by TSVDIR is assigned to Allison Mankin
2011-02-24
16 David Harrington Request for Last Call review by TSVDIR is assigned to Allison Mankin
2011-02-16
16 Samuel Weiler Request for Last Call review by SECDIR Completed. Reviewer: Richard Barnes.
2011-02-07
16 Samuel Weiler Request for Last Call review by SECDIR is assigned to Richard Barnes
2011-02-07
16 Samuel Weiler Request for Last Call review by SECDIR is assigned to Richard Barnes
2011-02-02
16 Amy Vezza Last call sent
2011-02-02
16 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
Reply-To: ietf@ietf.org …
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.
2011-02-02
16 Ron Bonica Last Call text changed
2011-02-02
16 Ron Bonica Last Call text changed
2011-02-02
16 Ron Bonica Last Call was requested
2011-02-02
16 Ron Bonica State changed to Last Call Requested from Publication Requested.
2011-02-02
16 (System) Ballot writeup text was added
2011-02-02
16 (System) Last call text was added
2011-02-02
16 (System) Ballot approval text was added
2011-02-02
16 Ron Bonica Draft added in state Publication Requested
2011-02-02
16 Ron Bonica Placed on agenda for telechat - 2011-03-03
2011-01-28
07 (System) New version available: draft-mrw-nat66-07.txt
2011-01-05
06 (System) New version available: draft-mrw-nat66-06.txt
2011-01-05
05 (System) New version available: draft-mrw-nat66-05.txt
2010-12-16
04 (System) New version available: draft-mrw-nat66-04.txt
2010-12-15
03 (System) New version available: draft-mrw-nat66-03.txt
2010-12-11
02 (System) New version available: draft-mrw-nat66-02.txt
2010-12-09
01 (System) New version available: draft-mrw-nat66-01.txt
2010-10-18
00 (System) New version available: draft-mrw-nat66-00.txt