Skip to main content

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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, 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 <fredbaker.ietf@gmail.com>, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Local-use IPv4/IPv6 Translation Prefix' to Proposed Standard (draft-ietf-v6ops-v4v6-xlat-prefix-02.txt)

The IESG has approved the following document:
- 'Local-use IPv4/IPv6 Translation Prefix'
  (draft-ietf-v6ops-v4v6-xlat-prefix-02.txt) as Proposed Standard

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-v4v6-xlat-prefix/


Ballot Text

Technical Summary

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

Working Group Summary

  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.

Document Quality

  Joe Clarke provided a helpful early OpsDir review, and the
  document was updated (with assistance / input from the WG) to address
  his comments. 

  
 
 It also used to Update: RFC6890, but it was only adding to a 
 registry created by RFC6890, so this was removed.


Personnel

   Fred Baker is the Document Shepherd
   Warren Kumari is RAD!


RFC Editor Note