<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4.4) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-v6ops-prefer8781-07" number="9872" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.30.0 -->version="3" updates="" obsoletes="" xml:lang="en"> <front> <!--[rfced] FYI - To closer reflect the full title of the document, we have updated the short title as follows. Note that this appears in the running header of the PDF output. Original: Prefer RFC8781 Current: IPv6 Prefix Discovery --> <titleabbrev="Prefer RFC8781">Recommendationsabbrev="IPv6 Prefix Discovery">Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis</title> <seriesInfoname="Internet-Draft" value="draft-ietf-v6ops-prefer8781-07"/>name="RFC" value="9872"/> <author fullname="Nick Buraglio"> <organization>Energy Sciences Network</organization> <address> <email>buraglio@forwardingplane.net</email> </address> </author> <author fullname="Tommy Jensen"> <organization/> <address> <email>tojens.ietf@gmail.com</email> </address> </author> <author fullname="Jen Linkova"> <organization>Google</organization> <address> <email>furry13@gmail.com</email> </address> </author> <date year="2025"month="August" day="07"/> <area>ops</area>month="September"/> <area>OPS</area> <workgroup>v6ops</workgroup> <keyword>IPv6</keyword> <keyword>DNS64</keyword> <keyword>PREF64</keyword> <keyword>NAT64</keyword> <keyword>CLAT</keyword> <abstract><?line 62?><t>On networks providing IPv4-IPv6 translation(RFC7915),(RFC 7915), hosts and other endpoints need to know the IPv6 prefix(es) used for translation (the NAT64prefix, RFC6052).prefix (RFC 6052)). This document provides guidelines for NAT64 prefix discovery, specifically recommending obtaining the NAT64 prefix from the Router Advertisement option(RFC8781)(RFC 8781) when available.</t> </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> <middle><?line 66?><section anchor="introduction"> <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. When a network provides NAT64, it is advantageous for endpoints to acquire the network's NAT64 prefixes (PREF64). Discovering the PREF64 enables endpoints to:</t> <ul spacing="normal"> <li> <t>Implement the customer-side translator (CLAT) function of the 464XLAT architecture <xref target="RFC6877"/>.</t> </li> <li> <t>Translate IPv4 literals to IPv6 literals(Section 7.1 of <xref target="RFC8305"/>).</t>(<xref target="RFC8305" section="7.1"/>).</t> </li> <li> <t>Perform local DNS64 <xref target="RFC6147"/> functions.</t> </li> <li> <t>Support applications relying on IPv4 address referral(Section 3.2.2 of <xref target="RFC7225"/>).</t>(<xref target="RFC7225" section="3.2.2"/>).</t> </li> </ul> <!--[rfced] To avoid the repetition of "based" twice in the same sentence and to clarify "[RFC7051] analysis", may we update this sentence as follows? Original: [RFC7050] introduces the first DNS64-based mechanism for PREF64 discovery based on [RFC7051] analysis. Perhaps: [RFC7050] introduces the first DNS64-based mechanism for PREF64 discovery per the analysis described in [RFC7051]. --> <t>Dynamic PREF64 discovery is useful to keep the NAT64 prefix configuration up-to-date, particularly for unmanaged endpoints or endpointswhichthat move between networks. <xref target="RFC7050"/> introduces the first DNS64-based mechanism for PREF64 discovery based on <xref target="RFC7051"/> analysis. However, subsequent methods have been developed to address the <xref target="RFC7050"/> limitations.</t> <t>For instance, <xref target="RFC8781"/> defines a Neighbor Discovery <xref target="RFC4861"/> option for Router Advertisements (RAs) to convey PREF64 information to hosts. This approach offers several advantages(Section 3 of <xref target="RFC8781"/>),(<xref target="RFC8781" section="3"/>), including fate sharing with other host network configuration parameters.</t> <!--[rfced] May we clarify the citations in the text below as follows? Original: Due to fundamental shortcomings of the [RFC7050] mechanism (Section 4), [RFC8781] is the preferred solution for new deployments. Perhaps: Due to fundamental shortcomings of the mechanism defined in [RFC7050] (see Section 4 for more details), [RFC8781] describes the preferred solution for new deployments. --> <t>Due to fundamental shortcomings of the <xref target="RFC7050"/> mechanism (<xref target="issues"/>), <xref target="RFC8781"/> is the preferred solution for new deployments. Implementations should strive for consistent PREF64 acquisition methods. The DNS64-based mechanism of <xref target="RFC7050"/> should be employed only when RA-based PREF64 delivery isunavailable,unavailable or as a fallback for legacy systems incapable of processing the PREF64 RA Option.</t> </section> <section anchor="terminology"> <name>Terminology</name><t>DNS64: a<dl spacing="normal" newline="false"> <dt>DNS64:</dt><dd>A mechanism for synthesizing AAAA records from A records, defined in <xreftarget="RFC6147"/>.</t> <t>NAT64: atarget="RFC6147"/>.</dd> <dt>NAT64:</dt><dd>A mechanism for translating IPv6 packets to IPv4packetspackets, 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(<xref target="RFC6144"/>)mode <xref target="RFC6144"/> or stateless mode(e.g. customer-side translator, CLAT,<xreftarget="RFC6877"/>).target="RFC6877"/> (e.g., customer-side translator (CLAT)). This document uses "NAT64" as a generalized term for atranslatortranslator, which uses the stateless IP/ICMPtranslation algorithmTranslation Algorithm defined in <xref target="RFC7915"/> and operates within a framework for IPv4/IPv6 translation described in <xreftarget="RFC6144"/>.</t> <t>PREF64target="RFC6144"/>.</dd> <dt>PREF64 (Pref64::/n or NAT64 prefix):</dt><dd>An IPv6 prefix used for IPv6 address synthesis and for translating network addresses and protocols from IPv6 clients to IPv4 servers using the algorithm defined in <xref target="RFC6052"/>.</dd> <dt>Router Advertisement (RA):</dt><dd>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> <!--[rfced] We note that some of the acronyms listed in the Terminology section are formatted in different ways (e.g., expanded form in parentheses, acronym in parentheses, and expanded form in description). To make these consistent, may we update to have the expanded form appear in the description of the acronyms listed? Original: PREF64 (or Pref64::/n, or NAT64 prefix): An IPv6 prefix used for IPv6 address synthesis and for network addresses and protocols translation from IPv6 clients to IPv4 servers using the algorithm defined in<xref target="RFC6052"/>.</t> <t>Router[RFC6052]. Router Advertisement (RA): A packet used by Neighbor Discovery<xref target="RFC4861"/>[RFC4861] and SLAAC to advertise the presence of the routers, together with other IPv6 configurationinformation.</t> <t>SLAAC:information. SLAAC: StateLess Address AutoConfiguration, [RFC4862] Perhaps: PREF64: Pref64::/n or NAT64 prefix. An IPv6 prefix used for IPv6 address synthesis and for network addresses and protocols translation from IPv6 clients to IPv4 servers using the algorithm defined in [RFC6052]. RA: Router Advertisement. A packet used by Neighbor Discovery [RFC4861] and SLAAC to advertise the presence of the routers, together with other IPv6 configuration information. SLAAC: Stateless Address Autoconfiguration [RFC4862]. --> <dt>SLAAC:</dt><dd>Stateless Address Autoconfiguration <xreftarget="RFC4862"/></t> <t>Thetarget="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 inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="recommendations-for-pref64-discovery"> <name>Recommendations for PREF64 Discovery</name> <section anchor="deployment-recommendations-for-endpoints"> <name>Deployment Recommendations for Endpoints</name> <t>Endpoints <bcp14>SHOULD</bcp14> attempt to obtain PREF64 information from RAs per <xreftarget="RFC8781"/>target="RFC8781"/>, instead of using the <xref target="RFC7050"/> method. In the absence of the PREF64 information in RAs, an endpoint <bcp14>MAY</bcp14> choose to fall back to the mechanism defined inRFC7050.<xref target="RFC7050"/>. This recommendation to prefer the <xref target="RFC8781"/> mechanism over the one defined in <xref target="RFC7050"/> is consistent withSection 5.1 of<xreftarget="RFC8781"/>.</t>target="RFC8781" section="5.1"/>.</t> </section> <section anchor="deployment-recommendations-for-operators"> <name>Deployment Recommendations for Operators</name> <t>Network operators deploying NAT64 <bcp14>SHOULD</bcp14> provide PREF64 information in Router Advertisements per <xref target="RFC8781"/>.</t> <section anchor="mobile-network-considerations"> <name>Mobile Network Considerations</name> <t>While <xref target="RFC8781"/> support is widely integrated into modern operating systems on mobile endpoints, equipment deployed in mobile network environments often lacks abilities to include the PREF64 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. These environments are encouraged to incorporate <xref target="RFC8781"/> when made practical by infrastructure upgrades or software stack feature additions.</t> </section> <section anchor="migration-considerations"> <name>Migration Considerations</name> <t>Transitioning from the <xref target="RFC7050"/> heuristic to using the <xref target="RFC8781"/> approach might require a period of time where both mechanisms coexist. How long this may take depends on the endpoint footprint, particularly the presence and number of endpoints running outdated operatingsystems, whichsystems that do not support <xref target="RFC8781"/>. Operators are advised to take those factors into account prior to removing support for the <xref target="RFC7050"/> heuristic, noting that it is still safe to add support for the <xref target="RFC8781"/> approach since endpoints that support it will always prefer it over <xref target="RFC7050"/> if they follow RFC requirements.</t> <t>Migrating away from DNS64-based discovery also reduces dependency on DNS64 in general, thereby eliminating DNSSEC and DNS64 incompatibility concerns(Section 6.2 of <xref target="RFC6147"/>).</t>(<xref target="RFC6147" section="6.2"/>).</t> </section> </section> </section> <section anchor="issues"> <name>Existing Issues withRFC7050</name>RFC 7050</name> <t>DNS-based discovery of the NAT64 prefix introduces some challenges, which make this approach less preferable than the latest developed alternatives (such as the PREF64 RAOption,Option <xref target="RFC8781"/>). This section outlines the keyissues,issues associated with <xreftarget="RFC7050"/>,target="RFC7050"/> with a focus on those not discussed in <xref target="RFC7050"/> or in the analysis of solutions for hosts to discover the NAT64 prefix(<xref target="RFC7051"/>).</t><xref target="RFC7051"/>.</t> <t>Signalling PREF64 in the RA option addresses all issues outlined in this section (seeSection 3 of<xreftarget="RFC8781"/>target="RFC8781" section="3"/> for details).</t> <section anchor="dependency-on-network-provided-recursive-resolvers"> <name>Dependency on Network-Provided Recursive Resolvers</name> <!--[rfced] As "are network-specific attributes" seems to directly describe "NAT64 and the exact values" rather than their presence, may we remove "the presence of" from this sentence? Original: Fundamentally, the presence of the NAT64 and the exact value of the prefix used for the translation are network-specific attributes. Perhaps: Fundamentally, the NAT64 and the exact value of the prefix used for the translation are network-specific attributes. --> <t>Fundamentally, the presence of the NAT64 and the exact value of the prefix used for the translation are network-specific attributes. 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 or runs a local recursive resolver, the corresponding name resolution APIs and libraries 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"/>. However, it has been observed that very few <xref target="RFC7050"/> implementations support the <xref target="RFC8880"/> requirements for special treatment of 'ipv4only.arpa.'. As a result, configuring such systems and applications to use resolvers other than the one provided by the network breaks the PREF64 discovery, leading to degraded user experience.</t> <t>VPN applications may override the endpoint's DNS configuration, for example, 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 cannot 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 of network traffic is routed into the VPN tunnel), endpoints may not discover the necessary PREF64, which negatively impacts their connectivity on IPv6-only networks.</t> <t>If both the network-provided DNS64 and the endpoint's resolver happen to utilize the Well-Known Prefix(64:ff9b::/96,(64:ff9b::/96) <xreftarget="RFC6052"/>),target="RFC6052"/>, the endpoint 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 new network lacks NAT64 entirely or uses a network-specificNAT64prefix(NSP,(NSP) <xreftarget="RFC6144"/>).</t>target="RFC6144"/> for NAT64.</t> <t>Signalling PREF64 in an RA option decouples the PREF64 discovery from the host's DNSresolversresolver configuration.</t> </section> <section anchor="network-stack-initialization-delay"> <name>Network Stack Initialization Delay</name> <t>When using SLAAC, an IPv6 host typically requires a single RA to acquire its network configuration. For IPv6-only endpoints, timely PREF64 discovery is critical, particularly for those performing local DNS64 or NAT64 functions, such as CLAT(<xref target="RFC6877"/>).<xref target="RFC6877"/>. Until a PREF64 is obtained, the endpoint's IPv4-only applications and communication to IPv4-only destinations are impaired. The mechanism defined in <xref target="RFC7050"/> does not bundle PREF64 information with other network configurationparameters,parameters and requires at least one round-trip time (to send a DNS request and receive a response) after the network stack configuration is completed.</t><t>Advertising PREF64 in RA, on<t>On the other hand,elminatesadvertising PREF64 in an RA eliminates the period when the host obtains IPv6 addresses and defaultrouters,routers but no PREF64.</t> </section> <section anchor="latency-in-updates-propagation"> <name>Latency in Updates Propagation</name><t>Section<!--[rfced] FYI, we have formatted the following quoted text to appear in <blockquote>. Please review and let us know of any objections. Original: Section 3 of<xref target="RFC7050"/>[RFC7050] states: "The node<bcp14>SHALL</bcp14>SHALL cache the replies it receives during the Pref64::/n discovery procedure, and it<bcp14>SHOULD</bcp14>SHOULD repeat the discovery process ten seconds before the TTL of theWell-KnownWell- Known Name's synthetic AAAA resource record expires." As a result, once a PREF64 is discovered, it will be used until the TTL expired, or until the node disconnects from the network. Current: Section 3 of [RFC7050] states: | The node SHALL cache the replies it receives during the Pref64::/n | discovery procedure, and it SHOULD repeat the discovery process | ten seconds before the TTL of the Well-Known Name's synthetic AAAA | resource record expires. As a result, once a PREF64 is discovered, it will be used until the TTL expires or until the node disconnects from the network. --> <t><xref target="RFC7050" section="3"/> states:</t> <blockquote>The node <bcp14>SHALL</bcp14> cache the replies it receives during the Pref64::/n discovery procedure, and it <bcp14>SHOULD</bcp14> repeat the discovery process ten seconds before the TTL of the Well-Known Name's synthetic AAAA resource record expires.</blockquote> <t>As a result, once a PREF64 is discovered, it will be used until the TTL expires or until the node disconnects from the network. There is no mechanism for an operator to force the PREF64 rediscovery on the node 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. This method has two significant drawbacks:</t> <ul spacing="normal"> <li> <t>Many networks utilize external DNS64 servers and therefore have no control over the TTLvalue,value if the PREF64 needs to be changed or withdrawn.</t> </li> <li> <t>The PREF64 changes need to be planned and executed at least TTL seconds in advance. If the operator needs to notify nodes that a particular prefix must not be used(e.g.(e.g., during a network outage or if the nodeslearntlearned a rogue PREF64 as a result of an attack), it might not be possible without interrupting the network connectivity for the affected nodes.</t> </li> </ul><t>Mechanism<t>The mechanism defined in <xref target="RFC8781"/> allowsto notifynotifying hosts about PREF64 changesimmidiately,immediately by sending an RA with updated information.</t> </section> <section anchor="multihoming-implications"> <name>Multihoming Implications</name><t>Section 3 of <xref target="RFC7050"/><t><xref target="RFC7050" section="3"/> requires a node to examine all received 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 different DNS64 servers belonging to different ISPs might return different PREF64s. 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 belongs 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. 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 for a given PREF64 and/or send traffic to the incorrect uplink.</t> <t>Advertising PREF64 in RAs allows hosts to track which PREF64 was advertised by which router and use that information to select the correctnexthop. Section 8 ofnext hop. <xref section="8" target="I-D.ietf-v6ops-claton"/> discusses this scenario in more details.</t> </section> <section anchor="security-implications"> <name>Security Implications</name> <t>As discussed inSection 7 of<xreftarget="RFC7050"/>,target="RFC7050" section="7"/>, the DNS-based PREF64 discovery is prone to DNS spoofing attacks. In addition to creating a wider attack surface for IPv6 deployments, <xref target="RFC7050"/> has other security challenges, which are discussed below.</t> <section anchor="secure-channel-def"> <name>Definition of Secure Channel</name> <t><xref target="RFC7050"/> requires a node's communication channel with a DNS64 server to be a "securechannel"channel", which it defines to mean "a communication channel a node has between itself and a DNS64 server protecting DNS protocol-related messages from interception andtampering."tampering". This need is redundant when another communication mechanism of IPv6-related configuration, specifically RAs, can already be defended against tampering, forexampleexample, by enabling RA-Guard <xref target="RFC6105"/>. <!--[rfced] As the sentence below reads awkwardly, may we rephrase it as follows? Additionally, may we clarify that the mechanisms are being used, not the RFCs? Original: Requiring nodes to implement two defense mechanisms when only one is necessary when [RFC8781] is used in place of [RFC7050] creates unnecessary risk. Perhaps: When the mechanism defined in [RFC8781] is used in place of the one defined in [RFC7050], nodes only need to implement one defense mechanism; requiring nodes to implement two defense mechanisms creates an unnecessary risk. --> Requiring nodes to implement two defense mechanisms when only one is necessary when <xref target="RFC8781"/> is used in place of <xref target="RFC7050"/> creates an unnecessary risk.</t> </section> <section anchor="secure-channel-example-of-ipsec"> <name>Secure Channel Example of IPsec</name> <t>One of the two examples that <xref target="RFC7050"/> defines to qualify 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 not supported as a practice by any common operating system DNS client. While they could, there have also since been multiple mechanisms defined for performing DNS-specificencryptionencryption, such as those defined in <xreftarget="RFC9499"/>target="RFC9499"/>, that would be more appropriately scoped to the applicable DNS traffic. These are also compatible with encrypted DNS advertisement by the network using Discovery of Network-designated Resolvers <xreftarget="RFC9463"/> thattarget="RFC9463"/>, which would ensure the clients know in advance that the DNS64 server supported the encryption mechanism.</t> </section> <section anchor="secure-channel-example-of-link-layer-encryption"> <name>Secure Channel Example of Link Layer Encryption</name> <t>The other example given by <xref target="RFC7050"/> that would allow a communication channel with a DNS64 server to qualify as a "secure channel" is the use of a "link layer utilizing data encryption technologies". As of the time of this writing, most common link layer implementations use data encryption already with no extra effort needed on the part of network nodes. While this appears to be a trivial way to satisfy this requirement, it also renders the requirement meaningless since any node along the path can still read the higher-layer DNS traffic containing the translation prefix. This seems to be at odds with the definition of "securechannel"channel", as explained in <xref section="2.2" sectionFormat="of" target="RFC7050"/>.</t> </section> </section> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>Obtaining PREF64 information using RAs improves the overall security of an IPv6-only endpoint as it mitigates all attack vectors related to a spoofed or rogue DNS response, as discussed inSection 7 of<xreftarget="RFC7050"/>.target="RFC7050" section="7"/>. Security considerations related to obtaining PREF64 information from RAs are discussed inSection 7 of<xreftarget="RFC8781"/>.</t>target="RFC8781" section="7"/>.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>This documentdoes not introduce anyhas no IANAconsiderations.</t>actions.</t> </section> </middle> <back> <displayreference target="I-D.ietf-v6ops-claton" to="CLAT"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC7050"> <front> <title>Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis</title> <author fullname="T. Savolainen" initials="T." surname="Savolainen"/> <author fullname="J. Korhonen" initials="J." surname="Korhonen"/> <author fullname="D. Wing" initials="D." surname="Wing"/> <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 access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack 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 Protocol 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</title> <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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</title> <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 protocol 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7050.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8781.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name><reference anchor="RFC4861"> <front> <title>Neighbor Discovery for IP version 6 (IPv6)</title> <author fullname="T. Narten" initials="T." surname="Narten"/> <author fullname="E. Nordmark" initials="E." surname="Nordmark"/> <author fullname="W. Simpson" initials="W." surname="Simpson"/> <author fullname="H. Soliman" initials="H." surname="Soliman"/> <date month="September" year="2007"/> <abstract> <t>This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4861"/> <seriesInfo name="DOI" value="10.17487/RFC4861"/> </reference> <reference anchor="RFC4862"> <front> <title>IPv6 Stateless Address Autoconfiguration</title> <author fullname="S. Thomson" initials="S." surname="Thomson"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <author fullname="T. Jinmei" initials="T." surname="Jinmei"/> <date month="September" year="2007"/> <abstract> <t>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t> </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-Abegnoli"/> <author fullname="G. Van de Velde" initials="G." surname="Van de Velde"/> <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.<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6105.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6052.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6144.xml"/> <!-- [rfced] Thecanonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution thatfollowing reference isnon-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filteringnot cited in thelayer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. This document is not an Internet Standards Track specification;text. Please let us know where itis published for informational 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 configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [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 inshould be cited; otherwise, it will be deleted from thecontext of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4references section. [RFC6146] Bagnulo, M., Matthews, P., andIPv6 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>StatefulI. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4Servers</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 allows 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 several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually requiredServers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/rfc/rfc6146>. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6146.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7225.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7915.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6147.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6877.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7051.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8880.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8305.xml"/> <!-- [CLAT] [I-D.ietf-v6ops-claton] draft-ietf-v6ops-claton-06 IESG State: I-D Exists as of 09/09/25 --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-claton.xml"/> </references> </references> <!--[rfced] FYI - We have alphabetized the names listed in theIPv6 client orAcknowledgments section. We believe that was theIPv4 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 Usingintent as only two were out of order. Let us know if you prefer thePort Control Protocol (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) optionoriginal order. --> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The authors would like tolearnthank theIPv6 prefix(es) used by a PCP-controlled NAT64 device to build IPv4-converted IPv6 addresses. This option is neededfollowing people forsuccessful communications when 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 describestheir valuable contributions: <contact fullname="Mike Bishop"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Lorenzo Colitti"/>, <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> </back> <!--[rfced] Throughout theStateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4text, "RA Option" andIPv6 packet headers (including ICMP 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 IPv6 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 records. DNS64 is"RA option" are usedwith an IPv6/IPv4 translator to enable client-server communication 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 how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK]</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</title> <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. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service 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 Prefix</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>Hostsinconsistently. Please review these occurrences andapplicationslet us know if/how they maybenefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64be made consistent. --> <!--[rfced] There arepresent inanetwork. This document analyzes all proposed solutions (known at the timenumber ofwriting) for communicating whetherinstances throughout thesynthesisdocument where an RFC citation istaking place, what address format was used, and what IPv6 prefix wasusedby the NAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending 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 Clients 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 purpose. However, in its Domain Name Reservation Considerations section (Section 8.1), that specification (RFC 7050) indicates that the name actually has no particularly special propertiesas an adjective. To clarify thatwould require special handling.</t> <t>Consequently, despitethewell-articulated special purposecontent ofthe name, 'ipv4only.arpa' wasan RFC is being described, notrecorded intheSpecial-Use Domain Names registry as a name with special properties.</t> <t>This document updatesRFC7050. It describes the special treatment required and formally declares the special properties of the name. It also adds 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 Network-designated Resolvers (DNR)</title> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.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>Thisdocumentspecifies 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 hostitself, may we rephrase these instances? An example from Section 1 can be seen here: Original: However, subsequent methods have been developed tolearn an Authentication Domain Name together with a list of IP addresses and a set of service parametersaddress [RFC7050] limitations. Perhaps: However, subsequent methods have been developed toreach 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 protocols, and by operators of DNS systems, has changed in the decades sinceaddress theDNS was first defined. This document gives current definitions for manylimitations of theterms 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 clarifications. Comprehensive lists of changed and new definitions can be foundmechanism described inAppendices A[RFC7050]. --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> andB.</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 Concurrency</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, eachlet us know if any changes are needed. Updates ofwhich may have different performance and connectivity characteristics. Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network, clients that attempt multiple connectionsthis nature typically result inparallel have a chance of establishing a connectionmorequickly. This document specifies requirementsprecise language, which is helpful foralgorithmsreaders. Note thatreduceour script did not flag any words in particular, but thisuser-visible delay and provides an example algorithm, referred toshould still be reviewed as"Happy Eyeballs". This document obsoletes the original algorithm 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> <?line 236?> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The authors would like to thank the following people for their valuable contributions: Mike Bishop, Mohamed Boucadair, Lorenzo Colitti, Tom Costello, Charles Eckel, Susan Hares, Nick Heatley, Gabor Lencse, Ted Lemon, David Lou, Peter Schmitt, Éric Vyncke, Chongfeng Xie.</t> </section> </back> <!-- ##markdown-source: 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==a best practice. --> </rfc>