[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 6346

Network Working Group                                         O. Maennel
Internet-Draft                                          T-Labs/TU-Berlin
Intended status: Standards Track                                 R. Bush
Expires: May 8, 2009                           Internet Initiative Japan
                                                            L. Cittadini
                                                    Universita' Roma Tre
                                                             S. Bellovin
                                                     Columbia University
                                                        November 4, 2008


    The A+P Approach to the Broadband Provider IPv4 Address Shortage
                          draft-ymbk-aplusp-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.
   This document may not be modified, and derivative works of it may not
   be created.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 8, 2009.

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 we run out of IPv4 addresses.  Letting hosts seamlessly
   communicate in an IPv4-world without assigning a unique globally



Maennel, et al.            Expires May 8, 2009                  [Page 1]

Internet-Draft          A+P Addressing Extension           November 2008


   routable IPv4 address to each of them is a challenging problem, for
   which many solutions have been proposed.  Some prominent ones involve
   carrier-grade-NATs (CGN), which have been shown to provide an
   inadequate experience to IPv4 users and enshrine a walled garden in
   the core of the provider.  Instead, we propose using specialized NATs
   at the consumer premises equipment (CPE) edge which treat some of the
   port number bits as part of an extended IPv4 address.

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


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Why Carrier-Grade-NATs are Harmful . . . . . . . . . . . .  3
     1.2.  Security of CGNs . . . . . . . . . . . . . . . . . . . . .  5
   2.  Proposed Solution  . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Design of the A+P Gateway Device . . . . . . . . . . . . .  6
     2.3.  Reasons for allowing multiple A+P gateways in sequence . .  9
     2.4.  Changes Required to the Network  . . . . . . . . . . . . . 10
       2.4.1.  Changes Required to CPE  . . . . . . . . . . . . . . . 10
       2.4.2.  Changes to Customer-Provided NAT (CN)  . . . . . . . . 10
       2.4.3.  Changes to Provider-Edge Routers (PE)  . . . . . . . . 11
       2.4.4.  Changes to Provider Border Routers (BR)  . . . . . . . 11
       2.4.5.  Changes to Network Core Routers  . . . . . . . . . . . 12
   3.  Implementation . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.1.  A+P dual-stack . . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  IPv6 and mixed V4-V6 traffic . . . . . . . . . . . . . . . 18
     3.3.  Handling ICMP  . . . . . . . . . . . . . . . . . . . . . . 18
     3.4.  Handling IP fragments  . . . . . . . . . . . . . . . . . . 19
     3.5.  The incremental path to A+P  . . . . . . . . . . . . . . . 20
   4.  Benefits and limitations of A+P  . . . . . . . . . . . . . . . 20
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 23
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 23
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 27






Maennel, et al.            Expires May 8, 2009                  [Page 2]

Internet-Draft          A+P Addressing Extension           November 2008


1.  Introduction

   Many large Internet Service Providers (ISPs) face the problem that
   their networks' customer edges are so large that even if they only
   give the "front" of each customer premises equipment (CPE) a single
   IPv4 address, they need two to five /8s of IPv4 space.  The looming
   exhaustion of the free IANA IPv4 pool makes it highly unlikely that
   they would be allocated that much public IPv4 address space.
   Therefore ISPs have to devise something more ingenious.  Deploying
   NATs is a direct consequence of the design of a new protocol (IPv6)
   which is incompatible on the wire; there is not the slightest
   compatibility mode.  Although undesirable, NATs are inevitable.

   Some broadband providers are testing an approach called Carrier Grade
   NAT (CGN).  It is essentially a number of IPv4 NATs in the core of
   their networks and various tunneling and translation techniques.  If
   the CPE has dual stack, traffic where source and destination is IPv6
   would not have to be NATted, but IPv4 would be heavily NATted.  We
   can contrast this to, for example, NAT-PT [RFC2766] [RFC4966] on the
   CPE, which would probably scale to the needs of even a large non-
   consumer backbone.  But, as we noted above, very large broadband
   consumer providers would need far too much IPv4 space for the NAT-PT
   front ends for their large consumer networks.

   Our main concern is that the imminent IPv4 address exhaustion is
   tempting operators to deploy technology which is damaging to the
   Internet as a whole.

1.1.  Why Carrier-Grade-NATs are Harmful

   We have taken up a desperate search for alternatives.  The reasons
   are simple:

   "Carrier grade" is a euphemism for centralized.  More semantics move
   to the core of the network.  This is bad in and of itself.  Net-heads
   call it "telco-think" because it is the telco model of smarts in the
   core as opposed to the Internet model of a simple, just-forward-
   packets core, with smart edges.  It also places the provider in the
   position of a walled garden, where the user is trapped behind
   unchangeable application and policies, the opposite of the "end-to-
   end" model of the Internet.

   With the smarts at the edges, e.g.  NAT-PT, one can easily field new
   protocols between consenting end-points by "just" tweaking the NATs
   at the corresponding CPE, even adding application layer gateways
   (ALGs) if they are needed.  However, CGNs do not build an Internet
   walled garden at the edges, they build it by restricting the core.




Maennel, et al.            Expires May 8, 2009                  [Page 3]

Internet-Draft          A+P Addressing Extension           November 2008


   With NAT in the core, if a customer wants a new application protocol
   which requires cooperation from the NAT, he gets to beg help from the
   broadband providers' engineers and lawyers, and all other users of
   carrier grade NATs.  This is the ultimate horror the NAT-haters fear,
   and, in this case, they are not all that wrong.

   One broadband provider has recently received a lot of bad press for
   just this, though we know that the engineers are very far from those
   responsible.  This shows that all new application protocols have to
   go through the carrier-loving lawyers to be allowed to be handled by
   the NATs in their core.  Today's NATs are typically mitigated by ALGs
   over which the customer has some degree of control, e.g. port
   forwarding or UPnP.  However, this is not expected to work anymore
   with CGNs.  CGN proposals admit that it is not expected that
   applications that require specific port assignment or port mapping
   from the NAT box will keep working
   [I-D.durand-softwire-dual-stack-lite].  We believe this is not an
   option and that the end-user must have the ability to control its own
   ALGs.  So, if someone wants to deploy a new application, they can
   talk to the broadband providers' lawyers or run new disruptive
   technology over HTTP; we can pick our poison.  And if the NAT is not
   where the customer can directly control it, i.e., it is anywhere back
   in the provider's network, then the provider controls what the user
   can control, i.e. it is not really under user control.  We do not
   wish to deal with the case where the provider has to decide whether
   to allow Skype v42 when they themselves provide a competing VoIP
   product.

   And remember that as IPv6 deploys, if we want to have one Internet,
   i.e.  IPv4 nodes talking freely with IPv6 nodes, then translation
   must be done somewhere.  The challenge is whether someone can figure
   out a scheme where it is done for these large networks?  We believe
   it should be at the customer edge, not in the core.

   Another issue with CGNs is scalability.  ISPs face a tension between
   the placement of CGNs within their network to aggregate as much as
   possible, when too much aggregation creates a massive state problem.
   To reduce the state, the placement ends up somewhere closer to the
   edge, where the benefits are somewhat limited.

   It is not clear how a CGN should maintain per-session state in a
   scalable manner.  This is particularly relevant given that each
   customer is very likely to open many TCP connections in parallel
   [SP-NAT].  State for improperly terminated sessions could remain
   stale for some time.  The CGN hence trades scalability for the amount
   of state that needs to be kept, which makes optimally placing a CGN a
   hard engineering problem.




Maennel, et al.            Expires May 8, 2009                  [Page 4]

Internet-Draft          A+P Addressing Extension           November 2008


   With CGNs, tracing hackers, spammers and other criminals will be
   impossible, unless all the connection based mapping information is
   recorded and stored.  This would not only cause concern for law
   enforcement services, but also for privacy advocates.  We discuss
   other security-related problems with CGNs in the next section.

1.2.  Security of CGNs

   NATs frequently need to initiate translation for secondary port
   numbers.  This may be a decision based on packet inspection (i.e.,
   looking for PORT commands in FTP [RFC0959] sessions), or it may rely
   on explicit signaling from the end host via protocols such as UPnP.
   Either way, CGNs pose a security threat and/or an administrative
   nightmare.

   The issue is proper authentication of such requests.  Most UPnP
   devices do not implement appropriate security features.  Even if they
   did, there would be no way to administer the security mechanism.
   Every end-user device would have to have a secret corresponding to
   some authentication field in the CGN.  End users will not set these
   up properly; providers do not want to maintain such a database.

   Decisions made based on packet inspection are just as problematic.  A
   request from one customer could easily request opening a port for an
   other customer's addresses, similar to the Java-based attack
   described by Martin et al in [Martin-Java].


2.  Proposed Solution

   The specific problem we are facing is that available IPv4 address
   space is insufficient to number the IPv4-speaking customers, while
   IPv6 is not widely enough deployed to migrate to an IPv6-only world.
   Therefore, we propose to extend the IPv4 address space by assigning
   to each customer a single IPv4 address which is extended by
   "stealing" bits from the port number in the TCP/UDP header, leaving
   the applications a reduced range of ports.  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
   [SP-NAT], and broadband consumers are not anticipated to deploy a
   massive number of applications over IPv4 (if they did, CGNs would be
   even more damaging than this "bit-stealing" proposal).  Assuming we
   could limit the applications' port addressing to 8 (or 12) bits, we
   can increase the effective size of an IPv4 address by 8 (or 4)
   additional bits.  In this scenario, 512 (or 16) customers could be
   multiplexed on the same IPv4 address, while allowing them a fixed
   range of 512 (or 4096) ports.  We call this "extended addressing" or
   "A+P" (Address Plus Port) addressing.  Various routing techniques can



Maennel, et al.            Expires May 8, 2009                  [Page 5]

Internet-Draft          A+P Addressing Extension           November 2008


   be employed to route on A+P addresses.  The main advantage of A+P is
   that it preserves the Internet "end-to-end" model by pushing the
   state on a device at the edge of the network, which we call A+P
   gateway.  In a world where address translation is inevitable, due
   both to IPv6-IPv4 incompatibilities and lack of IPv4 space, we strive
   to give control over the translation process to the customer.  In
   contrast to CGNs, the customer has potentially control over the A+P
   gateway directly, instead of using ad-hoc protocols to communicate
   with the CGN.  This setting enables us to preserve a bit from the
   Internet "end-to-end" model, where now at least packets that leave
   one user's home gateway are guaranteed to be delivered without
   modifications to the destination home gateway.

2.1.  Terminology

   In the rest of this draft, we will refer to the following network
   devices:

   1.  Customer Premises Equipment (CPE), i.e. cable/DSL modem.

   2.  Customer-Provided-NAT (CN), an A+P capable gateway which is under
       customer control (optional).

   3.  Provider Edge Router (PE), AKA customer aggregation router

   4.  Provider Border Router (BR), provider's edge to other providers

   5.  Network Core Routers (Core), provider routers not PE or BR

2.2.  Design of the A+P Gateway Device

   In this section, we discuss our view of the delicate design choices
   for the A+P gateway device.

   As the customer's hosts would likely be unaware of the restricted
   range of ports and the extended A+P addressing scheme, translation
   would be done at the border between the customer and the provider.
   In the most common case, this is the provider-provisioned cable or
   DSL modem on the customer's premises, into which the customer plugs
   their single computer or LAN.  This CPE has to be upgraded to A+P
   extended addressing and be informed of the port number range
   allocated to the customer.  This latter could be done, for example,
   via an extension to DHCP (e.g., [I-D.boucadair-dhc-port-range],
   [I-D.bajko-v6ops-port-restricted-ipaddr-assign]); or via a new
   protocol.  The CPE would also provide the A+P gateway function
   between the customer's LAN and the provider.

   As we do not wish to modify end hosts, we expect customers to send



Maennel, et al.            Expires May 8, 2009                  [Page 6]

Internet-Draft          A+P Addressing Extension           November 2008


   IPv4 packets from any port(s).  The A+P gateway functionality
   consists of translating/NATting port numbers outside the assigned
   port-range to ensure that they fall in the appropriate range.
   Packets originated from within the appropriate port-range will pass-
   through without re-translation.  We regard several constraints as
   important for our design:

   1)      Customer devices, such as computers and PDAs, must work
           without modification.  A+P shall be transparent to unaware
           end-users.  Emergence of new applications shall not be
           limited.

   2)      Customers must have the ability to configure the A+P gateway
           to fit their needs (e.g., packets from one home gateway will
           be delivered without modifications to the destination home
           gateway).

   3)      No state should be kept inside the ISP's network.  This
           implies that the A+P gateway functionality should be provided
           either by the CPE or by the CN.

   4)      Automatic configuration/administration must be supported.
           There should be no need for customers to call the ISP and
           tell them that they are operating their own A+P-aware
           devices.

   5)      Multiple A+P gateways should be able to operate in sequence
           along one data path without interfering with each other.

   6)      "Double-NAT" has to be avoided.  Based on constraint 5
           multiple A+P-aware devices might be present in a path, and
           once one has done some translation, those packets should not
           be re-translated.

   7)      IPv6 deployment should be encouraged.

   While we acknowledge that A+P works in an IPv4-only environment (in a
   way similar to [I-D.boucadair-port-range]) we strongly believe that
   IPv6 is the long-term solution to the problem, and that A+P should be
   considered only as a smooth transition towards an IPv6 world.  We
   therefore assume in constraint 7 that the ISP has migrated to an
   IPv6-only or dual-stack core and A+P can use IPv6 as a transport
   inside the network.  This ensures that A+P will not be an hindrance
   to the introduction of IPv6.

   These principles lead us to the following design:





