GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6346

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:
  1. use the IPv6 prefix already used for native IPv6 traffic, or

Bush Experimental [Page 22] RFC 6346 A+P Addressing Extension August 2011

  1. provide two prefixes to the port-restricted device: one for the

native IPv6 traffic and one for the IPv4 traffic.

    Note that:
  1. 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.
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6346.txt · Last modified: 2011/08/26 21:39 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki