Local-Use IPv4/IPv6 Translation Prefix
draft-ietf-v6ops-v4v6-xlat-prefix-02

[Ballot comment]
Like Suresh, I really appreciated the discussion of rationale in section 4. There is one possibility that I'm surprised is not discussed; namely, allocating 64:ff9b::/48 for this purpose, with the subset of addresses in 64:ff9b::/96 being *additionally* subject to the restrictions of RFC 6052. This would seem to have the advantages of:

- Complete address adjacency without the disadvantages of using 64:ff9a:ffff::/48
- Sharing an even longer prefix (48 bits) than the 31-bit and 47-bit prefixes discussed in the document
- Eliminating the caveat described in the final paragraph of section 5 entirely

This is obvious enough that it had to be considered and rejected by the WG; including the rationale for rejecting it seems appropriate here.

[Ballot comment]
Like Suresh, I really appreciated the discussion of rationale in section 4. There is one possibility that I'm surprised is not discussed; namely, allocating 64::ff9b::/48 for this purpose, with the subset of addresses in 64::ff9b::/96 being *additionally* subject to the restrictions of RFC 6052. This would seem to have the advantages of:

- Complete address adjacency without the disadvantages of using 64:ff9a:ffff::/48
- Sharing an even longer prefix (48 bits) than the 31-bit and 47-bit prefixes discussed in the document
- Eliminating the caveat described in the final paragraph of section 5 entirely

This is obvious enough that it had to be considered and rejected by the WG; including the rationale for rejecting it seems appropriate here.

[Ballot discuss]
* Section 4.2.

I found the explanation to be useful but the prefix that was not selected seems to be wrong (a prefix with non-zero bits past the prefix length does not really make sense). The prefix that is adjacent to 64:ff9b::/96 is actually 64:ff9a:ffff::/48 and not 64:ff9a:ffff:ffff::/48 as described in the document. This means that most of the text that follows is incorrect. i.e. The range will be 64:ff9a:ffff:: - 64:ff9b::ffff:ffff and not 64:ff9a:ffff:ffff:: - 64:ff9b::ffff:ffff

P.S.: I thought hard about whether this should be a DISCUSS or a COMMENT but I decided to go with a DISCUSS because I think it really needs to be fixed

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-v6ops-v4v6-xlat-prefix-01.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the IANA IPv6 Special-Purpose Address Registry located at:

https://www.iana.org/assignments/iana-ipv6-special-registry/

a single, new entry is to be made as follows:

Address Block: 64:ff9b:1::/48
Name: IPv4-IPv6 Translat.
RFC: [ RFC-to-be ]
Allocation Date: [ TBD-at-Registration ]
Termination Date: N/A
Source: True
Destination: True
Forwardable: True
Global: False

Second, in the Internet Protocol Version 6 Address Space registry located at:

https://www.iana.org/assignments/ipv6-address-space/

the following footnote will be added to the 0000::/8 entry:

"64:ff9b:1::/48 reserved for Local-use IPv4/IPv6 Translation" [ RFC-to-be ]

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: v6ops@ietf.org, fredbaker.ietf@gmail.com, v6ops-chairs@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix@ietf.org, draft-ietf-v6ops-v4v6-xlat-prefix.all@ietf.org, warren@kumari.net, Fred Baker
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Local-use IPv4/IPv6 Translation Prefix) to Proposed Standard


The IESG has received a request from the IPv6 Operations WG (v6ops) to
consider the following document:
- 'Local-use IPv4/IPv6 Translation Prefix'
  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 2017-06-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 reserves the IPv6 prefix 64:ff9b:1::/48 for local use
  within domains that enable IPv4/IPv6 translation mechanisms.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/ballot/


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

Document write-up for draft-ietf-v6ops-v4v6-xlat-prefix

1. Summary: The document shepherd is Fred Baker, who thinks this
document is ready for publication. The relevant AD is Warren Kumari.

This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use
within domains that enable IPv4/IPv6 translation mechanisms.  This
document updates RFC6890.

RFC 6890 is a BCP defining special purpose address registries.

2. Review and Consensus

The fundamental issue was raised by the author, who is solving a problem
he observes in his network. He uses SIIT-DC to translate between IPv4
clients and IPv6-only services in his data center, and separately uses
stateless NAT64 to certain IPv4-only services. The current specification
permits the use of exactly one prefix for "the" translator,
64:ff9b::/96. If he has two or more translators (in this case, one for
SIIT-DC and one for stateless NAT64) facing different networks, he needs
to be able to distinguish them, using different prefixes within his
network. The use of 64:ff9b:1::/48 enables him to do so.

As noted in
https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/, the
document was proposed as an individual submission in May 2016, discussed
in the working group, and adopted in March 2017. Discussion was not
about the validity of the requirement or alternate solutions, but about
address scope, "why this prefix" (checksum neutrality), and deployment
considerations. To review, consider
https://tools.ietf.org/rfcdiff?url2=draft-anderson-v6ops-v4v6-xlat-
prefix-02.txt

There exists a consensus supporting the revision.

3. Intellectual Property

There is no know IPR related to the document.

4. Other issues...

idnits complains bitterly about the use of prefixes other than
2001:db8::/32. This document is discussing issues with the use of
64:ff9b::/96, and recommending assignment of 64:ff9b:1::/48 to address
them. Since it discusses specific prefix assignment, it has to name the
prefixes.