summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6346.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6346.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6346.txt')
-rw-r--r--doc/rfc/rfc6346.txt2131
1 files changed, 2131 insertions, 0 deletions
diff --git a/doc/rfc/rfc6346.txt b/doc/rfc/rfc6346.txt
new file mode 100644
index 0000000..df6fb21
--- /dev/null
+++ b/doc/rfc/rfc6346.txt
@@ -0,0 +1,2131 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Bush, Ed.
+Request for Comments: 6346 Internet Initiative Japan
+Category: Experimental August 2011
+ISSN: 2070-1721
+
+
+ The Address plus Port (A+P) Approach to the IPv4 Address Shortage
+
+Abstract
+
+ We are facing the exhaustion of the IANA IPv4 free IP address pool.
+ Unfortunately, IPv6 is not yet deployed widely enough to fully
+ replace IPv4, and it is unrealistic to expect that this is going to
+ change before the depletion of IPv4 addresses. Letting hosts
+ seamlessly communicate in an IPv4 world without assigning a unique
+ globally routable IPv4 address to each of them is a challenging
+ problem.
+
+ This document proposes an IPv4 address sharing scheme, treating some
+ of the port number bits as part of an extended IPv4 address (Address
+ plus Port, or A+P). Instead of assigning a single IPv4 address to a
+ single customer device, we propose to extend the address field by
+ using bits from the port number range in the TCP/UDP header as
+ additional endpoint identifiers, thus leaving a reduced range of
+ ports available to applications. This means assigning the same IPv4
+ address to multiple clients (e.g., Customer Premises Equipment (CPE),
+ mobile phones), each with its assigned port range. In the face of
+ IPv4 address exhaustion, the need for addresses is stronger than the
+ need to be able to address thousands of applications on a single
+ host. If address translation is needed, the end-user should be in
+ control of the translation process -- not some smart boxes in the
+ core.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Experimental [Page 1]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are a candidate for any level of
+ Internet Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6346.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Experimental [Page 2]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Problems with Carrier Grade NATs . . . . . . . . . . . . . 4
+ 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Design Constraints and Functions . . . . . . . . . . . . . . . 6
+ 3.1. Design Constraints . . . . . . . . . . . . . . . . . . . . 6
+ 3.2. A+P Functions . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.3. Overview of the A+P Solution . . . . . . . . . . . . . . . 8
+ 3.3.1. Signaling . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.3.2. Address Realm . . . . . . . . . . . . . . . . . . . . 11
+ 3.3.3. Reasons for Allowing Multiple A+P Gateways . . . . . . 15
+ 3.3.4. Overall A+P Architecture . . . . . . . . . . . . . . . 16
+ 3.4. A+P Experiments . . . . . . . . . . . . . . . . . . . . . 17
+ 4. Stateless A+P Mapping Function . . . . . . . . . . . . . . . . 18
+ 4.1. Stateless A+P Mapping (SMAP) Gateway Function
+ Description . . . . . . . . . . . . . . . . . . . . . . . 18
+ 4.2. Implementation Mode . . . . . . . . . . . . . . . . . . . 20
+ 4.3. Towards IPv6-Only Networks . . . . . . . . . . . . . . . . 22
+ 4.4. PRR: On Stateless and Binding Table Modes . . . . . . . . 22
+ 4.5. General Recommendations on SMAP . . . . . . . . . . . . . 23
+ 5. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 24
+ 5.1. A+P Deployment Models . . . . . . . . . . . . . . . . . . 24
+ 5.1.1. A+P for Broadband Providers . . . . . . . . . . . . . 24
+ 5.1.2. A+P for Mobile Providers . . . . . . . . . . . . . . . 24
+ 5.1.3. A+P from the Provider Network Perspective . . . . . . 25
+ 5.2. Dynamic Allocation of Port Ranges . . . . . . . . . . . . 27
+ 5.3. Example of A+P-Forwarded Packets . . . . . . . . . . . . . 28
+ 5.3.1. Forwarding of Standard Packets . . . . . . . . . . . . 32
+ 5.3.2. Handling ICMP . . . . . . . . . . . . . . . . . . . . 32
+ 5.3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . 33
+ 5.3.4. Limitations of the A+P Approach . . . . . . . . . . . 33
+ 5.3.5. Port Allocation Strategy Agnostic . . . . . . . . . . 34
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
+ 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
+ 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
+ 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35
+ 8.2. Informative References . . . . . . . . . . . . . . . . . . 35
+ 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 37
+
+
+
+
+
+
+
+
+
+
+
+Bush Experimental [Page 3]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+1. Introduction
+
+ This document describes a technique to deal with the imminent IPv4
+ address space exhaustion. Many large Internet Service Providers
+ (ISPs) face the problem that their networks' customer edges are so
+ large that it will soon not be possible to provide each customer with
+ a unique public IPv4 address. Therefore, although undesirable,
+ address sharing, in the same molds as NAT, is inevitable.
+
+ To allow end-to-end connectivity between IPv4-speaking applications,
+ we propose to extend the semantics of the IPv4 address with bits from
+ the UDP/TCP header. Assuming we could limit the applications' port
+ addressing to any number of bits lower than 16, we can increase the
+ effective size of an IPv4 address by remaining additional bits of up
+ to 16. In this scenario, 1 to 65536 customers could be multiplexed
+ on the same IPv4 address, while allowing them a fixed or dynamic
+ range of 1 to 65536 ports. Customers could, for example, receive an
+ initial fixed port range, defined by the operator, and dynamically
+ request additional blocks, depending on their contract. We call this
+ "extended addressing" or "A+P" (Address plus Port) addressing. The
+ main advantage of A+P is that it preserves the Internet "end-to-end"
+ paradigm by not requiring translation (at least for some ports) of an
+ IP address.
+
+1.1. Problems with Carrier Grade NATs
+
+ Various forms of NATs will be installed at different levels and
+ places in the IPv4 Internet to achieve address compression. This
+ document argues for mechanisms where this happens as close to the
+ edge of the network as possible, thereby minimizing damage to the
+ End-to-End Principle and allowing end-customers to retain control
+ over the address and port translation. Therefore, it is essential to
+ create mechanisms to "bypass" NATs in the core, when applicable, and
+ keep the control at the end-user.
+
+ With Carrier Grade NATs (CGNs) in the core of the network, the user
+ is trapped behind unchangeable application policies, and the
+ deployment of new applications is hindered by the need to implement
+ the corresponding Application Level Gateways (ALGs) on the CGNs.
+ This is the opposite of the "end-to-end" model of the Internet.
+
+ With the smarts at the edges, one can easily deploy new applications
+ between consenting endpoints by merely tweaking the NATs at the
+ corresponding CPE, or even upgrading them to a new version that
+ supports a specific ALG.
+
+
+
+
+
+
+Bush Experimental [Page 4]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ Today's NATs are typically mitigated by offering the customers
+ limited control over them, e.g., port forwarding, Universal Plug and
+ Play or the NAT Port Mapping Protocol (UPnP/NAT-PMP). However, this
+ is not expected to work with CGNs. CGN proposals -- other than
+ DS-Lite [RFC6333] with A+P or the Port Control Protocol (PCP)
+ [PCP-BASE] -- admit that it is not expected that applications that
+ require specific port assignment or port mapping from the NAT box
+ will keep working.
+
+ Another issue with CGNs is the trade-off between session state and
+ network placement. The farther from the edge the CGN is placed, the
+ more session state needs to be kept due to larger subscriber
+ aggregation and the more disruption that occurs in the case of a
+ failure. In order to reduce the state, CGNs would end up somewhere
+ closer to the edge. Thus, the CGN trades scalability for the amount
+ of state that needs to be kept, which makes optimally placing a CGN a
+ hard engineering problem.
+
+ In some deployment scenarios, a CGN can be seen as the single point
+ of failure, and therefore the availability of delivered services can
+ be impacted by a single CGN device. Means to ensure state
+ synchronization and failover would be required to allow for service
+ continuity whenever a failure occurs.
+
+ Intra-domain paths may not be optimal for communications between two
+ nodes connected to the same domain deploying CGNs; they may lead to
+ path stretches.
+
+1.2. Requirements Language
+
+ 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 [RFC2119].
+
+2. Terminology
+
+ This document makes use of the following terms:
+
+ Public Realm: This realm contains only public routable IPv4
+ addresses. Packets in this realm are forwarded based on the
+ destination IPv4 address.
+
+ A+P Realm: This realm contains both public routable IPv4 and A+P
+ addresses.
+
+ A+P Packet: A regular IPv4 packet is forwarded based on the
+ destination IPv4 address and the TCP/UDP port numbers.
+
+
+
+
+Bush Experimental [Page 5]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ Private Realm: This realm contains IPv4 addresses that are not
+ globally routed. They may be taken from the [RFC1918] range.
+ However, this document does not make such an assumption. We
+ regard as private address space any IPv4 address that needs to be
+ translated in order to gain global connectivity, irrespective of
+ whether or not it falls in [RFC1918] space.
+
+ Port-Range Router (PRR): A device that forwards A+P packets.
+
+ Customer Premises Equipment (CPE): cable or DSL modem.
+
+ Provider Edge (PE) Router: Customer aggregation router.
+
+ Provider Border Router (BR): Provider's edge to other providers.
+
+ Network Core Routers (Core): Provider routers that are not at the
+ edges.
+
+3. Design Constraints and Functions
+
+ The problem of address space shortage is first felt by providers with
+ a very large end-user customer base, such as broadband providers and
+ mobile service providers. Though the cases and requirements are
+ slightly different, they share many commonalities. In the following
+ text, we develop a set of overall design constraints for solutions
+ addressing the IPv4 address shortage problem.
+
+3.1. Design Constraints
+
+ We regard several constraints as important for our design:
+
+ 1) End-to-end is under customer control: Customers shall have the
+ ability to deploy new application protocols at will. IPv4
+ address shortage should not be a license to break the Internet's
+ end-to-end paradigm.
+
+ 2) Backward compatibility: Approaches should be transparent to
+ unaware users. Devices or existing applications should be able
+ to work without modification. Emergence of new applications
+ should not be limited.
+
+ 3) Highly scalable and minimal state core: Minimal state should be
+ kept inside the ISP's network. If the operator is rolling out
+ A+P incrementally, it is understood there may be state in the
+ core in the non-A+P part of such a roll-out.
+
+
+
+
+
+
+Bush Experimental [Page 6]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ 4) Efficiency versus complexity: Operators should have the
+ flexibility to trade off port multiplexing efficiency and
+ scalability and end-to-end transparency.
+
+ 5) "Double-NAT" should be avoided: Multiple gateway devices might be
+ present in a path, and once one has done some translation, those
+ packets should not be retranslated.
+
+ 6) Legal traceability: ISPs must be able to provide the identity of
+ a customer from the knowledge of the IPv4 public address and the
+ port. This should have as low an impact as is reasonable on
+ storage by the ISP. We assume that NATs on customer premises do
+ not pose much of a problem, while provider NATs need to keep
+ additional logs.
+
+ 7) IPv6 deployment should be encouraged. NAT444 strongly biases the
+ users to the deployment of RFC 1918 addressing.
+
+ Constraint 5 is important: while many techniques have been deployed
+ to allow applications to work through a NAT, traversing cascaded NATs
+ is crucial if NATs are being deployed in the core of a provider
+ network.
+
+3.2. A+P Functions
+
+ The A+P architecture can be split into three distinct functions:
+ encaps/decaps, NAT, and signaling.
+
+ Encaps/decaps function: is used to forward port-restricted A+P
+ packets over intermediate legacy devices. The encapsulation function
+ takes an IPv4 packet, looks up the IP and TCP/UDP headers, and puts
+ the packet into the appropriate tunnel. The state needed to perform
+ this action is comparable to a forwarding table. The decapsulation
+ device SHOULD check if the source address and port of packets coming
+ out of the tunnel are legitimate (e.g., see [BCP38]). Based on the
+ result of such a check, the packet MAY be forwarded untranslated, MAY
+ be discarded, or MAY be NATed. In this document, we refer to a
+ device that provides this encaps/decaps functionality as a Port-Range
+ Router (PRR).
+
+ Network Address Translation (NAT) function: is used to connect legacy
+ end-hosts. Unless upgraded, end-hosts or end-systems are not aware
+ of A+P restrictions and therefore assume a full IP address. The NAT
+ function performs any address or port translation, including
+ Application Level Gateways (ALGs) whenever required. The state that
+ has to be kept to implement this function is the mapping for which
+ external addresses and ports have been mapped to which internal
+ addresses and ports, just as in CPEs embedding NAT today. A subtle,
+
+
+
+Bush Experimental [Page 7]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ but very important, difference should be noted here: the customer has
+ control over the NATing process or might choose to "bypass" the NAT.
+ If this is done, we call the NAT a Large-Scale NAT (LSN). However,
+ if the NAT does NOT allow the customer to control the translation
+ process, we call it a CGN.
+
+ Signaling function: is used to allow A+P-aware devices to get to know
+ which ports are assigned to be passed through untranslated and what
+ will happen to packets outside the assigned port range (e.g., could
+ be NATed or discarded). Signaling may also be used to learn the
+ encapsulation method and any endpoint information needed. In
+ addition, the signaling function may be used to dynamically assign
+ the requested port range.
+
+3.3. Overview of the A+P Solution
+
+ As mentioned above, the core architectural elements of the A+P
+ solution are three separated and independent functions: the NAT
+ function, the encaps/decaps function, and the signaling function.
+ The NAT function is similar to a NAT as we know it today: it performs
+ a translation between two different address realms. When the
+ external realm is public IPv4 address space, we assume that the
+ translation is many-to-one, in order to multiplex many customers on a
+ single public IPv4 address. The only difference with a traditional
+ NAT (Figure 1) is that the translator might only be able to use a
+ restricted range of ports when mapping multiple internal addresses
+ onto an external one, e.g., the external address realm might be port-
+ restricted.
+
+ "internal-side" "external-side"
+ +-----+
+ internal | N | external
+ address <---| A |---> address
+ realm | T | realm
+ +-----+
+
+ Figure 1: Traditional NAT
+
+ The encaps/decaps function, on the other hand, is the ability to
+ establish a tunnel with another endpoint providing the same function.
+ This implies some form of signaling to establish a tunnel. Such
+ signaling can be viewed as integrated with DHCP or as a separate
+ service. Section 3.3.1 discusses the constraints of this signaling
+ function. The tunnel can be an IPv6 or IPv4 encapsulation, a layer-2
+ tunnel, or some other form of softwire. Note that the presence of a
+ tunnel allows unmodified, naive, or even legacy devices between the
+ two endpoints.
+
+
+
+
+Bush Experimental [Page 8]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ Two or more devices that provide the encaps/decaps function are
+ linked by tunnels to form an A+P subsystem. The function of each
+ gateway is to encapsulate and decapsulate, respectively. Figure 2
+
+ depicts the simplest possible A+P subsystem, that is, two devices
+ providing the encaps/decaps function.
+
+ +------------------------------------+
+ Private | +----------+ tunnel +----------+ | Public
+ address --|-| gateway |==========| gateway |-|-- address
+ realm | +----------+ +----------+ | realm
+ +------------------------------------+
+ A+P subsystem
+
+ Figure 2: A Simple A+P Subsystem
+
+ Within an A+P subsystem, the public address realm is extended by
+ using bits from the port number when forwarding packets. Each device
+ is assigned one address from the external realm and a range of port
+ numbers. Hence, devices that are part of an A+P subsystem can
+ communicate with the public realm without the need for address
+ translation (i.e., preserving end-to-end packet integrity): an A+P
+ packet originated from within the A+P subsystem can be simply
+ forwarded over tunnels up to the endpoint, where it gets decapsulated
+ and routed in the external realm.
+
+3.3.1. Signaling
+
+ The following information needs to be available on all the gateways
+ in the A+P subsystem. It is expected that there will be a signaling
+ protocols such as [PR-ADDR-ASSIGN], [SHARED-ADDR-OPT],
+ [PORT-RANGE-OPT], or [PCP-BASE].
+
+ The information that needs to be shared is the following:
+
+ o a set of public IPv4 addresses,
+
+ o for each IPv4 address, a starting point for the allocated port
+ range,
+
+ o the number of delegated ports,
+
+ o the optional key that enables partial or full preservation of
+ entropy in port randomization -- see [PR-ADDR-ASSIGN],
+
+ o the lifetime for each IPv4 address and set of allocated ports,
+
+ o the tunneling technology to be used (e.g., "IPv6-encapsulation"),
+
+
+
+Bush Experimental [Page 9]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ o addresses of the tunnel endpoints (e.g., IPv6 address of tunnel
+ endpoints),
+
+ o whether or not NAT function is provided by the gateway,
+
+ o a device identification number and some authentication mechanisms,
+ and
+
+ o a version number and some reserved bits for future use.
+
+ Note that the functions of encapsulation and decapsulation have been
+ separated from the NAT function. However, to accommodate legacy
+ hosts, NATing is likely to be provided at some point in the path;
+ therefore, the availability or absence of NATing MUST be communicated
+ in signaling, as A+P is agnostic about NAT placement.
+
+ The port ranges can be allocated in two different ways:
+
+ o If applications or end-hosts behind the CPE are not UPnPv2/
+ NAT-PMP-aware, then the CPE SHOULD request ports via mechanisms,
+ e.g., as described in [PR-ADDR-ASSIGN] and [PORT-RANGE-OPT]. Note
+ that different port ranges can have different lifetimes, and the
+ CPE is not entitled to use them after they expire -- unless it
+ refreshes those ranges. It is up to the ISP to put mechanisms in
+ place (to prevent denial-of-service attacks) that determine what
+ percentage of already allocated port ranges should be exhausted
+ before a CPE may request additional ranges, how often the CPE can
+ request additional ranges, and so on.
+
+ o If applications behind the CPE are UPnPv2/NAT-PMP-aware,
+ additional ports MAY be requested through that mechanism. In this
+ case, the CPE should forward those requests to the LSN, and the
+ LSN should reply reporting if the requested ports are available or
+ not (and if they are not available, some alternatives should be
+ offered). Here again, to prevent potential denial-of-service
+ attacks, mechanisms should be in place to prevent UPnPv2/NAT-PMP
+ packet storms and fast port allocation. A detailed description of
+ this mechanism, called PCP, is in [PCP-BASE].
+
+ Whatever signaling mechanism is used inside the tunnels -- DHCP, IP
+ Control Protocol (IPCP), or PCP based, synchronization between the
+ signaling server and PRR must be established in both directions. For
+ example, if we use DHCP as the signaling mechanism, the PRR must
+ communicate to the DHCP server at least its IP range. The DHCP
+ server then starts to allocate IP addresses and port ranges to CPEs
+ and communicates back to the PRR which IP and port range have been
+ allocated to which CPE, so the PRR knows to which tunnel to redirect
+ incoming traffic. In addition, DHCP MUST also communicate lifetimes
+
+
+
+Bush Experimental [Page 10]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ of port ranges assigned to CPE via the PRR. DHCP server may be co-
+ located with the PRR function to ease address management and also to
+ avoid the need to introduce a communication protocol between the PRR
+ and DHCP.
+
+ If UPnPv2/NAT-PMP is used as the dynamic port allocation mechanism,
+ the PRR must also communicate to the DHCP (or IPCP) server to avoid
+ those ports. The PRR must somehow (e.g., using DHCP or IPCP options)
+ communicate back to CPE that the allocation of ports was successful,
+ so CPE adds those ports to existing port ranges.
+
+ Note that operation can be even simplified if a fixed length of port
+ ranges is assigned to all customers and no differentiation is
+ implemented based on port-range length. In such case, the binding
+ table maintained by the PRR can be dynamically built upon the receipt
+ of a first packet from a port-restricted device.
+
+3.3.2. Address Realm
+
+ Each gateway within the A+P subsystem manages a certain portion of
+ A+P address space; that is, a portion of IPv4 space that is extended
+ by borrowing bits from the port number. This address space may be a
+ single, port-restricted IPv4 address. The gateway MAY use its
+ managed A+P address space for several purposes:
+
+ o Allocation of a sub-portion of the A+P address space to other
+ authenticated A+P gateways in the A+P subsystem (referred to as
+ delegation). We call the allocated sub-portion delegated address
+ space.
+
+ o Exchange of (untranslated) packets with the external address
+ realm. For this to work, such packets MUST use a source address
+ and port belonging to the non-delegated address space.
+
+ If the gateway is also capable of performing the NAT function, it MAY
+ translate packets arriving on an internal interface that are outside
+ of its managed A+P address space into non-delegated address space.
+
+ Hence, a provider may have 'islands' of A+P as they slowly deploy
+ over time. The provider does not have to replace CPE until they want
+ to provide the A+P function to an island of users or even to one
+ particular user in a sea of non-A+P users.
+
+ An A+P gateway ("A"), accepts incoming connections from other A+P
+ gateways ("B"). Upon connection establishment (provided appropriate
+ authentication), B would "ask" A for delegation of an A+P address.
+ In turn, A will inform B about its public IPv4 address and will
+
+
+
+
+Bush Experimental [Page 11]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ delegate a portion of its port range to B. In addition, A will also
+ negotiate the encaps/decaps function with B (e.g., let B know the
+ address of the decaps device at the endpoint of the tunnel).
+
+ This could be implemented, for example, via a NAT-PMP- or DHCP-like
+ solution. In general, the following rule applies: a sub-portion of
+ the managed A+P address space is delegated as long as devices below
+ ask for it; otherwise, private IPv4 is provided to support legacy
+ hosts.
+
+ The following examples use an IPv4 address from the blocks reserved
+ for documentation as defined in [RFC5737].
+
+ private +-----+ +-----+ public
+ address ---| B |==========| A |--- Internet
+ realm +-----+ +-----+
+
+ Address space realm of A:
+ public IPv4 address = 192.0.2.1
+ port range = 0-65535
+
+ Address space realm of B:
+ public IPv4 address = 192.0.2.1
+ port range = 2560-3071
+
+ Figure 3: Configuration Example
+
+ Figure 3 illustrates a sample configuration. Note that A might
+ actually consist of three different devices: one that handles
+ signaling requests from B; one that performs encapsulation and
+ decapsulation; and, if provided, one device that performs the NATing
+ function (e.g., an LSN). Packet forwarding is assumed to be as
+ follows: in the "outbound" case, a packet arrives from the private
+ address realm to B. As stated above, B has two options: it can
+ either apply or not apply the NAT function. The decision depends
+ upon the specific configuration and/or the capabilities of A and B.
+ Note that NAT functionality is required to support legacy hosts;
+ however, this can be done at either of the two devices A or B. The
+ term "NAT" refers to translating the packet into the managed A+P
+ address (B has address 192.0.2.1 and ports 2560-3071 in the example
+ above). We then have two options:
+
+ 1) B NATs the packet. The translated packet is then tunneled to A.
+ A recognizes that the packet has already been translated because
+ the source address and port match the delegated space. A
+ decapsulates the packet and releases it in the public Internet.
+
+
+
+
+
+Bush Experimental [Page 12]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ 2) B does not NAT the packet. The untranslated packet is then
+ tunneled to A. A recognizes that the packet has not been
+ translated, so A forwards the packet to a co-located NATing
+ device, which translates the packet and routes it in the public
+ Internet. This device, e.g., an LSN, has to store the mapping
+ between the source port used to NAT and the tunnel where the
+ packet came from, in order to correctly route the reply. Note
+ that A cannot use a port number from the range that has been
+ delegated to B. As a consequence, A has to assign a part of its
+ non-delegated address space to the NATing function.
+
+ "Inbound" packets are handled in the following way: a packet from the
+ public realm arrives at A. A analyzes the destination port number to
+ understand whether or not the packet needs to be NATed.
+
+ 1) If the destination port number belongs to the range that A
+ delegated to B, then A tunnels the packet to B. B NATs the
+ packet using its stored mapping and forwards the translated
+ packet to the private domain.
+
+ 2) If the destination port number is from the address space of the
+ LSN, then A passes the packet on to the co-located LSN, which
+ uses its stored mapping to NAT the packet into the private
+ address realm of B. The appropriate tunnel is stored as well in
+ the mapping of the initial NAT. The LSN then encapsulates the
+ packet to B, which decapsulates it and normally routes it within
+ its private realm.
+
+ 3) Finally, if the destination port number falls in neither a
+ delegated range nor the address range of the LSN, A discards the
+ packet. If the packet is passed to the LSN, but no mapping can
+ be found, the LSN discards the packet.
+
+ Observe that A must be able to receive all IPv4 packets destined to
+ the public IPv4 address (192.0.2.1 in the example), so that it can
+ make routing decisions according to the port number. On the other
+ hand, B receives IPv4 packets destined to the public IPv4 address
+ only via the established tunnel with A. In other words, B uses the
+ public IPv4 address just for translation purposes, but it is not used
+ to make routing decisions. This allows us to keep the routing logic
+ at B as simple as described above, while enabling seamless
+ communication between A+P devices sharing the same public IPv4
+ address.
+
+
+
+
+
+
+
+
+Bush Experimental [Page 13]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ private +-----+ +-----+ public
+ address ---| B |==========| A |--- Internet
+ realm 1 +-----+ +-----+
+ |
+ private +-----+ |
+ address ---| C |============/
+ realm 2 +-----+
+
+ Address space realm of A:
+ public IPv4 address = 192.0.2.1
+ port range = 0-65535
+
+ Address space realm of B:
+ public IPv4 address = 192.0.2.1
+ port range = 2560-3071
+
+ Address space realm of C:
+ public IPv4 address = 192.0.2.1
+ port range = 0-2559
+
+ Figure 4: Hierarchical A+P
+
+ Consider the example shown in Figure 4. Here, both B and C use the
+ encaps/decaps function to establish a tunnel with A, and they are
+ assigned the same public IPv4 address with different, non-overlapping
+ port ranges. Assume that a host in B's private realm sends a packet
+ destined to address 192.0.2.1 and port 2000, and that B has been
+ instructed to NAT all packets destined to 192.0.2.1. Under these
+ assumptions, B receives the packet and NATs it using its own public
+ IPv4 address (192.0.2.1) and a port selected from its configured port
+ range (e.g., 3000). B then tunnels the translated packet to A. When
+ A receives the packet via the tunnel, it looks at the destination
+ address and port, recognizes C's delegated range, and then tunnels
+ the packet to C. Observe that, apart from stripping the tunnel
+ header, A handles the packet as if it came from the public Internet.
+ When C receives the packet, it NATs the destination address into one
+ address chosen from its private address realm, while keeping the
+ source address (192.0.2.1) and port (3000) untranslated. Return
+ traffic is handled the same way. Such a mechanism allows hosts
+ behind A+P devices to communicate seamlessly even when they share the
+ same public IPv4 address.
+
+ Please refer to Section 4 for a discussion of an alternative A+P
+ mechanism that does not incur path-stretch penalties for intra-domain
+ communication.
+
+
+
+
+
+
+Bush Experimental [Page 14]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+3.3.3. Reasons for Allowing Multiple A+P Gateways
+
+ Since each device in an A+P subsystem provides the encaps/decaps
+ function, new devices can establish tunnels and become in turn part
+ of an A+P subsystem. As noted above, being part of an A+P subsystem
+ implies the capability of talking to the external address realm
+ without any translation. In particular, as described in the previous
+ section, a device X in an A+P subsystem can be reached from the
+ external domain by simply using the public IPv4 address and a port
+ that has been delegated to X. Figure 5 shows an example where three
+ devices are connected in a chain. In other words, A+P signaling can
+ be used to extend end-to-end connectivity to the devices that are in
+ an A+P subsystem. This allows A+P-aware applications (or OSes)
+ running on end-hosts to enter an A+P subsystem and exploit
+ untranslated connectivity.
+
+ There are two modes for end-hosts to gain fine-grained control of
+ end-to-end connectivity. The first is where actual end-hosts perform
+ the NAT function and the encaps/decaps function that is required to
+ join the A+P subsystem. This option works in a similar way to the
+ NAT-in-the-host trick employed by virtualization software such as
+ VMware, where the guest operating system is connected via a NAT to
+ the host operating system. The second mode is when applications
+ autonomously ask for an A+P address and use it to join the A+P
+ subsystem. This capability is necessary for some applications that
+ require end-to-end connectivity (e.g., applications that need to be
+ contacted from outside).
+
+ +---------+ +---------+ +---------+
+ internal | gateway | | gateway | | gateway | external
+ realm --| 1 |======| 2 |======| 3 |-- realm
+ +---------+ +---------+ +---------+
+
+ Figure 5: An A+P Subsystem with Multiple Devices
+
+ Whatever the reasons might be, the Internet was built on a paradigm
+ that end-to-end connectivity is important. A+P makes this still
+ possible in a time where address shortage forces ISPs to use NATs at
+ various levels. In that sense, A+P can be regarded as a way to
+ bypass NATs.
+
+
+
+
+
+
+
+
+
+
+
+Bush Experimental [Page 15]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ +---+ (customer2)
+ |A+P|-. +---+
+ +---+ \ NAT|A+P|-.
+ \ +---+ |
+ \ | forward if in range
+ +---+ \+---+ +---+ /
+ |A+P|------|A+P|----|A+P|----
+ +---+ /+---+ +---+ \
+ / NAT if necessary
+ / (cust1) (prov. (e.g., provider NAT)
+ +---+ / router)
+ |A+P|-'
+ +---+
+
+ Figure 6: A Complex A+P Subsystem
+
+ Figure 6 depicts a complex scenario, where the A+P subsystem is
+ composed of multiple devices organized in a hierarchy. Each A+P
+ gateway decapsulates the packet and then re-encapsulates it again to
+ the next tunnel.
+
+ A packet can be NATed either when it enters the A+P subsystem, at
+ intermediate devices, or when it exits the A+P subsystem. This could
+ be, for example, a gateway installed within the provider's network,
+ together with an LSN. Then, each customer operates its own CPE.
+ However, behind the CPE, applications might also be A+P-aware and run
+ their own A+P-gateways; this enables them to have end-to-end
+ connectivity.
+
+ One limitation applies when "delayed translation" is used (e.g.,
+ translation at the LSN instead of the CPE). If devices using
+ "delayed translation" want to talk to each other, they SHOULD use A+P
+ addresses or out-of-band addressing.
+
+3.3.4. Overall A+P Architecture
+
+ A+P architecture
+
+ IPv4 Full-A+P AFTR CGN
+ | | | |
+ <-- Full IPv4 ---- Port range ---- Port range ---- Provider --->
+ allocated & dynamic & LSN NAT ONLY
+ allocation (NAT on CPE (No mechanism)
+ (no NAT) (NAT on CPE) and on LSN) for customer to
+ bypass CGN)
+
+ Figure 7: A+P Overall Architecture
+
+
+
+
+Bush Experimental [Page 16]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ The A+P architecture defines various deployment options within an
+ ISP. Figure 7 shows the spectrum of deployment options. On the far
+ left is the common deployment method for broadband subscribers today,
+ an IPv4 address unrestricted with full port range. Full-A+P refers
+ to a port-range allocation from the ISP. The customer must operate
+ an A+P-aware CPE device, and no NATing functionality is provided by
+ the ISP. The Address Family Transition Router (AFTR), such as
+ DS-Lite [RFC6333], is a hybrid. There is NAT present in the core (in
+ this document, referred to as LSN), but the user has the option to
+ "bypass" that NAT in one form or an other, for example, via A+P,
+ NAT-PMP, etc. Finally, a service provider that only deploys CGN will
+ place a NAT in the provider's core and does not allow the customer to
+ "bypass" the translation process or modify ALGs on the NAT. The
+ customer is provider-locked. Notice that all options (besides full
+ IPv4) require some form of tunneling mechanism (e.g., 4in6) and a
+ signaling mechanism (see Section 3.3.1).
+
+3.4. A+P Experiments
+
+ There are implementations of A+P as well as documented experiments.
+ France Telecom did experiments that are described in
+ [A+P-EXPERIMENTS]. As seen in that experiment, most tested
+ applications are unaffected. There are problems with torrent
+ protocol and applications, as the listening port is out of A+P port
+ range and some UPnP may be required to make it work with A+P.
+
+ Problems with BitTorrent have already been experienced in the wild by
+ users trapped behind a non-UPnP-capable CPE. The current workaround
+ for the end-user is to statically map ports, which can be done in the
+ A+P scenario as well.
+
+ BitTorrent tests and experiments in shared IP and port-range
+ environments are well described in [BITTORRENT-ADDR-SHARING].
+ Conclusions in that document tell us that two limitations were
+ experienced. The first occurred when two clients sharing the same IP
+ address tried to simultaneously retrieve the SAME file located in a
+ SINGLE remote peer. The second limitation occurred when a client
+ tried to download a file located on several seeders, when those
+ seeders shared the same IP address. Mutual file sharing between
+ hosts having the same IP address has been checked. Indeed, machines
+ having the same IP address can share files with no alteration
+ compared to current IP architectures.
+
+ Working implementations of A+P can be found in:
+
+ o Internet Systems Consortium AFTR
+ (http://www.isc.org/software/aftr),
+
+
+
+
+Bush Experimental [Page 17]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ o FT Orange opensource A+P (http://opensourceaplusp.weebly.com/)
+ developed by Xiaoyu Zhao, Xiaohong Deng, Tao Zheng, and
+
+ o 4rd (IPv4 Residual Deployment) from ipinfusion.com, which is
+ stateless A+P.
+
+4. Stateless A+P Mapping Function
+
+4.1. Stateless A+P Mapping (SMAP) Gateway Function Description
+
+ SMAP stands for Stateless A+P Mapping. This function is responsible
+ for, in a stateless scheme, encapsulating IPv4 packets in IPv6 ones
+ as well as decapsulating IPv4 packets from IPv6 ones. An SMAP
+ function may be hosted in a PRR, end-user device, etc.
+
+ As mentioned in Section 4.1 of [RFC6052], the suffix part may enclose
+ the port.
+
+ The Stateless A+P Mapping (SMAP) gateway consists in two basic
+ functions as described in Figure 8.
+
+ 1. SMAP encapsulates an IPv4 packet, destined to a shared IPv4
+ address, in an IPv6 one. The IPv6 source address is constructed
+ using an IPv4-embedded IPv6 address [RFC6052] from the IPv4
+ source address and port number plus the IPv6 prefix that has been
+ provisioned to the node performing the SMAP function. The
+ destination IPv6 address is constructed using the shared IPv4
+ destination address and port number plus the IPv6 prefix that has
+ been provisioned to the SMAP function and that is dedicated to
+ IPv4 destination addresses.
+
+ 2. SMAP extracts IPv4 incoming packets from IPv6 incoming ones that
+ have IPv6 source addresses belonging to the prefix of the node
+ performing the SMAP function. Extracted IPv4 packets are then
+ forwarded to the point identified by the IPv4 destination address
+ and port number.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Experimental [Page 18]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ +-------------------+
+ | |----IPv6---\
+ ----IPv4---\| |----IPv4---\\
+ -----------/| |-----------//
+ | |-----------/
+ | SMAP |
+ | | /--IPv6-----
+ /---IPv4----| |//---IPv4----
+ \-----------| |\\-----------
+ | | \-----------
+ +-------------------+
+
+ Figure 8: Stateless A+P Mapping Gateway Function
+
+ An SMAP-enabled node will perform the stateless 6/4 mapping function
+ for all public shared IPv4 addresses for which it was designated as a
+ stateless 6/4 mapping gateway.
+
+ To perform the stateless 6/4 mapping function, an SMAP gateway must:
+
+ o be provided with an IPv6 prefix (i.e., Pref6). The SMAP gateway
+ uses this prefix to construct IPv6 source addresses for all IPv4
+ shared addresses for which it was designated as an SMAP gateway.
+ The IPv6 prefix may be provisioned statically or dynamically
+ (e.g., DHCP).
+
+ o be able to know the IPv6 prefix of the node serving as another
+ SMAP gateway for IPv4 destination addresses. This prefix may be
+ known in various ways:
+
+ * Default or Well-Known Prefix (i.e., 64:ff9b::/96) that was
+ provisioned statically or dynamically;
+
+ * Retained at the reception of incoming IPv4-in-IPv6 encapsulated
+ packets;
+
+ * Discovered at the start of communication, thanks to mechanisms
+ such as DNS resolution, for example.
+
+ When the SMAP-enabled node receives IPv4 packets with IPv4 source
+ addresses for which it was not designated as an smap gateway, it will
+ not perform stateless 6/4 mapping function for those packets. Those
+ packets will be handled in a classical way (i.e., forwarded, dropped,
+ or locally processed).
+
+
+
+
+
+
+
+Bush Experimental [Page 19]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ When the SMAP-enabled node receives IPv6 packets with IPv6 addresses
+ that do not match with its IPv6 prefix, it will not perform the
+ stateless 6/4 mapping function for those packets. Those packets will
+ be handled in a classical way (i.e., forwarded, dropped, or locally
+ processed).
+
+4.2. Implementation Mode
+
+ In this configuration, the node A performs the stateless mapping
+ function on the received IPv4 traffic (encapsulated in IPv6 packets)
+ before forwarding to the node B. The node B performs the stateless
+ mapping function on the received IPv6 traffic (extracting IPv4
+ packets) before forwarding the IPv4 traffic to the destination
+ identified by the IPv4 destination address and port number. In the
+ opposite direction, and as previously, the node B performs the
+ stateless mapping function on the received IPv4 traffic
+ (encapsulating in IPv6 packets) before forwarding to the node A. The
+ node A performs the stateless mapping function on the received IPv6
+ traffic (extracting IPv4 packets) before forwarding the IPv4 traffic
+ to the point identified by the IPv4 destination address and port
+ number. In this case, only IPv6 traffic is managed in the network
+ segment between the nodes A and B.
+
+ +------+ +------+
+ | |----IPv6---\ | |
+ ----IPv4---\| |----IPv4---\\| |----IPv4---\
+ -----------/| |-----------//| |-----------/
+ | |-----------/ | |
+ | SMAP | | SMAP |
+ | | /----IPv6---| |
+ /---IPv4----| |//---IPv4----| |/---IPv4----
+ \-----------| |\\-----------| |\-----------
+ | | \-----------| |
+ +------+ +------+
+ node A node B
+
+ Figure 9
+
+ Several deployment scenarios of the SMAP function may be envisaged in
+ the context of port-range-based solutions:
+
+ o An SMAP function is embedded in a port-restricted device. Other
+ SMAP-enabled nodes are deployed in the boundaries between IPv6-
+ enabled realms and IPv4 ones. This scenario may be deployed
+ particularly for intra-domain communications so as to interconnect
+ heterogeneous realms (i.e., IPv6/IPv4) within the same Autonomous
+ System (AS).
+
+
+
+
+Bush Experimental [Page 20]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ o An SMAP function is embedded in a port-restricted device. Other
+ SMAP-enabled nodes are deployed in the interconnection segment
+ (with adjacent IPv4-only ones) of a given AS. This deployment
+ scenario is more suitable for service providers targeting the
+ deployment of IPv6 since it eases the migration to full IPv6.
+ Core nodes are not required to continue to activate both IPv4 and
+ IPv6 transfer capabilities.
+
+ Other considerations regarding the interconnection of SMAP-enabled
+ domains should be elaborated. The following provides a non-
+ exhaustive list of interconnection schemes.
+
+ o The interconnection of two domains implementing the SMAP function
+ may be deployed via IPv4 Internet (Figure 10): this means that
+ IPv4 packets encapsulated in IPv6 packets are transferred using
+ IPv6 until reaching the first SMAP-enabled node. Then, these
+ packets are decapsulated and are forwarded using IPv4 transfer
+ capabilities. A remote SMAP-enabled node will receive those
+ packets and proceed to an IPv4-in-IPv6 encapsulation. These
+ packets are then routed normally until reaching the port-
+ restricted devices that decapsulate the packets.
+
+ +------+ +------+ +--------+ +------+ +------+
+ | |--IPv6--\ | | | | | |---IPv6--\ | |
+ | |--IPv4--\\| |---|-IPv4---|--\| |---IPv4--\\| |
+ | |--------//| |---|--------|--/| |---------//| |
+ | |--------/ | | |Internet| | |---------/ | |
+ | SMAP | | SMAP | | IPv4 | | SMAP | | SMAP |
+ | | /--IPv6--| | | | | | /---IPv6--| |
+ | |//--IPv4--| |/--|-IPv4---|---| |//--IPv4---| |
+ | |\\--------| |\--|--------|---| |\\---------| |
+ | | \--------| | | | | | \---------| |
+ +------+ +------+ +--------+ +------+ +------+
+ Source node A node B Destination
+
+ Figure 10: Interconnection Scenario 1
+
+ o A second scheme is to use IPv6 to interconnect two realms that
+ implement the SMAP function (Figure 11). An IPv6 prefix (i.e.,
+ Pref6) assigned by IANA is used for this service. If appropriate
+ routing configurations have been enforced, then the IPv6-
+ encapsulated packets will be routed until the final destination.
+ In order to implement this model, IPv4-inferred IPv6 prefixes are
+ required to be injected in the IPv6 inter-domain routing tables.
+
+
+
+
+
+
+
+Bush Experimental [Page 21]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ +------+ +------------+ +------+
+ | | | | | |
+ | |----IPv6-----|----IPv6----|----IPv6----\ | |
+ | |----IPv4-----|------------|----IPv4----\\| |
+ | |-------------|------------|------------//| |
+ | |-------------|------------|------------/ | |
+ | SMAP | | Internet v6| | SMAP |
+ | | /-----IPv6--|------------|-----IPv6-----| |
+ | |//---IPv4----|------------|-------IPv4---| |
+ | |\\-----------|------------|--------------| |
+ | | \-----------|------------|--------------| |
+ | | | | | |
+ +------+ +------------+ +------+
+ Source Destination
+
+ Figure 11: Interconnection Scenario 2
+
+4.3. Towards IPv6-Only Networks
+
+ The deployment of the SMAP function allows for smooth migration of
+ networks to an IPv6-only scheme while maintaining the delivery of
+ IPv4 connectivity services to customers. The delivery of IPv4
+ connectivity services over an IPv6-only network does not require any
+ stateful function to be deployed on the core network. Owing to this
+ A+P mode, both the IPv4 service continuity and the migration to an
+ IPv6-only deployment model are facilitated.
+
+4.4. PRR: On Stateless and Binding Table Modes
+
+ The SMAP section (Section 4) discusses two modes: the binding and the
+ stateless modes. Dynamic port allocation is not a feature of the
+ stateless mode, but it is supported in the binding mode. In the
+ binding mode, distinct external IPv4 addresses may be used, but this
+ is not recommended.
+
+ o Stateless Mode
+
+ Complete stateless mapping implies that the IPv4 address and the
+ significant bits coding the port range are reflected inside the
+ IPv6 prefix assigned to the port-restricted device. This can be
+ achieved either by embedding the full IPv4 address and the
+ significant bits in the IPv6 prefix or by applying an algorithmic
+ approach. Two alternatives are offered when such a stateless
+ mapping is to be enabled:
+
+ - use the IPv6 prefix already used for native IPv6 traffic, or
+
+
+
+
+
+Bush Experimental [Page 22]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ - provide two prefixes to the port-restricted device: one for the
+ native IPv6 traffic and one for the IPv4 traffic.
+
+ Note that:
+
+ - Providing two IPv6 prefixes has the advantages of allowing a
+ /64 prefix for the port-restricted device along with another
+ prefix (e.g., a /56 or /64) for native IPv6 traffic. This
+ alternative allows the service provider to relate the native
+ IPv6 traffic addressing plan to the IPv4 addressing plan. The
+ drawback is having to allocate two prefixes to each port-
+ restricted device and to route them. In addition, an address
+ selection issue may be encountered.
+
+ - Providing one prefix for both needs (e.g., a /56 or a /64)
+ allows the service provider to handle two types of IPv6 prefix
+ for the port-restricted device and in routing tables. But the
+ drawback is that it strongly links the IPv4 addressing plan to
+ the allocated IPv6 prefixes.
+
+ As mentioned in Section 4.1 of [RFC6052], the suffix part may
+ enclose the port.
+
+ o Binding Table Mode
+
+ Another alternative is to assign a "normal" IPv6 prefix to the
+ port-restricted device and to use a binding table, which can be
+ hosted by a service node to correlate the (shared IPv4 address,
+ port range) with an IPv6 address part of the assigned IPv6 prefix.
+ For scalability reasons, this table should be instantiated within
+ PRR-enabled nodes that are close to the port-restricted devices.
+ The number of required entries if hosted at the interconnection
+ segment would be equal to the amount of subscribed users (one per
+ port-restricted device).
+
+4.5. General Recommendations on SMAP
+
+ If a Stateless A+P Mapping (SMAP) type of implementation is deployed
+ over intermediate IPv6-only-capable devices, it is recommended that
+ default routes are configured, and the IPv4 routing table is not
+ "leaked" into the IPv6 routing table in terms of having reachability
+ for the packets going towards the Internet.
+
+ One of the stateless A+P variants is 4rd [4rd].
+
+
+
+
+
+
+
+Bush Experimental [Page 23]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+5. Deployment Scenarios
+
+5.1. A+P Deployment Models
+
+5.1.1. A+P for Broadband Providers
+
+ Some large broadband providers will not have enough public IPv4
+ address space to provide every customer with a single IP address.
+ The natural solution is sharing a single IP address among many
+ customers. Multiplexing customers is usually accomplished by
+ allocating different port numbers to different customers somewhere
+ within the network of the provider.
+
+ It is expected that, when the provider wishes to enable A+P for a
+ customer or a range of customers, the CPE can be upgraded or replaced
+ to support A+P encaps/decaps functionality. Ideally, the CPE also
+ provides NATing functionality. Further, it is expected that at least
+ another component in the ISP network provides the corresponding A+P
+ functionality, and hence is able to establish an A+P subsystem with
+ the CPE. This device is referred to as an A+P router or Port-Range
+ Router (PRR), and could be located close to PE routers. The core of
+ the network MUST support the tunneling protocol (which SHOULD be
+ IPv6, as per Constraint 7) but MAY be another tunneling technology
+ when necessary. In addition, we do not wish to restrict any
+ initiative of customers who might want to run an A+P-capable network
+ on or behind their CPE. To satisfy both Constraints 1 and 2,
+ unmodified legacy hosts should keep working seamlessly, while
+ upgraded/new end-systems should be given the opportunity to exploit
+ enhanced features.
+
+5.1.2. A+P for Mobile Providers
+
+ In the case of mobile service providers, the situation is slightly
+ different. The A+P border is assumed to be the gateway (e.g.,
+ Gateway GPRS Support Node (GGSN) / Packet Data Network (PDN) gateway
+ (GW) of 3GPP, or Access Service Network (ASN) GW of Worldwide
+ Interoperability for Microwave Access (WiMAX)). The need to extend
+ the address is not within the provider network, but on the edge
+ between the mobile phone devices and the gateway. While desirable,
+ IPv6 connectivity may or may not be provided.
+
+ For mobile providers, we use the following terms and assumptions:
+
+ 1. provider network (PN)
+
+ 2. gateway (GW)
+
+ 3. mobile phone device (phone)
+
+
+
+Bush Experimental [Page 24]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ 4. devices behind the phone, e.g., laptop computer connecting via
+ phone to Internet
+
+ We expect that the gateway has a pool of IPv4 addresses and is always
+ in the data-path of the packets. Transport between the gateway and
+ phone devices is assumed to be an end-to-end layer-2 tunnel. We
+ assume that the phone as well as gateway can be upgraded to support
+ A+P. However, some applications running on the phone or devices
+ behind the phone (such as laptop computers connecting via the phone)
+ are not expected to be upgraded. Again, while we do not expect that
+ devices behind the phone will be A+P-aware or upgraded, we also do
+ not want to hinder their evolution. In this sense, the mobile phone
+ would be comparable to the CPE in the broadband provider case; it
+ would be the gateway to the PRR/LSN box in the network of the
+ broadband provider.
+
+5.1.3. A+P from the Provider Network Perspective
+
+ ISPs suffering from IPv4 address space exhaustion are interested in
+ achieving a high address space compression ratio. In this respect,
+ an A+P subsystem allows much more flexibility than traditional NATs:
+ the NAT can be placed at the customer and/or in the provider network.
+ In addition, hosts or applications can request ports and thus have
+ untranslated end-to-end connectivity.
+
+ +---------------------------+
+ private | +------+ A+P-in +-----+ | dual-stacked
+ (RFC 1918) --|-| CPE |==-IPv6-==| PRR |-|-- network
+ space | +------+ tunnel +-----+ | (public addresses)
+ | ^ +-----+ |
+ | | IPv6-only | LSN | |
+ | | network +-----+ |
+ +----+----------------- ^ --+
+ | |
+ on customer within provider
+ premises and control network
+
+ Figure 12: A Simple A+P Subsystem Example
+
+ Consider the deployment scenario in Figure 12, where an A+P subsystem
+ is formed by the CPE and a PRR within the ISP core network and
+ preferably is close to the customer edge. Inside the subsystem,
+ packets are forwarded based on address and port. The provider MAY
+ deploy an LSN co-located with the PRR to handle packets that have not
+ been translated by the CPE. In such a configuration, the ISP allows
+ the customer to freely decide whether the translation is done at the
+
+
+
+
+
+Bush Experimental [Page 25]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ CPE or at the LSN. In order to establish the A+P subsystem, the CPE
+ will be configured automatically (e.g., via a signaling protocol that
+ conforms to the requirements stated above).
+
+ Note that the CPE in the example above is provisioned with only an
+ IPv6 address on the external interface.
+
+ +------------ IPv6-only transport ------------+
+ | +---------------+ | | |
+ | |A+P-application| | +--------+ | +-----+ | dual-stacked
+ | | on end-host |=|==| CPE w/ |==|==| PRR |-|-- network
+ | +---------------+ | +--------+ | +-----+ | (public addresses)
+ +---------------+ | +--------+ | +-----+ |
+ private IPv4 <-*--+->| NAT | | | LSN | |
+ address space \ | +--------+ | +-----+ |
+ for legacy +|--------------|----------+
+ hosts | |
+ | |
+ end-host with | CPE device | provider
+ upgraded | on customer | network
+ application | premises |
+
+ Figure 13: An Extended A+P Subsystem with End-Host Running A+P-Aware
+ Applications
+
+ Figure 13 shows an example of how an upgraded application running on
+ a legacy end-host can connect to another host in the public realm.
+ The legacy host is provisioned with a private IPv4 address allocated
+ by the CPE. Any packet sent from the legacy host will be NATed
+ either at the CPE (if configured to do so) or at the LSN (if
+ available).
+
+ An A+P-aware application running on the end-host MAY use the
+ signaling described in Section 3.3.1 to connect to the A+P subsystem.
+ In this case, the application will be delegated some space in the A+P
+ address realm, and will be able to contact the public realm (i.e.,
+ the public Internet) without the need for translation.
+
+ Note that part of A+P signaling is that the NATs are optional.
+ However, if neither the CPE nor the PRR provides NATing
+ functionality, then it will not be possible to connect legacy end-
+ hosts.
+
+ To enable packet forwarding with A+P, the ISP MUST install at its A+P
+ border a PRR that encaps/decaps packets. However, to achieve a
+ higher address space compression ratio and/or to support CPEs without
+ NATing functionality, the ISP MAY decide to provide an LSN as well.
+ If no LSN is installed in some part of the ISP's topology, all CPEs
+
+
+
+Bush Experimental [Page 26]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ in that part of the topology MUST support NAT functionality. For
+ reasons of scalability, it is assumed that the PRR is located within
+ the access portion of the network. The CPE would be configured
+ automatically (e.g., via an extended DHCP or NAT-PMP, which has the
+ signaling requirements stated above) with the address of the PRR and
+ of the LSN (if one is being provided). Figure 12 illustrates a
+ possible deployment scenario.
+
+5.2. Dynamic Allocation of Port Ranges
+
+ Allocating a fixed number of ports to all CPEs may lead to exhaustion
+ of ports for high-usage customers. This is a perfect recipe for
+ upsetting more demanding customers. On the other hand, allocating to
+ all customers ports sufficiently to match the needs of peak users
+ will not be very efficient. A mechanism for dynamic allocation of
+ port ranges allows the ISP to achieve two goals: a more efficient
+ compression ratio of the number of customers on one IPv4 address and,
+ on the other hand, no limit of the more demanding customers'
+ communication.
+
+ Additional allocation of ports or port ranges may be made after an
+ initial static allocation of ports.
+
+ The mechanism would prefer allocations of port ranges from the same
+ IP address as the initial allocation. If it is not possible to
+ allocate an additional port range from the same IP, then the
+ mechanism can allocate a port range from another IP within the same
+ subnet. With every additional port range allocation, the PRR updates
+ its routing table. The mechanism for allocating additional port
+ ranges may be part of normal signaling that is used to authenticate
+ the CPE to the ISP.
+
+ The ISP controls the dynamic allocation of port ranges by the PRR by
+ setting the initial allocation size and maximum number of allocations
+ per CPE, or the maximum allocations per subscription, depending on
+ subscription level. There is a general observation that the more
+ demanding customer uses around 1024 ports when heavily communicating.
+ So, for example, a first suggestion might be 128 ports initially and
+ then dynamic allocations of ranges of 128 ports up to 511 more
+ allocations maximum. A configured maximum number of allocations
+ could be used to prevent one customer acting in a destructive manner
+ should they become infected. The maximum number of allocations might
+ also be more finely grained, with parameters of how many allocations
+ a user may request per some time frame. If this is used, evasive
+ applications may need to be limited in their bad behavior; for
+ example, one additional allocation per minute would considerably slow
+ a port request storm.
+
+
+
+
+Bush Experimental [Page 27]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ There is likely no minimum request size. This is because A+P-aware
+ applications running on end-hosts MAY request a single port (or a few
+ ports) for the CPE to be contacted on (e.g., Voice over IP (VoIP)
+ clients register a public IP and a single delegated port from the
+ CPE, and accept incoming calls on that port). The implementation on
+ the CPE or PRR will dictate how to handle such requests for smaller
+ blocks: for example, half of available blocks might be used for
+ "block-allocations", 1/6 for single port requests, and the rest for
+ NATing.
+
+ Another possible mechanism to allocate additional ports is UPnP/
+ NAT-PMP (as defined in Section 3.3.1), if applications behind CPE
+ support it. In the case of the LSN implementation (DS-Lite), as
+ described in Section 3.3.4 about the A+P overall architecture,
+ signaling packets are simply forwarded by the CPE to the LSN and back
+ to the host running the application that requested the ports, and the
+ PRR allocates the requested port to the appropriate CPE. The same
+ behavior may be chosen with AFTR, if requested ports are outside of
+ the static initial port allocation. If a full A+P implementation is
+ selected, then UPnPv2/NAT-PMP packets are accepted by the CPE,
+ processed, and the requested port number is communicated through the
+ normal signaling mechanism between CPE and PRR tunnel endpoints
+ (PCP).
+
+5.3. Example of A+P-Forwarded Packets
+
+ This section provides a detailed example of A+P setup, configuration,
+ and packet flow from an end-host connected to an A+P service provider
+ to any host in the IPv4 Internet, and how the return packets flow
+ back. The following example discusses an A+P-unaware end-host, where
+ the NATing is done at the CPE. Figure 14 illustrates how the CPE
+ receives an IPv4 packet from the end-user device. We first describe
+ the case where the CPE has been configured to provide the NAT
+ functionality (e.g., by the customer through interaction with a
+ website or by automatic signaling). In the following, we call a
+ packet that is translated at the CPE an "A+P-forwarded packet", an
+ analogy with the port-forwarding function employed in today's CPEs.
+ Upon receiving a packet from the internal interface, the CPE
+ translates, encapsulates, and forwards it to the PRR. The NAT on the
+ CPE is assumed to have a default route to the public realm through
+ its tunnel interface.
+
+ When the PRR receives the A+P-forwarded packet, it decapsulates the
+ inner IPv4 packet and checks the source address. If the source
+ address does match the range assigned to A+P-enabled CPEs, then the
+ PRR simply forwards the decapsulated packet onward. This is always
+ the case for A+P-forwarded packets. Otherwise, the PRR assumes that
+ the packet is not A+P-forwarded and passes it to the LSN function,
+
+
+
+Bush Experimental [Page 28]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ which in turn translates and forwards the packet based on the
+ destination address. Figure 14 shows the packet flow for an outgoing
+ A+P-forwarded packet.
+
+ +-----------+
+ | Host |
+ +-----+-----+
+ | | 198.51.100.2
+ IPv4 datagram 1 | |
+ | |
+ v | 198.51.100.1
+ +---------|---------+
+ |CPE | |
+ +--------|||--------+
+ | ||| 2001:db8::2
+ | ||| 192.0.2.3 (100-200)
+ IPv6 datagram 2| |||
+ | |||<-IPv4-in-IPv6
+ | |||
+ -----|-|||-------
+ / | ||| \
+ | ISP access network |
+ \ | ||| /
+ -----|-|||-------
+ | |||
+ v ||| 2001:db8::1
+ +--------|||--------+
+ |PRR ||| |
+ +---------|---------+
+ | | 192.0.2.1
+ IPv4 datagram 3 | |
+ -----|--|--------
+ / | | \
+ | ISP network / |
+ \ Internet /
+ -----|--|--------
+ | |
+ v | 203.0.113.1
+ +-----+-----+
+ | IPv4 Host |
+ +-----------+
+
+ Figure 14: Forwarding of Outgoing A+P-Forwarded Packets
+
+
+
+
+
+
+
+
+Bush Experimental [Page 29]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ +-----------------+--------------+-----------------------------+
+ | Datagram | Header field | Contents |
+ +-----------------+--------------+-----------------------------+
+ | IPv4 datagram 1 | IPv4 Dst | 203.0.113.1 |
+ | | IPv4 Src | 198.51.100.2 |
+ | | TCP Dst | 80 |
+ | | TCP Src | 8000 |
+ | --------------- | ------------ | --------------------------- |
+ | IPv6 datagram 2 | IPv6 Dst | 2001:db8::1 |
+ | | IPv6 Src | 2001:db8::2 |
+ | | IPv4 Dst | 203.0.113.1 |
+ | | IPv4 Src | 192.0.2.3 |
+ | | TCP Dst | 80 |
+ | | TCP Src | 100 |
+ | --------------- | ------------ | --------------------------- |
+ | IPv4 datagram 3 | IPv4 Dst | 203.0.113.1 |
+ | | IPv4 Src | 192.0.2.3 |
+ | | TCP Dst | 80 |
+ | | TCP Src | 100 |
+ +-----------------+--------------+-----------------------------+
+
+ Datagram Header Contents
+
+ An incoming packet undergoes the reverse process. When the PRR
+ receives an IPv4 packet on an external interface, it first checks
+ whether or not the destination address falls within the A+P CPE
+ delegated range. If the address space was delegated, then the PRR
+ encapsulates the incoming packet and forwards it through the
+ appropriate tunnel for that IP/port range. If the address space was
+ not delegated, the packet would be handed to the LSN to check if a
+ mapping is available.
+
+ Figure 15 shows how an incoming packet is forwarded, under the
+ assumption that the port number matches the port range that was
+ delegated to the CPE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Experimental [Page 30]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ +-----------+
+ | Host |
+ +-----+-----+
+ ^ | 198.51.100.2
+ IPv4 datagram 3 | |
+ | |
+ | | 198.51.100.1
+ +---------|---------+
+ |CPE | |
+ +--------|||--------+
+ ^ ||| 2001:db8::2
+ | ||| 192.0.2.3 (100-200)
+ IPv6 datagram 2| |||
+ | |||<-IPv4-in-IPv6
+ | |||
+ -----|-|||-------
+ / | ||| \
+ | ISP access network |
+ \ | ||| /
+ -----|-|||-------
+ | |||
+ | ||| 2001:db8::1
+ +--------|||--------+
+ |PRR ||| |
+ +---------|---------+
+ ^ | 192.0.2.1
+ IPv4 datagram 1 | |
+ -----|--|--------
+ / | | \
+ | ISP network / |
+ \ Internet /
+ -----|--|--------
+ | |
+ | | 203.0.113.1
+ +-----+-----+
+ | IPv4 Host |
+ +-----------+
+
+ Figure 15: Forwarding of Incoming A+P-Forwarded Packets
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Experimental [Page 31]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ +-----------------+--------------+-----------------------------+
+ | Datagram | Header field | Contents |
+ +-----------------+--------------+-----------------------------+
+ | IPv4 datagram 1 | IPv4 Dst | 198.51.100.3 |
+ | | IPv4 Src | 203.0.113.1 |
+ | | TCP Dst | 100 |
+ | | TCP Src | 80 |
+ | --------------- | ------------ | --------------------------- |
+ | IPv6 datagram 2 | IPv6 Dst | 2001:db8::2 |
+ | | IPv6 Src | 2001:db8::1 |
+ | | IPv4 Dst | 198.51.100.3 |
+ | | IP Src | 203.0.113.1 |
+ | | TCP Dst | 100 |
+ | | TCP Src | 80 |
+ | --------------- | ------------ | --------------------------- |
+ | IPv4 datagram 3 | IPv4 Dst | 198.51.100.2 |
+ | | IPv4 Src | 203.0.113.1 |
+ | | TCP Dst | 8000 |
+ | | TCP Src | 80 |
+ +-----------------+--------------+-----------------------------+
+
+ Datagram Header Contents
+
+ Note that datagram 1 travels untranslated up to the CPE; thus, the
+ customer has the same control over the translation as he has today --
+ a home gateway with customizable port-forwarding.
+
+5.3.1. Forwarding of Standard Packets
+
+ Packets for which the CPE does not have a corresponding port-
+ forwarding rule are tunneled to the PRR that provides the LSN
+ function. We underline that the LSN MUST NOT use the delegated space
+ for NATing. See [RFC6333] for network diagrams that illustrate the
+ packet flow in this case.
+
+5.3.2. Handling ICMP
+
+ ICMP is problematic for all NATs because it lacks port numbers. A+P
+ routing exacerbates the problem.
+
+ Most ICMP messages fall into one of two categories: error reports or
+ ECHO/ECHO replies (commonly known as "pings"). For error reports,
+ the offending packet header is embedded within the ICMP packet; NAT
+ devices can then rewrite that portion and route the packet to the
+ actual destination host. This functionality will remain the same
+ with A+P; however, the PRR will need to examine the embedded header
+ to extract the port number, while the A+P gateway will do the
+ necessary rewriting.
+
+
+
+Bush Experimental [Page 32]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ ECHO and ECHO replies are more problematic. For ECHO, the A+P
+ gateway device must rewrite the "Identifier" and perhaps "Sequence
+ Number" fields in the ICMP request, treating them as if they were
+ port numbers. This way, the PRR can build the correct A+P address
+ for the returning ECHO replies, so they can be correctly routed back
+ to the appropriate host in the same way as TCP/UDP packets. Pings
+ originated from the public realm (Internet) towards an A+P device are
+ not supported.
+
+5.3.3. Fragmentation
+
+ In order to deliver a fragmented IP packet to its final destination
+ (among those having the same IP address), the PRR should activate a
+ dedicated procedure similar to the one used by [RFC6146], Section
+ 3.5, in the sense that it should reassemble the fragments in order to
+ look at the destination port number.
+
+ Note that it is recommended to use a Path MTU Discovery (PMTUD)
+ mechanism (e.g., [RFC1191]).
+
+ Security issues related to fragmentation are out of scope of this
+ document. For more details, refer to [RFC1858].
+
+5.3.4. Limitations of the A+P Approach
+
+ One limitation that A+P shares with any other IP-address-sharing
+ mechanism is the availability of well-known ports. In fact, services
+ run by customers that share the same IP address will be distinguished
+ by the port number. As a consequence, it will be impossible for two
+ customers who share the same IP address to run services on the same
+ port (e.g., port 80). Unfortunately, working around this limitation
+ usually implies application-specific hacks (e.g., HTTP and HTTPS
+ redirection), discussion of which is out of the scope of this
+ document. Of course, a provider might charge more for giving a
+ customer the well-known port range, 0..1024, thus allowing the
+ customer to provide externally available services. Many applications
+ require the availability of well-known ports. However, those
+ applications are not expected to work in an A+P environment unless
+ they can adapt to work with different ports. Such applications do
+ not work behind today's NATs either.
+
+ Another problem that is common to all NATs is coexistence with IPsec.
+ In fact, a NAT that also translates port numbers prevents the
+ Authentication Header (AH) and Encapsulating Security Payload (ESP)
+ from functioning properly, both in tunnel and in transport mode. In
+ this respect, we stress that, since an A+P subsystem exhibits the
+ same external behavior as a NAT, well-known workarounds (such as
+ [RFC3715]) can be employed.
+
+
+
+Bush Experimental [Page 33]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ A+P, as all other port-sharing solutions, suffers from the issues
+ documented in [RFC6269], but that's something we'll have to live
+ with.
+
+ For the host-based A+P, issues related to application conflicts when
+ trying to bind to an out-of-range port are to be further assessed.
+ Note that extensions to the host-based model have been proposed in
+ the past (e.g., the Port-Enhanced Address Resolution Protocol (ARP)
+ extension documented in http://software.merit.edu/pe-arp/).
+
+5.3.5. Port Allocation Strategy Agnostic
+
+ Issues raised by [PR-IP-ISSUES] have been analyzed in
+ [STATELESS-4v6]. As seen in that document, most of the issues apply
+ to host-based port-sharing solutions. A+P is not intended to be a
+ host-based port-sharing solution.
+
+ The conclusion of [STATELESS-4v6] is that the set of issues
+ specifically attributed to A+P either do not apply to CPE-based
+ flavors or can be mitigated. The A+P solution represents a
+ reasonable trade-off compared to alternatives in areas such as
+ binding logging (for data storage purposes) and ease of deployment
+ and operations, all of which are actually facilitated by such a
+ solution.
+
+6. Security Considerations
+
+ With CGNs/LSNs, tracing hackers, spammers, and other criminals will
+ be difficult, requiring logging, recording, and storing of all
+ connection-based mapping information. The need for storage implies a
+ trade-off. On one hand, the LSNs can manage addresses and ports as
+ dynamically as possible in order to maximize aggregation. On the
+ other hand, the more quickly the mapping between private and public
+ space changes, the more information needs to be recorded. This would
+ cause concern not only for law enforcement services, but also for
+ privacy advocates.
+
+ A+P offers a better set of trade-offs. All that needs to be logged
+ is the allocation of a range of port numbers to a customer. By
+ design, this will be done rarely, improving scalability. If the NAT
+ functionality is moved further up the tree, the logging requirement
+ will be as well, increasing the load on one node, but giving it more
+ resources to allocate to a busy customer, perhaps decreasing the
+ frequency of allocation requests.
+
+
+
+
+
+
+
+Bush Experimental [Page 34]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ The other extreme is A+P NAT on the customer premises. Such a node
+ would be no different than today's NAT boxes, which do no such
+ logging. We thus conclude that A+P is no worse than today's
+ situation, while being considerably better than CGNs.
+
+7. Acknowledgments
+
+ The authors wish to especially thank Remi Despres and Pierre Levis
+ for their help on the development of the A+P approach. We also thank
+ David Ward for review, constructive criticism, and interminable
+ questions, and Dave Thaler for useful criticism on "stackable" A+P
+ gateways. We would also like to thank the following persons for
+ their feedback on earlier versions of this work: Rob Austein, Gert
+ Doering, Dino Farinacci, Russ Housley, Ruediger Volk, Tina Tsou, and
+ Pasi Sarolahti.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+8.2. Informative References
+
+ [4rd] Despres, R., Matsushima, S., Murakami, T., and O. Troan,
+ "IPv4 Residual Deployment across IPv6-Service networks
+ (4rd) ISP-NAT's made optional", Work in Progress,
+ March 2011.
+
+ [A+P-EXPERIMENTS]
+ Deng, X., Boucadair, M., and F. Telecom, "Implementing A+P
+ in the provider's IPv6-only network", Work in Progress,
+ March 2011.
+
+ [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
+ Defeating Denial of Service Attacks which employ IP Source
+ Address Spoofing", BCP 38, RFC 2827, May 2000.
+
+ [BITTORRENT-ADDR-SHARING]
+ Boucadair, M., Grimault, J., Levis, P., and A.
+ Villefranque, "Behavior of BitTorrent service in an IP
+ Shared Address Environment", Work in Progress, March 2011.
+
+ [PCP-BASE]
+ Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
+ Selkirk, "Port Control Protocol (PCP)", Work in Progress,
+ July 2011.
+
+
+
+Bush Experimental [Page 35]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ [PORT-RANGE-OPT]
+ Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
+ T. ZOU), "Huawei Port Range Configuration Options for PPP
+ IPCP", Work in Progress, June 2011.
+
+ [PR-ADDR-ASSIGN]
+ Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
+ "Port Restricted IP Address Assignment", Work in Progress,
+ September 2010.
+
+ [PR-IP-ISSUES]
+ Thaler, D., "Issues With Port-Restricted IP Addresses",
+ Work in Progress, February 2010.
+
+ [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+ November 1990.
+
+ [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
+ Considerations for IP Fragment Filtering", RFC 1858,
+ October 1995.
+
+ [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+ E. Lear, "Address Allocation for Private Internets",
+ BCP 5, RFC 1918, February 1996.
+
+ [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
+ (NAT) Compatibility Requirements", RFC 3715, March 2004.
+
+ [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
+ Reserved for Documentation", RFC 5737, January 2010.
+
+ [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+ Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+ October 2010.
+
+ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+ NAT64: Network Address and Protocol Translation from IPv6
+ Clients to IPv4 Servers", RFC 6146, April 2011.
+
+ [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+ Roberts, "Issues with IP Address Sharing", RFC 6269,
+ June 2011.
+
+ [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+ Stack Lite Broadband Deployments Following IPv4
+ Exhaustion", RFC 6333, August 2011.
+
+
+
+
+
+Bush Experimental [Page 36]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ [SHARED-ADDR-OPT]
+ Boucadair, M., Levis, P., Grimault, J., Savolainen, T.,
+ and G. Bajko, "Dynamic Host Configuration Protocol
+ (DHCPv6) Options for Shared IP Addresses Solutions",
+ Work in Progress, December 2009.
+
+ [STATELESS-4v6]
+ Dec, W., Asati, R., Bao, C., and H. Deng, "Stateless 4Via6
+ Address Sharing", Work in Progress, July 2011.
+
+9. Contributing Authors
+
+ This document has nine primary authors.
+
+ Gabor Bajko
+ Nokia
+ EMail: gabor.bajko@nokia.com
+
+ Mohamed Boucadair
+ France Telecom
+ 3, Av Francois Chateaux
+ Rennes 35000
+ France
+ EMail: mohamed.boucadair@orange-ftgroup.co
+
+ Steven M. Bellovin
+ Columbia University
+ 1214 Amsterdam Avenue
+ MC 0401
+ New York, NY 10027
+ US
+ Phone: +1 212 939 7149
+ EMail: bellovin@acm.org
+
+ Randy Bush
+ Internet Initiative Japan
+ 5147 Crystal Springs
+ Bainbridge Island, Washington 98110
+ US
+ Phone: +1 206 780 0431 x1
+ EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+Bush Experimental [Page 37]
+
+RFC 6346 A+P Addressing Extension August 2011
+
+
+ Luca Cittadini
+ Universita' Roma Tre
+ via della Vasca Navale, 79
+ Rome, 00146
+ Italy
+ Phone: +39 06 5733 3215
+ EMail: luca.cittadini@gmail.com
+
+ Olaf Maennel
+ Loughborough University
+ Department of Computer Science - N.2.03
+ Loughborough
+ United Kingdom
+ Phone: +44 115 714 0042
+ EMail: o@maennel.net
+
+ Reinaldo Penno
+ Juniper Networks
+ 1194 North Mathilda Avenue
+ Sunnyvale, California 94089
+ US
+ EMail: rpenno@juniper.net
+
+ Teemu Savolainen
+ Nokia
+ Hermiankatu 12 D
+ TAMPERE, FI-33720
+ Finland
+ EMail: teemu.savolainen@nokia.com
+
+ Jan Zorz
+ Go6 Institute Slovenia
+ Frankovo naselje 165
+ Skofja Loka, 4220
+ Slovenia
+ EMail: jan@go6.si
+
+Editor's Address
+
+ Randy Bush (editor)
+ Internet Initiative Japan
+ 5147 Crystal Springs
+ Bainbridge Island, Washington 98110
+ US
+
+ Phone: +1 206 780 0431 x1
+ EMail: randy@psg.com
+
+
+
+
+Bush Experimental [Page 38]
+