One document matched: draft-despres-v6ops-apbp-00.txt
Internet Engineering Task Force R. Despres
Internet-Draft RD-IPtech
Intended status: Informational April 7, 2008
Expires: October 9, 2008
A Scalable IPv4-IPv6 Transition Architecture
Need for an address-port-borrowing-protocol (APBP)
draft-despres-v6ops-apbp-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 October 9, 2008.
Abstract
This document discusses, for the IPv4-IPv6 coexistence period, the
combined requirement that: (1) legacy IPv4 hosts can establish IPv4
transport connections from customer sites having IPv6-only permanent
addresses; (2) for good scalability, no network address translations
(NATs), and a fortiori no application level gateways (ALGs), need to
be supported within network infrastructures. To satisfy this
requirement, it is concluded that an address-port-borrowing-protocol
(APBP) is needed.
Despres Expires October 9, 2008 [Page 1]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. A simple configuration to be supported - need for an APBP . . 4
3. Anycast and unicast IPv6 addresses of APBP servers . . . . . . 5
4. Upward compatibility with other mechanisms - APBP DHCPv6
option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Other supported configurations . . . . . . . . . . . . . . . . 6
5.1. Other transport and upper-level protocols . . . . . . . . 6
5.2. Pure IPv4 end-to-end connections in dual-stack hosts
at no public-IPv4 address . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Risk of denial of service attacks . . . . . . . . . . . . 8
6.2. Reuse of obsolete address-port combinations . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Despres Expires October 9, 2008 [Page 2]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
1. Introduction
It is now well recognized that, during the transition period from
IPv4 to IPv6 [RFC0791] [RFC2460], somme IPv4 transport connections
(TCP, UDP, etc.) will have to be established across some IPv6-only
infrastructures [Bagnulo-Baker].
Various approaches have been proposed recently for a number of
identified transition configurations, namely [SHANTI] [NAT64]
[NATv4v6v4] [ALD] [sNAT-PT] [MNAT-PT].
SHANTI has the scalability property that no network address
translator (NAT) and a fortiori no application layer gateway (ALG) is
needed in internet service providers (ISP) infrastructures. It uses
for this, without naming it, a type of protocol which we call here
address-port-borrowing-protocol (APBP). With such a protocol, a host
at an IPv6-only address can borrow, from its ISP infrastructure, the
address-port combinations it needs to establish IPv4 connections with
public-IPv4 addresses.
In the client-server configuration of SHANTI, IPv6-capable client
hosts, complemented to support SHANTI, establish IPv4 connections
with IPv4-only servers. The complement in these hosts includes an
internal IPv6-to-IPv4 NAT (with an ALG for all application protocols
that need it).
This draft proposes to keep the scalability property of SHANTI (No
NAT needed in ISP infrastructures), but with a scope extended to the
support IPv4-only hosts in sites having IPv6-only public addresses.
It also proposes that the complement in IPv6-capable hosts, for their
support of IPv4 connections, be simplified, so as to include needing
no NAT (and a fortiori no ALG), and to be functionally more powerful,
leaving no restriction on which application level protocols can be
used. For this, it builds on concepts introduced with the Dual Stack
Transition Mechanism (DSTM) which has been introduced as early as in
2000, but became obsolete in IETF documents in 2005.
A detailed description of the proposed APBP protocol is beyond the
scope of this draft, but no major difficulty is expected to specify
one.
The proposed architecture being new, and having not been validated on
any implementation, is likely to need refinements, and possibly
corrections. It is submitted for a first round of reactions.
Despres Expires October 9, 2008 [Page 3]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
2. A simple configuration to be supported - need for an APBP
We first consider a simple configuration among those that will need
to be supported during the transition period, and analyze how the
scalability objective we have retained can be satisfied. An IPv4-
only client host is in a site that only has an IPv6 prefix (no
public-IPv4 address). It needs to establish an File Transfer
Protocol (FTP) connection which a server at a public-IPv4 address.
Since the client has only a PRIVATE IPv4 address, and since the
server must only see a PUBLIC IPv4 address to send packets back to
its clients, there must be a NAT somewhere between the two endpoints;
This NAT has to include ALG for FTP.
Since the scalability objective excludes that such a NAT be needed in
the ISP infrastructure, it must be in the CPE router of the site.
There, it must be able to send to the server IPv4 packets that have
their definitive source address, which must be PUBLIC IPv4. This
address has therefore to be borrowed from some IPv6-IPv4 ISP gateway,
where interfaces to both IPv6 and IPv4 routing domains are available.
Between the CPE router and this ISP gateway, IPv4 packets will have
to be encapsulated in IPv6 ones.
Since public-IPv4 addresses have become a precious resource,
borrowing a public-IPv4 address with complete exclusivity for the
duration of an FTP connection would be a waste. The CPE router
should rather borrow address-port combinations, letting the same
address free to be used by other hosts (or the same one) for
connections using different ports.
In summary, to satisfy the scalability objective of no NAT with ALG
in ISP infrastructures for the configuration of Figure 1, an address-
port-borrowing-protocol (APBP) is needed. With it, CPE routers,
acting as APBP clients borrow address-port combinations from ISP
gateways acting as APBP servers. Between APBP clients and APBP
servers, IPv4 packets are encapsulated in IPv6 packets.
Despres Expires October 9, 2008 [Page 4]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
IPv4-ONLY HOST CPE Router IPv6-IPv4 IPv4-capable HOST
ISP Gateway
* FTP Client * FTP server
.-----. .-----.
| | * IPv4-IPv4 NAT | |
| | * FTP ALG | |
| | * APBP client * APBP server | |
| | .---------. .-------. | |
| 4 | | 4 4/6| |4/6 4 | | 4 |
'--+--' '-+-----+-' '-+---+-' '--+--'
| | | | | |
'----------' '--------------' '---- . . . --'
Private-IPv4 IPv6 ONLY Public IPv4
\____________________/ \________________/
Customer site ISP infrastructure
A SIMPLE CONFIGURATION TO BE SUPPORTED
(APBP = address-port-borrowing-protocol)
Figure 1
Note that the reason why the client host is IPv4-only for the
considered connection can be one of the following :
o The APPLICATION is IPv4-only, and if the stack is dual stack, it
has no means obtain a temporary IPv4 public address.
o The PROTOCOL STACK is IPv4-only.
3. Anycast and unicast IPv6 addresses of APBP servers
For ISP gateways to securely release address-port combinations that
are no longer in use, all packets of a given connection must traverse
the same ISP gateway, and some form of keep-alive control has to be
exercised.
On the other hand, different connections established by a given
client need not to traverse the same ISP gateway.
APBP ISP gateways should therefore have two IPv6 addresses:
Despres Expires October 9, 2008 [Page 5]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
o an ANYCAST address, to be used by a client host when it needs to
borrow a new address-port combination;
o a UNICAST address, to be used by APBP clients as IPv6 destination
of IPv4 packets they encapsulate, and to be advertised for this by
APBP servers when they lend address-port combinations.
4. Upward compatibility with other mechanisms - APBP DHCPv6 option
Upward compatibility of the new mechanism with existing ones must be
ensured as follows:
o APBP-capable CPE routers must activate APBP if and only if
attached to APBP-capable ISP infrastructures.
o The behavior of APBP-unable CPE routers must be independent from
whether they are attached to APBP-capable or APBP-unable ISP
infrastructures.
This can be achieved with an APBP specific DHCPv6 option [RFC3315].
This option: (1) is advertised by APBP-capable ISP infrastructures;
(2) must have been received by APBP-capable CPE routers before they
activate the APBP logic; (3) is ignored by APBP-unable CPE routers
(like any DHCPv6 option the code of which is unknown by these
routers).
Besides its upward compatibility role, the APBP DHCPv6 option is used
to indicate to APBP-clients the IPv6 anycast address of APBP servers
of their ISPs.
5. Other supported configurations
APBP, which has been shown to be necessary for the particular
configuration of Section 2, is also applicable to many other
configurations.
5.1. Other transport and upper-level protocols
All other transport protocols than TCP and all other application-
level protocols than FTP that are supported in the IPv4-IPv4 NAT of
the CPE router are possible on the physical configuration of
Figure 1.
Thus, any protocol combination that works across a given IPv4-IPv4
NAT between a private-IPv4 domain and a public-IPv4 domain will also
work between a private-IPv4 domain and an IPv6 domain, provided that:
Despres Expires October 9, 2008 [Page 6]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
(1) this NAT is completed with an APBP-client function, (2) the local
ISP supports APBP servers.
Note that among these protocols there are the particular ones that
make port reservations in NATs for hosts in private-IPv4 domains to
become accessible from the outside (UPnP, STUN etc.).
5.2. Pure IPv4 end-to-end connections in dual-stack hosts at no public-
IPv4 address
If the support of the APBP-client function is added to a dual-stack
host, and if this host is attached to an ISP infrastructure where
APBP is supported, this host can establish pure IPv4 end-to-end
transport connections with IPv4-only remote hosts (Figure 2).
No NAT being needed on the end-to-end path, packets keep their IPv4
source and destination IPv4 addresses and ports unchanged from source
to destination. Thus, ALL IPv4-capable applications, which
necessarily work with public-IPv4 addresses at both ends, also work
across the IPv6 domain of this configuration.
APBP-capable IPv6-IPv4 IPv4-only host
Dual-Stack Host ISP Gateway
* APBP client
.-----. .-----.
| | <== E2E IPv4 transport connection ==> | |
| | | |
| | Possible * APBP server | |
| | IPv6-capable .-------. | |
| 4/6 | CPE router |4/6 4 | | 4 |
'--+--' | '-+---+-' '--+--'
| V | | |
'---------- . . . ----------' '---- . . . --'
IPv6 IPv6 Public IPv4
\_________________/ \________________/
Customer site ISP infrastructure
APBP BETWEEN ABPB-CAPABLE DUAL-STACK HOSTS AND ISP GATEWAYS
Figure 2
Despres Expires October 9, 2008 [Page 7]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
Applications that need to dynamically advertise their address-port
combinations, e.g. for callbacks or referrals, obtain these
combinations, when APBP is used, at their socket programming
interface as usual.
With Windows Sockets, for example, local address-port combinations
are obtained by applications as results of getsockname() function
calls. A client application calls getsockname() after having made a
connect() function call, which has triggered the needed APBP address-
port combination request. A server application calls getsockname()
after having made a bind() function call with INADDR_ANY as local
IPv4 address, which has triggered the needed APBP address-port
combination request.
6. Security Considerations
6.1. Risk of denial of service attacks
Like any ISP provided function using limited resources, APBP servers
may be subject to denial of service attacks.
The amount of traffic needed for such attacks is however
significantly greater than that needed for NATs with ALGs, for two
reasons :
o For a new connection, it is an ANYCAST address which, in the APBP
case, is used to reach the ISP gateway in charge of a connection.
This facilitates load sharing among many ISP gateways, possibly
largely remote from one another.
o The amount of processing per data packet needed for APBP can be
significantly smaller than that needed for NATs (no transport-
level checksums to deal with, and no ALGs needed).
6.2. Reuse of obsolete address-port combinations
APBP servers, like NATs, have to maintain stateful information about
currently used address-port combinations. Precautions are therefore
needed to ensure that, when an address-port combination is reused, no
confusion be possible between packets of a new connection and packets
of old ones.
For this, APBP clients must check that encapsulated IPv4 packets they
receive do belong to the right active application socket.
They can do it securely if IPv4 packets are encapsulated in UDP
datagrams (themselves encapsulated in IPv6 packets), and if UDP ports
Despres Expires October 9, 2008 [Page 8]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
of APBP-clients point to the concerned application sockets.
With this precaution, no danger of confusion is foreseen between
packets of old and new connections that use the same address-port
combination.
7. IANA Considerations
The following assignments by IANA are desirable:
o A UDP port number for the APBP-server application (Section 6.2).
o A DHCPv6 option code for APBP-capable ISP infrastructures to
advertise their capability (Section 4).
8. Acknowledgements
This draft is in continuity with previous works that influenced it,
or at least anticipated some of its contents. In particular, the
work of Laurent Toutain and his colleagues on DSTM, as early as in
2000, had a significant influence. Myung-Ki Shin's work on the port
option of DSTM in 2002 was unknown by the author, but anticipated the
idea of address-port combination borrowed by IPv6-capable hosts.
Brian Carpenter was first, as far as the author knows, to post a
draft where address-port combinations were borrowed directly from ISP
gateways.
Despres Expires October 9, 2008 [Page 9]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
9. References
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
9.2. Informative References
[ALD] "draft-woodyatt-ald-02 (work in progress)", December 2007.
[Bagnulo-Baker]
"draft-bagnulo-v6ops-6man-nat64-pb-statement-01 (work in
progress)", February 2008.
[DSTM] "Dual Stack Transition Mechanism -
http://www.ipv6.rennes.enst-bretagne.fr/dstm/".
[MNAT-PT] "draft-v6ops-van-beijnum-mnat-pt-00 (work in progress)",
February 2008.
[NAT64] "draft-bagnulo-v6ops-6man-nat64-pb-statement-00 (work in
progress)", November 2007.
[NATv4v6v4]
"draft-durand-v6ops-natv4v6v4-00 (work in progress)",
November 2007.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[SHANTI] "draft-carpenter-shanti-01.txt (work in progress)",
November 2007.
[sNAT-PT] "draft-miyata-v6ops-snatpt-00 (work in progress)",
February 2008.
Despres Expires October 9, 2008 [Page 10]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 2008
Author's Address
Remi Despres
RD-IPtech
3 rue du President Wilson
Levallois,
France
Phone: +33 6 72 74 94 88
Email: remi.despres@free.fr
Despres Expires October 9, 2008 [Page 11]
Internet-Draft IPv4-IPv6 transition scalability - APBP April 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.
Despres Expires October 9, 2008 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:12 |