Internet Engineering Task Force                               R. Despres
Internet-Draft                                                 RD-IPtech
Intended status: Informational                             July 14, 2008
Expires: January 15, 2009

              A Scalable IPv4-IPv6 Transition Architecture
           Need for an address-port-borrowing-protocol (APBP)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 15, 2009.


   This document discusses, for the IPv4-IPv6 coexistence period, the
   combined requirement that: (1) legacy IPv4 hosts can establish IPv4
   transport connection s 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 January 15, 2009                [Page 1]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 2008

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  A simple configuration to be supported - need for an APBP  . .  4
   3.  Other supported transport connections  . . . . . . . . . . . .  5
   4.  Other supported configurations . . . . . . . . . . . . . . . .  6
   5.  Some protocol considerations . . . . . . . . . . . . . . . . .  7
   6.  Security considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

Despres                 Expires January 15, 2009                [Page 2]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 2008

1.  Introduction

   It is now well recognized that, during the transition period from
   IPv4 to IPv6 [RFC0791] [RFC2460], some 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
   that has no public IPv4 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
   support IPv4-only hosts in sites that have no public IPv4 addresses.

   It also proposes that the SHANTI complement in IPv6-capable hosts,
   for their support of IPv4 connections:

   o  be simplified, so as to not include a NAT (and a fortiori an ALG)

   o  be functionally more powerful, leaving no restriction on which
      upper layer protocols can be used (SCTP compatibility in

   For this, SCTP builds on concepts introduced with the Dual Stack
   Transition Mechanism (DSTM) which has been introduced in
   draft-toutain-ngtrans-dstm-00 (expired in 1999) and last documented
   in draft-bound-dstm-exp-04 (expired in April 2006).

   A detailed description of the proposed APBP protocol is beyond the
   scope of this draft, but no major difficulty is expected to specify

Despres                 Expires January 15, 2009                [Page 3]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 2008

   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.

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
   objective of no NAT in the ISP infrastructure can be satisfied
   Figure 1.  An IPv4-only host is in a site that has an IPv6 prefix and
   has no public IPv4 address.  It needs to establish a File Transfer
   Protocol connection (FTP) whith a server located somewhere on the
   IPv4 Internet.

   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 we took as a requirement that no NAT be needed in the ISP
   infrastructure, NAT capability must be supported in the CPE router of
   the site.  For this NAT to be able to build IPv4 packets having their
   public IPv4 source address, this address has to be borrowed from some
   ISP gateway that has interfaces to both IPv6 and public IPv4 routing
   domains.  Between the CPE router and this ISP gateway, IPv4 packets
   will have to be encapsulated in IPv6 packets.

   Since public IPv4 addresses have become a scarce resource, and since
   most customer sites need only a few of the 64K possible ports which
   can be associated with their IP address, a better usage of public
   IPv4 addresses is achievable if what is borrowed from ISP gateways is
   not than just an address, but rather a combination including one
   address an a range of ports permitted to be associated with it.
   Thus, the same globally unique IPv4 addresses can be used by other
   customer sites, for connections using different ports.

   In summary, to satisfy the objective of no NAT with ALG in ISP
   infrastructures in the configuration of Figure 1, an address-port-
   borrowing-protocol (APBP) is needed.

   With it, CPE routers act as APBP clients.  They borrow address-port
   combinations from ISP gateways that act as APBP servers.  Between
   APBP clients and APBP servers, IPv4 packets are encapsulated in IPv6

Despres                 Expires January 15, 2009                [Page 4]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 2008

    IPv4-ONLY HOST   CPE Router        IPv6-IPv4      IPv4-capable HOST
                                      ISP Gateway

     * FTP Client <====> <========== FTP / TCP ==========> * FTP server
       .-----.                                             .-----.
       |     |                                             |     |
       |     |     * IPv4-IPv4 NAT                         |     |
       |     |     * FTP ALG                               |     |
       |     |     * APBP client       * APBP server       |     |
       |     |     .---------. <= APBP=> .-------.         |     |
       |  4  |     | 4    4/6|           |4/6  4 |         |  4  |
       '--+--'     '-+-----+-'           '-+---+-'         '--+--'
          |          |     |               |   |              |
          '----------'     '---------------'   '---- . . . ---'
          Private-IPv4         IPv6 ONLY         Public IPv4

        \____________________/ \______-__________/
             Customer site      ISP infrastructure

              (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 the host has no public IPv4
      address (the protocol stack can be IPv4-only or dual stack).

   o  The PROTOCOL STACK is IPv4-only (the application can be IPv4-ony
      or IPv4 and IPv6).

3.  Other supported transport connections

   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.

   Transport connections in the reverse direction are also possible, if
   the NAT has assigned some address-port combinations for them,
   typically by means of one of the existing protocols existing for this
   (STUN, UPnP, NAT-PMP, etc.).

Despres                 Expires January 15, 2009                [Page 5]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 2008

   More generally, any protocol combination that works today across a
   IPv4-IPv4 NAT of a given type will also work, with the same type of
   IPv4-IPv4 NAT in any site having no public IPv4 address provided

   1.  The site has an IPv6 prefix.

   2.  The local ISP supports APBP servers.

   3.  This IPv4-IPv4 NAT is complemented with an APBP-client function.

4.  Other supported configurations

   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).

          APBP-capable               IPv6-IPv4      IPv4-only host
        Dual-Stack Host             ISP Gateway

            <======= E2E IPv4 transport connection =======>

        * APBP client  <== APBP ==>  * APBP server
          .-----.                                       .-----.
          |     |     Possible                          |     |
          |     |   IPv6-capable       .-------.        |     |
          | 4/6 |    CPE router        |4/6  4 |        |  4  |
          '--+--'         |            '-+---+-'        '--+--'
             |            V              |   |             |
             '---------- . . . ----------'   '---- . . . --'
                 IPv6            IPv6           Public IPv4

           \_________________/ \________________/
                 Customer site   ISP infrastructure


                                 Figure 2

   No NAT being needed on the end-to-end path, packets keep their IPv4

Despres                 Expires January 15, 2009                [Page 6]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 2008

   source and destination IPv4 addresses and ports unchanged from source
   to destination.  All IPv4 capable applications that need public-IPv4
   addresses at both ends can work across the IPv6 domain of this

   In this configuration, applications that need to dynamically
   advertise their address-port combinations, e.g. for callbacks or
   referrals, obtain these combinations 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.  Client applications make these calls after having made
   connect() function calls.  Server applications call make them after
   their bind() function calls with INADDR_ANY as local IPv4 addresses.

5.  Some protocol considerations

   Since some server applications check that several related transport
   connections initiated by a same client do come from the same IP
   addresses, APBP clients should borrow only one public IP address, and
   manage a set of ports to be used with this address.

   For simplicity, and to minimize interactions between APBP clients and
   servers, these ports should be obtained in significant quantity at
   each request.  This quantity necessarily depends on policies of ISPs
   that operate APBP servers.  Typically, a maximum quantity per
   customer site would help preventing denial of service attacks.
   Provision could be made in the protocol for APBP clients to increase
   and decrease from time to time the number of their borrowed ports
   according to fluctuations of their needs.

   In APBP clients, port management may be optimized so as to increase
   the number of transport connections that are possible with a given
   number of ports.  In particular, port reuse based on endpoint
   dependent mappings may be envisaged for ports that are assigned to
   outgoing transport connections known not to need endpoint independent
   mapping (DNS, HTTP, SMTP, POP3, NNTP, Telnet, SNMP, etc.).

   To avoid that APBP client failures would cause indefinite port
   reservations in APBP servers, some keep-alive mechanism should be
   part of the protocol.  Also, APBP clients should explicitly release
   their borrowed address-ports when they have been using none for a
   significant time.

   For scalability of the APBP server function, the destination address
   used by APBP clients to request address-ports sets when they have

Despres                 Expires January 15, 2009                [Page 7]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 2008

   none yet,would advantageously be an anycast address.  Responses to
   these requests should then indicate unicast addresses of particular
   APBP server instances that have responded (further exchanges of
   encapsulated IPv4 packets must be with these particular instances,
   where the particular address-ports that have been obtained are

6.  Security considerations

   If a third party would be able to act as an ISP APBP server, it would
   be able to intercept all the end-to-end traffic that uses an public
   IPv4 address borrowed from it.

   This can however be made impossible if, in infrastructures of ISPs
   that support APBP, precautions are taken so that addresses of APBP
   servers cannot be counterfeited from customer sites.

7.  IANA Considerations

   The protocol has still to be specified in details, but it can be
   expected that a UDP port number will be needed for the supervisory
   part of APBP.

   Also, having a standardized anycast address to reach APBP servers
   would be simpler than depending on an ISP dependent parameter, plus
   maybe a DHCPv6 option to advertise it.

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 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 January 15, 2009                [Page 8]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 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.

              "draft-bagnulo-v6ops-6man-nat64-pb-statement-01 (work in
              progress)", February 2008.

   [DSTM]     "Dual Stack Transition Mechanism -

   [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.

              "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 January 15, 2009                [Page 9]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 2008

Author's Address

   Remi Despres
   3 rue du President Wilson


Despres                 Expires January 15, 2009               [Page 10]

Internet-Draft   IPv4-IPv6 transition scalability - APBP       July 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

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

   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

Despres                 Expires January 15, 2009               [Page 11]