Behave and Softwires WGs D. Wing
Internet-Draft D. Ward
Intended status: Informational Cisco
Expires: March 20, 2009 A. Durand
Comcast
September 16, 2008
A Comparison of Proposals to Replace NAT-PT
draft-wing-nat-pt-replacement-comparison-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 20, 2009.
Abstract
As we approach IPv4 address depletion, the IETF must provide for IPv4
and IPv6 coexistence: a way for ISPs and enterprises to reduce
public IPv4 address consumption and a way for hosts to migrate to
IPv6 connectivity -- while providing reasonable access for those IPv6
hosts to access the IPv4 Internet.
This draft compares seven proposals for IPv6 and IPv4 coexistence.
Wing, et al. Expires March 20, 2009 [Page 1]
Internet-Draft NAT-PT Replacement Comparison September 2008
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Proposals . . . . . . . . . . . . . . . . . . . . 5
3.1. IPv4 hosts in Customer Premise . . . . . . . . . . . . . . 6
3.1.1. APB-Revised (APBR) . . . . . . . . . . . . . . . . . . 6
3.1.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 8
3.1.3. NAT444 . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. IPv6 hosts in Customer Premise . . . . . . . . . . . . . . 10
3.2.1. IVI . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2. NAT6 . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.3. NAT64 . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4. NAT-PT . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.5. sNAT-PT . . . . . . . . . . . . . . . . . . . . . . . 13
4. Changes Required in Network Elements . . . . . . . . . . . . . 13
4.1. IPv4 and IPv6 Hosts Accessing the IPv4 Internet . . . . . 14
4.2. IPv4 Hosts Accessing the IPv4 Internet . . . . . . . . . . 16
4.3. IPv4 Internet Accessing IPv6 hosts . . . . . . . . . . . . 16
5. Port Forwarding . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Static Incoming Ports . . . . . . . . . . . . . . . . . . 17
5.2. Dynamic Incoming Ports . . . . . . . . . . . . . . . . . . 18
6. Analysis with V6OPS's NAT64 Problem Statement . . . . . . . . 19
7. Comparison of Proposals with NAT-PT Problems . . . . . . . . . 19
7.1. Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . 19
7.1.1. Issues with Protocols Embedding IP Addresses . . . . . 19
7.1.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . 19
7.1.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . 20
7.1.4. Loss of Information through Incompatible Semantics . . 20
7.1.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . 20
7.1.6. NAT-PT Interaction with SCTP and Multihoming . . . . . 20
7.1.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . 20
7.1.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . 20
7.2. Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . 21
7.2.1. Network Topology Constraints Implied by NAT-PT . . . . 21
7.2.2. Scalability and Single Point of Failure Concerns . . . 21
7.2.3. Issues with Lack of Address Persistence . . . . . . . 21
7.2.4. DoS Attacks on Memory and Address/Port Pool . . . . . 21
7.3. Issues Directly Related to Use of DNS-ALG . . . . . . . . 21
7.3.1. Address Selection Issues when Communicating with
Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . 21
7.3.2. Non-Global Validity of Translated RR Records . . . . . 21
7.3.3. Inappropriate Translation of Responses to A Queries . 22
7.3.4. DNS-ALG and Multi-Addressed Nodes . . . . . . . . . . 22
7.3.5. Limitations on Deployment of DNS Security
Capabilities . . . . . . . . . . . . . . . . . . . . . 22
7.4. Impact on IPv6 Application Development . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
Wing, et al. Expires March 20, 2009 [Page 2]
Internet-Draft NAT-PT Replacement Comparison September 2008
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Wing, et al. Expires March 20, 2009 [Page 3]
Internet-Draft NAT-PT Replacement Comparison September 2008
1. Terminology
The following terms are used throughout this document.
Carrier Grade NAT (CGN): A NAT or NAPT device used by many
subscribers, where 'many' would be on the order of dozens to
hundreds of thousands of subscribers. This might NAT between
any combination of IPv4 and IPv6.
CPE: Customer Premise Equipment. A device that performs routing
functions. This device does not perform NAT functions. (Some
referenced specifications use the term 'Home GateWay' (HGW) to
mean the same thing. We use CPE because the subscriber might
not be a business and not a 'home'.)
DNS rewriting: The generalized function of synthesizing a DNS AAAA
response from a DNS A response. The term "DNS rewriting"
instead of "DNS-ALG" because in NAT-PT [RFC2766] DNS-ALG meant a
DNS rewriting function with an interface to the NAT function.
NAT: Network Address Translation. This translates IP addresses, one-
for-one, between two networks, without changing transport
protocol ports. The two networks might be IPv4 (NAT44), IPv6
and IPv4 (NAT64), or IPv4 and IPv6 (NAT46). This document
follows (the unfortunate) common usage that "NAT" can also mean
"NAPT".
NAPT: Network Address and Port Translation. This translates IP
addresses and transport protocol ports (e.g., TCP, UDP) between
two networks. Because the port number is changed, a NAPT
usually requires a translation first occur from the side of the
NAPT with more IP addresses and ports -- this is generally
considered the 'inside' of the NAPT. This creates state in the
NAPT.
Softwire A tunnel for carrying IPv4 and IPv6 traffic over IPv6 and
IPv4 networks [RFC4925].
2. Introduction
As the Internet approaches IPv4 address depletion, it will be
necessary for Internet Service Providers to continue to
simultaneously provide their users with access to the IPv4 Internet,
reduce the number of IPv4 public addresses consumed by each
subscriber, and provide a way for subscribers to migrate to IPv6.
The proposals have several high-level attributes in common:
Wing, et al. Expires March 20, 2009 [Page 4]
Internet-Draft NAT-PT Replacement Comparison September 2008
Provide access to the IPv4 Internet: There are two approaches to
provide access to the v4 Internet. One approach is to have a
dual-stack host with some modifications from the classic design
[RFC4213]. The other approach is to have an IPv6-only host and
operate a NAT device between the IPv6-only host and the IPv4
Internet.
Reduce consumption of global IPv4 addresses: NAPT technology, and
NAPT itself, allows more than one host to simultaneously use a
single IPv4 address. NAPT technology is used in all proposals to
conserve IPv4 public address space.
IPv6 migration: it is important that a migration path for users
and content providers to move to IPv6 is enabled and encouraged.
This is necessary because operating a NAT device in order to
reduce per-subscriber IPv4 address consumption is not a viable
long-term solution: we will still exhaust the IPv4 public address
space, and operating NATs is expensive and reduces the reliability
of the Internet.
Port limitations: All proposals use a NAPT to provide access to
the IPv4 Internet, which reduces the number of ports each
subscriber can use. This has negative impacts on some
applications (e.g., Apple iTunes, Google Maps). This problem is
resolved by the content provider and the subscriber both using
IPv6.
This draft is discussed on the [v4v6interm-interest] mailing list.
Individual proposals are discussed on the mailing list indicated in
this document.
3. Overview of Proposals
This document classifies the proposals into two categories. The
first category provides IPv4 and IPv6 access to the subscriber, and
the second category provides IPv6 access to the subscriber. In both
categories, IPv4 addresses are conserved by using a NAT device. This
NAT device is placed in the carrier's network ("Carrier Grade NAT")
or (in the case of APB-Revised) in the CPE. In all proposals (except
NAT444) a host can obtain native IPv6 connectivity with native IPv6
hosts without regard to the co-existence proposal.
The descriptions below provide a very brief overview of each
proposal, in alphabetical order.
Wing, et al. Expires March 20, 2009 [Page 5]
Internet-Draft NAT-PT Replacement Comparison September 2008
3.1. IPv4 hosts in Customer Premise
For Internet access, the following proposals allow for IPv4 hosts in
the customer premise.
3.1.1. APB-Revised (APBR)
APB-Revised (APBR) (no document yet available) shares each IPv4
address amongst several subscribers through a stateless CGN. APBP
was introduced in [I-D.despres-v6ops-apbp] and APB-Revised further
evolves the concept so that mappings, between IPv6 addresses and
IPv4-address/port-ranges are static. The static mapping avoids the
need for the service provider equipment to NAT.
APBR can be implemented with subscriber site tunnel endpoints either
in a router (CPE or other router) or in the APBR host. In both
implementations, each subscriber site is assigned a subset of public
IPv4 address range available to the CGN, typically limited to a
single address and a restricted port range. Figure 1 shows the APBR
architecture in the case where the tunnel is established between the
CPE router (upgraded to support APBPR) and the softwire tunnel
concentrator. Any IPv4 traffic from hosts behind the CPE is NAT'd
(using classic NAT44) and forwarded through the tunnel to the tunnel
endpoint. The CPE NATs using the external port range it is
'borrowing' from the APBR endpoint. This is abbreviated APBR-CPE in
this document.
This proposal is discussed in [Softwires].
APBR allows for two implementations for IPv4 access. Figure 1 shows
APBR using a CGN (abbreviated APBR-CGN in this document).
+---+ +-------------+
IPv6 host-----+ | +----------------+IPv6 Internet|
| +--IPv6------+ +-------------+
Dual-stack host--+ |
|NAT| +--------+ +-------------+
IPv4 host----+ +===IPv6 tunnel===+softwire+--+IPv4 Internet|
+---+ | tunnel | +-------------+
|concent.|
+--------+
|<private IPv4>NAT<----------------------------public v4---->
Figure 1: APBPR-CPE, tunnel between CPE and CGN
In the figure above, the IPv6 tunnel is an IPv4-over-IPv6 tunnel.
Wing, et al. Expires March 20, 2009 [Page 6]
Internet-Draft NAT-PT Replacement Comparison September 2008
Figure 2 shows another APBR architecture where the tunnel is
established directly between the host (upgraded to support APBR) and
the APBR tunnel endpoint. Any IPv4 traffic from the APBR host is
routed through the tunnel to the softwire tunnel concentrator.
Tunnelling is sufficient; no NAT device is needed between the host
and the public IPv4 network. This is abbreviated APBR-host in this
document.
+---+ +-------------+
IPv6 host-----+ | +----------------+IPv6 Internet|
| +--IPv6------+ +-------------+
Dual-stack host--+ |
|NAT| +--------+ +-------------+
IPv4 host----+ +===IPv6 tunnel===+softwire+--+IPv4 Internet|
+---+ | tunnel | +-------------+
|concent.|
+--------+
|<private IPv4>NAT<----------------------------public v4---->
Figure 2: APBR-host - tunnel between CPE and APBR tunnel endpoint
Figure 3 shows the APBR architecture with two tunnels. One tunnel is
established between the CPE router and the APBR endpoint, and a
second tunnel between the subscriber host and the CPE router. In
this architecture, the CPE is upgraded to establish a tunnel to the
softwire tunnel concentrator (external side) and to accept a tunnel
from the host (internal side); the APBR host IP stack is upgraded to
establish a tunnel to the CPE. Any traffic from the APBR host is
routed by the host's APBR stack and forwarded through the tunnel to
the CPE. Tunnelling is sufficient; no NAT device is needed between
the host and the core IPv4 network. This is abbreviated APBR-HC
(Host and CPE) in this document.
Wing, et al. Expires March 20, 2009 [Page 7]
Internet-Draft NAT-PT Replacement Comparison September 2008
+---+ +-------------+
IPv6 host-----+ | +----------------+IPv6 Internet|
| +--IPv6------+ +-------------+
DS host==v4/v4==+ |
|NAT| +--------+ +-------------+
IPv4 host----+ +===IPv6 tunnel===+softwire+--+IPv4 Internet|
+---+ | tunnel | +-------------+
|concent.|
+--------+
|<------- public v4 (partially in 2 consecutive tunnels ------>
|<-private v4-->|<--service provider IPv6--->|<----public v4-->
Figure 3: APBR-HC - tunnels between CPE and APBR-tunnel endpoint and
between host and CPE
3.1.2. Dual-Stack Lite (DS-Lite)
Dual-Stack Lite (DS-Lite) provides a global IPv4 address that is
shared amongst several subscribers through a CGN. Each subscriber
network is connected to the CGN through a tunnel, using IPv6 as the
tunnel transport. All IPv4 traffic is sent inside of that tunnel.
The tunnel endpoint implements Dual-Stack [RFC4213]. DS-lite is
currently described in two Internet Drafts,
[I-D.durand-dual-stack-lite] and [I-D.droms-softwires-snat], and is
discussed in [Softwires].
DS-Lite can be implemented with the tunnel endpoints either in a
router (CPE or aggregation router) or in a host. In both cases, a
single subscriber IPv4 address or IPv4 prefix may overlap, or even be
identical for all subscribers. Addresses from overlapping address
spaces are disambiguated by the tunnels between the subscriber
networks and the CGN.
Figure 4 shows the DS-Lite architecture in the case where the tunnel
is terminated in a router, which could be the CPE or an aggregation
router. In the diagram, the router terminating the tunnel is a CPE,
but another router could be used as well (e.g., service provider's
aggregation router). In this architecture, the router is upgraded to
establish a tunnel to the CGN, and does not perform any NAT
processing on subscriber traffic. The router provides DHCP service
(addresses and other configuration information) to the subscriber
hosts. This is abbreviated "DS-Lite router" in this document.
Wing, et al. Expires March 20, 2009 [Page 8]
Internet-Draft NAT-PT Replacement Comparison September 2008
+------+ +-------------+
IPv6 host-----+ | +-----------------+IPv6 Internet|
| +--IPv6------+ +-------------+
Dual-stack host-+ |
|router| +---+ +-------------+
IPv4 host-----+ +===IPv6 tunnel=========+CGN+--+IPv4 Internet|
+------+ +---+ +-------------+
|<--private v4 (partially in tunnel)-->NAT<---public v4---->
|<--service provider IPv6-->|<----public v4---->
Figure 4: Dual-Stack Lite, tunnel terminated on router (DS-Lite
router)
The choice of encapsulation for the IPv6 tunnel is outside the scope
of this document.
Figure 5 shows the DS-Lite architecture when the tunnel is terminated
in the subscriber host. In this architecture, the DS-Lite host IP
stack is upgraded to establish a tunnel to the CGN, through an
unmodified CPE and across either IPv6 transport. IPv4 traffic from
the DS-Lite host is routed through the tunnel to the CGN. This is
abbreviated "DS-Lite host" in this document.
+------+ +-------------+
IPv6 host----+ +-------------------------------+IPv6 Internet|
| | +-------------+
|router|
DS-Lite | | +---+ +-------------+
host==================IPv4-over-IPv6 tunnel==+CGN+--+IPv4 Internet|
+------+ +---+ +-------------+
|<--private v4 (in tunnel)------------->NAT<---public v4---->
|<-subscr. IPv6-->|<--service provider IPv6-->|<----public v4---->
Figure 5: Dual-Stack Lite, tunnel terminated on host (DS-Lite host)
The choice of encapsulation for the IPv6 tunnel is outside the scope
of this document.
3.1.3. NAT444
NAT444 (no written proposal) would NAT twice: first using a NAT
device in the customer premise (as typically deployed today) and
another NAT device in the ISP's network (a CGN). This proposal is
discussed in [Behave].
This proposal does not provide native IPv6 access to the subscriber,
Wing, et al. Expires March 20, 2009 [Page 9]
Internet-Draft NAT-PT Replacement Comparison September 2008
but doesn't preclude it if the host or its CPE wanted to use a
tunneling solution (e.g., Teredo [RFC4380])
+---+ +---+ +-------------+
IPv4 host----+NAT+------IPv4---------+CGN+--+IPv4 Internet|
+---+ +---+ +-------------+
|<-private v4->|<----private v4------->|<----public v4---->
Figure 6: NAT444
3.2. IPv6 hosts in Customer Premise
For Internet access, the following proposals require IPv6 hosts in
the customer premise, and do not support IPv4 hosts. These proposals
provide access to the IPv4 Internet without requiring dual-stack on
client equipment.
3.2.1. IVI
IVI ([I-D.xli-behave-ivi], [I-D.baker-behave-ivi]) uses an address
and service architecture designed to facilitate transition from an
IPv4 Internet to an IPv6 Internet. This service contains three
parts: A DNS Application Layer Gateway, a stateful Network Address
Translator that enables IPv6 clients to initiate connections to IPv4
servers and peers, and a stateless Network Address Translator that
enables IPv4 and IPv6 systems to interoperate freely.
For an IPv6 host needing access to IPv4 hosts, IVI is similar to both
SIIT [RFC2765] and NAT-PT [RFC2766] but with a different address
format. Rather than using the DNS-ALG described in [RFC2766], the
DNS rewriting function (A to AAAA) is fixed and points to a specific
IVI gateway, which removes the relationship between the NAT function
and DNS function. The DNS server may be in the IVI gateway or in a
separate system related to it.
IVI also allows IPv4 hosts to access a IPv6 host, using a stateless
NAT. This is accomplished by providing the IPv6 host an IVI address,
which is simply an IPv6 address from a pool of IPv6 addresses. This
pool of IPv6 addresses has a fixed IPv4-to-IPv6 mapping algorithm
applied to translate between the two address families and the
translation is implemented by an IVI gateway. The IPv6 address would
be advertised in DNS with an A record, pointing to the IVI gateway.
This allows IPv6-only hosts to have a presence on the IPv4 Internet.
In this scheme, subsets of the IPv4 addresses are embedded in prefix-
specific IPv6 addresses and these IPv6 addresses can therefore
communicate with the global IPv6 networks directly and can
communicate with the global IPv4 networks via stateless (or almost
Wing, et al. Expires March 20, 2009 [Page 10]
Internet-Draft NAT-PT Replacement Comparison September 2008
stateless) gateways. DNS rewriting is not used, or necessary, for
this fixed mapping of IPv4 addresses to IPv6 address.
This proposal is discussed in [Behave].
+-------------+
+--------------------------+IPv6 Internet|
| +-------------+
| +-----+
+---+ | +----+ IVI |----+
IPv6 host---+ | | / +-----+ \ +-------------+
|CPE+--IPv6-< >--+IPv4 Internet|
IPv6 host---+ | \ +-----------+ / +-------------+
+---+ +-+DNS-rewrite|-+
+-----------+
Figure 7: IVI
3.2.2. NAT6
NAT6 [I-D.jennings-behave-nat6] encourages IPv6 host itself to
provide necessary DNS rewriting functions (appending a configured
IPv6 prefix to an IPv4 address to create an IPv6 address) and have
the NAT function (from IPv6 to IPv4) performed in the network. By
having the host provide the DNS rewriting function, a DNS rewriting
function in the network is avoided. This proposal is discussed in
[Behave].
+-------------+
+--------------+IPv6 Internet|
| +-------------+
+---+ |
IPv6 host---+ | | +----+ +-------------+
|CPE+--IPv6--+NAT6+-----+IPv4 Internet|
IPv6 host---+ | +----+ +-------------+
+---+
Figure 8: NAT6
3.2.3. NAT64
For an IPv6 host needing access to IPv4 hosts, NAT64
[I-D.bagnulo-behave-nat64] uses the logic of SIIT [RFC2765] and
NAT-PT [RFC2766] but with a different address format. This removes
the relationship between the NAT function and DNS function. Rather
than using the DNS-ALG described in [RFC2766], the DNS service simply
advertises DNS A and AAAA records specifying the IPv6 address of the
NAT64 device (which is a CGN device). The DNS server may be in the
Wing, et al. Expires March 20, 2009 [Page 11]
Internet-Draft NAT-PT Replacement Comparison September 2008
CGN or in a separate system related to it. This proposal is
discussed in [Behave].
+-------------+
+----------------------------+IPv6 Internet|
| +-------------+
| +-----+
+---+ | +-----+NAT64+-----+
IPv6 host---+ | | / +-----+ \ +-------------+
|CPE+--IPv6-< >--+IPv4 Internet|
IPv6 host---+ | \ +-------------+ / +-------------+
+---+ +-+DNS rewriting|-+
+-------------+
Figure 9: NAT64
Note: the following network architecture is not described in NAT64
[I-D.bagnulo-behave-nat64], but is included here for completeness.
It is also possible to utilize NAT64 to access private IPv4 address
(Figure 10). This is useful if there are a lot of IPv4 servers and
it is too difficult or expensive to put each of them on a global IPv4
address, and it is not possible to upgrade them to IPv6.
+-----+
+---+ +-----+NAT64+-----+
IPv6 host---+ | / +-----+ \ +--------------+
|CPE+---IPv6--- < >--+ Private IPv4 |
IPv6 host---+ | Internet \ +- - - - - - -+ / +--------------+
+---+ +-+DNS rewriting|-+
+- - - - - - -+
Figure 10: NAT64 to Private IPv4 Addresses
Note that in this scenario, DNS rewriting is probably avoidable, as
all of the IPv4 addresses could be given AAAA records.
3.2.4. NAT-PT
This section is provided for reference only, because NAT-PT has been
deprecated by [RFC4966].
NAT-PT [RFC2766] provides a combined DNS-ALG and NAT function, which
share state. This is typically implemented in a single device.
Wing, et al. Expires March 20, 2009 [Page 12]
Internet-Draft NAT-PT Replacement Comparison September 2008
+-------------+
+----------------------+IPv6 Internet|
| +-------------+
| +-----------+
| | +- - -+ |
+---+ | +--+ NAT +--+
IPv6 host---+ | | /| +- + -+ |\ +-------------+
|CPE+--IPv6-< | | | >--+IPv4 Internet|
IPv6 host---+ | \| +- -+- -+ |/ +-------------+
+---+ +-+DNS-ALG|-+
| +- - - -+ |
+-----------+
Figure 11: NAT-PT
NAT-PT [RFC2766] and [RFC4966] can be discussed in [Behave].
3.2.5. sNAT-PT
For an IPv6 host needing access to IPv4 hosts, sNAT-PT
[I-D.miyata-v6ops-snatpt] provides DNS rewriting and NAT
functionality. The DNS rewriting component is described in
[I-D.endo-v6ops-dnsproxy].
sNAT-PT also provides access from the IPv4 Internet to IPv6 hosts
with a 1:1 mapping.
This proposal is discussed in [Behave].
+-------------+
+------------------------------+IPv6 Internet|
| +-------------+
| +-------+
+---+ | +-----+sNAT-PT|-----+
IPv6 host---+ | | / +-------+ \ +-------------+
|CPE+--IPv6-< >--+IPv4 Internet|
IPv6 host---+ | \ +-------------+ / +-------------+
+---+ +--+DNS rewriting|--+
+-------------+
Figure 12: sNAT-PT
4. Changes Required in Network Elements
This section describes changes to network elements for various
scenarios. In all cases, the content provider's DNS and content
provider's network does not need to change (except due to the problem
Wing, et al. Expires March 20, 2009 [Page 13]
Internet-Draft NAT-PT Replacement Comparison September 2008
of port limitations as described in Section 2).
4.1. IPv4 and IPv6 Hosts Accessing the IPv4 Internet
For the case of an IPv4 host, IPv6 host, or dual-stack host that need
to connect to IPv4 hosts on the Internet, the following table
summarizes the changes required to various network elements:
+-----------+--------------+--------------+-----------+-------------+
| Proposal | Subscriber | Subscriber | Home | ISP Access |
| | Devices | Devices w/o | Gateway | Network |
| | w/CPE | CPE | (CPE) | |
+-----------+--------------+--------------+-----------+-------------+
| APBR-CPE | no change | (not | APBR CPE | APBR |
| | | applicable) | | endpoint |
| | | | | (stateless) |
+-----------+--------------+--------------+-----------+-------------+
| APBR-host | (not | APBR CPE | APBR CPE | APBR |
| | applicable) | | | endpoint |
| | | | | (stateless) |
+-----------+--------------+--------------+-----------+-------------+
| APBR-HC | APBR support | (not | APBR CPE | APBR |
| | | applicable) | internal | endpoint |
| | | | & | (stateless) |
| | | | external | |
+-----------+--------------+--------------+-----------+-------------+
| NAT444 | no change | no change | no change | NAT v4v4 |
+-----------+--------------+--------------+-----------+-------------+
| DS-Lite | no change | (not | DS-Lite | NAT v4v4 |
| router | | supported; | CPE | w/tunnel |
| | | use DS-Lite | | |
| | | host) | | |
+-----------+--------------+--------------+-----------+-------------+
| DS-Lite | (not | DS-Lite v6 | no change | NAT v4v4 |
| host | supported; | | | w/tunnel |
| | use DS-Lite | | | |
| | router) | | | |
+-----------+--------------+--------------+-----------+-------------+
| IVI | move to v6 | move to v6 | move to | IVI + DNS |
| | | | v6 | rewriting |
+-----------+--------------+--------------+-----------+-------------+
| NAT6 | move to v6 | move to v6 | move to | NAT6 |
| | | | v6 | |
+-----------+--------------+--------------+-----------+-------------+
| NAT64 | move to v6 | move to v6 | move to | NAT64 + DNS |
| | | | v6 | rewriting |
+-----------+--------------+--------------+-----------+-------------+
Wing, et al. Expires March 20, 2009 [Page 14]
Internet-Draft NAT-PT Replacement Comparison September 2008
+-----------+--------------+--------------+-----------+-------------+
| NAT-PT | move to v6 | move to v6 | move to | NAT-PT + |
| | | | v6 | DNS-ALG |
+-----------+--------------+--------------+-----------+-------------+
| sNAT-PT | move to v6 | move to v6 | move to | sNAT-PT + |
| | | | v6 | DNS |
| | | | | rewriting |
+-----------+--------------+--------------+-----------+-------------+
Table 1: Changes Required to Network Elements
For IPv6 hosts that access the IPv4 Internet, the following table
describes the high-level technologies used by each proposal.
+------------------+------------------+--------------+--------------+
| Proposal | ISP's Internal | DNS Impact | Carrier |
| | Network | | Grade NAT |
+------------------+------------------+--------------+--------------+
| APBR-CGN and | IPv4/IPv6 tunnel | no change | (no CGN) |
| APBP-borrow | | | |
+------------------+------------------+--------------+--------------+
| DS-Lite router | IPv4/IPv6 tunnel | no change | IPv4/IPv4 |
+------------------+------------------+--------------+--------------+
| DS-Lite host | IPv4/IPv6 tunnel | no change | IPv4/IPv4 |
+------------------+------------------+--------------+--------------+
| NAT444 | (v6 not | (v6 not | (v6 not |
| | supported) | supported) | supported) |
+------------------+------------------+--------------+--------------+
| IVI | v4 NATted, | DNS | IPv6/IPv4 |
| | native v6 | rewriting | |
| | address | | |
+------------------+------------------+--------------+--------------+
| NAT64 | v4 NATted, | DNS | IPv6/IPv4 |
| | native v6 | rewriting | |
| | address | | |
+------------------+------------------+--------------+--------------+
| NAT-PT | v4 NATted, | DNS-ALG | IPv6/IPv4 |
| | native v6 | | |
| | address | | |
+------------------+------------------+--------------+--------------+
| sNAT-PT | v4 NATted, | DNS | IPv6/IPv4 |
| | native v6 | rewriting | |
| | address | | |
+------------------+------------------+--------------+--------------+
Table 2: IPv6 to IPv4 - technologies involved
Wing, et al. Expires March 20, 2009 [Page 15]
Internet-Draft NAT-PT Replacement Comparison September 2008
4.2. IPv4 Hosts Accessing the IPv4 Internet
The following table compares the four mechanisms that support end
hosts running IPv4 to access the IPv4 Internet: APB-Revised, Dual-
Stack Lite, NAT444.
+----------+-------------------+-----------------+------------------+
| Proposal | CPE | ISP's Internal | Service Provider |
| | | Network | Equipment |
+----------+-------------------+-----------------+------------------+
| APBR-CPE | IPv6 support + | IPv6 | IPv6 tunnel |
| | IPv4/IPv6 tunnel | | termination |
| | + NAT44 | | |
+----------+-------------------+-----------------+------------------+
| DS-Lite | IPv6 support + | IPv6 | IPv6 tunnel |
| router | IPv4/IPv6 tunnel | | termination, |
| | | | NAT44 (CGN) |
+----------+-------------------+-----------------+------------------+
| DS-Lite | IPv6 support (if | IPv6 (if using | IPv6 tunnel |
| host | using DS-Lite | DS-Lite IPv6 | termination, |
| | IPv6 tunneling) | tunneling) | NAT44 |
+----------+-------------------+-----------------+------------------+
| NAT444 | no change | multi-realm | NAT44 (CGN) |
| | | IPv4 | |
+----------+-------------------+-----------------+------------------+
Table 3: IPv4 Hosts Accessing the IPv4 Internet
The proposals IVI, NAT6, NAT64, NAT-PT, and sNAT-PT are not shown in
table Table 3 because those proposals provide no support for IPv4-
only hosts to access the IPv4 Internet.
4.3. IPv4 Internet Accessing IPv6 hosts
IVI, NAT-PT, and sNAT-PT all provide mechanisms for IPv4 hosts on the
Internet to access IPv6-only servers. Such mappings consume IPv4
address space.
IVI: IVI allows 1:1 mapping from an IPv4 client to an IPv6 server.
IVI also allows 1:n mappings, by utilizing the TCP/UDP port number of
the incoming IPv4 packet in the algorithm to determine the
destination IPv6 host; this conserves IPv4 address space consumption
for those hosts that need a few TCP/UDP ports available from the IPv4
Internet.
NAT-PT: NAT-PT allows 1:n mapping from an IPv4 client to an IPv6
server, which is accomplished by dynamically mapping an IPv4 address
to an IPv6 address after a DNS "A" record query.
Wing, et al. Expires March 20, 2009 [Page 16]
Internet-Draft NAT-PT Replacement Comparison September 2008
sNAT-PT: NAT-PT allows 1:1 mapping from an IPv4 client to an IPv6
server.
5. Port Forwarding
Some applications require accepting incoming UDP or TCP traffic.
When the remote host is on IPv4, the incoming traffic will be
directed towards an IPv4 address. The applications are separated
into two broad categories: those requiring static incoming ports and
those requiring dynamic incoming ports.
Due to IPv4 NATs and IPv4 firewalls, some applications use [UPnP-IGD]
(e.g., XBox) or ICE [I-D.ietf-mmusic-ice] (e.g., SIP, Yahoo!/Google/
Microsoft chat networks), other applications have all but completely
abandoned incoming connections (e.g., most FTP transfers use passive
mode). But some applications rely on ALGs, UPnP IGD, or manual port
configuration. Further discussion in the IETF community is necessary
to decide how to proceed on this issue.
Note: Placing application awareness (i.e., ALG) in the CGN will
cause bug fixes and new features to be delayed by development,
testing, and deployment. To prevent such delays, application
awareness should be placed elsewhere (e.g., in the CPE or in the
end host).
Note: Extending NAT-PMP [I-D.cheshire-nat-pmp] to support IPv6
could provide provide static port forwarding and dynamic port
forwarding for IPv4 and IPv6 hosts needing access from IPv4 hosts.
5.1. Static Incoming Ports
Static incoming ports are used by applications for multiple sessions.
Note: Some applications (e.g., BitTorrent) can use UPnP IGD to
control IPv4 NATs and open a static incoming port. However,
technical limitations of UPnP IGD appear to prevent UPnP IGD from
being directly implemented in a CGN. The most significant
technical limitation is that UPnP IGD expects the control point
(the host) to be able to specify the public port; with hundreds of
subscribers utilizing the same public IP address, this is
untenable. Other UPnP IGD technical limitations may be
surmountable (e.g., UPnP IGD's ability to create and destroy
mappings for other IP addresses).
Examples of applications that require static incoming ports include:
Wing, et al. Expires March 20, 2009 [Page 17]
Internet-Draft NAT-PT Replacement Comparison September 2008
o HTTP
o SMTP (must be on TCP/25)
o ssh
o BitTorrent
o games (of particular note is that XBox uses UPnP IGD)
The solutions proposed for static ports are:
APBR-host and APBR-HC: assign a port in the available port range;
advertise it with the IPv4 address using a DNS SRV resource
record.
Dual-Stack Lite: none
NAT444: none
IVI: assign IPv6 IVI address to IPv6 hosts that require incoming
IPv4 connections
NAT6: none
NAT64: none
sNAT-PT: assign IPv4 address to IPv6 hosts that require incoming
IPv4 sessions.
5.2. Dynamic Incoming Ports
Dynamic incoming ports are, generally, used by applications for a
single session. Examples of applications that require dynamic
incoming ports include:
o applications that use real-time transport protocol (RTP)
* SIP, RTSP, H.323, MGCP, H.248/Megaco
o non-passive FTP client
o games (of particular note is that XBox uses UPnP IGD)
The solutions proposed for dynamic ports are:
APBR-host and APBR-HC: assign a port in the available port range.
Wing, et al. Expires March 20, 2009 [Page 18]
Internet-Draft NAT-PT Replacement Comparison September 2008
Dual-Stack Lite: none
NAT444: none (although it is reasonable to expect that ALGs, as
they exist in today's IPv4 NATs, might be utilized)
IVI: assign IPv6 IVI address to IPv6 hosts that require incoming
IPv4 connections
NAT6: none
NAT64: applications could be modified to support STUN (for TCP
and UDP) to learn their public IPv4 address and TCP/UDP port.
sNAT-PT: assign IPv4 address to IPv6 hosts that require incoming
IPv4 connections.
6. Analysis with V6OPS's NAT64 Problem Statement
This section analyzes how each proposal maps to the requirements in
[I-D.ietf-v6ops-nat64-pb-statement-req].
[[Placeholder until [I-D.ietf-v6ops-nat64-pb-statement-req] becomes
more stable.]]
7. Comparison of Proposals with NAT-PT Problems
The following sections analyze how proposals fare against the
problems caused by NAT-PT [RFC2766] as documented in [RFC4966]:
7.1. Issues Unrelated to an DNS-ALG
7.1.1. Issues with Protocols Embedding IP Addresses
NAT6 requires applications to handle NAT6 traversal themselves.
The other proposals are silent on this issue, but in general using an
application layer gateway (ALG), in some device in the network,
appears to be the only solution to this problem. See also Section 5.
7.1.2. NAPT-PT Redirection Issues
All proposals are silent on this issue.
Wing, et al. Expires March 20, 2009 [Page 19]
Internet-Draft NAT-PT Replacement Comparison September 2008
7.1.3. NAT-PT Binding State Decay
NAT6 and NAT64 discuss binding lifetimes.
The other proposals are silent on this issue.
7.1.4. Loss of Information through Incompatible Semantics
All proposals are silent on this issue.
7.1.5. NAT-PT and Fragmentation
[[NAT64, NAT6, DS-Lite, and IVI all mention fragmentation. Need to
analyze how they differ.]]
7.1.6. NAT-PT Interaction with SCTP and Multihoming
IVI supports multi-homing if there is a 1:1 mapping between IPv4 and
IPv6 addresses. However, 1:1 mapping is not sustainable as we
approach IPv4 exhaustion.
APBR (both APBR-host and APBR-HC) support SCTP.
The other proposals are silent on this issue. All proposals seem to
be considering only TCP, UDP, and ICMP.
7.1.7. NAT-PT as a Proxy Correspondent Node for MIPv6
All proposals are silent on this issue.
7.1.8. NAT-PT and Multicast
IVI can support Source-Specific Multicast [RFC4607] (see Section 7 of
[I-D.xli-behave-ivi]).
Dual-Stack Lite does not support multicast.
NAT6 does not specify how it can work with multicast.
The other proposals are silent on this issue.
Note: it may be possible for IGMP messages to be propagated and
proxied [RFC4605] across their respective NAT device [RFC5135].
More study on this is needed.
Wing, et al. Expires March 20, 2009 [Page 20]
Internet-Draft NAT-PT Replacement Comparison September 2008
7.2. Issues Exacerbated by the Use of DNS-ALG
7.2.1. Network Topology Constraints Implied by NAT-PT
The separation of NAT and DNS-rewriting reduces the impact of this
issue. IVI, NAT64, and sNAT-PT separate the NAT and DNS-rewrite
functions, and avoid this constraint.
7.2.2. Scalability and Single Point of Failure Concerns
The separation of NAT and DNS-rewriting reduces the impact of this
issue. IVI, NAT64, and sNAT-PT all separate the NAT and DNS-rewrite
functions.
7.2.3. Issues with Lack of Address Persistence
TBD.
7.2.4. DoS Attacks on Memory and Address/Port Pool
A CGN would only allow a certain subscriber to open a certain number
of ports, thereby preventing a single subscriber from DoSing other
subscribers ([I-D.nishitani-cgn], "a CGN SHOULD limit the number of
the CGN external ports").
7.3. Issues Directly Related to Use of DNS-ALG
7.3.1. Address Selection Issues when Communicating with Dual-Stack End-
Hosts
Unlike NAT-PT, all proposals that involve DNS-rewriting (IVI, NAT64,
sNAT-PT) do not return synthetic AAAA records if a real AAAA record
exists. This prevents the problem. A DNS timeout (of the AAAA
query) will prevent the optimum DNS response from being returned
(that is, the real AAAA record rather than the synthesized AAAA
record pointing to the CGN device), but it is still possible to
connect even when such a timeout occurs. In practice, such DNS
timeouts are not a common occurance.
In [I-D.bagnulo-behave-nat64], EDNS0 [RFC2671] is proposed as the
mechanism for a host to determine if the AAAA record is synthetic
(that is, generated by the DNS rewriting function) or if the AAAA
record is genuine (that is, was not synthesized).
7.3.2. Non-Global Validity of Translated RR Records
TBD.
Wing, et al. Expires March 20, 2009 [Page 21]
Internet-Draft NAT-PT Replacement Comparison September 2008
7.3.3. Inappropriate Translation of Responses to A Queries
sNAT-PT avoids this problem with its stateful DNS proxy.
7.3.4. DNS-ALG and Multi-Addressed Nodes
The additional NAT binding state is not created if the DNS rewriting
and NAT functions are separate. Thus, this problem is avoided by
[I-D.xli-behave-ivi], [I-D.bagnulo-behave-nat64], and
[I-D.miyata-v6ops-snatpt].
7.3.5. Limitations on Deployment of DNS Security Capabilities
DNSSEC is incompatible with synthesized DNS responses (DNS
rewriting).
NAT64 recommends that DNSSEC-capable IPv6-only hosts use the EDNS SAS
option to ignore synthetic DNS responses. This would allow the IPv6
host to ignore synthetic DNS responses and allows DNSSEC to work for
non- synthesized AAAA responses. This means, however, that DNSSEC
only works for native IPv6 AAAA responses, and DNSSEC cannot be used
for IPv4 A responses.
No other proposal discusses how it would work with DNSSEC.
Note: A proposal that does DNS rewriting only in a validating
resolver (after validation), or construct records in the
authoritative server, will work fine with DNSsec.
7.4. Impact on IPv6 Application Development
TBD.
8. Security Considerations
[[Placeholder.]]
9. Acknowledgements
Thanks to the authors of the contributions compared in this document,
Cullen Jennings (NAT6); Marcelo Bagnulo, Philip Matthews, Iljitsch
van Beijnum (NAT64); Xing Li, Maoke Chen, Congxiao Bao, Hong Zhang,
Jianping Wu, Fred Baker (IVI); Alain Durand, Ralph Droms, Brian
Haberman (DS-Lite); Tomohiro Nishitani, Shin Miyakawa (CGN); Remi
Despres (APB-Revised); Hiroshi Miyata, Masahito Endo (sNAT-PT).
Wing, et al. Expires March 20, 2009 [Page 22]
Internet-Draft NAT-PT Replacement Comparison September 2008
Thanks to Fred Baker, Dave Thaler and Eric Vyncke for their review
and suggested improvements to the document.
10. IANA Considerations
This document has no IANA actions.
11. References
11.1. Normative References
[I-D.bagnulo-behave-nat64]
Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64/DNS64:
Network Address and Protocol Translation from IPv6 Clients
to IPv4 Servers", draft-bagnulo-behave-nat64-00 (work in
progress), June 2008.
[I-D.baker-behave-ivi]
Li, X., Bao, C., and F. Baker, "IVI Update to SIIT and
NAT-PT", draft-baker-behave-ivi-00 (work in progress),
September 2008.
[I-D.durand-dual-stack-lite]
Durand, A., "Dual-stack lite broadband deployments post
IPv4 exhaustion", draft-durand-dual-stack-lite-00 (work in
progress), July 2008.
[I-D.endo-v6ops-dnsproxy]
Endo, M. and H. Miyata, "Translator Friendly DNS Proxy",
draft-endo-v6ops-dnsproxy-00 (work in progress),
August 2008.
[I-D.ietf-v6ops-nat64-pb-statement-req]
Bagnulo, M., Baker, F., and I. Beijnum, "IPv4/IPv6
Coexistence and Transition: Requirements for solutions",
draft-ietf-v6ops-nat64-pb-statement-req-00 (work in
progress), May 2008.
[I-D.jennings-behave-nat6]
Jennings, C., "NAT for IPv6-Only Hosts",
draft-jennings-behave-nat6-00 (work in progress),
July 2008.
[I-D.miyata-v6ops-snatpt]
Miyata, H. and M. Endo, "sNAT-PT: Simplified Network
Address Translation - Protocol Translation",
Wing, et al. Expires March 20, 2009 [Page 23]
Internet-Draft NAT-PT Replacement Comparison September 2008
draft-miyata-v6ops-snatpt-01 (work in progress),
September 2008.
[I-D.nishitani-cgn]
Nishitani, T. and S. Miyakawa, "Carrier Grade Network
Address Translator (NAT) Behavioral Requirements for
Unicast UDP, TCP and ICMP", draft-nishitani-cgn-00 (work
in progress), July 2008.
[I-D.xli-behave-ivi]
Li, X., Chen, M., Bao, C., Zhang, H., and J. Wu, "Prefix-
specific and Stateless Address Mapping (IVI) for IPv4/IPv6
Coexistence and Transition", draft-xli-behave-ivi-00 (work
in progress), July 2008.
[RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", RFC 4966, July 2007.
11.2. Informative References
[Behave] IETF, "BEHAVE working group mailing list",
<https://www.ietf.org/mailman/listinfo/behave>.
[I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.despres-v6ops-apbp]
Despres, R., "A Scalable IPv4-IPv6 Transition Architecture
Need for an address-port-borrowing-protocol (APBP)",
draft-despres-v6ops-apbp-01 (work in progress), July 2008.
[I-D.droms-softwires-snat]
Droms, R. and B. Haberman, "Softwires Network Address
Translation (SNAT)", draft-droms-softwires-snat-01 (work
in progress), July 2008.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
Wing, et al. Expires March 20, 2009 [Page 24]
Internet-Draft NAT-PT Replacement Comparison September 2008
(SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", RFC 4925, July 2007.
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[Softwires]
IETF, "Softwires working group mailing list",
<https://www.ietf.org/mailman/listinfo/softwires>.
[UPnP-IGD]
UPnP Forum, "Universal Plug and Play Internet Gateway
Device", 2000,
<http://www.upnp.org/standardizeddcps/igd.asp>.
[v4v6interm-interest]
IETF, "v4v6interm-interest mailing list", <https://
www.ietf.org/mailman/listinfo/v4v6interm-interest>.
Wing, et al. Expires March 20, 2009 [Page 25]
Internet-Draft NAT-PT Replacement Comparison September 2008
Authors' Addresses
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
David Ward
Cisco Systems, Inc.
Email: wardd@cisco.com
Alain Durand
Comcast
1500 Market st
Philadelphia, PA 19102
USA
Email: alain_durand@cable.comcast.com
Wing, et al. Expires March 20, 2009 [Page 26]
Internet-Draft NAT-PT Replacement Comparison September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
This document was produced using xml2rfc v1.33 (of
http://xml.resource.org/) from a source in RFC-2629 XML format.
Wing, et al. Expires March 20, 2009 [Page 27]