rfc9872.original.xml   rfc9872.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
4) --> -ietf-v6ops-prefer8781-07" number="9872" category="info" consensus="true" submis
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft sionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3" upd
-ietf-v6ops-prefer8781-07" category="info" consensus="true" submissionType="IETF ates="" obsoletes="" xml:lang="en">
" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.30.0 -->
<front> <front>
<title abbrev="Prefer RFC8781">Recommendations for Discovering IPv6 Prefix U <title abbrev="NAT64 Prefix Discovery">Recommendations for Discovering IPv6
sed for IPv6 Address Synthesis</title> Prefix Used for IPv6 Address Synthesis</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-prefer8781-07"/> <seriesInfo name="RFC" value="9872"/>
<author fullname="Nick Buraglio"> <author fullname="Nick Buraglio">
<organization>Energy Sciences Network</organization> <organization>Energy Sciences Network</organization>
<address> <address>
<email>buraglio@forwardingplane.net</email> <email>buraglio@forwardingplane.net</email>
</address> </address>
</author> </author>
<author fullname="Tommy Jensen"> <author fullname="Tommy Jensen">
<organization/> <organization/>
<address> <address>
<email>tojens.ietf@gmail.com</email> <email>tojens.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jen Linkova"> <author fullname="Jen Linkova">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<email>furry13@gmail.com</email> <email>furry13@gmail.com</email>
</address> </address>
</author> </author>
<date year="2025" month="August" day="07"/> <date year="2025" month="September"/>
<area>ops</area> <area>OPS</area>
<workgroup>v6ops</workgroup> <workgroup>v6ops</workgroup>
<keyword>IPv6</keyword> <keyword>IPv6</keyword>
<keyword>DNS64</keyword> <keyword>DNS64</keyword>
<keyword>PREF64</keyword> <keyword>PREF64</keyword>
<keyword>NAT64</keyword> <keyword>NAT64</keyword>
<keyword>CLAT</keyword> <keyword>CLAT</keyword>
<abstract>
<?line 62?>
<t>On networks providing IPv4-IPv6 translation (RFC7915), hosts and other endpoi <abstract>
nts need to know the IPv6 prefix(es) used for translation (the NAT64 prefix, RFC <t>On networks providing IPv4-IPv6 translation (RFC 7915), hosts and other endpo
6052). This document provides guidelines for NAT64 prefix discovery, specificall ints need to know the IPv6 prefix(es) used for translation (the NAT64 prefix (RF
y recommending obtaining the NAT64 prefix from Router Advertisement option (RFC8 C 6052)). This document provides guidelines for NAT64 prefix discovery, specific
781) when available.</t> ally recommending obtaining the NAT64 prefix from the Router Advertisement optio
n (RFC 8781) when available.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
github.com/buraglio/draft-nbtjjl-v6ops-prefer8781"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-v6ops-prefer8781/"/>.
</t>
<t>
Discussion of this document takes place on the
v6ops Working Group mailing list (<eref target="mailto:v6ops@ietf.org"/>
),
which is archived at <eref target="https://datatracker.ietf.org/wg/v6ops
/about/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/v6ops/"
/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/buraglio/draft-nbtjjl-v6ops-prefer8781"
/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 66?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Devices translating between IPv4 and IPv6 packet headers <xref target=" RFC7915"/> use a NAT64 prefix to map IPv4 addresses into the IPv6 address space, and vice versa. <t>Devices translating between IPv4 and IPv6 packet headers <xref target=" RFC7915"/> use a NAT64 prefix to map IPv4 addresses into the IPv6 address space, and vice versa.
When a network provides NAT64, it is advantageous for endpoints to acquire the n etwork's NAT64 prefixes (PREF64). When a network provides NAT64, it is advantageous for endpoints to acquire the n etwork's NAT64 prefixes (PREF64).
Discovering the PREF64 enables endpoints to:</t> Discovering the PREF64 enables endpoints to:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Implement the customer-side translator (CLAT) function of the 464XL AT architecture <xref target="RFC6877"/>.</t> <t>Implement the customer-side translator (CLAT) function of the 464XL AT architecture <xref target="RFC6877"/>.</t>
</li> </li>
<li> <li>
<t>Translate IPv4 literals to IPv6 literals (Section 7.1 of <xref targ et="RFC8305"/>).</t> <t>Translate IPv4 literals to IPv6 literals (<xref target="RFC8305" se ction="7.1"/>).</t>
</li> </li>
<li> <li>
<t>Perform local DNS64 <xref target="RFC6147"/> functions.</t> <t>Perform local DNS64 <xref target="RFC6147"/> functions.</t>
</li> </li>
<li> <li>
<t>Support applications relying on IPv4 address referral (Section 3.2. 2 of <xref target="RFC7225"/>).</t> <t>Support applications relying on IPv4 address referral (<xref target ="RFC7225" section="3.2.2"/>).</t>
</li> </li>
</ul> </ul>
<t>Dynamic PREF64 discovery is useful to keep the NAT64 prefix configurati <t>Dynamic PREF64 discovery is useful to keep the NAT64 prefix configurati
on up-to-date, particularly for unmanaged endpoints or endpoints which move betw on up-to-date, particularly for unmanaged endpoints or endpoints that move betwe
een networks. en networks.
<xref target="RFC7050"/> introduces the first DNS64-based mechanism for PREF64 d <xref target="RFC7050"/> introduces the first DNS64-based mechanism for PREF64 d
iscovery based on <xref target="RFC7051"/> analysis. iscovery per the analysis described in <xref target="RFC7051"/>.
However, subsequent methods have been developed to address <xref target="RFC7050 However, subsequent methods have been developed to address the limitations of th
"/> limitations.</t> e mechanism described in <xref target="RFC7050"/>.</t>
<t>For instance, <xref target="RFC8781"/> defines a Neighbor Discovery <xr ef target="RFC4861"/> option for Router Advertisements (RAs) to convey PREF64 in formation to hosts. <t>For instance, <xref target="RFC8781"/> defines a Neighbor Discovery <xr ef target="RFC4861"/> option for Router Advertisements (RAs) to convey PREF64 in formation to hosts.
This approach offers several advantages (Section 3 of <xref target="RFC8781"/>), This approach offers several advantages (<xref target="RFC8781" section="3
including fate sharing with other host network configuration parameters.</t> "/>), including fate sharing with other host network configuration parameters.</
<t>Due to fundamental shortcomings of the <xref target="RFC7050"/> mechani t>
sm (<xref target="issues"/>), <xref target="RFC8781"/> is the preferred solution <t>Due to fundamental shortcomings of the mechanism defined in <xref targe
for new deployments. t="RFC7050"/> (see <xref target="issues"/> for more details), <xref target="RFC8
781"/> describes the preferred solution for new deployments.
Implementations should strive for consistent PREF64 acquisition methods. Implementations should strive for consistent PREF64 acquisition methods.
The DNS64-based mechanism of <xref target="RFC7050"/> should be employed only wh en RA-based PREF64 delivery is unavailable, or as a fallback for legacy systems incapable of processing the PREF64 RA Option.</t> The DNS64-based mechanism of <xref target="RFC7050"/> should be employed only wh en RA-based PREF64 delivery is unavailable or as a fallback for legacy systems i ncapable of processing the PREF64 RA Option.</t>
</section> </section>
<section anchor="terminology"> <section anchor="terminology">
<name>Terminology</name> <name>Terminology</name>
<t>DNS64: a mechanism for synthesizing AAAA records from A records, define
d in <xref target="RFC6147"/>.</t>
<t>NAT64: a mechanism for translating IPv6 packets to IPv4 packets and vic
e versa. The translation is done by translating the packet headers according to
the IP/ICMP Translation Algorithm defined in <xref target="RFC7915"/>. NAT64 tr
anslators can operate in stateful (<xref target="RFC6144"/>) or stateless mode (
e.g. customer-side translator, CLAT, <xref target="RFC6877"/>).
This document uses "NAT64" as a generalized term for a translator which uses the
stateless IP/ICMP translation algorithm defined in <xref target="RFC7915"/> and
operates within a framework for IPv4/IPv6 translation described in <xref target
="RFC6144"/>.</t>
<t>PREF64 (or Pref64::/n, or NAT64 prefix): An IPv6 prefix used for IPv6 a
ddress synthesis and for network addresses and protocols translation from IPv6 c
lients to IPv4 servers using the algorithm defined in <xref target="RFC6052"/>.<
/t>
<t>Router Advertisement (RA): A packet used by Neighbor Discovery <xref ta
rget="RFC4861"/> and SLAAC to advertise the presence of the routers, together wi
th other IPv6 configuration information.</t>
<t>SLAAC: StateLess Address AutoConfiguration, <xref target="RFC4862"/></
t>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i
nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and
only when, they
appear in all capitals, as shown here.</t>
<?line -18?>
</section> <dl spacing="normal" newline="false">
<dt>DNS64:</dt><dd>A mechanism for synthesizing AAAA records from A records,
defined in <xref target="RFC6147"/>.</dd>
<dt>NAT64:</dt><dd>A mechanism for translating IPv6 packets to IPv4 packets,
and vice versa. The translation is done by translating the packet headers
according to the IP/ICMP Translation Algorithm defined in <xref
target="RFC7915"/>. NAT64 translators can operate in stateful mode <xref
target="RFC6144"/> or stateless mode <xref target="RFC6877"/> (e.g., customer-
side translator (CLAT)).
This document uses "NAT64" as a generalized term
for a translator, which uses the stateless IP/ICMP Translation Algorithm
defined in <xref target="RFC7915"/> and operates within a framework for
IPv4/IPv6 translation described in <xref target="RFC6144"/>.</dd>
<dt>PREF64:</dt><dd>Pref64::/n or NAT64 prefix. An IPv6 prefix used for
IPv6 address synthesis <xref target="RFC6146"/>.</dd>
<dt>RA:</dt><dd>Router Advertisement. A packet used by Neighbor Discovery
<xref target="RFC4861"/> and SLAAC to advertise the presence of the routers,
together with other IPv6 configuration information.</dd>
<dt>SLAAC:</dt><dd>Stateless Address Autoconfiguration <xref target="RFC4862"/
>.</dd>
</dl>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
</section>
<section anchor="recommendations-for-pref64-discovery"> <section anchor="recommendations-for-pref64-discovery">
<name>Recommendations for PREF64 Discovery</name> <name>Recommendations for PREF64 Discovery</name>
<section anchor="deployment-recommendations-for-endpoints"> <section anchor="deployment-recommendations-for-endpoints">
<name>Deployment Recommendations for Endpoints</name> <name>Deployment Recommendations for Endpoints</name>
<t>Endpoints <bcp14>SHOULD</bcp14> attempt to obtain PREF64 information <t>Endpoints <bcp14>SHOULD</bcp14> attempt to obtain PREF64 information
from RAs per <xref target="RFC8781"/> instead of using <xref target="RFC7050"/> from RAs per <xref target="RFC8781"/>, instead of using the method described in
method. <xref target="RFC7050"/>.
In the absence of the PREF64 information in RAs, an endpoint <bcp14>MAY</bcp14> In the absence of the PREF64 information in RAs, an endpoint <bcp14>MAY</bcp14>
choose to fall back to the mechanism defined in RFC7050. choose to fall back to the mechanism defined in <xref target="RFC7050"/>.
This recommendation to prefer the <xref target="RFC8781"/> mechanism over one de This recommendation to prefer the mechanism defined in <xref target="RFC8781"/>
fined in <xref target="RFC7050"/> is consistent with Section 5.1 of <xref target over the one defined in <xref target="RFC7050"/> is consistent with <xref target
="RFC8781"/>.</t> ="RFC8781" section="5.1"/>.</t>
</section> </section>
<section anchor="deployment-recommendations-for-operators"> <section anchor="deployment-recommendations-for-operators">
<name>Deployment Recommendations for Operators</name> <name>Deployment Recommendations for Operators</name>
<t>Network operators deploying NAT64 <bcp14>SHOULD</bcp14> provide PREF6 4 information in Router Advertisements per <xref target="RFC8781"/>.</t> <t>Network operators deploying NAT64 <bcp14>SHOULD</bcp14> provide PREF6 4 information in Router Advertisements per <xref target="RFC8781"/>.</t>
<section anchor="mobile-network-considerations"> <section anchor="mobile-network-considerations">
<name>Mobile Network Considerations</name> <name>Mobile Network Considerations</name>
<t>While <xref target="RFC8781"/> support is widely integrated into mo dern operating systems on mobile endpoints, equipment deployed in mobile network environments often lacks abilities to include the PREF64 Option into RAs. <t>While support for the option specified in <xref target="RFC8781"/> is widely integrated into modern operating systems on mobile endpoints, equipmen t deployed in mobile network environments often lacks abilities to include the P REF64 Option into RAs.
Therefore, the immediate deployment and enablement of PREF64 by mobile operators may not currently be feasible and the recommendations outlined in this document are not presently applicable to mobile network operators. Therefore, the immediate deployment and enablement of PREF64 by mobile operators may not currently be feasible and the recommendations outlined in this document are not presently applicable to mobile network operators.
These environments are encouraged to incorporate <xref target="RFC8781"/> when m ade practical by infrastructure upgrades or software stack feature additions.</t > These environments are encouraged to incorporate the option specified in <xref t arget="RFC8781"/> when made practical by infrastructure upgrades or software sta ck feature additions.</t>
</section> </section>
<section anchor="migration-considerations"> <section anchor="migration-considerations">
<name>Migration Considerations</name> <name>Migration Considerations</name>
<t>Transitioning from the <xref target="RFC7050"/> heuristic to using <t>Transitioning from the heuristic procedure in <xref target="RFC7050
the <xref target="RFC8781"/> approach might require a period of time where both "/> to using the approach in <xref target="RFC8781"/> might require a period of
mechanisms coexist. time where both mechanisms coexist.
How long this may take depends on the endpoint footprint, particularly the prese How long this may take depends on the endpoint footprint, particularly the prese
nce and number of endpoints running outdated operating systems, which do not sup nce and number of endpoints running outdated operating systems that do not suppo
port <xref target="RFC8781"/>. rt the option in <xref target="RFC8781"/>.
Operators are advised to take those factors into account prior to removing suppo Operators are advised to take those factors into account prior to removing suppo
rt for the <xref target="RFC7050"/> heuristic, noting that it is still safe to a rt for the heuristic procedure in <xref target="RFC7050"/>, noting that it is st
dd support for the <xref target="RFC8781"/> approach since endpoints that suppor ill safe to add support for the approach in <xref target="RFC8781"/> since endpo
t it will always prefer it over <xref target="RFC7050"/> if they follow RFC requ ints that support it will always prefer it over <xref target="RFC7050"/> if they
irements.</t> follow RFC requirements.</t>
<t>Migrating away from DNS64-based discovery also reduces dependency o <t>Migrating away from DNS64-based discovery also reduces dependency o
n DNS64 in general, thereby eliminating DNSSEC and DNS64 incompatibility concern n DNS64 in general, thereby eliminating DNSSEC and DNS64 incompatibility concern
s (Section 6.2 of <xref target="RFC6147"/>).</t> s (<xref target="RFC6147" section="6.2"/>).</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="issues"> <section anchor="issues">
<name>Existing Issues with RFC7050</name> <name>Existing Issues with RFC 7050</name>
<t>DNS-based discovery the NAT64 prefix introduces some challenges, which <t>DNS-based discovery of the NAT64 prefix introduces some challenges, whi
make this approach less preferable than latest developed alternatives (such as P ch make this approach less preferable than the latest developed alternatives (su
REF64 RA Option, <xref target="RFC8781"/>). ch as the PREF64 RA Option <xref target="RFC8781"/>).
This section outlines the key issues, associated with <xref target="RFC7050"/>, This section outlines the key issues associated with <xref target="RFC7050"/> wi
with a focus on those not discussed in <xref target="RFC7050"/> or in the analys th a focus on those not discussed in <xref target="RFC7050"/> or in the analysis
is of solutions for hosts to discover NAT64 prefix (<xref target="RFC7051"/>).</ of solutions for hosts to discover the NAT64 prefix <xref target="RFC7051"/>.</
t> t>
<t>Signalling PREF64 in RA option addresses all issues outlined in this se <t>Signalling PREF64 in the RA Option addresses all issues outlined in thi
ction (see Section 3 of <xref target="RFC8781"/> for details).</t> s section (see <xref target="RFC8781" section="3"/> for details).</t>
<section anchor="dependency-on-network-provided-recursive-resolvers"> <section anchor="dependency-on-network-provided-recursive-resolvers">
<name>Dependency on Network-Provided Recursive Resolvers</name> <name>Dependency on Network-Provided Recursive Resolvers</name>
<t>Fundamentally, the presence of the NAT64 and the exact value of the p <t>The presence or absence of NAT64 functionality, as well as its
refix used for the translation are network-specific attributes. associated prefix (if present), are network-dependent attributes.
Therefore, <xref target="RFC7050"/> requires the endpoint discovering the prefix to use the DNS64 resolvers provided by the network. Therefore, <xref target="RFC7050"/> requires the endpoint discovering the prefix to use the DNS64 resolvers provided by the network.
If the device or an application is configured to use other recursive resolvers o r runs a local recursive resolver, the corresponding name resolution APIs and li braries are required to recognize 'ipv4only.arpa.' as a special name and give it special treatment. If the device or an application is configured to use other recursive resolvers o r runs a local recursive resolver, the corresponding name resolution APIs and li braries are required to recognize 'ipv4only.arpa.' as a special name and give it special treatment.
This issue and remediation approach are discussed in <xref target="RFC8880"/>. This issue and remediation approach are discussed in <xref target="RFC8880"/>.
However, it has been observed that very few <xref target="RFC7050"/> implementat However, it has been observed that very few implementations of the method descri
ions support <xref target="RFC8880"/> requirements for special treatment of 'ipv bed in <xref target="RFC7050"/> support the requirements specified in <xref targ
4only.arpa.'. et="RFC8880"/> for special treatment of 'ipv4only.arpa.'.
As a result, configuring such systems and applications to use resolvers other th As a result, configuring such systems and applications to use resolvers o
an the one provided by the network breaks the PREF64 discovery, leading to degra ther than the one provided by the network breaks the PREF64 discovery, leading t
ded user experience.</t> o degraded user experience.</t>
<t>VPN applications may override the endpoint's DNS configuration, for e xample, by configuring enterprise DNS servers as the node's recursive resolvers and forcing all name resolution through the VPN. <t>VPN applications may override the endpoint's DNS configuration, for e xample, by configuring enterprise DNS servers as the node's recursive resolvers and forcing all name resolution through the VPN.
These enterprise DNS servers typically lack DNS64 functionality and therefore ca nnot provide information about the PREF64 used within the local network. These enterprise DNS servers typically lack DNS64 functionality and therefore ca nnot provide information about the PREF64 used within the local network.
If the VPN is configured in so-called "split tunneling" mode (when only a subset If the VPN is configured in so-called "split tunneling" mode (when only a
of network traffic is routed into the VPN tunnel), endpoints may not discover t subset of network traffic is routed into the VPN tunnel), endpoints may not dis
he necessary PREF64, which negatively impacts their connectivity on IPv6-only ne cover the necessary PREF64, which negatively impacts their connectivity on IPv6-
tworks.</t> only networks.</t>
<t>If both the network-provided DNS64 and the endpoint's resolver happen <t>If both the network-provided DNS64 and the endpoint's resolver happen
to utilize the Well-Known Prefix (64:ff9b::/96, <xref target="RFC6052"/>), the to utilize the Well-Known Prefix (64:ff9b::/96) <xref target="RFC6052"/>, the e
endpoint would end up using a PREF64 that's valid for the current network. ndpoint would end up using a PREF64 that's valid for the current network.
However, if the endpoint changes its network attachment, it can't detect if the However, if the endpoint changes its network attachment, it can't detect if the
new network lacks NAT64 entirely or uses a network-specific NAT64 prefix (NSP, < new network lacks NAT64 entirely or uses a network-specific prefix (NSP) <xref t
xref target="RFC6144"/>).</t> arget="RFC6144"/> for NAT64.</t>
<t>Signalling PREF64 in RA option decouples the PREF64 discovery from th <t>Signalling PREF64 in an RA Option decouples the PREF64 discovery from
e host's DNS resolvers configuration.</t> the host's DNS resolver configuration.</t>
</section> </section>
<section anchor="network-stack-initialization-delay"> <section anchor="network-stack-initialization-delay">
<name>Network Stack Initialization Delay</name> <name>Network Stack Initialization Delay</name>
<t>When using SLAAC, an IPv6 host typically requires a single RA to acqu ire its network configuration. <t>When using SLAAC, an IPv6 host typically requires a single RA to acqu ire its network configuration.
For IPv6-only endpoints, timely PREF64 discovery is critical, particularly for t hose performing local DNS64 or NAT64 functions, such as CLAT (<xref target="RFC6 877"/>). For IPv6-only endpoints, timely PREF64 discovery is critical, particularly for t hose performing local DNS64 or NAT64 functions, such as CLAT <xref target="RFC68 77"/>.
Until a PREF64 is obtained, the endpoint's IPv4-only applications and communicat ion to IPv4-only destinations are impaired. Until a PREF64 is obtained, the endpoint's IPv4-only applications and communicat ion to IPv4-only destinations are impaired.
The mechanism defined in <xref target="RFC7050"/> does not bundle PREF64 informa The mechanism defined in <xref target="RFC7050"/> does not bundle PREF64 informa
tion with other network configuration parameters, and requires at least one roun tion with other network configuration parameters and requires at least one round
d-trip time (to send a DNS request and receive a response) after the network sta -trip time (to send a DNS request and receive a response) after the network stac
ck configuration is completed.</t> k configuration is completed.</t>
<t>Advertising PREF64 in RA, on the other hand, elminates the period whe <t>On the other hand, advertising PREF64 in an RA eliminates the period
n the host obtains IPv6 addresses and default routers, but no PREF64.</t> when the host obtains IPv6 addresses and default routers but no PREF64.</t>
</section> </section>
<section anchor="latency-in-updates-propagation"> <section anchor="latency-in-updates-propagation">
<name>Latency in Updates Propagation</name> <name>Latency in Updates Propagation</name>
<t>Section 3 of <xref target="RFC7050"/> states: "The node <bcp14>SHALL< <t><xref target="RFC7050" section="3"/> states:</t>
/bcp14> cache the replies it receives during the Pref64::/n discovery procedure, <blockquote>The node <bcp14>SHALL</bcp14> cache the replies it receives during t
and it <bcp14>SHOULD</bcp14> repeat the discovery process ten seconds before th he Pref64::/n discovery procedure, and it <bcp14>SHOULD</bcp14> repeat the disco
e TTL of the Well-Known Name's synthetic AAAA resource record expires." very process ten seconds before the TTL of the Well-Known Name's synthetic AAAA
As a result, once a PREF64 is discovered, it will be used until the TTL expired, resource record expires.</blockquote>
or until the node disconnects from the network. <t>As a result, once a PREF64 is discovered, it will be used until the TTL expir
es or until the node disconnects from the network.
There is no mechanism for an operator to force the PREF64 rediscovery on the nod e without disconnecting the node from the network. There is no mechanism for an operator to force the PREF64 rediscovery on the nod e without disconnecting the node from the network.
If the operator needs to change the PREF64 value used in the network, they need to proactively reduce the TTL value returned by the DNS64 server. If the operator needs to change the PREF64 value used in the network, they need to proactively reduce the TTL value returned by the DNS64 server.
This method has two significant drawbacks:</t> This method has two significant drawbacks:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>Many networks utilize external DNS64 servers and therefore have n o control over the TTL value, if the PREF64 needs to be changed or withdrawn.</t > <t>Many networks utilize external DNS64 servers and therefore have n o control over the TTL value if the PREF64 needs to be changed or withdrawn.</t>
</li> </li>
<li> <li>
<t>The PREF64 changes need to be planned and executed at least TTL s econds in advance. If the operator needs to notify nodes that a particular prefi x must not be used (e.g. during a network outage or if the nodes learnt a rogue PREF64 as a result of an attack), it might not be possible without interrupting the network connectivity for the affected nodes.</t> <t>The PREF64 changes need to be planned and executed at least TTL s econds in advance. If the operator needs to notify nodes that a particular prefi x must not be used (e.g., during a network outage or if the nodes learned a rogu e PREF64 as a result of an attack), it might not be possible without interruptin g the network connectivity for the affected nodes.</t>
</li> </li>
</ul> </ul>
<t>Mechanism defined in <xref target="RFC8781"/> allows to notify hosts about PREF64 changes immidiately, by sending an RA with updated information.</t> <t>The mechanism defined in <xref target="RFC8781"/> allows notifying ho sts about PREF64 changes immediately by sending an RA with updated information.< /t>
</section> </section>
<section anchor="multihoming-implications"> <section anchor="multihoming-implications">
<name>Multihoming Implications</name> <name>Multihoming Implications</name>
<t>Section 3 of <xref target="RFC7050"/> requires a node to examine all received AAAA resource records to discover one or more PREF64s and to utilize al l learned prefixes. <t><xref target="RFC7050" section="3"/> requires a node to examine all r eceived AAAA resource records to discover one or more PREF64s and to utilize all learned prefixes.
However, this approach presents challenges in some multihomed topologies where d ifferent DNS64 servers belonging to different ISPs might return different PREF64 s. However, this approach presents challenges in some multihomed topologies where d ifferent DNS64 servers belonging to different ISPs might return different PREF64 s.
In such cases, it is crucial that traffic destined for synthesized addresses is sent to the correct NAT64 and the source address selected for those flows belong s to the prefix from that ISP's address space. In such cases, it is crucial that traffic destined for synthesized addresses is sent to the correct NAT64 and the source address selected for those flows belong s to the prefix from that ISP's address space.
In other words, the node needs to associate each discovered PREF64 with upstream information, including the IPv6 prefix and default gateway. In other words, the node needs to associate each discovered PREF64 with upstream information, including the IPv6 prefix and default gateway.
Currently, there is no reliable way for a node to map a DNS64 response (and the prefix learned from it) to a specific upstream in a multihoming scenario. Currently, there is no reliable way for a node to map a DNS64 response (and the prefix learned from it) to a specific upstream in a multihoming scenario.
Consequently, the node might inadvertently select an incorrect source address fo r a given PREF64 and/or send traffic to the incorrect uplink.</t> Consequently, the node might inadvertently select an incorrect source address fo r a given PREF64 and/or send traffic to the incorrect uplink.</t>
<t>Advertising PREF64 in RAs allows hosts to track which PREF64 was adve <t>Advertising PREF64 in RAs allows hosts to track which PREF64 was adve
rtised by which router and use that information to select the correct nexthop. rtised by which router and use that information to select the correct next hop.
Section 8 of <xref target="I-D.ietf-v6ops-claton"/> discusses this scenario in m <xref section="8" target="I-D.ietf-v6ops-claton"/> discusses this scenario in mo
ore details.</t> re details.</t>
</section> </section>
<section anchor="security-implications"> <section anchor="security-implications">
<name>Security Implications</name> <name>Security Implications</name>
<t>As discussed in Section 7 of <xref target="RFC7050"/>, the DNS-based PREF64 discovery is prone to DNS spoofing attacks. <t>As discussed in <xref target="RFC7050" section="7"/>, the DNS-based P REF64 discovery is prone to DNS spoofing attacks.
In addition to creating a wider attack surface for IPv6 deployments, <xref targe t="RFC7050"/> has other security challenges, which are discussed below.</t> In addition to creating a wider attack surface for IPv6 deployments, <xref targe t="RFC7050"/> has other security challenges, which are discussed below.</t>
<section anchor="secure-channel-def"> <section anchor="secure-channel-def">
<name>Definition of Secure Channel</name> <name>Definition of Secure Channel</name>
<t><xref target="RFC7050"/> requires a node's communication channel wi <t><xref target="RFC7050"/> requires a node's communication channel wi
th a DNS64 server to be a "secure channel" which it defines to mean "a communica th a DNS64 server to be a "secure channel", which it defines to mean "a communic
tion channel a node has between itself and a DNS64 server protecting DNS protoco ation channel a node has between itself and a DNS64 server protecting DNS protoc
l-related messages from interception and tampering." ol-related messages from interception and tampering".
This need is redundant when another communication mechanism of IPv6-related conf This need is redundant when another communication mechanism of IPv6-rel
iguration, specifically RAs, can already be defended against tampering, for exam ated configuration, specifically RAs, can already be defended against tampering,
ple by enabling RA-Guard <xref target="RFC6105"/>. for example, by enabling RA-Guard <xref target="RFC6105"/>.
Requiring nodes to implement two defense mechanisms when only one is necessary w When the mechanism defined in <xref target="RFC8781"/> is used in place of the o
hen <xref target="RFC8781"/> is used in place of <xref target="RFC7050"/> create ne defined in <xref target="RFC7050"/>,
s unnecessary risk.</t> nodes only need to implement one defense mechanism; requiring nodes to implement
two defense mechanisms creates an unnecessary risk.</t>
</section> </section>
<section anchor="secure-channel-example-of-ipsec"> <section anchor="secure-channel-example-of-ipsec">
<name>Secure Channel Example of IPsec</name> <name>Secure Channel Example of IPsec</name>
<t>One of the two examples that <xref target="RFC7050"/> defines to qu alify a communication channel with a DNS64 server is the use of an "IPsec-based virtual private network (VPN) tunnel". As of the time of this writing, this is n ot supported as a practice by any common operating system DNS client. While they could, there have also since been multiple mechanisms defined for performing DN S-specific encryption such as those defined in <xref target="RFC9499"/> that wou ld be more appropriately scoped to the applicable DNS traffic. These are also co mpatible with encrypted DNS advertisement by the network using Discovery of Netw ork-designated Resolvers <xref target="RFC9463"/> that would ensure the clients know in advance that the DNS64 server supported the encryption mechanism.</t> <t>One of the two examples that <xref target="RFC7050"/> defines to qu alify a communication channel with a DNS64 server is the use of an "IPsec-based virtual private network (VPN) tunnel". As of the time of this writing, this is n ot supported as a practice by any common operating system DNS client. While they could, there have also since been multiple mechanisms defined for performing DN S-specific encryption, such as those defined in <xref target="RFC9499"/>, that w ould be more appropriately scoped to the applicable DNS traffic. These are also compatible with encrypted DNS advertisement by the network using Discovery of Ne twork-designated Resolvers <xref target="RFC9463"/>, which would ensure the clie nts know in advance that the DNS64 server supported the encryption mechanism.</t >
</section> </section>
<section anchor="secure-channel-example-of-link-layer-encryption"> <section anchor="secure-channel-example-of-link-layer-encryption">
<name>Secure Channel Example of Link Layer Encryption</name> <name>Secure Channel Example of Link Layer Encryption</name>
<t>The other example given by <xref target="RFC7050"/> that would allo w a communication channel with a DNS64 server to qualify as a "secure channel" i s the use of a "link layer utilizing data encryption technologies". As of the ti me of this writing, most common link layer implementations use data encryption a lready with no extra effort needed on the part of network nodes. While this appe ars to be a trivial way to satisfy this requirement, it also renders the require ment meaningless since any node along the path can still read the higher-layer D NS traffic containing the translation prefix. This seems to be at odds with the definition of "secure channel" as explained in <xref section="2.2" sectionFormat ="of" target="RFC7050"/>.</t> <t>The other example given by <xref target="RFC7050"/> that would allo w a communication channel with a DNS64 server to qualify as a "secure channel" i s the use of a "link layer utilizing data encryption technologies". As of the ti me of this writing, most common link layer implementations use data encryption a lready with no extra effort needed on the part of network nodes. While this appe ars to be a trivial way to satisfy this requirement, it also renders the require ment meaningless since any node along the path can still read the higher-layer D NS traffic containing the translation prefix. This seems to be at odds with the definition of "secure channel", as explained in <xref section="2.2" sectionForma t="of" target="RFC7050"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Obtaining PREF64 information using RAs improves the overall security of <t>Obtaining PREF64 information using RAs improves the overall security of
an IPv6-only endpoint as it mitigates all attack vectors related to spoofed or an IPv6-only endpoint as it mitigates all attack vectors related to a spoofed o
rogue DNS response, as discussed in Section 7 of <xref target="RFC7050"/>. r rogue DNS response, as discussed in <xref target="RFC7050" section="7"/>.
Security considerations related to obtaining PREF64 information from RAs are dis Security considerations related to obtaining PREF64 information from RAs are dis
cussed in Section 7 of <xref target="RFC8781"/>.</t> cussed in <xref target="RFC8781" section="7"/>.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document does not introduce any IANA considerations.</t> <t>This document has no IANA actions.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-v6ops-claton" to="CLAT"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC7050"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 050.xml"/>
<title>Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis< <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
/title> 781.xml"/>
<author fullname="T. Savolainen" initials="T." surname="Savolainen"/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
> 119.xml"/>
<author fullname="J. Korhonen" initials="J." surname="Korhonen"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="D. Wing" initials="D." surname="Wing"/> 174.xml"/>
<date month="November" year="2013"/>
<abstract>
<t>This document describes a method for detecting the presence of
DNS64 and for learning the IPv6 prefix used for protocol translation on an acces
s network. The method depends on the existence of a well-known IPv4-only fully q
ualified domain name "ipv4only.arpa.". The information learned enables nodes to
perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stac
k and multi-interface deployments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7050"/>
<seriesInfo name="DOI" value="10.17487/RFC7050"/>
</reference>
<reference anchor="RFC8781">
<front>
<title>Discovering PREF64 in Router Advertisements</title>
<author fullname="L. Colitti" initials="L." surname="Colitti"/>
<author fullname="J. Linkova" initials="J." surname="Linkova"/>
<date month="April" year="2020"/>
<abstract>
<t>This document specifies a Neighbor Discovery option to be used
in Router Advertisements (RAs) to communicate prefixes of Network Address and Pr
otocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8781"/>
<seriesInfo name="DOI" value="10.17487/RFC8781"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4861"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<front> 861.xml"/>
<title>Neighbor Discovery for IP version 6 (IPv6)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<author fullname="T. Narten" initials="T." surname="Narten"/> 862.xml"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="W. Simpson" initials="W." surname="Simpson"/> 105.xml"/>
<author fullname="H. Soliman" initials="H." surname="Soliman"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<date month="September" year="2007"/> 052.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<t>This document specifies the Neighbor Discovery protocol for IP 144.xml"/>
Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each o <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
ther's presence, to determine each other's link-layer addresses, to find routers 225.xml"/>
, and to maintain reachability information about the paths to active neighbors. <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
[STANDARDS-TRACK]</t> 915.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</front> 146.xml"/>
<seriesInfo name="RFC" value="4861"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<seriesInfo name="DOI" value="10.17487/RFC4861"/> 147.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<reference anchor="RFC4862"> 877.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<title>IPv6 Stateless Address Autoconfiguration</title> 051.xml"/>
<author fullname="S. Thomson" initials="S." surname="Thomson"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="T. Narten" initials="T." surname="Narten"/> 880.xml"/>
<author fullname="T. Jinmei" initials="T." surname="Jinmei"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="September" year="2007"/> 463.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>This document specifies the steps a host takes in deciding how 499.xml"/>
to autoconfigure its interfaces in IP version 6. The autoconfiguration process i <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ncludes generating a link-local address, generating global addresses via statele 305.xml"/>
ss address autoconfiguration, and the Duplicate Address Detection procedure to v <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
erify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t> ietf-v6ops-claton.xml"/>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
<reference anchor="RFC6105">
<front>
<title>IPv6 Router Advertisement Guard</title>
<author fullname="E. Levy-Abegnoli" initials="E." surname="Levy-Abeg
noli"/>
<author fullname="G. Van de Velde" initials="G." surname="Van de Vel
de"/>
<author fullname="C. Popoviciu" initials="C." surname="Popoviciu"/>
<author fullname="J. Mohacsi" initials="J." surname="Mohacsi"/>
<date month="February" year="2011"/>
<abstract>
<t>Routed protocols are often susceptible to spoof attacks. The ca
nonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that i
s non-trivial to deploy. This document proposes a light-weight alternative and c
omplement to SEND based on filtering in the layer-2 network fabric, using a vari
ety of filtering criteria, including, for example, SEND status. This document is
not an Internet Standards Track specification; it is published for informationa
l purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6105"/>
<seriesInfo name="DOI" value="10.17487/RFC6105"/>
</reference>
<reference anchor="RFC6052">
<front>
<title>IPv6 Addressing of IPv4/IPv6 Translators</title>
<author fullname="C. Bao" initials="C." surname="Bao"/>
<author fullname="C. Huitema" initials="C." surname="Huitema"/>
<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
<author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
<author fullname="X. Li" initials="X." surname="Li"/>
<date month="October" year="2010"/>
<abstract>
<t>This document discusses the algorithmic translation of an IPv6
address to a corresponding IPv4 address, and vice versa, using only statically c
onfigured information. It defines a well-known prefix for use in algorithmic tra
nslations, while allowing organizations to also use network-specific prefixes wh
en appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as wel
l as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scena
rios. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6052"/>
<seriesInfo name="DOI" value="10.17487/RFC6052"/>
</reference>
<reference anchor="RFC6144">
<front>
<title>Framework for IPv4/IPv6 Translation</title>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="X. Li" initials="X." surname="Li"/>
<author fullname="C. Bao" initials="C." surname="Bao"/>
<author fullname="K. Yin" initials="K." surname="Yin"/>
<date month="April" year="2011"/>
<abstract>
<t>This note describes a framework for IPv4/IPv6 translation. This
is in the context of replacing Network Address Translation - Protocol Translati
on (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IP
v4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6
network. This document is not an Internet Standards Track specification; it is
published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6144"/>
<seriesInfo name="DOI" value="10.17487/RFC6144"/>
</reference>
<reference anchor="RFC6146">
<front>
<title>Stateful NAT64: Network Address and Protocol Translation from
IPv6 Clients to IPv4 Servers</title>
<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
<author fullname="P. Matthews" initials="P." surname="Matthews"/>
<author fullname="I. van Beijnum" initials="I." surname="van Beijnum
"/>
<date month="April" year="2011"/>
<abstract>
<t>This document describes stateful NAT64 translation, which allow
s IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One
or more public IPv4 addresses assigned to a NAT64 translator are shared among s
everal IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64,
no changes are usually required in the IPv6 client or the IPv4 server.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6146"/>
<seriesInfo name="DOI" value="10.17487/RFC6146"/>
</reference>
<reference anchor="RFC7225">
<front>
<title>Discovering NAT64 IPv6 Prefixes Using the Port Control Protoc
ol (PCP)</title>
<author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
<date month="May" year="2014"/>
<abstract>
<t>This document defines a new Port Control Protocol (PCP) option
to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4
-converted IPv6 addresses. This option is needed for successful communications w
hen IPv4 addresses are used in referrals.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7225"/>
<seriesInfo name="DOI" value="10.17487/RFC7225"/>
</reference>
<reference anchor="RFC7915">
<front>
<title>IP/ICMP Translation Algorithm</title>
<author fullname="C. Bao" initials="C." surname="Bao"/>
<author fullname="X. Li" initials="X." surname="Li"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="T. Anderson" initials="T." surname="Anderson"/>
<author fullname="F. Gont" initials="F." surname="Gont"/>
<date month="June" year="2016"/>
<abstract>
<t>This document describes the Stateless IP/ICMP Translation Algor
ithm (SIIT), which translates between IPv4 and IPv6 packet headers (including IC
MP headers). This document obsoletes RFC 6145.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7915"/>
<seriesInfo name="DOI" value="10.17487/RFC7915"/>
</reference>
<reference anchor="RFC6147">
<front>
<title>DNS64: DNS Extensions for Network Address Translation from IP
v6 Clients to IPv4 Servers</title>
<author fullname="M. Bagnulo" initials="M." surname="Bagnulo"/>
<author fullname="A. Sullivan" initials="A." surname="Sullivan"/>
<author fullname="P. Matthews" initials="P." surname="Matthews"/>
<author fullname="I. van Beijnum" initials="I." surname="van Beijnum
"/>
<date month="April" year="2011"/>
<abstract>
<t>DNS64 is a mechanism for synthesizing AAAA records from A recor
ds. DNS64 is used with an IPv6/IPv4 translator to enable client-server communica
tion between an IPv6-only client and an IPv4-only server, without requiring any
changes to either the IPv6 or the IPv4 node, for the class of applications that
work through NATs. This document specifies DNS64, and provides suggestions on ho
w it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6147"/>
<seriesInfo name="DOI" value="10.17487/RFC6147"/>
</reference>
<reference anchor="RFC6877">
<front>
<title>464XLAT: Combination of Stateful and Stateless Translation</t
itle>
<author fullname="M. Mawatari" initials="M." surname="Mawatari"/>
<author fullname="M. Kawashima" initials="M." surname="Kawashima"/>
<author fullname="C. Byrne" initials="C." surname="Byrne"/>
<date month="April" year="2013"/>
<abstract>
<t>This document describes an architecture (464XLAT) for providing
limited IPv4 connectivity across an IPv6-only network by combining existing and
well-known stateful protocol translation (as described in RFC 6146) in the core
and stateless protocol translation (as described in RFC 6145) at the edge. 464X
LAT is a simple and scalable technique to quickly deploy limited IPv4 access ser
vice to IPv6-only edge networks without encapsulation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6877"/>
<seriesInfo name="DOI" value="10.17487/RFC6877"/>
</reference>
<reference anchor="RFC7051">
<front>
<title>Analysis of Solution Proposals for Hosts to Learn NAT64 Prefi
x</title>
<author fullname="J. Korhonen" initials="J." role="editor" surname="
Korhonen"/>
<author fullname="T. Savolainen" initials="T." role="editor" surname
="Savolainen"/>
<date month="November" year="2013"/>
<abstract>
<t>Hosts and applications may benefit from learning if an IPv6 add
ress is synthesized and if NAT64 and DNS64 are present in a network. This docume
nt analyzes all proposed solutions (known at the time of writing) for communicat
ing whether the synthesis is taking place, what address format was used, and wha
t IPv6 prefix was used by the NAT64 and DNS64. These solutions enable both NAT64
avoidance and local IPv6 address synthesis. The document concludes by recommend
ing the standardization of the approach based on heuristic discovery.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7051"/>
<seriesInfo name="DOI" value="10.17487/RFC7051"/>
</reference>
<reference anchor="RFC8880">
<front>
<title>Special Use Domain Name 'ipv4only.arpa'</title>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<date month="August" year="2020"/>
<abstract>
<t>NAT64 (Network Address and Protocol Translation from IPv6 Clien
ts to IPv4 Servers) allows client devices using IPv6 to communicate with servers
that have only IPv4 connectivity.</t>
<t>The specification for how a client discovers its local network'
s NAT64 prefix (RFC 7050) defines the special name 'ipv4only.arpa' for this purp
ose. However, in its Domain Name Reservation Considerations section (Section 8.1
), that specification (RFC 7050) indicates that the name actually has no particu
larly special properties that would require special handling.</t>
<t>Consequently, despite the well-articulated special purpose of t
he name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names regist
ry as a name with special properties.</t>
<t>This document updates RFC 7050. It describes the special treatm
ent required and formally declares the special properties of the name. It also a
dds similar declarations for the corresponding reverse mapping names.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8880"/>
<seriesInfo name="DOI" value="10.17487/RFC8880"/>
</reference>
<reference anchor="RFC9463">
<front>
<title>DHCP and Router Advertisement Options for the Discovery of Ne
twork-designated Resolvers (DNR)</title>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="T. Reddy.K" initials="T." role="editor" surname="R
eddy.K"/>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<author fullname="N. Cook" initials="N." surname="Cook"/>
<author fullname="T. Jensen" initials="T." surname="Jensen"/>
<date month="November" year="2023"/>
<abstract>
<t>This document specifies new DHCP and IPv6 Router Advertisement
options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS,
and DNS over QUIC). Particularly, it allows a host to learn an Authentication D
omain Name together with a list of IP addresses and a set of service parameters
to reach such encrypted DNS resolvers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9463"/>
<seriesInfo name="DOI" value="10.17487/RFC9463"/>
</reference>
<reference anchor="RFC9499">
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
<date month="March" year="2024"/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens of
different RFCs. The terminology used by implementers and developers of DNS proto
cols, and by operators of DNS systems, has changed in the decades since the DNS
was first defined. This document gives current definitions for many of the terms
used in the DNS in a single document.</t>
<t>This document updates RFC 2308 by clarifying the definitions of
"forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and cla
rifications. Comprehensive lists of changed and new definitions can be found in
Appendices A and B.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="9499"/>
<seriesInfo name="DOI" value="10.17487/RFC9499"/>
</reference>
<reference anchor="RFC8305">
<front>
<title>Happy Eyeballs Version 2: Better Connectivity Using Concurren
cy</title>
<author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<date month="December" year="2017"/>
<abstract>
<t>Many communication protocols operating over the modern Internet
use hostnames. These often resolve to multiple IP addresses, each of which may
have different performance and connectivity characteristics. Since specific addr
esses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal
on a network, clients that attempt multiple connections in parallel have a chanc
e of establishing a connection more quickly. This document specifies requirement
s for algorithms that reduce this user-visible delay and provides an example alg
orithm, referred to as "Happy Eyeballs". This document obsoletes the original al
gorithm description in RFC 6555.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8305"/>
<seriesInfo name="DOI" value="10.17487/RFC8305"/>
</reference>
<reference anchor="I-D.ietf-v6ops-claton">
<front>
<title>464XLAT Customer-side Translator (CLAT): Node Recommendations
</title>
<author fullname="Jen Linkova" initials="J." surname="Linkova">
<organization>Google</organization>
</author>
<author fullname="Tommy Jensen" initials="T." surname="Jensen">
</author>
<date day="25" month="July" year="2025"/>
<abstract>
<t> 464XLAT [RFC6877] defines an architecture for providing IPv4
connectivity across an IPv6-only network. The solution contains two
key elements: provider-side translator (PLAT) and customer-side
translator (CLAT). This document complements [RFC6877] and updates
Requirements for IPv6 Customer Edge Routers to Support IPv4-as-
a-Service (RFC8585) by providing recommendations for the node
developers on enabling and disabling CLAT functions.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-v6ops-claton-06"/>
</reference>
</references> </references>
</references> </references>
<?line 236?> <section numbered="false" anchor="acknowledgments">
<section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors would like to thank the following people for their valuable <t>The authors would like to thank the following people for their
contributions: Mike Bishop, Mohamed Boucadair, Lorenzo Colitti, Tom Costello, C valuable contributions: <contact fullname="Mike Bishop"/>, <contact
harles Eckel, Susan Hares, Nick Heatley, Gabor Lencse, Ted Lemon, David Lou, Pet fullname="Mohamed Boucadair"/>, <contact fullname="Lorenzo Colitti"/>,
er Schmitt, Éric Vyncke, Chongfeng Xie.</t> <contact fullname="Tom Costello"/>, <contact fullname="Charles Eckel"/>,
<contact fullname="Susan Hares"/>, <contact fullname="Nick Heatley"/>,
<contact fullname="Ted Lemon"/>, <contact fullname="Gábor Lencse"/>,
<contact fullname="David Lou"/>, <contact fullname="Peter Schmitt"/>,
<contact fullname="Éric Vyncke"/>, and <contact fullname="Chongfeng
Xie"/>.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source: </rfc>
H4sIAAAAAAAAA5Vb3XbbRpK+x1P00heWckgqshX/6MzOhLHsRLOyrZXkZOb4
6KIJNMmOQABBA5IZHz/AvsU+y+6L7VdV3UCDpDNZ35gCG93V9fPVV9XNyWSS
NLbJzakaXZm0XK9NkenGloVTi7JWZ9al5b2pbbFU55f3z9RlbRb2k/rgTMYD
+OEsy2rjnLreFM3KOOtGiZ7Pa3OPWekFU6urN69ePH9xPEpS3ZhlWW9OlS0W
ZZJkZVroNdbPar1oJtY0i8n9s7Jyk4rfpLcm3z5PXDtfW+cgWbOpMPz89c0b
pR4pnbsSy9giMxVkN0UzGquRyWxT1lbn9Mf57Af8B2FH51c3b0ZJ0a7npj5N
sFFzmqTYqylc605VU7cmgdBPE10bfaogRfJQ1nfLumyrU8ViJXdmg2fZaaIm
vHv6/+zd9bMT+nB59fqNfHo3u5EPry5mN8m9KVqspdRgKqVkL79gDdLwj/Ql
nq61zf2Y70kh07Je4rGu09WpWjVN5U6PjiC9bmqd3pl6GgYdPSyP+LUjPS/b
5ogWtM2qnUND87bWy9yWR6LoYt78+mu+o+oRXsmhF9fglbCUzDGFexz92VkS
3TarsiYtYUalFm2ei53f2fRO/eCn4e8guC7s7+x2p+p1YerlRl2n1hSpceqd
acgGPNKIZrq9fA8XfNB1BuVVuS7MtDDNaHfJG/j1Rv3dkKEH8zTlr3jI6vt+
Sc9oj3smwKvqwhZ35b3eI/GPZbnMzWDiRVvXm+On8aRFWa/xwj27AcLh+bff
fes/kspOk4QCYjjm5MWz4/7jE//x2fG334WP337XPz056T8+C6s8eRLGPn95
/F0/4Hn4+OL5816isNqLFy+CcC9Pnj3tPr58GQY8FRnOJ2fTKGZT+A5UkiST
yUTpuSMHbZLkfaEKMaNTVV3e28wDysmEAQTDCpezOtWBF/VwrFala5zSRaZK
4EqtEN9VaQs8KwzwpynVXVE+KHwnOFQxOB0Yd6jaAFCDqWkkB6YfOg46PJyq
m5V1CmjUAgIbLyXcb9niv9wWRgAxfltlHh03Y+Uqk9qFTXWeb1QdkJR2Wc4b
bQv6tL26WtTlWl0hULG3WYaJGusML19WnS7IOQ7VwwouqO/hTXqem6koeG2z
DI6XPFLnRVOXWZvSW0lyZu4thU63dyw+h/4N5iCls0pFY4QfjVoZnZnaqY9e
97ekP6WH0kLda135CQTxsQbMUfYW8M+hDp2aMa9Doijszelp8gvvIvhCr2Re
Z6xso2ADnd3rotFLU7ai897sWEqnv7W2Nrykn+exGwiK+Q4Ehw+nSZzA6BX5
AlOSGt1ganitUt+o83WVixFofNq6plybeuIgaKdQCHVAuH4IjChY6apc8PiT
Zyf/wBeM1bYxadNC1o8+zm6nvMKNn8WILnOMq5HGaHesxO7BwbWRyZ9Pj2mB
jz7wbg9loktTE2KovITfSRKStRDet51oTgZft1VV1o3SVZXDTyXH1ybfsJMW
A7sqRnLI0IvwdPpk+iQIQahCQiRnGwCkTYNau4AgO8KFgKAcpcZUu96PxLuw
SyA5z99Wk6acUEoewysRCWmb6xrBRB7QFmtdwCOyyGADx3hY2XSl1li7c/QA
ONPko0fbW3JWDhOKDYizsLVrRG+TuSbEWJt0BWR3a152Z1cyCNL6KY9v4eI6
34DyTJOfygeDUcCCdu7Mby250NogC2ZOrTRLBrEyjMnLSuArqLuXMLdr22hv
tuQNhLCFa3RB0fTRo8EtJlkwIiFCjV2u5hFT2/AwShy3AUVoK/tQBg52NQNW
QhDY4t5swoa7RISX8SXD8DRhgIT31KWGrsvFghDD0ZbhJ13QRl77tPNZEhp4
bos0bxkUF+T9bqU5Lh9ALzzC01IdPAwdBE6BXIxNkGLOWkOSwcUzTVuBBA50
owHuYkYXorHXa2/Yg8+fwSNb4758OYx1asUnhMTUsI8r87bTX2EeoPUqLzes
uWnSwYSPJCzf5nipqZG++RUiltY15AZer4xdzvKk3jNIreYrLhiCjTfg558b
cAwSg/0Q4cGJ4WrmXw4ei4zVhWHRpQ0mwZrcZoE8NQf2s6C5Wep0o9wGwq4J
0VNd0XASANZGtLgt+LyaqffsW1NKPjemhtbLvFxuYBnayimWGIaS86XB7zTT
DP84SdYIDU6C3Z9j79sZxOixDMswdOzOG6e4KKMFMD3p/t5KRUqR3mNywNm/
QJRuBpOyTwyzpE5JVP4ypL6j81dvLztgp+lmOaocOPZ6e0OcX6ceCvuE4lSq
kUUqRBNCA2MR9Q0D6IFXw8ntIdmPn+eEGusSKenATJfTr6apMZcf4z4DHfo4
7ohOS0l8xNKMxDeWpqCQtr8TRsG0rGcd5z5BW36Ttt9LFBQR61X/oSKE3cmu
HSOBJYawoFhnEPBF5snRDlEEcUhrOx+4ygm5infSA0JwRDPc5vSoYN+P88/h
qZoVMW/sOeOQyoSilkUVLBB86kkQfYNIacq0zN1ASPZuni/NrSkix3SmJlfE
qsHNvqopYqi0sb1UERhOWwlOypuAD/9hYiB5ry9ms1eShPx0Af8cFV4BQmte
E3HZlEvDGB3BtWxsANNR7oDEvMipUtfkIhekztArmLVN+Sp+cxzke3KbMCii
0FYPDBGjtx+ub6iSp//Vu/f8+er1f344v3p9Rp+vf5pdXHQfEj/i+qf3Hy7O
+k/9m6/ev337+t2ZvIynavAoGb2d/XMk7HX0/vLm/P272cWIjNEMQkfXnITm
FK7QETTXQPfaJQPP/OHV5f/89/GJ+vz537C/J8fHL7988X+8OH5+gj8IwmW1
DtHHpPtNgmxrNFEA+EYOgKjADXLYQnO+eSgASTUVA998JM3cnqq/zNPq+OSv
/gFtePAw6GzwkHW2+2TnZVHinkd7lum0OXi+pemhvLN/Dv4Oeo8e/uVvVIep
yfGLv/01ocSzr2Plg7/zeox7pM66zL33ndeBRyZJ91H5vekGSbFqyNBSye0j
SVLIzVDcIigiSgHqhpxBoSRRHvMRSv+gEYWE/nwQdHuWsJTlyfRFR3sVdKbS
VVk6IUPkI5zUfVrqM2WEJ14CnwbqgTboReE/HXuSjUScBDpVlCa3wVz4tYtZ
DwNFIIPfRSUMzTn9M4Z5z4kByRH534NuGR55OkZqFVj3BvNF5dd0uJcHD8zG
kj1Sb8u5BQcK676ifWVGsAry/LKib3sVOV9eWcpi4F8bBoUl5bVMimRK13VI
8SR2IFzEBmWxrqAZKxQQtmLFyD5F1X5cyECmuLd1WcgmygW0rnI4ABIShoFn
Gk43QrtN7FnC3kQuuBWzUBi+rA0jj7KwRGaJifSklxFKCmfpUSzCbEg3XrDe
Omu9UUXZgJmATBcN9AGcXBjtLDFLmoqzy5bRYZ08uNUu2NJ8kp9oPl/I0nSs
3YFmOkF4a84MVUWTId5KaiNKJQYdlTUMSFvujcrkeg3Wh2U1/JjK7DlZFvwE
TL+V8r6tYGZqYxA7gxUeaHqQIqLXRvMQUAUbijp2Lrv0+XLbr5hD8liukwhY
hpXMyrQ1AgxFN8TuyUMvdFeircEAGqhYGiaavNyWjEaNXRvaHB7Pkcn7+Kb4
NZ8wPZezKi95divmbPQd+wPMxU5Ly3ZYtCjLpkI512yV7wNOQWaX7jtJ0Zfv
dVvwdmH+jANmJ0jGnnRmJXtBiLYoaDusYOuC1FgnpmWxgbZwggWMSCPY74nG
t9zqs1RIlNDUGtBBa/rZucDYr/wxiSG6141vXOE5ENjphfG1/d6JtowEA6Ym
7kPRfB2YEIhiTp0/6I0L2IynDMMR7nLaoF5JnsNseB7M7qvVxDscBNaYSvwq
rjr7HgcdqOBt6ZKEQxWUhzC4dJgQmr5EYKyoDSLCUN+ikAUw6vr1K7Z1eAFB
XuFLBqUNpYgUSBh1Cp71rSWu9w65rnxNjsiFHdfrkk/8ntXnR76K55JzZxc7
3aao9eNQKSFvIl2aYmk611qLn8RNDi5qROuCM4gSfzwSNXJ0jpRScN8ee3It
XgRB2y6Vo15DKMKc375HPammiPbK1ojnuTK1HBG8+c7iY/kbhRLw0QcjOTjF
BimhdW47N3MrSciGb1mRykOTQ/KtNNzhvEGRQx0edG0vMtC1XWKinAzU5Vra
ru86RdURPFh2tIvvQQUHzhi1v3HEkmUG3Ct3hx1tiNzSp+jJpWT+jKhEWzvq
w1wZbJDKrCR50/eK8s14b60jmw25yXwCWqh7nbfdgO1CsdnqIXCS8tKEEwFi
kCgGQDuGaba3jA9VNwTUbKtz3XfhW1+qSXTVYYuB+XD5F7XHQTJF+oyPBbgH
VMRtYE/buBQTyKQVpMKrO1X262ACADa1CqTxvDtG1IuMigdVKecgdJImA6Sr
Nrs8l8I5t/Na18RVSH1eGZkAclouC/u7UY9tdX9C1dFU15WePpZOBasYAvDU
NNWShAA8hi+aGvmXbO4Djr2QRxIyEsFhq4Vwp/V3ooeOwm6j7i6mX2F1buaW
c67iM0FtBp6FeYiBebtLGOctmniA09Ip25adnG97/9NkRgqAOtscGTdYT5IX
ZRVPLWmrg4a/N25kTDYzAxvZjKj9V/xIzSHRnYtpZHQAlqPQ8S2xzDAfymil
GmFEvIPCDLH78+W7oTzEK2iG2nqCGvz/sSP/HjYXxnIc9EmTVsckXrxxI0U4
NTLozdBf0SJxAfb92O31Z9/XSTk75vmOpzarumyXK54GG+gZ5d71mk3ljwGJ
ivsgDWcxmhOgRxhBAur7CbGVuiUuWPgUP1Y4I4/vktFjCcDtQCctD2Oa+onl
hMTCHyMHA2BakC462VyOfCeR2S63ILScYbDrBesD5xYEZ1Q1UhGV9Ud/tJ7M
djiOqEwoAbpkIs5E/WRdh8OGkH0Ls+QMSoUTyELKVMhYbqMXlBfuSXNyTvVs
wlL2Jzy0cSaykbtOOjcWE3Sw3jtYcAEEdIWEwsEBDkeAQyN/MXk++Y+C+iz+
2svBs5PTxeLl/PT06OWzcd+bOxwPsfuBe/X4E7WB5+g6mJCgAmsjr9g+ifgq
qbdkDzeL4dRE1OmUxfIpuG9ENig2VoQVDE9wqMfET+j4MbxP5xdhuJSIkuzw
jqVDQAJ1bujq3QQ25ADvri/Hfbv1TxCBDCjeVrnZjxx9iUPkw0d9H5uD+Jfk
Hyrya66wzgsUS9Stlog5M7neJHLQLIrnFiT3TbhbySdMfYx2uVcTE1+C40Hw
6Jg5VvOWLG98p1icMSrdqbrKN3vPRNPachW554xTCFwlR7okeHyq2/Wuu0Pd
sQpEkzr8/pDAd/g/wKh573HE9Lh1ZbLxdgjwHQyJ+RiWKVioMm+LwBF821rG
othtmO7zWFITQpaythxn7W089UkxK6FvAoY5KFm+t1MT9Zj/1Wng2OfzYMeG
UhFsTJkMQFVkE9CvSkreA+zCUVhq72a/tUTlZYLUUFrgpFrRnbBDpRdNh1oi
hFT1Wx1v8lLKSA3tPwmtpe1wGIeS2Z90YlGAZc5lk48NX6AzDoeI8KZzg0MJ
f+QA7Wrk/75HD5YJxfplJVouMDvxZMjwocp4KfDkSi+13BXZ4dz+uJEa9u5U
jW587lTSFE4BNMa3buAvDERBdygX2/6iRXfyEkUAnyZikL8agld90w6Tge0I
Sx2ORgFGbS3UCSW1HeaSM2ngzc1F4OURUr+DWzwOpzbUJfGHja5s69T4Y0Yi
JeQt09GQR5XcpIjiJghDkROK8bmRNNxylAVJZMaMj5n6b1hzPAknMdejXYf0
XBLQWjDc8GyzOw+U9gRRlEETD8t1uvK+xetR8BBv6NcNRuGvd0XwtKFbjG5X
MVWUZBOvKeVQ60IJ180iJxbdxSxm1D6fSzOh05RMUZumrYueZArOCYnybF16
5My2sQTwGbUAXbGi4qjWD9TqdqdJ8o1Sb3XR04Euh5tPXJfng7ndFvvimxkF
34Bo6jJXHVHpRO1ysFdBp5258QrKyOikdRILmeEbOV3240PGDqrBa3RZkfbO
HdVPoKR8cBSQi1YO/k5HP3S1AuxZfdVM1IpabNi6voGko/wSMve6pbsVBLve
gHJ07GO2v5UF19FLLhMDd+B5IVtNfVigzbLtNqf78KFgpMKSyMjdIceLdCD9
mlXppPkb/JNPzeq26t2zh/qe8gWKBPaJZxCbxaGW1teyjO+wUSssVo+/TciU
ess0dr223O6mzgAc0vm7e5p5DCejtsp8Kz8+36RWLrZuV3zvhO+OhRz6VWiN
KAfHIySkkoaOtqj68GCa7QWuYXOGUhy0syY/lh157+55LM3IljNZdz0uYpfD
dpfvrbuoOSaVA1Ln2m+Tfbiiyx4E/tJDzixdBiL+Ooy0uaEGcqgKu0Hn15eu
a04TCkTf+W3wwRgTnFQ76oRJhzWtW6mNycdDQSJkxHdkunsmFFD9JUVqNBVN
OBjjxgS48bDf4xXdnfubXPytJ2cL9ijZlQuTxXc5WS5s77Eb3oTk7Ujef5Bb
Lh0ad0Hc9fqUIVv0mSc4q3dDR42BdeyH8cWqrbuwA5qAlG8e9GaavApnMr6B
67MP6gDLbU7uEPOlj+CgdPFT9w0n5kfqIGjOrxX8jFVhG75YprubsbHodI0n
ChuXmkKD+kAympivzoUeHUsgzgKmxNxKjn/EPhSifHbDBt0yoeyBmkLdqS1E
PiI3IRIYHMgbsp8G1Yot7v6Ay7mALl3DlG/i+1I22Eu7/m4F5zn5WtgaW0Y6
eXSAMLxx5/cW+2qBbLYqq2mHKi8YVfbev77tuljOd1m9guUIkSJW2qmCYNfU
EyGoHcLXzA2bYd1l1AGcjUP23rqBFlc9gJeC3Yj7JFVZLhhcOVFIqIfzMSYd
1PiSlEQnqbUfCDioF4il/oZOdB8vbqcSX5BYc2Fju83+YauPQvrBH82dUTKx
4U4v68aoVytK2Ln6/IjnNJNUHkwQW1+S5Kvg/thtlVH+vdC+j/HScwOtRrJG
GDvyItumu/dJEWng+SP9lel95EqjUu7DopI1+UI6gsN16eaSJ4lkoHCRaQI8
4JS3poYN5QIJbMraqfFNfgojva64TQ02zbyNiQ5fLsio5079EL73XYhVhhIP
rjtyOR2W3Wr9DW7Y81UIujCnc3hLxofLUA4dCmB7SyqYml6wQd+QApFPsWm/
V7PJj61GQfDR/67idppcsQm5ZS2EquzbuExEeSFn4lPTvnVGns46CG0u/mpw
zTSwZ7BAOXvo3Yd939ClzX6C2ro775tb3vja74g1B6ehH1p0ZxUkqd+yJ4VR
Bd770W+tzokdfc2T9jmqvyrLpwTM+Ua8vEeAe1s3mJTOVe8pnQVWd/Dz5btD
3yccTdWsu6XLpTl/pssT1CEhkzXSsI+Pe/l2FXFbOYxnUxLzJ8nL3ZsV0kDm
a3dTJfc1uEZJqTsXUh/zfz7zlJNY7utzciLNRiYOJJNcKerSEPJ1KQ6Vdr2R
yAjdGWEOWwyVfkhzK0Z5CNd6GZeZikFxTEUB2+GiOBPg/r4DbcxnL/rhCnWj
+dCbthHOWj3RDjJJH7RPSOzNWw1+aZj1FwZhk3C2hkCgLl/Dp2uhOffR/zxo
sBX6LZ2v0MOVR/6VTl/JePq2VfRFRpYeVafKzgj/MgroN1rqQm8M3ekK78tt
Qv8LIj9WOMF8E8VEtAVO7v+viIgDye2D8K2QUSNiGCpnUYWrk+rpN33xzgHL
q8Jz7T8RMmvqF/lgiObfPoQiIbZXCjjKmysIOeBfyiwWdFpFgC6/e2C2h8oy
PhiQeqwLMCkoQAVdl9DoTjzRduKVxG4gh1tsZGx0/sUs318/KPimtfSZugGc
9LhLS8Tayo0SqXvxXtnd1m5WnBvkPgbtS7ppIJGmnohOogji0j/6iVZ8oCvM
1v84zBk6UvObggqyzN9JkMPVmDbs2B9eYT4B8AMKfP4c6JT/WY33wy9f+OpD
R8m2rwe9735NtqdrKvFL9BQmr8t731Ys+ScaeU+HBLR3e9ckJVftjV1yGqK3
PPu6N3J1JmRnsiMxOWl+SE/At+65OuBLqn+CPzKh9SxtsNd4pfKPdt1dvtw5
vt1Zsbvfp85n72a7d68GN866NnV3dYS9jd8ciup/jkcNKZp7lhLg5SZbMjdN
Pp/KnSeT/ftoAf82oy+CSfIbWedRJ7d3RrBeI3TJcHKdh7ZdmZJgy/dCbM2d
KU4F3Lei6wUkyKl6S5P8YB1KhbF6W640Few/lG2qM21R8F8gyxS/l9h6bpvG
jum3sfgD6RJLjQlTa+ILr9M7k4/VdevgKD9BsaBb/MPdn8BPcoPa7EdNl8sv
ACFk6xuscmHWxNPO9L3FH2U7VpfUoFfX6Qoehej+3/+qEW0/bwpMTkshYEGk
luofFgXy/wFt3l6Aij4AAA==
</rfc>
 End of changes. 44 change blocks. 
597 lines changed or deleted 215 lines changed or added

This html diff was produced by rfcdiff 1.48.