draft-ietf-6man-ra-pref64-00.txt   draft-ietf-6man-ra-pref64-01.txt 
IPv6 Maintenance L. Colitti IPv6 Maintenance L. Colitti
Internet-Draft E. Kline Internet-Draft J. Linkova
Intended status: Standards Track J. Linkova Intended status: Standards Track Google
Expires: September 25, 2019 Google Expires: December 30, 2019 June 28, 2019
March 24, 2019
Discovering PREF64 in Router Advertisements Discovering PREF64 in Router Advertisements
draft-ietf-6man-ra-pref64-00 draft-ietf-6man-ra-pref64-01
Abstract Abstract
This document specifies a Router Advertisement option to communicate This document specifies a Router Advertisement option to communicate
NAT64 prefixes to clients. NAT64 prefixes to clients.
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 32 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 25, 2019. This Internet-Draft will expire on December 30, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
2. Use cases for communicating the NAT64 prefix to hosts . . . . 3 2. Use cases for communicating the NAT64 prefix to hosts . . . . 3
3. Why include the NAT64 prefix in Router Advertisements . . . . 3 3. Why include the NAT64 prefix in Router Advertisements . . . . 3
4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Option format . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Option format . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Handling Multiple NAT64 Prefixes . . . . . . . . . . . . . . 5 6. Handling Multiple NAT64 Prefixes . . . . . . . . . . . . . . 6
7. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . 9
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
NAT64 [RFC6146] with DNS64 [RFC6147] is a widely-deployed mechanism NAT64 [RFC6146] with DNS64 [RFC6147] is a widely-deployed mechanism
to provide IPv4 access on IPv6-only networks. In various scenarios, to provide IPv4 access on IPv6-only networks. In various scenarios,
the host must be aware of the NAT64 prefix in use by the network. the host must be aware of the NAT64 prefix in use by the network.
This document specifies a Router Advertisement [RFC4861] option to This document specifies a Router Advertisement [RFC4861] option to
communicate the NAT64 prefix to hosts. communicate the NAT64 prefix to hosts.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology 1.2. Terminology
Pref64: an IPv6 prefix used for IPv6 address synthesis [RFC6146]; Pref64 (or NAT64 prefix): an IPv6 prefix used for IPv6 address
synthesis [RFC6146];
PvD: Provisioning Domain, a set of network configuration information;
for more information, see [RFC7556].
PvD-aware host A host that supports the association of network NAT64: Network Address and Protocol Translation from IPv6 Clients to
configuration information into PvDs and the use of these PvDs. Also IPv4 Servers ([RFC6146]);
named PvD-aware node in [RFC7556].
RA: Router Advertisement, a message used by IPv6 routers to advertise RA: Router Advertisement, a message used by IPv6 routers to advertise
their presence together with various link and Internet parameters their presence together with various link and Internet parameters
([RFC4861]); ([RFC4861]);
DNS64: a mechanism for synthesizing AAAA records from A records
([RFC6147]);
2. Use cases for communicating the NAT64 prefix to hosts 2. Use cases for communicating the NAT64 prefix to hosts
On networks employing NAT64, it is useful for hosts to know the NAT64 On networks employing NAT64, it is useful for hosts to know the NAT64
prefix for several reasons, including the following: prefix for several reasons, including the following:
o Local DNSSEC validation. As discussed in [RFC6147] section 2, the o Local DNSSEC validation. As discussed in [RFC6147] section 2, the
stub resolver in the host "will try to obtain (real) AAAA RRs, and stub resolver in the host "will try to obtain (real) AAAA RRs, and
in case they are not available, the DNS64 function will synthesize in case they are not available, the DNS64 function will synthesize
AAAA RRs for internal usage." This is required in order to use AAAA RRs for internal usage." This is required in order to use
DNSSEC on a NAT64 network. DNSSEC on a NAT64 network.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
Updatability: it is possible to change the NAT64 prefix at any time, Updatability: it is possible to change the NAT64 prefix at any time,
because when it changes, it is possible to notify hosts by sending a because when it changes, it is possible to notify hosts by sending a
new Router Advertisement. new Router Advertisement.
Deployability: all IPv6 hosts and networks are required to support Deployability: all IPv6 hosts and networks are required to support
[RFC4861]. Other options such as [RFC7225] require implementing [RFC4861]. Other options such as [RFC7225] require implementing
other protocols. other protocols.
4. Semantics 4. Semantics
This option only supports a NAT64 prefix length of 96 bits, as this To support prefix lengths defined in ([RFC6052]) this option contains
is by the most common configuration used by hosts and supporting the prefix length field. However as /96 prefix is considered to be
variable prefix length would significantly increase the option size. the most common usecase, the prefix length field is optional and only
Networks using one of the other prefix lengths supported in presents for non-/96 prefixes. It allows to keep the option length
([RFC6052]) can use other mechanisms such as [RFC7050] or [RFC7225]. to a minimum (16 bytes) for the most common case and increase it to
If different prefix lengths become common, another RA option can be 20 bytes for non-/96 prefixes only (see Section 5 below for more
created to configure them. details).
This option specifies exactly one NAT64 prefix for all IPv4 This option specifies exactly one NAT64 prefix for all IPv4
destinations. If the network operator desires to route different destinations. If the network operator desires to route different
parts of the IPv4 address space to different NAT64 devices, this can parts of the IPv4 address space to different NAT64 devices, this can
be accomplished by routing more specifics of the NAT64 prefix to be accomplished by routing more specifics of the NAT64 prefix to
those devices. For example, if the operator would like to route those devices. For example, if the operator would like to route
10.0.0.0/8 through NAT64 device A and the rest of the IPv4 space 10.0.0.0/8 through NAT64 device A and the rest of the IPv4 space
through NAT64 device B, and the operator's NAT64 prefix is through NAT64 device B, and the operator's NAT64 prefix is
2001:db8:a:b::/96, then the operator can route 2001:db8:a:b::/96, then the operator can route
2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/64 to NAT64 B. 2001:db8:a:b::a00:0/104 to NAT64 A and 2001:db8:a:b::/64 to NAT64 B.
This option may appear more than once in a Router Advertisement (e.g. This option may appear more than once in a Router Advertisement (e.g.
in case of graceful renumbering the network from one NAT64 prefix to in case of graceful renumbering the network from one NAT64 prefix to
another). Host behaviour with regards to synthesizing IPv6 addresses another). Host behaviour with regards to synthesizing IPv6 addresses
from IPv4 addresses SHOULD follow the recommendations given in from IPv4 addresses SHOULD follow the recommendations given in
Section 3 of [RFC7050], limited to the NAT64 prefixes that have non- Section 3 of [RFC7050], limited to the NAT64 prefixes that have non-
zero lifetime. zero lifetime.
In a network that provides both IPv4 and NAT64, it may be desirable In a network (or a provisioning domain) that provides both IPv4 and
for certain IPv4 addresses not to be translated. An example might be NAT64, it may be desirable for certain IPv4 addresses not to be
private address ranges that are local to the network and should not translated. An example might be private address ranges that are
be reached through the NAT64. This type of configuration cannot be local to the network/provisioning domain and should not be reached
conveyed to hosts using this option, or through other NAT64 prefix through the NAT64. This type of configuration cannot be conveyed to
provisioning mechanisms such as [RFC7050] or [RFC7225]. This problem hosts using this option, or through other NAT64 prefix provisioning
does not apply in IPv6-only networks, because in such networks, the mechanisms such as [RFC7050] or [RFC7225]. This problem does not
host does not have an IPv4 address and cannot reach any IPv4 apply in IPv6-only networks, because in such networks, the host does
destinations without the NAT64. not have an IPv4 address and cannot reach any IPv4 destinations
without the NAT64. The multihoming and multiple provisioning domains
scenarios are discussed in Section 7.
5. Option format 5. Option format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Lifetime | | Type | Length | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Prefix + + +
| | | Highest 96 bits of the Prefix |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest bits (96-127) of the prefix (optional, if Length > 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: NAT64 Prefix Option Format Figure 1: NAT64 Prefix Option Format
Fields: Fields:
Type 8-bit identifier of the RDNSS option type as assigned by Type 8-bit identifier of the Pref64 option type as assigned by
IANA: TBD IANA: TBD
Length 8-bit unsigned integer. The length of the option (including Length 8-bit unsigned integer. The length of the option (including
the Type and Length fields) is in units of 8 octets. The the Type and Length fields) is in units of 8 octets. If the
sender MUST set the Length to 2. A host MUST ignore the prefix length is 96 bits the sender MUST set the Length to 2
NAT64 prefix option if the length field value is 1. If the and include the 96 bits of the prefix in the option. If the
Length field value exceeds 2, the host MUST utilize the prefix length is not 96 bits then the sender MUST set the
first 16 octets and ignore the rest of the option. length to 3 and include all 128 bits of the prefix in the
Prefix field and set the Prefix Length field to the prefix
length. The receiver MUST ignore the Pref64 option if the
length field value is 1. If the Length field value exceeds
3, the receiver MUST utilize the first 21 octets and ignore
the rest of the option.
Lifetime 16-bit unsigned integer. The maximum time in seconds over Lifetime 16-bit unsigned integer. The maximum time in seconds over
which this NAT64 prefix MAY be used. The value of Lifetime which this NAT64 prefix MAY be used. The value of Lifetime
SHOULD by default be set to lesser of 3 x MaxRtrAdvInterval SHOULD by default be set to lesser of 3 x MaxRtrAdvInterval
or 65535 seconds. A value of zero means that the prefix or 65535 seconds. A value of zero means that the prefix
MUST no longer be used. MUST no longer be used.
Prefix The 96-bit NAT64 prefix.
Highest 96-bit unsigned integer. Contains bits 0 - 95 of the NAT64
96 bits prefix.
of the
prefix
Lowest 32-bit unsigned integer. Contains bits 96 - 127 of the NAT64
bits of prefix.
the
prefix
Prefix 8-bit unsigned integer. The sender MUST set it only to one
Length of the following values: 32, 40, 48, 56, 64 ([RFC6052]. The
receiver MUST ignore the Pref64 option if the prefix length
value is not set to one of those numbers.
Reserved A 3-byte unused field. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
6. Handling Multiple NAT64 Prefixes 6. Handling Multiple NAT64 Prefixes
In some cases a host may receive multiple NAT64 prefixes from In some cases a host may receive multiple NAT64 prefixes from
different sources. Possible scenarios include (but are not limited different sources. Possible scenarios include (but are not limited
to): to):
o the host is using multiple mechanisms to discover Pref64 prefixes o the host is using multiple mechanisms to discover Pref64 prefixes
(e.g. by using PCP ([RFC7225]) and/or by resolving IPv4-only fully (e.g. by using PCP ([RFC7225]) and/or by resolving IPv4-only fully
qualified domain name ([RFC7050]) in addition to receiving the qualified domain name ([RFC7050]) in addition to receiving the
skipping to change at page 6, line 39 skipping to change at page 7, line 44
Like most IPv6 configuration information, the Pref64 option is Like most IPv6 configuration information, the Pref64 option is
specific to the network on which it is received. For example, a specific to the network on which it is received. For example, a
Pref64 option received on a particular wireless network may not be Pref64 option received on a particular wireless network may not be
usable unless the traffic is also sourced on that network. usable unless the traffic is also sourced on that network.
Similarly, a host connected to a cellular network that povides NAT64 Similarly, a host connected to a cellular network that povides NAT64
generally cannot use that NAT64 for destinations reached through a generally cannot use that NAT64 for destinations reached through a
VPN tunnel that terminates outside that network. VPN tunnel that terminates outside that network.
Thus, correct use of this option on a multihomed host generally Thus, correct use of this option on a multihomed host generally
requires the host to be PVD-aware. requires the host to support the concept of multiple Provisioning
Domains (PvD, a set of configuration information associated with a
network, [RFC7556]) and to be able to use these PvDs.
This issue is not specific to the Pref64 RA option and, for example, This issue is not specific to the Pref64 RA option and, for example,
is quite typical for DNS resolving on multihomed hosts (e.g. a host is quite typical for DNS resolving on multihomed hosts (e.g. a host
might resolve a destination name by using the corporate DNS server might resolve a destination name by using the corporate DNS server
via the VPN tunnel but then send the traffic via its Internet-facing via the VPN tunnel but then send the traffic via its Internet-facing
interface). interface).
8. IANA Considerations 8. IANA Considerations
The IANA is requested to assign a new IPv6 Neighbor Discovery Option The IANA is requested to assign a new IPv6 Neighbor Discovery Option
skipping to change at page 7, line 34 skipping to change at page 8, line 39
provide hosts with invalid configuration. provide hosts with invalid configuration.
The security measures that must already be in place to ensure that The security measures that must already be in place to ensure that
Router Advertisements are only received from legitimate sources Router Advertisements are only received from legitimate sources
eliminate the problem of NAT64 prefix validation described in section eliminate the problem of NAT64 prefix validation described in section
3.1 of [RFC7050]. 3.1 of [RFC7050].
10. Acknowledgements 10. Acknowledgements
Thanks to the following people (in alphabetical order) for their Thanks to the following people (in alphabetical order) for their
review and feedback: Mikael Abrahamsson, Brian E Carpenter, Nick review and feedback: Mikael Abrahamsson, Mark Andrews, Brian E
Heatley, Tatuya Jinmei, David Schinazi. Carpenter, Nick Heatley, Martin Hunek, Tatuya Jinmei, Erik Kline,
Michael Richardson, David Schinazi.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010, DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>. <https://www.rfc-editor.org/info/rfc6052>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-intarea-provisioning-domains] [I-D.ietf-intarea-provisioning-domains]
Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W. Pfister, P., Vyncke, E., Pauly, T., Schinazi, D., and W.
Shao, "Discovering Provisioning Domain Names and Data", Shao, "Discovering Provisioning Domain Names and Data",
draft-ietf-intarea-provisioning-domains-04 (work in draft-ietf-intarea-provisioning-domains-05 (work in
progress), March 2019. progress), June 2019.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005, RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>. <https://www.rfc-editor.org/info/rfc4033>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
skipping to change at page 9, line 33 skipping to change at page 10, line 38
Authors' Addresses Authors' Addresses
Lorenzo Colitti Lorenzo Colitti
Google Google
Roppongi 6-10-1 Roppongi 6-10-1
Minato, Tokyo 106-6126 Minato, Tokyo 106-6126
JP JP
Email: lorenzo@google.com Email: lorenzo@google.com
Erik Kline
Google
Roppongi 6-10-1
Minato, Tokyo 106-6126
JP
Email: ek@google.com
Jen Linkova Jen Linkova
Google Google
1 Darling Island Rd 1 Darling Island Rd
Pyrmont, NSW 2009 Pyrmont, NSW 2009
AU AU
Email: furry@google.com Email: furry@google.com
 End of changes. 18 change blocks. 
61 lines changed or deleted 84 lines changed or added

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