Maennel, et al.            Expires May 8, 2009                  [Page 7]

Internet-Draft          A+P Addressing Extension           November 2008


   1)      The A+P gateway should automatically translate any packet
           that does not come from the proper port range (Constraint 1).
           Conversely, port numbers within the proper range should not
           be translated.  The latter choice ensures that, in presence
           of multiple A+P-aware devices, we do not re-translate.
           (Constraints 4, 5, and 6)

   2)      The customer needs either to have an administrative login on
           the CPE, and/or must be able to operate their own A+P-aware
           device (with a "public" A+P address, NOT a private [RFC1918]
           address).  (Constraint 2, and 5)

   3)      Packet encapsulation should be done on the first A+P gateway,
           if multiple gateways are presents (otherwise the CPE) and if
           A+P-in-v6 transport is used in the network (Constraints 3, 5,
           and 7).  This could be automatically signaled, for example
           via DHCP (Constraint 4).

   4)      The translation performed by a provider-supplied CPE should
           be as accommodating as possible.  Packet snooping and/or ALGs
           may be added for well known protocols (e.g., FTP, SIP,
           Skype), but the translation for obscure/unknown protocols
           (e.g., gaming) might have to be manually configured by the
           customer.  (Constraints 1, 2, and 5)

   5)      If neither CPE nor CN is A+P capable, an unrestricted IPv4
           address shall be provided.  (This is to facilitate migration
           and fulfill constraints 1, 3, and 4).  To avoid exploitation
           of this principle (e.g. a customer operating an "old"/legacy
           CPE just to get an unrestricted address), an ISP could choose
           to provide no-IPv4 (i.e., only IPv6) service.  Note that this
           requires that the ISP learns about A+P capable devices
           (either CPE or CN).  This implies that DHCP needs to be
           extended to communicate A+P capability in the request
           message.

   We leave unspecified for now the question of how large a port number
   range is allocated to each customer.  We anticipate that the
   allocation available to a customer will be determined by ISP-specific
   policy, perhaps as a function of the fee charged to the customer.
   One possible solution could be to allocate ranges of IPs with a
   static assigned port range.  For example, the ISP could offer
   "classes of service", e.g., the first block of IPs offers a port-
   range of 4096 ports, the second class offers 512 ports, the third
   class offers 16 ports.  If the customer wants more ports, the address
   needs to be moved into a different class.  Obviously, this does not
   go without a service interruption for this particular customer (i.e.,
   the customer has to get a new IP).  However, this solves the problem



