Local-Use IPv4/IPv6 Translation Prefix
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Fred Baker <firstname.lastname@example.org>, email@example.com 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/
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!