draft-ietf-v6ops-v4v6-xlat-prefix-01.txt   draft-ietf-v6ops-v4v6-xlat-prefix-02.txt 
IPv6 Operations T. Anderson IPv6 Operations T. Anderson
Internet-Draft Redpill Linpro Internet-Draft Redpill Linpro
Intended status: Standards Track May 12, 2017 Intended status: Standards Track June 20, 2017
Expires: November 13, 2017 Expires: December 22, 2017
Local-use IPv4/IPv6 Translation Prefix Local-use IPv4/IPv6 Translation Prefix
draft-ietf-v6ops-v4v6-xlat-prefix-01 draft-ietf-v6ops-v4v6-xlat-prefix-02
Abstract Abstract
This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use
within domains that enable IPv4/IPv6 translation mechanisms. within domains that enable IPv4/IPv6 translation mechanisms.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 13, 2017. This Internet-Draft will expire on December 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 13 skipping to change at page 4, line 13
the same time avoids wasting too much of the IPv6 address space. the same time avoids wasting too much of the IPv6 address space.
4.2. Prefix Value 4.2. Prefix Value
It is desirable to minimise the amount of additional "pollution" in It is desirable to minimise the amount of additional "pollution" in
the unallocated IPv6 address space caused by the reservation made by the unallocated IPv6 address space caused by the reservation made by
this document. Ensuring the reserved prefix is adjacent to the this document. Ensuring the reserved prefix is adjacent to the
64:ff9b::/96 WKP already reserved by [RFC6052] accomplishes this. 64:ff9b::/96 WKP already reserved by [RFC6052] accomplishes this.
Given the previous decision to use a prefix length of /48, this Given the previous decision to use a prefix length of /48, this
leaves two options: 64:ff9a:ffff:ffff::/48 and 64:ff9b:1::/48. leaves two options: 64:ff9a:ffff::/48 and 64:ff9b:1::/48.
64:ff9a:ffff:ffff::/48 has the benefit that it is completely adjacent 64:ff9a:ffff::/48 has the benefit that it is completely adjacent to
to the [RFC6052] WKP. That is, 64:ff9a:ffff:ffff::/48 and the [RFC6052] WKP. That is, 64:ff9a:ffff::/48 and 64:ff9b::/96
64:ff9b::/96 combines to form a uninterrupted range of IPv6 addresses combines to form a uninterrupted range of IPv6 addresses starting
starting with 64:ff9a:ffff:ffff:: and ending with 64:ff9b::ffff:ffff. with 64:ff9a:ffff:: and ending with 64:ff9b::ffff:ffff.
64:ff9b:1::/48 is, on the other hand, not completely adjacent to 64:ff9b:1::/48 is, on the other hand, not completely adjacent to
64:ff9b::/96. The range starting with 64:ff9b::1:0:0 and ending with 64:ff9b::/96. The range starting with 64:ff9b::1:0:0 and ending with
64:ff9b:0:ffff:ffff:ffff:ffff:ffff would remain unallocated. 64:ff9b:0:ffff:ffff:ffff:ffff:ffff would remain unallocated.
This particular drawback is, however, balanced by the fact that the This particular drawback is, however, balanced by the fact that the
smallest possible aggregate prefix that covers both the [RFC6052] WKP smallest possible aggregate prefix that covers both the [RFC6052] WKP
and 64:ff9a:ffff:ffff::/48 is much larger than the smallest possible and 64:ff9a:ffff::/48 is much larger than the smallest possible
aggregate prefix that covers both the [RFC6052] WKP and aggregate prefix that covers both the [RFC6052] WKP and
64:ff9b:1::/48. These aggregate prefixes are 64:ff9a::/31 and 64:ff9b:1::/48. These aggregate prefixes are 64:ff9a::/31 and
64:ff9b::/47, respectively. IPv6 address space is allocated using 64:ff9b::/47, respectively. IPv6 address space is allocated using
prefixes rather than address ranges, so it could be argued that prefixes rather than address ranges, so it could be argued that
64:ff9b:1::/48 is the option that would cause special-use prefixes 64:ff9b:1::/48 is the option that would cause special-use prefixes
reserved for IPv4/IPv6 translation to "pollute" the minimum possible reserved for IPv4/IPv6 translation to "pollute" the minimum possible
amount of unallocated IPv6 address space. amount of unallocated IPv6 address space.
Finally, 64:ff9b:1::/48 also has the advantage that its textual Finally, 64:ff9b:1::/48 also has the advantage that its textual
representation is considerably shorter than 64:ff9a:ffff:ffff::/48. representation is shorter than 64:ff9a:ffff::/48. While this might
While this might seem insignificant, the preference human network seem insignificant, the preference human network operators have for
operators have for addresses that are simple to type should not be addresses that are simple to type should not be underestimated.
underestimated.
After weighing the above pros and cons, 64:ff9b:1::/48 was chosen. After weighing the above pros and cons, 64:ff9b:1::/48 was chosen.
5. Deployment Considerations 5. Deployment Considerations
64:ff9b:1::/48 is intended as a technology-agnostic and generic 64:ff9b:1::/48 is intended as a technology-agnostic and generic
reservation. A network operator may freely use it in combination reservation. A network operator may freely use it in combination
with any kind of IPv4/IPv6 translation mechanism deployed within with any kind of IPv4/IPv6 translation mechanism deployed within
their network. their network.
skipping to change at page 7, line 25 skipping to change at page 7, line 25
April 2011, <http://www.rfc-editor.org/info/rfc6146>. April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, "IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016, DOI 10.17487/RFC7915, June 2016,
<http://www.rfc-editor.org/info/rfc7915>. <http://www.rfc-editor.org/info/rfc7915>.
Acknowledgements Acknowledgements
The author would like to thank Fred Baker, Mohamed Boucadair, Brian E The author would like to thank Fred Baker, Mohamed Boucadair, Brian E
Carpenter, Pier Carlo Chiodi, Joe Clarke, David Farmer, Warren Carpenter, Pier Carlo Chiodi, Joe Clarke, David Farmer, Suresh
Kumari, Holger Metschulat, Federico Santandrea and David Schinazi for Krishnan, Warren Kumari, Holger Metschulat, Federico Santandrea and
contributing to the creation of this document. David Schinazi for contributing to the creation of this document.
Author's Address Author's Address
Tore Anderson Tore Anderson
Redpill Linpro Redpill Linpro
Vitaminveien 1A Vitaminveien 1A
0485 Oslo 0485 Oslo
Norway Norway
Phone: +47 959 31 212 Phone: +47 959 31 212
 End of changes. 8 change blocks. 
17 lines changed or deleted 16 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/