Maennel, et al.            Expires May 8, 2009                  [Page 8]

Internet-Draft          A+P Addressing Extension           November 2008


   of dynamic allocation for the ISP.  We leave details of this issue
   for future work.

2.3.  Reasons for allowing multiple A+P gateways in sequence

   There are many known difficulties with NATs in general.  Most are
   related to NATs breaking the end-to-end principle of the Internet.
   Some applications, such as gaming or peer-to-peer, are known to have
   difficulties if some kind of address/port translation is used.  This
   behavior is independent of where the translation takes place, thus
   privately operated NATs can be considered to be as limiting as CGNs.
   There is one major difference: today's work-around is that the user
   owns and controlls the NAT and is typically able to alter some of the
   translation properties, for example by defining their own port
   forwarding rules.  The main criticisms of CGNs is that this "work-
   around" is not guaranteed to be an option for the end-user.

   However, A+P could evolve beyond this limitation of NATs and actually
   re-establish real end-to-end connectivity between end-devices.
   Section Section 3.1 shows that what is needed to achieve this is to
   allow multiple A+P gateways to operate in a sequence.  Hence the
   constraints 5 and 6.

   The key observation is that the A+P gateway could be given a globally
   routable IPv4 address, though restricted in the usable port-range.
   For an end-user this could mean that, enabling an A+P-gateway on an
   end-system could be as easy as installing a "kernel-patch".  In this
   case the end-system would be capable of establishing end-to-end
   connectivity with other IPv4 speakers in the Internet and it would be
   possible to contact the end-host on those assigned ports.

   This obviously poses a security threat to the end-system in a similar
   way as connecting a legacy host to the Internet with a publicly
   routable IPv4 address.  (Note that such as system could be placed
   behind an application firewall.)  Our main goal is that the A+P-
   design should allow for two possible usage scenarios:

   1)      Not upgraded legacy end-devices receive a [RFC1918] private
           address and work as today behind a NAT (e.g., the CPE).  The
           CPE would have to be upgraded to A+P extended addressing.

   2)      Upgraded dual-stacked systems would understand A+P extended
           addressing and thus could provide A+P gateway functionality
           themselves.  Therefore they would receive a globally routable
           (though port restricted) A+P address.  For those kind of
           systems, packets could be delivered unmodified end-to-end,
           hence overcoming some of the general limitations of today's
           NATs.



