One document matched: draft-mrw-nat66-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1071 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1071.xml'>
<!ENTITY rfc1624 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1624.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY rfc2463 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2463.xml'>
<!ENTITY rfc2526 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2526.xml'>
<!ENTITY rfc2993 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2993.xml'>
<!ENTITY rfc3587 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3587.xml'>
<!ENTITY rfc4193 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
<!ENTITY rfc4291 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml'>
<!ENTITY rfc4864 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4864.xml'>
<!ENTITY rfc4787 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4787.xml'>
<!ENTITY I-D.thaler-ipv6-saf SYSTEM
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thaler-ipv6-saf.xml'>
]/>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-mrw-nat66-00.txt">
<front>
<title abbrev="NAT66">IPv6-to-IPv6 Network Address Translation (NAT66)</title>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city> <region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405 7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-secuirty.com</uri>
</address>
</author>
<author fullname="Fred Baker" initials="F.J."
surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<phone>+1-408-526-4257</phone>
<email>fred@cisco.com</email>
</address>
</author>
<date month="October" year="2010" />
<area>Transport</area>
<abstract>
<t>
This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Address Translation (NAT66) function that provides the address
independence benefit associated with IPv4-to-IPv4 NAT (NAT44) while
minimizing, but not completely eliminating, the problems associated
with NAT44.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119"/>.
</t>
</section>
<section title="Introduction">
<t>
This document describes a stateless, transport-agnostic IPv6-to-IPv6
Network Address Translation (NAT66) function that provides the address
independence benefit associated with IPv4-to-IPv4 NAT (NAT44) while
minimizing, but not completely eliminating, the problems associated
with NAT44.
</t>
</section>
<section title="What is Address Independence?">
<t>
As used in this document, IPv6 Address Independence consists of the
following set of local network properties:
<list style="symbols">
<t>
The IPv6 addresses in use inside the local network (for nodes, ACLs,
logs) do not need to be renumbered if the ISP changes a site's
external address prefix.
</t>
<t>
The IPv6 addresses in use inside the local network (for nodes, ACLs,
logs) or within other connected networks (such as a second ISP for
multihoming) do not need to be renumbered when a site changes ISPs.
</t>
<t>
It is not necessary for an administrator to convince an ISP to route
his or her internal IPv6 addresses.
</t>
</list>
This address independence requirement has been a primary driver for
IPv4 NAT deployment in medium to large-sized enterprise networks,
including NAT deployments in enterprises that have plenty of IPv4
provider-independent address space (from IPv4 "swamp space").
</t>
<t>
The Local Network Protection document <xref target="RFC4864"/>
discusses a related concept called "Address Autonomy" as a benefit of
NAT44. RFC 4864 indicates that address autonomy can be achieved by
the simultaneous use of global addresses on all nodes within a site
that need external connectivity, and Unique Local Addresses (ULAs)
<xref target="RFC4193"/> for all internal communication. However,
this solution fails to meet the requirement for address independence,
because if an ISP renumbering event occurs, all of the hosts, routers,
DHCP servers, ACLs, firewalls and other internal systems that are
configured with global addresses from the ISP will need to be
renumbered before global connectivity is fully restored.
</t>
<t>
The use of IPv6 Provider Independent (PI) addresses has also been
suggested as a means to fulfill the address independence requirement.
However, this solution requires that an enterprise qualify to receive
a PI assignment and persuade their ISP to install specific routes for
the enterprise's PI addresses. There are a number of practical issues
with this approach, especially if there is a desire to route to a
number of geographically and topologically diverse set of sites, which
can sometimes involve coordinating with several ISPs to route portions
of a single PI prefix. These problems have caused numerous
enterprises with plenty of IPv4 swamp space to choose to use IPv4 NAT
for part, or substantially all, of their internal network instead of
using their provider-independent address space.
</t>
</section>
<section title="NAT66 Applicability">
<t>
NAT66 provides a simple and compelling solution to meet the Address
Independence requirement in IPv6. The address independence benefit
stems directly from the translation function of the network address
translator. To avoid as many of the issues associated with NAT44 as
possible, NAT66 is defined to include a two-way, checksum-neutral,
algorithmic translation function, and nothing else.
</t>
<t>
NAT66 does not include a port mapping function, and the defined
address mapping mechanism is checksum-neutral. This avoids the need
for a NAT66 device to re-write transport layer headers, making it
feasible to deploy new or improved transport layer protocols without
upgrading NAT66 devices. Because NAT66 does not involve re-writing
transport-layer headers, NAT66 will not interfere with encrypting the
full IP payload in many cases.
</t>
<t>
The default NAT66 address mapping mechanism is purely algorithmic, so
NAT66 devices do not need to maintain per-node or per-connection
state, allowing deployment of more robust and adaptive networks than
can be deployed using NAT44. Since the default NAT66 mapping can be
performed in either direction, it does not interfere with inbound
connection establishment, thus allowing internal nodes to participate
in direct peer-to-peer applications.
</t>
<t>
Although NAT66 compares favorably to NAT44 in several ways, it does
not eliminate all of the architectural problems associated with IPv4
NAT, as described in <xref target="RFC2993"/>. NAT66 involves
modifying IP headers in transit, so it is not compatible with security
mechanisms that involve end-to-end encryption of the IP header, or
mechanisms, such as AH, that provide integrity protection for the IP
header. NAT66 may interfere with the use of application protocols that
transmit IP addresses in the application-specific portion of the IP
packet. These applications currently require application layer
gateways (ALGs) to work correctly through NAT44 devices, and similar
ALGs may be required for these applications to work through NAT66
devices. The use of separate internal and external address prefixes
creates complexity for DNS deployment, due the desire for internal
nodes to communicate with other internal nodes using internal
addresses, while external nodes need to obtain external addresses to
communicate with the same nodes. Typically, this results in the
deployment of "split DNS", which may add complexity to network
configuration.
</t>
<t>
There are significant technical impacts associated with the
deployment of any address translation mechanism, including NAT66, and
we strongly encourage anyone who is considering the implementation or
deployment of NAT66 to read RFC 4864 <xref target="RFC4864"/>, and to
carefully consider the alternatives described in that document, some
of which may cause fewer problems than NAT66.
</t>
</section>
<section title="NAT66 Overview">
<t>
NAT66 may be implemented in an IPv6 router to map one IPv6 address
prefix to another IPv6 address prefix as each IPv6 packet transits the
router. A router that implements a NAT66 function is referred to as a
NAT66 device.
</t>
<t>
In its simplest form, a NAT66 device will be attached to two network
links, one of which is an "internal" network link attached to a leaf
network within a single administrative domain, and the other of which
is an "external" network with connectivity to the global Internet.
All of the hosts on the internal network will use addresses from a
single, locally-routed prefix, and those addresses will be translated
to/from addresses in a globally-routable prefix as IP packets transit
the NAT66 device.
</t>
<t>
The following picture shows a NAT66 device attached to two networks.
In this example, the internal network uses IPv6 Unique Local
Addresses (ULAs) <xref target="RFC4193"/> to represent the internal
IPv6 nodes, and the external network uses globally routable IPv6
addresses to represent the same nodes.
</t>
<figure>
<artwork>
<![CDATA[
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
|
|
+---------+
| NAT66 |
| Device |
+---------+
|
|
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
]]>
</artwork>
</figure>
<t>
When a NAT66 device forwards packets in the "outbound" direction, from
the internal network to the external network, NAT66 overwrites the
IPv6 source address (in the IPv6 header) with a corresponding address
from the external prefix. When packets are forwarded in the "inbound"
direction, from the external network to the internal network, the IPv6
destination address is overwritten with a corresponding address in the
internal prefix. Using the prefixes shown in the diagram above, as an
IP packet passes through the NAT66 device in the outbound direction, the
source address prefix (FD01:0203:0405:/48) will be overwritten with
the external address prefix (2001:0DB8:0001:/48). In an inbound
packet, the destination prefix (2001:0DB8:0001:/48) will be
overwritten with the internal network prefix (FD01:0203:0405:/48). In
both cases, it is the local IPv6 address that is overwritten; the
remote IPv6 address remains unchanged. Nodes on the internal network
are said to be "behind" the NAT66 device.
</t>
<t>
NAT66 can also be used between two private networks. In these
cases, both networks may use ULA prefixes, with each subnet in one
network mapped into a corresponding subnet in the other network, and
vice versa. Or, each network may use ULA prefixes for internal
addressing, and global unicast addresses on the other network.
</t>
<figure>
<artwork>
<![CDATA[
Internal Prefix = FD01:4444:5555:/48
--------------------------------------
V | External Prefix
V | 2001:0DB8:6666:/48
V +---------+ ^
V | NAT66 | ^
V | Device | ^
V +---------+ ^
External Prefix | ^
2001:0DB8:0001:/48 | ^
--------------------------------------
Internal Prefix = FD01:0203:0405:/48
]]>
</artwork>
</figure>
<t>
In some cases, more than one NAT66 device may be attached to a
network. In those cases, NAT66 devices may be configured with
the same internal and external prefixes, or they may be configured
with the same internal prefix and different external prefixes.
</t>
<figure>
<artwork>
<![CDATA[
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
| |
| |
+---------+ +---------+
| NAT66 | | NAT66 |
| Device | | Device |
| #1 | | #2 |
+---------+ +---------+
| |
| |
--------------------------------------
Internal Netowrk: Prefix = FD01:0203:0405:/48
]]>
</artwork>
</figure>
<figure>
<artwork>
<![CDATA[
External Network #1: External Network #2:
Prefix = 2001:0DB8:0001:/48 Prefix = 2001:0DB8:5555:/48
--------------------------- --------------------------
| |
| |
+---------+ +---------+
| NAT66 | | NAT66 |
| Device | | Device |
| #1 | | #2 |
+---------+ +---------+
| |
| |
--------------------------------------
Internal Netowrk: Prefix = FD01:0203:0405:/48
]]>
</artwork>
</figure>
</section>
<section title="Mapping with No Per-Flow State">
<t>
When NAT66 is used as described in this document, no per-node or per-flow
state is maintained in the NAT66 device. Both inbound and outbound
packets are translated algorithmically, using only information found
in the IPv6 header. Due to this property, NAT66's two-way, algorithmic
address mapping can support both outbound and inbound connection
establishment without the need for state-priming or rendevous
mechanisms. This is a significant improvement over NAT44 devices, but
it also has significant security implications which are described in the
Security Considerations section.
</t>
</section>
<section title="Checksum-Neutral Mapping">
<t>
When a change is made to one of the IP header fields in the IPv6
pseudo-header checksum (such as one of the IP addresses), the checksum
field in the transport layer header may become invalid. Fortunately,
an incremental change in the area covered by the Internet standard
checksum <xref target="RFC1071"/> will result in a well-defined change
to the checksum value <xref target="RFC1624"/>. So, a checksum change
caused by modifying part of the area covered by the checksum can
be corrected by making a complementary change to a different 16-bit
field covered by the same checksum.
</t>
<t>
The NAT66 mapping mechanisms described in this document are
checksum-neutral, which means that they result in IP headers that will
generate the same IPv6 pseudo-header checksum when the checksum is
calculated using the standard Internet checksum algorithm
<xref target="RFC1071"/>. Any changes that are made during
translation of the IPv6 prefix are offset by changes to other parts of
the IPv6 address. This results in transport layers that use the
Internet checksum (such as TCP and UDP) calculating the same IPv6
pseudo header checksum for both the internal and external forms of the
same packet, which avoids the need for the NAT66 device to modify those
transport layer headers to correct the checksum value.
</t>
</section>
<section title="NAT66 Prefix Mapping">
<t>
When a NAT66 device is configured with internal and external prefixes
that are 48 bits (a /48) or shorter, the NAT66 Prefix Mapping described
in this section MUST be used. All NAT66 devices MUST support
NAT66 prefix mapping.
</t>
<t>
To produce a checksum neutral transformation, the NAT66 device
calculates the 16-bit one's complement sum of both the internal and
external IPv6 prefixes, as described above. The difference between the
original and mapped prefix checksums is calculated using 16-bit one's
complement arithmetic, and the difference is added to the original
value of thes subnet value in bits 33-48 (inclusive) of the address.
If the resulting value is 0xFFFF, it is changed to 0x0000.
</t>
<t>
This mapping results in no modification of the Interface Identifier
(IID), which is held in the lower half of the IPv6 address, so it will
not interfere with future protocols that may use unique IIDs for node
identification. However, use of this mapping is restricted to cases
where both the internal and external prefixes are 48 bits long (a /48)
or shorter, leaving at least 16 subnet bits that can be modified to
ensure checksum neutrality. The NAT66 Address mapping described below
handles cases where longer prefixes are in use.
</t>
<section title="Prefix Mapping Example">
<t>
For the network shown in the first example diagram in the NAT66
Overview section above, we might have the following example:
</t>
<t>
Internal Prefix: FD01:0203:0405:/48
External Prefix: 2001:0DB8:0001:/48
</t>
<t>
If a node with internal address FD01:0203:0405:0001::1234 sends an
outbound packet through the NAT66 device, the resulting external
address will be 2001:0DB8:0001:D550::1234. The resulting address is
obtained by calculating the checksum of both the internal and external
48-bit prefixes, sutracting the internal prefix from the external
prefix using one's complement arithmetic and adding the result to the
16-bit subnet field (in this case 0x0001).
</t>
<t>
To show the work:
</t>
<t>
The one's complement checksum of FD01:0203:0405 is 0xFCF5.
The one's complement checksum of 2001:0DB8:0001 is 0xD245.
Using one's complement math, 0xD245 - 0xFCF5 = 0xD54F.
The subnet mask in the original packet is 0x0001.
Using one's complement math, 0x0001 + 0xD54F = 0xD550.
Since 0xD550 != 0xFFFF, it is not changed to 0x0000.
</t>
<t>
So, the value 0xD550 is written in the 16-bit subnet mask area,
resulting in a mapped external address of 2001:0DB8:0001:D550::1234.
</t>
<t>
When a response packet is received, it will contain the
destination address 2001:0DB8:0001:D550::0001, which will be
mapped using the same mapping algorithm, back to
FD01:0203:0405:0001::1234.
</t>
<t>
In this case, the difference between the two prefixes will be
calculated as follows:
</t>
<t>
Using one's complement math, 0xFCF5 - 0xD245 = 0x2AB0.
The subnet mask in the original packet = 0xD550.
Using one's complement math, 0xD550 + 0x2AB0 = 0x0001.
Since 0x0001 != 0xFFFF, it is not changed to 0x0000.
</t>
<t>
So the value 0x0001 is written into the subnet field, and the
internal value of the subnet field is properly restored.
</t>
</section>
</section>
<section title="Address Mapping for Longer Prefixes">
<t>
In some cases, it may desireable to use NAT66 with global prefixes
longer than /48. In those cases, the checksum correction will need
to be performed in the IID portion (the lower 64-bits) of the address,
because the subnet portion of the address is not 16 bits or longer. This
section describes a two-way, algorithmic, checksum neutral mapping algorithm
for those cases. NAT66 devices will only use this algorithm when mapping
addresses with prefixes longer than 48 bits. All NAT66 devices
SHOULD implement the address mapping algorithm described in this section.
</t>
<t>
The address mapping algorithm consists of finding a 16-bit
portion of the IID that does not contain the value 0xFFFF, and
performing the checksum correction (as described above) in that
portion of the IID. Since all NAT66 devices will use the same
algorithm to select the location of the checksum correction, the
mapping algorithm will continue to be fully reversible.
</t>
<t>
The algorithm for finding a location for the checksum correction consists
of checking the highest order 16-bits of the IID (bits 65-80 of the address).
If those 16-bits do not equal 0xFFFF, the checksum correction value is
added to those bits. If those bits are equal to OxFFFF, the next 16 bits
(bits 81-96) are checked. If they do not equal 0xFFFF, the checksum
correction is added to those bits. If necessary this check is performed
for the remaining 16-bit values (bits 97-112 and bits 113-128) in
succession. Since the checksum correction algorithm cannot result in
a value of 0xFFFF, running this algorithm in the other direction will
result in the same IID used in the original packet.
</t>
<t>
Although any 16-bit portion of an IPv6 IID could contain 0xFFFF,
an IID of all-ones is a reserved anycast identifier that should not be
used on the network <xref target="RFC2526"/>. If a NAT66 device discovers a
packet with an IID of all-zeros while performing address mapping, that packet
MUST be dropped, and an ICMPv6 Parameter Problem error SHOULD be generated
<xref target="RFC2463"/>.
</t>
<t>
Note: this mechanism does involve modification of the IID, so it may
not be compatible with future mechanisms that use unique IIDs for
node identification.
</t>
</section>
<section title="Prefixes for Internal Addressing">
<t>
NAT66 devices MUST support manual configuration of internal and
external address prefixes, and MUST NOT place any restrictions on
those prefixes except that they be valid IPv6 unicast address
prefixes, as described in <xref target="RFC4291"/>.
</t>
</section>
<section title="NAT Behavioral Requirements">
<t>
NAT66 devices MUST support hairpinning behavior, as defined in the NAT
Behavioral Requirements for UDP document <xref target="RFC4787"/>. This
means that when a NAT66 device receives a packet on the internal
interface that has a destination address that matches the site's external
prefix, it will translate the packet and forward it internally. This
allows internal nodes to reach other internal nodes using their external,
global addresses when necessary.
</t>
<t>
Because NAT66 does not perform port mapping and uses a one-to-one,
reversible mapping algorithm, none of the other NAT behavioral
requirements apply to NAT66.
</t>
<t>
NAT66 devices that do not have a manually configured internal prefix
SHOULD randomly generate a ULA prefix for the internal network and
advertise that prefix in router advertisements. NAT66 devices with more
than one internal interface SHOULD assign a (non-0xFFFF) subnet number
to each link, and include the subnet number in router advertisements
on the corresponding link. NAT66 devices that generate a ULA prefix
MUST generate the prefix using a random number as described in RFC4291
<xref target="RFC4193"/>, and SHOULD store the randomly generated
prefix is non-volatile storage for continued use.
</t>
</section>
<section title="A Note on Port Mapping">
<t>
In addition to overwriting IP addresses when packets are forwarded,
NAT44 devices often overwrite the source port number in outbound
traffic, and the destination port number in inbound traffic. This
mechanism is called "port mapping".
</t>
<t>
The major benefit of port mapping is that it allows multiple computers
to share a single IPv4 address. A large number of internal IPv4
addresses (typically from the 10.0.0.0/8 prefix) can be mapped into a
single external, globally routable IPv4 address, with the local port
number used to identify which internal node should receive each
inbound packet. This address amplification feature should not be
needed in IPv6, where every attached network should be assigned at
least a /48 prefix, leaving room for 16 subnet bits and a 64 bit
Interface Identifier <xref target="RFC3587"/>.
</t>
<t>
Since port mapping requires re-writing a portion of the transport
layer header, it requires NAT66 devices to be aware of all of the
transport protocols that they forward, thus stifling the development
of new and improved transport protocols. Modifying the transport
layer header is incompatible with security mechanisms that encrypt the
full IP payload, and restricts the NAT66 device to forwarding
transport layers that use weak checksum algorithms that are easily
recalculated in routers. Since there is significant detriment caused
by modifying transport layer headers and very little, if any, benefit
to the use of port mapping in IPv6, NAT66 devices that comply with
this specification MUST NOT perform port mapping.
</t>
</section>
<section title="Security Considerations">
<t>
When NAT66 is deployed using either of the two-way, algorithmic mappings
defined in the document, it allows direct inbound connections to
internal nodes. While this can be viewed as a benefit of NAT66
vs. NAT44, it does open internal nodes to attacks that would not be
possible in a NAT44 network. Although this situation is not
substantially worse, from a security standpoint, than running IPv6
with no NAT, some enterprises may assume that a NAT66 device will
offer similar protection to a NAT44 device. For this reason, it is
RECOMMENDED that NAT66 devices include an IPv6 firewall function, and
the firewall function SHOULD be configured by default to block all
incoming connections. Administrators could then enable inbound
connectivity for specific ports by reconfiguring the firewall.
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no IANA considerations.
</t>
</section>
<section title="Acknowledgements">
<t>
The checksum-neutral algorithmic address mapping described in this
document is based on e-mail written by Iljtsch Van Beijnum.
</t>
<t>
The following people provided advice or review comments that
substantially improved this document: Jari Arrko, Iljtsch Van Beijnum,
Remi Depres, Tony Hain, Ed Jankiewicz, Dave Thaler, Mark Townsley.
</t>
<t>
This document was written using the xml2rfc tool described in RFC 2629
<xref target="RFC2629"/>.
</t>
</section>
<section title="Change Log">
<section title="Changes Between draft-mrw-behave-nat66-00 and -01">
<t>
There were several minor changes made between the *behave-nat66-00 and
-01 versions of this draft:
<list style="symbols">
<t> Added Fred Baker as a co-author.</t>
<t> Minor mathematical corrections.</t>
<t> Added AH to paragraph on NAT security issues. </t>
<t> Added additional NAT topologies to overview (diagrams TBD). </t>
</list>
</t>
</section>
<section title="Changes between *behave-nat66-01 and -02">
<t>
There were further changes made between *behave-nat66-01 and -02:
<list style="symbols">
<t> Removed topology hiding mechanism.</t>
<t> Added diagrams.</t>
<t> Made minor updates based on mailing list feedback.</t>
<t> Added discussion of IPv6 SAF document.</t>
<t> Added applicability section. </t>
<t> Added discussion of Address Independence requirement.</t>
<t> Added hairpining requirement and discussion of
applicability of other NAT behavioral requirements.
</t>
</list>
</t>
</section>
<section title="Changes between *behave-nat66-02 and *nat66-00">
<t>
There were further changes made between behave-nat66-02 and nat66-02:
<list style="symbols">
<t> Added mapping for prefixes longer than /48.</t>
<t> Change draft name to remove reference to the behave WG.</t>
<t> Resolved various open issues and fixed typos.</t>
</list>
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
&rfc1071;
&rfc1624;
&rfc2119;
&rfc2463;
&rfc2526;
&rfc3587;
&rfc4193;
&rfc4291;
&rfc4787;
</references>
<references title="Informative References">
&rfc2629;
&rfc2993;
&rfc4864;
&I-D.thaler-ipv6-saf;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:47 |