One document matched: draft-ietf-softwire-stateless-4v6-motivation-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-softwire-stateless-4v6-motivation-03"
ipr="trust200902">
<front>
<title abbrev="Solution Motivations">Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions</title>
<author fullname="Mohamed Boucadair" initials="M." role="editor"
surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
<organization>Softbank Telecom</organization>
<address>
<postal>
<street></street>
<city>Tokyo</city>
<country>Japan</country>
</postal>
<email>satoru.matsushima@tm.softbank.co.jp</email>
</address>
</author>
<author fullname="Yiu Lee" initials="Y." surname="Lee">
<organization>Comcast</organization>
<address>
<postal>
<street></street>
<country>US</country>
</postal>
<email>Yiu_Lee@Cable.Comcast.com</email>
</address>
</author>
<author fullname="Olaf Bonness" initials="O." surname="Bonness">
<organization>Deutsche Telekom</organization>
<address>
<postal>
<street></street>
<country>Germany</country>
</postal>
<email>Olaf.Bonness@telekom.de</email>
</address>
</author>
<author fullname="Isabel Borges" initials="I." surname="Borges">
<organization>Portugal Telecom</organization>
<address>
<postal>
<street></street>
<country>Portugal</country>
</postal>
<email>Isabel@ptinovacao.pt</email>
</address>
</author>
<author fullname="Gang Chen" initials="G." surname="Chen">
<organization>China Mobile</organization>
<address>
<postal>
<street>53A,Xibianmennei Ave.</street>
<city>Beijing</city>
<region>Xuanwu District</region>
<code>100053</code>
<country>China</country>
</postal>
<email>chengang@chinamobile.com</email>
</address>
</author>
<date day="15" month="June" year="2012" />
<workgroup>Softwires Working Group</workgroup>
<abstract>
<t>IPv4 service continuity is one of the most pressing problems that
must be resolved by Service Providers during the IPv6 transition period
– especially after the exhaustion of the public IPv4 address
space. Current standardization effort that addresses IPv4 service
continuity focuses on stateful mechanisms. This document elaborates on
the motivations for the need to undertake a companion effort to specify
stateless IPv4 over IPv6 approaches.</t>
<!---->
<t></t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>When the global IPv4 address space is exhausted, Service Providers
will be left with an address pool that cannot be increased anymore. Many
services and network scenarios will be impacted by the lack of IPv4
public addresses. Providing access to the (still limited) IPv6 Internet
only won't be sufficient to address the needs of customers, as most of
them will continue to access legacy IPv4-only services. Service
Providers must guarantee their customers that they can still access IPv4
contents although they will not be provisioned with a global IPv4
address anymore. Means to share IPv4 public addresses are unavoidable
<xref target="RFC6269"></xref>.</t>
<t>Identifying the most appropriate solution(s) to the IPv4 address
exhaustion as well as IPv4 service continuity problems and deploying
them in a real network with real customers is a very challenging and
complex process for all Service Providers. There is nothing like a "One
size fits all" solution or one target architecture that would work for
all situations. Each Service Provider has to take into account its own
context (e.g., service infrastructures), policies and marketing strategy
(a document that informs Service Providers about the impact of the IPv4
address shortage, and provides some recommendations and guidelines, is
available at <xref target="EURESCOM"></xref>).</t>
<t>Current standardization effort that is meant to address this IPv4
service continuity issue focuses mainly on stateful mechanisms that
sharing of global IPv4 addresses between Customers is based upon the
deployment of NAT (Network Address Translation) capabilities in the
network. Because of some caveats of such stateful approaches the Service
Provider community feels that a companion effort is required to specify
stateless IPv4 over IPv6 approaches. Note that the stateless solution
elaborated in this document focuses on the carrier-side stateless IPv4
over IPv6 solution. In the context of address sharing, states should be
maintained in other equipments, e.g. customer premises equipment or
host.</t>
<t>This document provides elaboration on the need for carrier-side
stateless IPv4 over IPv6 solution.</t>
<t>More discussions about stateless vs. stateful can be found at <xref
target="RFC6144"></xref>.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:</t>
<t><list hangIndent="5" style="hanging">
<t hangText="State:"><xref target="RFC1958">as used in </xref>.</t>
<t hangText="Session state:">refers to an information state as
defined in Section 2.3 of <xref target="RFC2663"></xref>. In
particular, it refers to the state maintained by the NAT so that
datagrams pertaining to a session are routed to the right node.
Note, TCP/UDP sessions are uniquely identified by the tuple of
(source IP address, source TCP/UDP port, target IP address, target
TCP/UDP port) while ICMP query sessions are identified by the tuple
of (source IP address, ICMP query ID, target IP address).</t>
<t hangText="User-session state:">refers to session state belonging
to a given user.</t>
<t hangText="Stateful 4/6 solution">(or stateful solution in short):
denotes a solution where the network maintains user-session states
relying on the activation of a NAT function in the Service
Providers' network <xref
target="I-D.ietf-behave-lsn-requirements"></xref>. The NAT function
is responsible for sharing the same IPv4 address among several
subscribers and to maintain user-session state.</t>
<t hangText="Stateless 4/6 solution">(or stateless solution in
short): denotes a solution which does not require any per-user state
(see Section 2.3 of <xref target="RFC1958"></xref>) to be maintained
by any IP address sharing function in the Service Provider's
network. This category of solutions assumes a dependency between an
IPv6 prefix and IPv4 address. In an IPv4 address sharing context,
dedicated functions are required to be enabled in the CPE router to
restrict the source IPv4 port numbers. Within this document, "port
set" and "port range" terms are used interchangeably.</t>
</list></t>
</section>
<section anchor="motivations"
title="Why Stateless IPv4 over IPv6 Solutions are Needed?">
<t><!---->Below is provided a list of motivations which justify the need
for a stateless solution (in no particular order):<?rfc subcompact="yes"?><list
style="format (%d)">
<t>Minimizes impact on OSS and logging systems. Ideally, it does not
require OSS & logging systems that wouldn't be there in a pure
IPv6 network.</t>
<t>Does not require maintaining per-subscriber configuration on
active data plane network elements.</t>
<t>Scales in terms of IP forwarding capacity, rather than amount of
dynamic state, or new session creation rate.</t>
<t>Support a single architecture that allows 1:1 or N:1 (port range)
NAT44 usage without additional extensions.</t>
<t>Preserves current engineering practices (e.g., anycast-based
load-balancing).</t>
<t>Relies on IPv6 and supports transition to an IPv6-only
network.</t>
<t>Supports asymmetric routing to/from the IPv4 Internet.</t>
<t>Maximizes the ease of deployment and redundancy of nodes.</t>
<t>Readily supports a multi vendor environment (including
redundancy).</t>
<t>Allows direct user-user traffic flows (i.e., allows for
no-tromboning)</t>
<t>Retains today's user experience (NAT on CPE) and supports today's
operational model.</t>
<t>Does not require deployment of (additional) dynamic signaling
protocols to the end-user CPE beyond those already used.</t>
<t>Minimizes required non-regression testing effort.</t>
<t>Does not require organizational changes.</t>
<t>Assumes a clear separation between the service and the network
layer and therefore there is no interference between delivered
services and underlying network transfer capabilities.</t>
</list></t>
<t><?rfc subcompact="no"?></t>
<t>This section elaborates further on the aforementioned
motivations.</t>
<section title="Network Architecture Simplification">
<t>The activation of the stateless function in the Service Provider's
network does not introduce any major constraint on the network
architecture and its engineering. The following sub-sections elaborate
on these aspects.</t>
<section anchor="network_dim" title="Network Dimensioning">
<t>Because no per-user state <xref target="RFC1958"></xref> is
required, a stateless solution does not need to take into account
the maximum number of simultaneous user-sessions and the maximum
number of new user-sessions per second to dimension its networking
equipment. Like current network dimensioning practices, only
considerations related to the customers number, traffic trends and
the bandwidth usage need be taken into account.</t>
</section>
<section anchor="no_intra" title="No Intra-domain Constraint">
<t>Stateless IPv4/IPv6 interconnection functions can be ideally
located at the boundaries of an Autonomous System (e.g., ASBRs that
peer with external IPv4 domains); in such case intra-domain paths
are not altered: there is no need to force IP packets to cross a
given node for instance; intra-domain routing processes are not
tweaked to direct the traffic to dedicated nodes. Stateless
solutions optimize CPE-to-CPE communication in that packets don't go
through the interconnection function.</t>
</section>
<section anchor="log"
title="Logging - No Need for Dynamic Binding Notifications">
<t>Network abuse reporting requires traceability <xref
target="RFC6269"></xref>. To provide such traceability, prior to
IPv4 address sharing, logging the IPv4 address assigned to a user
was sufficient and generates relatively small logs. The advent of
stateful IPv4 address allows dynamic port assignment, which then
requires port assignment logging. This logging of port assignments
can be considerable.</t>
<t>In contrast, static port assignments do not require such
considerable logging. The volume of the logging file may not be seen
as an important criterion for privileging a stateless approach
because stateful approaches can also be configured (or designed) to
assign port ranges and therefore lead to acceptable log volumes.</t>
<t>If a dynamic port assignment mode is used, dedicated interfaces
and protocols must be supported to forward binding data records
towards dedicated platforms. The activation of these dynamic
notifications may impact the performance of the dedicated device.
For stateless solutions, there is no need for dynamic procedures
(e.g., using SYSLOG) to notify a mediation platform about assigned
bindings.</t>
<t>Some Service Providers have a requirement to use only existing
logging systems and to avoid introducing new ones (mainly because of
CAPEX considerations). This requirement is easily met with stateless
solutions.</t>
</section>
<section anchor="proto"
title="No Additional Protocol for Port Control is Required">
<t>Stateless solutions do not require activating a new dynamic
signaling protocol in the end-user CPE in addition to those already
used. In particular, existing protocols (e.g., UPnP IGD:2 <xref
target="UPnP-IGD"></xref>) can be used to control the NAT mappings
in the CPE.</t>
</section>
</section>
<section title="Operational Tasks and Network Maintenance Efficiency">
<t></t>
<section anchor="current" title="Preserve Current Practices">
<t>Service Providers require as much as possible to preserve the
same operations as for current IP networking environments.</t>
<t>If stateless solutions are deployed, common practices are
preserved. In particular, the maintenance and operation of the
network do not require any additional constraints such as: path
optimization practices, enforcing traffic engineering policies,
issues related to traffic oscillation between stateful devices,
load-balancing the traffic or load sharing the traffic among
egress/ingress points can be used, etc. Particularly, <list
style="symbols">
<t>anycast-based schemes can be used for load-balancing and
redundancy purposes.</t>
<t>asymmetric routing to/from the IPv4 Internet is natively
supported and no path-pinning mechanisms have to be additionally
implemented.</t>
</list></t>
</section>
<section anchor="planned" title="Planned Maintenance Operations">
<t>Since no state is maintained by stateless IPv4/IPv6
interconnection nodes, no additional constraint needs to be taken
into account when upgrading these nodes (e.g., adding a new service
card, upgrading hardware, periodic reboot of the devices, etc.). In
particular, current practices that are enforced to (gracefully)
reboot or to shutdown routers can be maintained.</t>
</section>
<section anchor="reliability" title="Reliability and Robustness">
<t>Compared to current practices (i.e., without a CGN in place), no
additional capabilities are required to ensure reliability and
robustness in the context of stateless solutions. Since no state is
maintained in the Service Provider's network, state synchronization
procedures are not required.</t>
<t>High availability (including failure recovery) is ensured owing
to best current practices in the field.</t>
</section>
<section anchor="multi" title="Support of Multi-Vendor Redundancy">
<t>Deploying stateful techniques, especially when used in the
Service Providers networks, constrain severely deploying
multi-vendor redundancy since very often proprietary vendor-specific
protocols are used to synchronize state. This is not an issue for
the stateless case. Concretely, the activation of the stateless
IPv4/IPv6 interconnection function does not prevent nor complicate
deploying devices from different vendors.</t>
<t>This criterion is very important for Service Providers having a
sourcing policy to avoid mono-vendor deployments and to operate
highly-available networks composed on multi-vendors equipment.</t>
</section>
<section anchor="qualification"
title="Simplification of Qualification Procedures">
<t>The introduction of new functions and nodes into operational
networks follows strict procedures elaborated by Service Providers.
These procedures include in-lab testing and field trials. Because of
their nature, stateless implementations optimize testing time and
procedures:</t>
<t><list style="symbols">
<t>The specification of test suites to be conducted should be
shorter;</t>
<t>The required testing resources (in terms of manpower) are
likely to be less solicited that they are for stateful
approaches.</t>
</list>One of the privileged approaches to integrate stateless
IPv4/IPv6 interconnection function consists in embedding stateless
capabilities in existing operational nodes (e.g., IP router). In
this case, any software or hardware update would require to execute
non-regression testing activities. In the context of the stateless
solutions, the non-regression testing load due to an update of the
stateless code is expected to be minimal.</t>
<t>For the stateless case, testing effort and non-regression testing
are to be taken into account for the CPE side. This effort is likely
to be lightweight compared to the testing effort, including the
non-regression testing, of a stateful function which is co-located
with other routing functions for instance.</t>
</section>
</section>
<section title="Facilitating Service Evolution">
<t></t>
<section anchor="identification" title="Implicit Host Identification">
<t>Service Providers do not offer only IP connectivity services but
also added value services (a.k.a., internal services). Upgrading
these services to be IPv6-enabled is not sufficient because of
legacy devices. In some deployments, the delivery of these
added-value services relies on implicit identification mechanism
based on the source IPv4 address. Due to address sharing, implicit
identification will fail <xref target="RFC6269"></xref>; replacing
implicit identification with explicit authentication will be seen as
a non acceptable service regression by the end users (less Quality
of Experience (QoE)).</t>
<t>When a stateless solution is deployed, implicit identification
for internal services is likely to be easier to implement: the
implicit identification should be updated to take into account the
port range and the IPv4 address. Techniques as those analyzed in
<xref target="I-D.ietf-intarea-nat-reveal-analysis"></xref> are not
required for the delivery of these internal services if a stateless
solution is deployed.</t>
<t>Note stateful approaches configured to assign port ranges allows
also to support implicit host identification.</t>
</section>
<section anchor="organisation" title="No Organizational Impact">
<t>Stateless solutions adopt a clear separation between the
IP/transport layers and the service layers; no service interference
is to be observed when a stateless solution is deployed. This clear
separation:</t>
<t><list style="hanging">
<t hangText="Facilitates service evolution:">Since the payload
of IPv4 packets is not altered in the path, services can evolve
without requiring any specific function (e.g., Application Level
Gateway (ALG)) in the Service Provider's network;</t>
<t hangText="Limits vendor dependency:">The upgrade of
value-added services does not involve any particular action from
vendors that provide devices embedding the stateless IPv4/IPv6
interconnection function.</t>
<t
hangText="No service-related skills are required for network operators who manage devices that embed the IPv4/IPv6 interconnection function:">IP
teams can be in charge of these devices; there is a priori no
need to create a dedicated team to manage and to operate devices
embedding the stateless IPv4/IPv6 interconnection function. The
introduction of stateless capabilities in the network are
unlikely to degrade management costs.</t>
</list></t>
</section>
</section>
<section title="Cost Minimization Opportunities">
<t>To make decision for which solution is to be adopted, Service
Providers usually undertake comparative studies about viable technical
solutions. It is not only about technical aspects but also economical
optimization (both CAPEX and OPEX considerations). From a Service
Provider perspective, stateless solutions are more attractive because
they do less impact the current network operations and maintenance
model that is widely based on stateless approaches. <xref
target="cost"></xref> shows the general correspondence between
technical benefits and potential economic reduction opportunities.</t>
<t>While not all Service Providers environments are the same, a
detailed case study from one Service Provider <xref
target="I-D.matsushima-v6ops-transition-experience"></xref> reports
that stateless transition solutions can be considerably less expensive
than stateful transition solutions.</t>
<t><?rfc subcompact="yes" ?></t>
<texttable anchor="cost" style="all"
title="Cost minimization considerations">
<ttcol align="center">Section</ttcol>
<ttcol align="center">Technical and Operation Benefit</ttcol>
<ttcol align="center">Cost Area</ttcol>
<c><xref target="network_dim"></xref></c>
<c>Network dimensioning</c>
<c>Network</c>
<c><xref target="no_intra"></xref></c>
<c>No Intra-domain constraint</c>
<c>Network</c>
<c><xref target="log"></xref></c>
<c>Logging</c>
<c>Network & Ops</c>
<c><xref target="proto"></xref></c>
<c>No additional control protocol</c>
<c>Network</c>
<c><xref target="current"></xref></c>
<c>Preserve current practices</c>
<c>Ops</c>
<c><xref target="planned"></xref></c>
<c>Planned maintenance</c>
<c>Ops</c>
<c><xref target="reliability"></xref></c>
<c>Reliability and robustness</c>
<c>Network & Ops</c>
<c><xref target="multi"></xref></c>
<c>Multi-Vendor Redundancy</c>
<c>Network</c>
<c><xref target="qualification"></xref></c>
<c>Simple qualification</c>
<c>Ops</c>
<c><xref target="identification"></xref></c>
<c>Implicit Host Identification for internal services</c>
<c>Ops</c>
<c><xref target="organisation"></xref></c>
<c>Organizational Impact</c>
<c>Ops</c>
</texttable>
<t><?rfc subcompact="no" ?></t>
</section>
</section>
<section title="Discussion">
<t>Issues common to all address sharing solutions are documented in
<xref target="RFC6269"></xref>. The following sub-sections enumerate
some open questions for a CPE-based stateless solution. There are no
universal answers to these open questions since each Service Provider
has its own constraints (e.g., available address pool, address sharing
ratio, etc.).</t>
<section anchor="dependency"
title="Dependency Between IPv4 and IPv6 Address Assignments">
<t>Complete stateless mapping implies that the IPv4 address and the
significant bits that are used to encode the set of assigned ports can
be retrieved from the IPv6 prefix assigned to the CPE. This
requirement can be addressed by either using the IPv6 prefix also used
to forward IPv6 traffic natively, or allocating two prefixes to the
CPE (one that will be used to forward IPv6 traffic natively, and the
other one to forward IPv4 traffic).</t>
<t><list style="symbols">
<t>Providing two IPv6 prefixes avoids the complexity that may be
related to the adaptation of the IPv6 addressing scheme to the
IPv4 addressing scheme. The drawback is the need to allocate two
prefixes instead of one to each CPE and to announce them
accordingly, possibly at the cost of jeopardizing the routing and
forwarding efficiencies.</t>
<t>The use of a single prefix to cover both the forwarding of IPv6
and IPv4-in-IPv6 traffic avoids the need to maintain a double
information (e.g., for customer identification and management
purposes and for forwarding table maintenance purposes). This
scheme somewhat links strongly the IPv4 addressing scheme to the
allocated IPv6 prefixes. For Service Providers requiring to apply
specific policies on per Address-Family (e.g., IPv4, IPv6), some
provisioning tools (e.g., DHCPv6 option) may be required to derive
in a deterministic way the IPv6 address to be used for the IPv4
traffic based on the IPv6 prefix delegated to the home
network.</t>
</list></t>
</section>
<section anchor="efficiency" title="IPv4 Port Utilisation Efficiency">
<t>CGN-based solutions, because they can dynamically assign ports,
provide better IPv4 address sharing ratio than stateless solutions
(i.e., can share the same IP address among a larger number of
customers). For Service Providers who desire an aggressive IPv4
address sharing, a CGN-based solution is more suitable than the
stateless. However<list style="format %d:">
<t>When port overloading is used, some applications are likely to
be broken.</t>
<t>in case a CGN pre-allocates port ranges, e.g.- to alleviate
traceability complexity (see <xref target="log"></xref>), it also
reduces its port utilization efficiency.</t>
</list></t>
</section>
<section anchor="randomization" title="IPv4 Port Randomization">
<t>Preserving port randomization <xref target="RFC6056"></xref> may be
more or less difficult depending on the address sharing ratio (i.e.,
the size of the port space assigned to a CPE). The CPE can only
randomize the ports inside a fixed port range.</t>
<t>More discussion to improve the robustness of TCP against Blind
In-Window Attacks can be found at <xref target="RFC5961"></xref>.
Other means than the (IPv4) source port randomization to provide
protection against attacks should be used (e.g., use <xref
target="I-D.vixie-dnsext-dns0x20"></xref> to protect against DNS
attacks, <xref target="RFC5961"></xref> to improve the robustness of
TCP against Blind In-Window Attacks, use IPv6).</t>
</section>
</section>
<section title="Conclusion">
<t>As discussed in <xref target="motivations"></xref>, stateless
solutions provide several interesting features. Trade-off between the
positive vs. negative aspects of stateless solutions is left to Service
Providers. Each Service Provider will have to select the appropriate
solution (stateless, stateful or even both) meeting its
requirements.</t>
<t>This document recommends to undertake as soon as possible the
appropriate standardization effort to specify a stateless IPv4 over IPv6
solution.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No action is required from IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Except for the less efficient port randomization of and routing loops
<xref target="RFC6324"></xref>, stateless 4/6 solutions are expected to
introduce no more security vulnerabilities than stateful ones. Because
of their stateless nature, they may in addition reduce denial of service
opportunities.</t>
</section>
<section title="Contributors">
<t>The following individuals have contributed to this document:</t>
<figure>
<artwork type="text/plain"><![CDATA[
Christian Jacquenet
France Telecom
Email: christian.jacquenet@orange.com
Pierre Levis
France Telecom
Email: pierre.levis@orange.com
Masato Yamanishi
SoftBank BB
Email: myamanis@bb.softbank.co.jp
Yuji Yamazaki
Softbank Mobile
Email: yuyamaza@bb.softbank.co.jp
Hui Deng
China Mobile
Email: denghui02@gmail.com
]]></artwork>
</figure>
<t></t>
</section>
<section title="Acknowledgments">
<t>Many thanks to the following individuals who provided valuable
comments:</t>
<figure align="center">
<artwork><![CDATA[+---------------+---------------+---------------+---------------+
| X. Deng | W. Dec | D. Wing | A. Baudot |
| E. Burgey | L. Cittadini | R. Despres | J. Zorz |
| M. Townsley | L. Meillarec | R. Maglione | J. Queiroz |
| C. Xie | X. Li | O. Troan | J. Qin |
| B. Sarikaya | N. Skoberne | J. Arkko | D. Lui |
+---------------+---------------+---------------+---------------+
]]></artwork>
</figure>
<t></t>
<t>Special thanks to W. Dec who provided a summary of the motivation
items.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.6144'?>
<?rfc include='reference.RFC.1958'?>
<?rfc include='reference.RFC.2663'?>
<?rfc include='reference.RFC.6056'?>
<reference anchor="EURESCOM"
target="http://archive.eurescom.eu/~pub/deliverables/documents/P1900-series/P1952/D2bis/P1952-D2bis.pdf">
<front>
<title>IPv4 address exhaustion: Issues and Solutions for Service
Providers</title>
<author fullname="Levis, P., Borges, I., Bonness, O. and L. Dillon L."
surname="Levis, P., Borges, I., Bonness, O. and L. Dillon L.">
<organization></organization>
</author>
<date month="March" year="2010" />
</front>
</reference>
<reference anchor="UPnP-IGD" target="http://upnp.org/specs/gw/igd2/">
<front>
<title>Universal Plug and Play (UPnP) Internet Gateway Device (IGD)
V 2.0</title>
<author fullname="UPnP Forum" surname="UPnP Forum">
<organization></organization>
</author>
<date month="December" year="2010" />
</front>
</reference>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>
<?rfc include='reference.I-D.vixie-dnsext-dns0x20'?>
<?rfc include='reference.RFC.5961'?>
<?rfc include='reference.RFC.6324'?>
<?rfc include='reference.I-D.matsushima-v6ops-transition-experience'?>
<?rfc include='reference.I-D.ietf-intarea-nat-reveal-analysis'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:48:50 |