Maennel, et al.            Expires May 8, 2009                  [Page 9]

Internet-Draft          A+P Addressing Extension           November 2008


   As section Section 3.1 explains in more detail, this is achieved by
   A+P-in-IPv6 encapsulation similarly to already existing approaches
   (such as NAT-PT).  This way A+P is capable of routing on IPv6 and
   thus bypassing the limitations of NATs.  One open issue for future
   work is the choice of mechanism to sub-assign multiple parallel A+P
   gateways.  For the moment, assume that the CPE allocates sub-port
   ranges to subsequent end-devices.  (In a very similar way as a NAT
   allocates addresses from some private address space to end-hosts;
   with the difference that the address space to be allocated is
   globally routable IPv4 addresses, which are restricted in the port-
   range.)

2.4.  Changes Required to the Network

2.4.1.  Changes Required to CPE

   Our design, described above, requires modifications to the CPE.
   However, modifications are also required by current CGN designs, for
   example [I-D.durand-softwire-dual-stack-lite] says, "It is expected
   that the home gateway is either software upgradable, replaceable or
   provided by the service provider as part of a new contract."

   An A+P gateway CPE would be configured, hopefully automatically, with

   o  IPv4 and/or IPv6 addressing for the customer's LAN

   o  The IPv4 A+P extended address for the WAN side to connect to the
      provider, which includes the range of port number to use on the
      WAN side, and

   o  an IPv6 address for the WAN side to connect to the provider, which
      includes "instructions" how to encapsulate A+P-packets within
      IPv6.

2.4.2.  Changes to Customer-Provided NAT (CN)

   Alternatively, as occasionally happens today, the customer could
   provide its own A+P gateway and the CPE would then function as a
   simple cable/DSL modem.  This customer A+P gateway would be
   configured with an IPv4 A+P extended address which is allocated to
   the customer (e.g., via extended DHCP).

   The customer NAT is entirely optional.  The customer does not have to
   operate such a device.  If he does not, then the provider-installed
   CPE performs the A+P gateway function.

   The CN is simply a symbol for customer control.  Therefore, a mixture
   of CPE and CN devices is also possible, where the customer gets full



Maennel, et al.            Expires May 8, 2009                 [Page 10]

Internet-Draft          A+P Addressing Extension           November 2008


   control over the CPE via an administrative login.  However, this
   could also range as far as computers with a special kernel patch to
   become A+P-aware.  Therefore, we denote in this draft CPE/CN as an
   A+P-aware device that is under full customer control and has an A+P
   extended address.

2.4.3.  Changes to Provider-Edge Routers (PE)

   Ultimately, we expect that all CPE/CNs take the functionality of the
   A+P gateway, as we would like to avoid state in the network.
   Therefore, the provider's customer aggregation router (aka PE)
   performs only some optional security-related functions, i.e.,
   assuring that a CPE/CN does not send packets from ports other than
   the allocated range, as the replies in turn, would then go back to
   some other hosts.  This is a comparable threat to IP source address
   spoofing.  Ideally, want to enforce the analog of BCP 38 [BCP38].
   This means that no packets outside of the assigned address and port
   number range should ever leave the PE for the network.

   We acknowledge that the PE router could also provide the A+P gateway
   functionality if the CPE/CN is not A+P capable.  Unfortunately, this
   comes very close to the walled garden effect that a CGN would cause.
   For this reason, we suggest that legacy CPEs shall be assigned either
   an unrestricted IPv4 address or no IPv4 service at all (by design
   principle 5 above).  However, even if the PE provides the A+P gateway
   functionality, there is one important difference with respect to
   CGNs: customers who wish to "escape" from the walled garden can run
   their own upgraded CN.  This way customers can become aware of which
   ports will be A+P NATted and which will not, so they have control
   over their own applications with no need to interact with the ISP
   (e.g., there's no need for UPnP equivalents on the PE).

2.4.4.  Changes to Provider Border Routers (BR)

   Routers at the provider's edge which face other providers need to be
   aware of the extended A+P IPv4 addresses.  They must have the ability
   to forward packets to the corresponding CPE based on IPv4 address and
   port.

   We suggest that the provider network use IPv6 as the tunneling
   mechanism.  The CPE/CN would encapsulate the A+P extended address
   within an IPv6 address using a well-known IPv6 prefix.  Then the core
   would route on the IPv6 address.  The border routers would recognize
   the well-known IPv6 prefix, de-capsulate the inner IPv4 packet, and
   normally route on the IPv4 address.  Return or inbound packets would
   be encapsulated in a similar fashion and thus correctly delivered to
   the CPE/CN.  Thus the provider's network could be IPv6 only, or any
   other layer 3/2.5 protocol.



Maennel, et al.            Expires May 8, 2009                 [Page 11]

Internet-Draft          A+P Addressing Extension           November 2008


2.4.5.  Changes to Network Core Routers

   If transport through the provider is chosen appropriately, e.g.  A+P-
   in-IPv6-encapsulation, then the network's core routers need no
   understanding of A+P extended IPv4 addressing at all.  Routing
   through the core without some form of tunneling would require the
   deployment of IPv4-A+P all the way to the PE routers.  As the
   original problem was insufficient IPv4 space, we assume that IPv6 or
   other non-IPv4 tunneling will be used.

   However, while we recommend IPv6, we acknowledge that A+P is the
   natural extension of IPv4, and should work seamlessly.  In an IPv4-
   only (or dual-stacked) network, we propose to host only unsplit/full
   IPv4 addresses on the PE.  In this case no modifications to the core
   have to be done to allow routing of /32-or-longer prefixes and
   forwarding will work with legacy equipment.  Only the PE would have
   to be upgraded to A+P-awareness and then make A+P decisions.


3.  Implementation

3.1.  A+P dual-stack

   There is wide consensus that the only long term solution to the IPv4
   address shortage is speeding up the deployment of IPv6.  Hence, we
   argue that the main design requirement for any short term solution is
   that it ease, or at least not hamper, ISP-wide IPv6 deployment.  A+P
   addressing enables ISPs to run an IPv6-only core with dual-stack
   devices at the edge.  In fact, the CPE/CN and the BR are the only
   devices that need to support dual-stack.  A+P addressing requires
   that those devices get an IPv6 addresses assigned that belongs to an
   ISP-wide well-known prefix (WKP), which only needs to be routable
   within the ISP.  The CPE/CN learns both WKP and its A+P address plus
   port range, and configures its WAN interface accordingly.  Figure 1
   shows an example of how WKP and A+P are combined to obtain an IPv6
   address at the CPE/CN.















Maennel, et al.            Expires May 8, 2009                 [Page 12]

Internet-Draft          A+P Addressing Extension           November 2008


         Configuration (e.g., from DHCP):
         --------------------------------
         WKP = 4999::/64  (64 bits)
         A = 12.0.0.1     (32 bits)
         P = ports 4096 to 8191

         Port bits usage:
         --------------------------------
         P = Pa + Pp                 (16 bit port field in TCP header)
         Pa = address extension      (4 bits)
         Pp = restricted port number (12 bits)

             from 0001000000000000 (4096) to 0001111111111111 (8191)
                  \__/\__________/
                   /        \
                  /          \
           +-------------+  +-------------+
           | part of A+P |  |  bits for   |
           |  address    |  | port number |
           |  (4 bits)   |  |  (12 bits)  |
           +-------------+  +-------------+

         IPv6 prefix:
         --------------------------------
         4999:0:0:0   : 0c00:0001 : 1000 ::  /100
         \________/     \___________/        \__/
            WKP          A+P address     (64+32+4 bits)


      Building an IPv6 prefix from Well Known Prefix and A+P address

                                 Figure 1

   This address is routed within the provider's core network.  We expect
   that A+P-in-IPv6 addresses are highly aggregatable, so that the
   resulting prefixes do not contribute to large routing tables, but can
   be announced with very little impact on the overall routing table
   size in the ISP core network.

   We now describe how a packet is transported from an end-user behind
   an A+P gateway towards the IPv4-Internet, and then the opposite
   direction.  In the following examples, we assume that the end-user
   host is not A+P-aware (e.g., via kernel patches).  Hence, packets
   have to be NATted at the CPE/CN.  The CPE/CN receives an IPv4 packet
   from the end-user device to a destination address V4D. If private
   IPv4 address space [RFC1918] is used it NATs.  If the packet already
   originated from the assigned IPv4 address, it ensures that the source
   port falls into the allocated port range, and then encapsulates the



Maennel, et al.            Expires May 8, 2009                 [Page 13]

Internet-Draft          A+P Addressing Extension           November 2008


   packet in an IPv6 packet where the source address is WKP+A+P, and the
   destination address is WKP+V4D. We assume that the NAT is operating
   on the 4-tuple (source_IPv4, source_port, destination_IPv4,
   destination_port).  (Using the terminology of [RFC3489], this is
   mostly a "symmetric" NAT; see the discussion of statelessness in the
   BR, below, for the exception.)

   The packet is then sent using standard routing in the ISP core up to
   the provider's BR.  Note that there is no preconfigured tunnel
   between the CPE/CN and the BR; the packet is routed based on the
   destination address, rather than to a predetermined endpoint.  When
   the BR receives the packet, it de-capsulates the IPv4 packet where
   the source is A and the destination is V4D. Figure 2 shows routing of
   outgoing packets.  Observe that if the source port does not initially
   fall in the configured range (datagram 1), it is translated at the
   CPE/CN (datagram 2).



































Maennel, et al.            Expires May 8, 2009                 [Page 14]

Internet-Draft          A+P Addressing Extension           November 2008


                   +-----------+
                   |    Host   |
                   +-----+-----+
                      |  |12.0.0.1 (ports 4096 to 8191)
      IPv4 datagram 1 |  |
                      |  |
                      v  |
               +---------|---------+
               |CPE/CN   |         |
               +--------|||--------+
                      | |||4999:0:0:0:0c00:0001:1000::/100
       IPv6 datagram 2| |||
                      | |||<-IPv4-in-IPv6
                      | |||
                 -----|-|||-------
               /      | |||        \
              |     ISP network     |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      v |||
               +--------|||--------+
               |BR      |||        |
               +---------|---------+
                      |  |
      IPv4 datagram 3 |  |
                 -----|--|--------
               /      |  |         \
              |     Internet        |
               \      |  |         /
                 -----|--|--------
                      |  |
                      v  |128.0.0.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                   Figure 2: Routing of Outgoing Packets













Maennel, et al.            Expires May 8, 2009                 [Page 15]

Internet-Draft          A+P Addressing Extension           November 2008


     +-----------------+--------------+-----------------------------+
     |        Datagram | Header field | Contents                    |
     +-----------------+--------------+-----------------------------+
     | IPv4 datagram 1 |     IPv4 Dst | 128.0.0.1                   |
     |                 |     IPv4 Src | 12.0.0.1                    |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 32000                       |
     | --------------- | ------------ | --------------------------- |
     | IPv6 Datagram 2 |     IPv6 Dst | 4999:0:0:0:128.0.0.1::      |
     |                 |     IPv6 Src | 4999:0:0:0:0c00:0001:1001:: |
     |                 |     IPv4 Dst | 128.0.0.1                   |
     |                 |     IPv4 Src | 12.0.0.1                    |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 4097                        |
     | --------------- | ------------ | --------------------------- |
     | IPv4 datagram 3 |     IPv4 Dst | 128.0.0.1                   |
     |                 |     IPv4 Src | 12.0.0.1                    |
     |                 |      TCP Dst | 80                          |
     |                 |      TCP Src | 4097                        |
     +-----------------+--------------+-----------------------------+

                         Datagram header contents

   An incoming packet undergoes the reverse process.  When a BR receives
   an IPv4 packet on an external interface, it extracts the address and
   port and then uses that information to build a WKP+A+P IPv6
   destination address.  The packet is then routed in the ISP core to
   the user's A+P gateway, which is then able to de-capsulate the IPv4
   packet or reverse the applied NAT mapping.  Note that the packet
   processing at the BR is completely stateless, since there is no need
   to know how many bits of the port are "stolen" by the address.  The
   longest prefix rule will just deliver the packet to the corresponding
   A+P gateway.  All the state is kept on the CPE/CN, i.e., at the edge.
   Figure 3 shows how an incoming packet is routed.  Observe that the
   port translation at the CPE/CN (datagram 3) only happens if the
   CPE/CN has a preexisting mapping.  Otherwise, the port number is left
   untouched.  Overall, this approach brings two major advantages over
   CGNs: (i) there are no scalability issues, and (ii) it allows a
   customer to be contacted on the restricted port range with no extra
   signaling.  (This eliminates the filtering implicitly required for
   "symmetric" NATs in [RFC3489].)










Maennel, et al.            Expires May 8, 2009                 [Page 16]

Internet-Draft          A+P Addressing Extension           November 2008


                   +-----------+
                   |    Host   |
                   +-----+-----+
                      ^  |12.0.0.1 (ports 4096 to 8191)
      IPv4 datagram 3 |  |
                      |  |
                      |  |
               +---------|---------+
               |CPE/CN   |         |
               +--------|||--------+
                      ^ |||4999:0:0:0:0c00:0001:1000::/100
       IPv6 datagram 2| |||
                      | |||<-IPv4-in-IPv6
                      | |||
                 -----|-|||-------
               /      | |||        \
              |     ISP network     |
               \      | |||        /
                 -----|-|||-------
                      | |||
                      | |||
               +--------|||--------+
               |BR      |||        |
               +---------|---------+
                      ^  |
      IPv4 datagram 1 |  |
                 -----|--|--------
               /      |  |         \
              |     Internet        |
               \      |  |         /
                 -----|--|--------
                      |  |
                      |  |128.0.0.1
                   +-----+-----+
                   | IPv4 Host |
                   +-----------+

                   Figure 3: Routing of Incoming Packets













Maennel, et al.            Expires May 8, 2009                 [Page 17]

Internet-Draft          A+P Addressing Extension           November 2008


     +-----------------+--------------+-----------------------------+
     |        Datagram | Header field | Contents                    |
     +-----------------+--------------+-----------------------------+
     | IPv4 datagram 1 |     IPv4 Dst | 12.0.0.1                    |
     |                 |     IPv4 Src | 128.0.0.1                   |
     |                 |      TCP Dst | 4097                        |
     |                 |      TCP Src | 80                          |
     | --------------- | ------------ | --------------------------- |
     | IPv6 Datagram 2 |     IPv6 Dst | 4999:0:0:0:0c00:0001:1001:: |
     |                 |     IPv6 Src | 4999:0:0:0:128.0.0.1::      |
     |                 |     IPv4 Dst | 12.0.0.1                    |
     |                 |       IP Src | 128.0.0.1                   |
     |                 |      TCP Dst | 4097                        |
     |                 |      TCP Src | 80                          |
     | --------------- | ------------ | --------------------------- |
     | IPv4 datagram 3 |     IPv4 Dst | 12.0.0.1                    |
     |                 |     IPv4 Src | 128.0.0.1                   |
     |                 |      TCP Dst | 32000                       |
     |                 |      TCP Src | 80                          |
     +-----------------+--------------+-----------------------------+

                         Datagram header contents

3.2.  IPv6 and mixed V4-V6 traffic

   Note that if IPv4/IPv6 dual stack is provided on the customer's LAN,
   IPv6 to IPv6 destinations would be transported untranslated from the
   customer's host to the provider's border with other providers.

   If the customer has an IPv6-only LAN, then the A+P gateway providing
   translation should also provide NAT-PT service so that the customer
   could communicate with the IPv4 Internet.

3.3.  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 reply (commonly known as "ping").  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 provider's BR will need to examine the
   embedded header to extract the port number, while the A+P gateway
   will do the necessary rewriting.

   ECHO and ECHO reply are more problematic.  For ECHO, the A+P gateway



Maennel, et al.            Expires May 8, 2009                 [Page 18]

Internet-Draft          A+P Addressing Extension           November 2008


   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 BR 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.  (We leave pings
   originated from an external domain/legacy Internet towards an A+P
   device for future work.)

3.4.  Handling IP fragments

   Much like ICMP packets, IP fragmented packets are known to be hard to
   handle in any address translation mechanism [RFC3022].  In fact, only
   the first IP fragment contains the TCP (UDP) header.  This issue is
   commonly dealt with by keeping additional state at the NAT device to
   allow fragments to be mapped to the correct TCP (UDP) session.  In
   the A+P gateway solution, fragments coming from the internal domain
   can be avoided if the core network runs IPv6 only and the PE ensures
   that no layer-3 fragmentation is performed by the customer equipment.
   Fragments coming from the external domain are harder to handle.
   Commercial NATs extract the port number out of the first fragment and
   keep that information to map subsequent fragments.  Moreover, when
   the first fragment is not the first one to be received at the NAT,
   the fragment needs to be stored until the port number is known
   [CCIE-Pro].  Note that a deployment scenario which intends to handle
   fragments must ensure that all the fragments of the same original IP
   packet arrive at the same fragment handling host.

   We propose to route fragments to special boxes by exploiting the
   prefix combination in a similar way to Figure 1.  The BR is able to
   detect that a packet is fragmented when it receives it; in that case,
   it uses a different well-known prefix which is intended for fragments
   only (we call it WKPF).  Hence the BR builds an IPv6 packet where the
   destination address is WKPF+A and then uses normal routing.
   Fragments are then routed to a special box which we call "fragment
   handler" (FH).  The FH is in charge of keeping track of the port
   numbers used by each fragment.  Namely, upon receiving the first
   fragment, the FH stores a mapping <src_ip, ip_id> --> <dst_port> (8
   bytes in total), which it uses to build the correct WKP+A+P address
   for all the fragments of the same IP packet (identified by the pair
   <src_ip, ip_id>).  After storing such a mapping, all subsequent
   fragments can be forwarded to the correct A+P destination address.
   This way, fragment storage is only required for out-of-order
   fragments, until the fragment carrying the port number is received.
   Since out-of-order packets are pretty rare, the FH is not expected to
   buffer an high number of fragments.  (If it runs out of space,
   perhaps because of a resource exhaustion attack, it can always
   discard older fragments.)  Observe that a CGN also needs to remember
   the dst_ip information, since it cannot trust the dst_ip in the



Maennel, et al.            Expires May 8, 2009                 [Page 19]

Internet-Draft          A+P Addressing Extension           November 2008


   packet itself.  In this case, each entry in the mapping takes 12
   bytes instead of 8.

   Finally, handling fragments via a specific prefix gives the network
   operator the flexibility to deploy multiple FHs.  There are two limit
   cases: on one hand, a single FH that handles all the fragments in the
   network (the FH then announces WKPF); on the other hand, a FH for
   each destination IP (the FH then announces WKPF+A).  Again, the
   longest prefix matching rule gives the ISP the autonomy to choose any
   intermediate point in between.

3.5.  The incremental path to A+P

   In this section we will discuss one possibility for large networks to
   deploy A+P incrementally.  As discussed above, the A+P scheme
   requires changes to the CPE, the BR, and (optionally) the PE.
   Changes to the routing system include the addition of the WKP and
   WKPF.  The upgrade of the BR, as well as routing the WKP/WKPF have to
   be done before the first customers transition to A+P. In addition, it
   is possible to provide the A+P gateway function at the PE routers
   while gradually upgrading the CPEs.  (We stress here once again that
   as soon as the PE is upgraded and A+P is activated, the customer must
   be able to operate its own CN, if he or she so desires.)

   One important consideration has not been described thus far: the BR
   mentioned in this document is essentially the BR of the A+P part of
   the network, and does not necessarily have to be the border router of
   the ISP.  In this sense it might be possible to upgrade a smaller but
   contiguous part of a larger network, as long as it supports dual-
   stack.  However, care needs to be taken that all routers (BR) that
   might form the boundary of the "upgraded cloud", are upgraded to A+P.
   In this case, those routers translate "A+P packets" into "legacy IPv4
   packets" and vice versa.

   A+P clouds can be independently deployed within the ISP network; the
   only constraint that needs to be satisfied is that the A+P address
   space does not overlap with the IPv4 address space which still serves
   legacy CPEs.  As the A+P deployment speeds up, small clouds can be
   easily merged into bigger ones, leading the way to the ultimate goal
   of a single, ISP-wide A+P cloud.  For instance, a deployment plan
   could be to install A+P clouds at some neighboring PoPs, then merge
   them at the state level, and so on.


4.  Benefits and limitations of A+P

   A+P addressing leverages internal routing in the ISP to route packets
   on extended addresses in a stateless manner.  This allows customers



Maennel, et al.            Expires May 8, 2009                 [Page 20]

Internet-Draft          A+P Addressing Extension           November 2008


   to be assigned globally routable addresses and to accept incoming
   connections on their A+P port range.  Observe that the statefulness
   of NATs hampers this desirable feature, and forces users to use out-
   of-band signaling (e.g., UPnP).  From the perspective of the ISP, on
   the other hand, A+P statelessness usually means lower deployment
   costs and less scalability issues with respect to stateful approaches
   like NAT.  Moreover, A+P allows ISP to fine-tune their network via
   standard internal routing management, without adding an extra layer
   of complexity (e.g., point-to-point tunnels).

   We now discuss the limitations of the A+P approach.  Recall that a
   transport session is identified by a 5-tuple

             <src_ip, src_port, dst_ip, dst_port, protocol>

   Hence, any mechanism that shares the same IP address among multiple
   hosts intrinsically poses limitations on the number of active
   transport sessions that a single host can maintain.  Observe that
   connections with different hosts (or even different applications on
   the same host) are only minimally impacted, because they can be
   differentiated by means of the dst_ip (dst_port) field.  Therefore,
   the only case in which address sharing causes troubles is multiple
   outbound transport sessions with the same remote host and the same
   port.  In fact, in this case only the src_port field can be used to
   differentiate; however that field can not be fully exploited, since
   it is also used to multiplex multiple users on the same IP address.
   While multiple sessions with the same remote application are not a
   widespread practice, some very popular websites (e.g., GoogleMaps and
   iTunes) have been reported to use very large numbers of TCP/IP
   connections to maximize parallelism.  The current estimate of the
   number of parallel sessions used by those websites is circa 70
   [I-D.durand-softwire-dual-stack-lite].  In this respect, A+P with 8
   port bits would allow every host to maintain up to 256 parallel
   connections with the same remote process, while still providing 256
   times more addresses for end hosts.

   Another 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
   implies application-specific hacks (e.g., HTTP and HTTPS virtual
   hosting), discussion of which is out of the scope of this document.
   Of course, a provider might charge more for giving a customer the
   'normal' port range, 0..N, thus allowing the customer to provide
   externally available services at 'normal' ports.  Observe that some
   popular applications (e.g., BitTorrent) require the availability of



Maennel, et al.            Expires May 8, 2009                 [Page 21]

Internet-Draft          A+P Addressing Extension           November 2008


   well known ports.  However, those applications can easily adapt to
   work with different ports, as users of such tools update them
   frequently (e.g., to gain new features).


5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


6.  Security Considerations

   The primary security issue any time a NAT is mentioned is the
   implicit firewall provided by a NAT.  Any proposal to eliminate NATs
   raises the specter of insecure hosts lying naked before a hostile
   Internet.  For a number of reasons, we do not think this is a serious
   issue here.  In fact, under certain assumptions our A+P scheme is
   more secure than CGN.

   A NAT owned by a customer, whether a home consumer or a large
   enterprise, is under the control of that customer.  All machines on
   the customer's side of the NAT have unfettered access to each other
   machines on the same; generally, this is what is desired.  A+P NATs
   do not change that.  CGNs do not change the access property, either.
   However, with a CGN there are *many* machines on the inside of the
   translation, not all of which are in the customer's administrative
   domain.  Unless other firewall mechanisms are employed, CGNs create
   added risk of unauthorized access.

   By contrast, the protection scope of an A+P NAT is, by definition, at
   the boundary to the customer network.  The access properties are thus
   precisely what traditional NATs have provided.

   There is one notable exception to this point.  As discussed in
   Section 3.1, inbound packets addressed to the assigned port number
   range are passed through unchanged, even if no outbound packets were
   sent to the originator.  While this allows customers to run their own
   servers on certain ports, it also allows attackers to probe these
   servers without the protection provided today by provider-supplied
   NAT boxes.  The issue is not that internal machines are addressable
   -- that is an inevitable corollary to servers being run -- but that
   it may represent a change from today's behavior.  Furthermore, the
   effect on the customer varies greatly, depending on what port number
   range they are assigned; someone who is assigned 0-4K derives more
   benefit and runs more risk than someone who is assigned 48K-52K,



Maennel, et al.            Expires May 8, 2009                 [Page 22]

Internet-Draft          A+P Addressing Extension           November 2008


   since the latter is in the IANA-assigned dynamic port range.

   A useful middle ground would be provision of a customer-controllable
   switch in the CPE that controls what happens to such packets.  If
   filtering is to be done, state must be kept, which might be costly;
   this suggests that perhaps it should only be done in the CPE if it is
   replacing current CPE that provides NAT functionality.  If customers
   have their own CN, they have the option of buying one with or without
   such a feature, according to their own needs.

   Note that regardless of the existence of such an option, the CPE/CN
   will need customer-controllable port number-mapping capability, since
   most customers will not be assigned a range that corresponds to the
   servers they wish to run.

   An unrelated risk is resource consumption in the FH.  As noted,
   stored fragments can be discarded as needed.  Most likely, some sort
   of fairness scheme should be employed, so that large numbers of
   fragments arriving for one customer do not impact other customers'
   ability to receive fragmented packets.

   There does not appear to be any risk if WKP or WKPF are announced
   outside of the provider's network.  Assume that an attacker knows
   them.  He or she could could send directly to addresses in those
   ranges.  For WKP, this is probably harmless; one could reach the same
   box more simply by just sending to its IPv4 address.  For WKPF
   addresses, this might be a way to send extra traffic to the FHs;
   there wouldn't seem to be any particular benefit to the attacker
   compared with simply sending fragments, however.


7.  Acknowledgments

   The authors wish to thank David Ward for review, endless constructive
   criticism, and interminable questions, and Cullen Jennings for
   discussion and review of fragmentation.  We would also like to thank
   the following persons for their valuable feedback on earlier versions
   of this work: Bernhard Ager, Rob Austein, Alain Durand, Dino
   Farinacci, Hamed Haddadi, Russ Housley, Wolfgang Muehlbauear, Steve
   Uhlig and Ruediger Volk.


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.



Maennel, et al.            Expires May 8, 2009                 [Page 23]

Internet-Draft          A+P Addressing Extension           November 2008


8.2.  Informative References

   [BCP38]    Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, May 2000.

   [CCIE-Pro]
              Doyle, J., "Routing TCP/IP Volume I (CCIE Professional
              Development)", 1998.

   [I-D.bajko-v6ops-port-restricted-ipaddr-assign]
              Bajko, G. and T. Savolainen, "Port Restricted IP Address
              Assignment",
              draft-bajko-v6ops-port-restricted-ipaddr-assign-01 (work
              in progress), October 2008.

   [I-D.boucadair-dhc-port-range]
              Boucadair, M., Grimault, J., Levis, P., and A.
              Villefranque, "DHCP Options for Conveying Port Mask and
              Port Range Router IP Address",
              draft-boucadair-dhc-port-range-01 (work in progress),
              October 2008.

   [I-D.boucadair-port-range]
              Boucadair, M., Grimault, J., Levis, P., and A.
              Villefranque, "Provider-Provisioned CPE: IPv4 Connectivity
              Access in the context of IPv4  address exhaustion",
              draft-boucadair-port-range-00 (work in progress),
              October 2008.

   [I-D.durand-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", draft-durand-softwire-dual-stack-lite-00
              (work in progress), September 2008.

   [Martin-Java]
              Martin, D., Rajagopalan, S., and A. Rubin, "Blocking Java
              Applets at the Firewall", Proceedings of the Internet
              Society Symposium on Network and Distributed System
              Security, pp. 16-26, 1997.

   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
              STD 9, RFC 959, October 1985.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.



Maennel, et al.            Expires May 8, 2009                 [Page 24]

Internet-Draft          A+P Addressing Extension           November 2008


   [RFC2766]  Tsirtsis, G. and P. Srisuresh, "Network Address
              Translation - Protocol Translation (NAT-PT)", RFC 2766,
              February 2000.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

   [RFC4966]  Aoun, C. and E. Davies, "Reasons to Move the Network
              Address Translator - Protocol Translator (NAT-PT) to
              Historic Status", RFC 4966, July 2007.

   [SP-NAT]   Alcock, S., Nelson, R., and D. Miles, "Characterizing the
              Network Connection Behavior of Residential Broadband
              Subscribers", draft, under-submission , 2009.


Authors' Addresses

   Olaf Maennel
   T-Labs/TU-Berlin
   Ernst-Reuter-Platz 7
   Berlin  10587
   Germany

   Phone: +491607199931
   Email: olaf@maennel.net


   Randy Bush
   Internet Initiative Japan
   5147 Crystal Springs
   Bainbridge Island, Washington  98110
   US

   Phone: +1 206 780 0431 x1
   Email: randy@psg.com









Maennel, et al.            Expires May 8, 2009                 [Page 25]

Internet-Draft          A+P Addressing Extension           November 2008


   Luca Cittadini
   Universita' Roma Tre
   via della Vasca Navale, 79
   Rome,   00146
   Italy

   Phone: +39 06 5733 3215
   Email: luca.cittadini@gmail.com


   Steven M. Bellovin
   Columbia University
   1214 Amsterdam Avenue
   MC 0401
   New York, NY  10027
   US

   Phone: +1 212 939 7149
   Email: bellovin@acm.org
































Maennel, et al.            Expires May 8, 2009                 [Page 26]

Internet-Draft          A+P Addressing Extension           November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Maennel, et al.            Expires May 8, 2009                 [Page 27]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/