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

Versions: 00

Behavior Engineering for Hindrance                         D. Miles, Ed.
Avoidance                                                 Alcatel-Lucent
Internet-Draft                                               M. Townsley
Intended status: Informational                             Cisco Systems
Expires: September 4, 2009                                 March 4, 2009

                            Layer2-Aware NAT

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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

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

   The list of current Internet-Drafts can be accessed at

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

   This Internet-Draft will expire on September 4, 2008.

Copyright Notice

   Copyright (c) 2008 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document describes a "Layer2-Aware" IPv4-to-IPv4 (NAT44) Service
   Provider NAT function that identifies subscriber traffic based on IP-

Miles & Townsley        Expires September 4, 2008               [Page 1]

Internet-Draft              Layer2-Aware NAT                  March 2008

   independent methods such as a link-layer address, VLAN, PPP session,
   tunnel, etc. in order to allow one to either avoid "double-NAT"
   (NAT444) of subscriber IP traffic altogether, the need for additional
   "Shared Service-Provider" IPv4 address space, or partitioning of RFC
   1918 space between subscribers.  While the mechanisms described in
   this document may be applicable to a variety of network
   architectures, the primary focus is on residential "fixed-line"
   Internet access.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Network Topology . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Link-Layer Subscriber Identification (NAT44) . . . . . . .  6
     4.2.  Home Network with NAT (NAT444) . . . . . . . . . . . . . .  6
     4.3.  Bridged Home Network (NAT44) . . . . . . . . . . . . . . .  7
     4.4.  Routed Home Network (NAT44)  . . . . . . . . . . . . . . .  8
   5.  L2-Aware NAT Support . . . . . . . . . . . . . . . . . . . . .  8
   6.  L2-Aware NAT Requirements  . . . . . . . . . . . . . . . . . .  9
     6.1.  IP Addressing  . . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  Inbound Connections  . . . . . . . . . . . . . . . . . . .  9
     6.3.  UPnP and NAT-PMP . . . . . . . . . . . . . . . . . . . . .  9
   7.  Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Subscriber to Network  . . . . . . . . . . . . . . . . . . 10
     7.2.  Network to Subscriber  . . . . . . . . . . . . . . . . . . 10
   8.  Operational Considerations . . . . . . . . . . . . . . . . . . 11
     8.1.  In-band CPE Management . . . . . . . . . . . . . . . . . . 11
     8.2.  Logging and Accounting . . . . . . . . . . . . . . . . . . 11
     8.3.  External Port Limits . . . . . . . . . . . . . . . . . . . 12
       8.3.1.  HTTP Intercept and Redirect  . . . . . . . . . . . . . 12
       8.3.2.  Limit Override . . . . . . . . . . . . . . . . . . . . 13
   9.  IPv6 Co-existance  . . . . . . . . . . . . . . . . . . . . . . 13
   10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     13.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Miles & Townsley        Expires September 4, 2008               [Page 2]

Internet-Draft              Layer2-Aware NAT                  March 2008

1.  Introduction

   As public IPv4 space diminishes service providers become increasingly
   concerned about maintaining IPv4 services post exhaustion.  The
   assumption behind this concern is that a significant part of Internet
   content will remain on IPv4 post exhaustion.  IPv4 continuity
   approaches can be broadly classed as either IPv4-to-IPv6 translation
   or IPv4 tunneling both combined with a component of IPv4 public
   address sharing.  L2-Aware NAT is a mechanism that permits devices
   which terminate the subscriber sessions to perform a NAPT function.
   Examples of a subscriber session may include a Softwire, L2TP
   session, PPP session, link-layer session, logical/physical
   interfaces, or future tunneling techniques.  If an IPv4 over IPv6
   encapsulation is used between the NAT and an individual subscriber, a
   L2-Aware NAT may be used one side of the tunnel to provide IPv4
   access over an IPv6-only network as described in

   L2-Aware NAT differs from existing IPv4 NATs, or that proposed
   in[I-D.nishitani-cgn], because it is not reliant on the uniqueness of
   the NAT inside address to create NAT mappings or to forward
   downstream traffic towards the subscriber.  A Traditional NAT
   [RFC3022] is deployed between two network segments are commonly
   referred to as either the inside and outside, or LAN and WAN
   segments.  A L2-Aware NAT has many subscriber sessions (conceptually
   many inside/LAN segments) which are uniquely identified to allow for
   each subscriber to have their own NAT mapping table.  In L2-Aware
   NAT, the NAT function supports hosts with the duplicated inside/LAN
   address provided they exist on different subscriber sessions.  This
   technique can be leveraged post IPv4-exhaustion within the
   constraints of existing host and CPE implementations to assign the
   exact same public IPv4 address to every subscriber session and to
   then perform IPv4-to-IPv4 NAT on the subscriber traffic.  For
   example, multiple PPP subscribers could be assigned the exact same
   IPv4 address through IPCP and the L2-Aware NAT will translate all
   packets to an external/WAN public IPv4 address by including
   subscriber-identifier as an additional delimiter in the NAT mapping

   L2-Aware NAT assumes that there is some way to identify individual
   subscriber packets by some method other than the source IPv4 address
   assigned to the subscriber.  While there are a number of ways this
   can be achieved, it may not always be possible without upgrading RG
   equipment, altering existing deployment topology, etc.  When it can
   be achieved, subscriber aware NAT can be used to alleviate challenges
   associated with overlapping RFC 1918 space described in

Miles & Townsley        Expires September 4, 2008               [Page 3]

Internet-Draft              Layer2-Aware NAT                  March 2008

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Background

   Pre-IPv4 Exhaustion, ISP have usually assigned one unique public IPv4
   addresses to each unique subscriber.  Subscribers themselves may
   choose to assign their public IPv4 address directly to hosts, or to
   traditional NAT devices within their network.  In a post-exhaustion
   world an ISP will find it increasingly difficult to source additional
   globally unique IPv4 addresses for a growing subscriber population.

   IPv6 is the obvious alternative to IPv4 transport in a post-
   exhaustion world; however, it is appreciated that IPv4 addresses will
   exhaust prior to significant penetration of IPv6 content, hence IPv4
   services will continue to be used and new customers must be able to
   access any existing IPv4 content.  In order to support this model
   with minimal change to existing IPv4 hosts or customer premise
   equipment a translation technique akin to NAPT may be employed.
   Since the operator cannot acquire any more public IPv4 addresses, one
   public IPv4 address needs to be shared by a number of subscribers.

   A problem with IPv4 NAT when deployed within an ISP is that it
   translates between exactly two network segments.  If a Carrier Grade
   NAT (CGN) is centrally located within the ISP then it is a
   requirement that hosts within the inside IP segment need a unique
   IPv4 address.

   L2-Aware NAT relies on the identification of the subscriber and their
   unique logical or virtual network segment using layer 2 mechanisms.
   L2-Aware NAT allows multiple network segments to share a common
   public IPv4 address when combined with NAPT.  Conceptually L2-Aware
   NAT is a NAT for multiple non-unique inside networks.

   By adopting a L2-Aware NAT, an ISP can avoid change to existing IPv4
   host or CPE while maintaining an IPv4-continuity service.  Unlike a
   CGN, L2-Aware NAT allows an ISP to assign a duplicate IPv4 addresses
   to many subscribers

3.  Terminology

Miles & Townsley        Expires September 4, 2008               [Page 4]

Internet-Draft              Layer2-Aware NAT                  March 2008

   Address                   An IP layer identifier for an interface or
                             set of interfaces

   BNG                       Broadband Network Gateway

   Host                      A non-routing IPv4 node that sources and
                             receives IP packets

   IP                        Internet Protocol Version 4 (IPv4)

   Node                      A device that implements IPv4

   Router                    A node that forwards packets not directly
                             addressed to itself

   Network Segment           A unique layer 3 forwarding topology

   NAT                       Network Address Translation

   CGN                       Carrier Grade NAT

   Subscriber-ID             A node-specific unique identifier for
                             exactly one subscriber.  This may be
                             generalised as a unique link-layer
                             encapsulation identifier

4.  Network Topology

   The L2-Aware NAT MUST be deployed within the subscriber aware device,
   examples of which include BRAS, LNS, BNG, CMTS or Softwire
   Concentrators.  Without the loss of generality, when BNG term is used
   in the following text it equally applies to any type of a device
   deploying Session-Aware NAT.  By deploying L2-Aware NAT inside the
   same device that terminates the subscriber session, session
   information including Session-ID can be passed to the L2-Aware NAT

   L2-Aware NATs terminate multiple network segments into a single NAT
   function comprised of virtual NAT tables for each subscriber.

Miles & Townsley        Expires September 4, 2008               [Page 5]

Internet-Draft              Layer2-Aware NAT                  March 2008

4.1.  Link-Layer Subscriber Identification (NAT44)
                             |  Session                |
                             |Termination              |
                             |+---------+              |
   Subscriber --------------+|-         | +----------+ |
                Session      || \-------|-|Subscriber| |
                             ||         | |   Aware  |.....Internet
                             || /-------|-|      NAT | |
   Subscriber --------------+|-         | +----------+ |
                Session      |+---------+              |
                             |                         |
                             |                         |

   Subscribers may be identified through the use of a unique per-
   subscriber link-layer address or the provision of a per-subscriber
   logical or physical interface.  Examples may include PPPoE, L2TP,
   Softwires, [I-D.durand-dual-stack-lite], per-client VLAN, unique
   link-layer/MAC address or any other method where by some unique layer
   2 information is presented to the L2-Aware NAT.  When subscribers are
   directly attached all subscriber-to-subscriber communication MUST
   occur through the L2-Aware NAT.

   It is expected that all clients will be assigned the same IPv4
   address that is in turn translated.  This IP address should be an
   IANA reserved IP address to allow future implementations to know when
   they are behind a L2-Aware NAT.  This IANA-reserved address space
   could be common with that proposed in [I-D.durand-dual-stack-lite].

4.2.  Home Network with NAT (NAT444)
                             |  Session                |
                             |Termination              |
       |    +---+            |+---------+              |
   LAN +----|NAT|------------+|-        | +----------+ |
       |    +---+  Session   || \-------|-|Subscriber| |
                             ||         | |   Aware  |.....Internet
       |    +---+            || /-------|-|      NAT | |
   LAN +----|NAT|------------+|-        | +----------+ |
       |    +---+  Session   |+---------+              |
                             |                         |
                             |                         |

   To support fixed broadband networks without change to existing NAT
   device, the home network NAT may exist between the subscriber LAN and
   the L2-Aware NAT.  In this example the home network LAN would

Miles & Townsley        Expires September 4, 2008               [Page 6]

Internet-Draft              Layer2-Aware NAT                  March 2008

   typically be RFC 1918 address space, and is first NAT by the home
   network device.  The address to which the LAN RFC 1918 address space
   is translated to should be an IANA reserved IP address and may be
   common with the IANA-reserved address space proposed in

   This approach has the advantage of requiring no CPE change though it
   is subject to a number of limitations associated with historical NAT
   implementations on consumer CPE while providing a workaround for the
   shared address space problem described in

   Note that the presence of a NAT device in front of Session-Aware NAT
   creates a double-NAT environment and has all the implications

4.3.  Bridged Home Network (NAT44)
                                |  Session                |
                                |Termination              |
       |    +------+            |+---------+              |
   LAN +----|Bridge|------------+|-        | +----------+ |
       |    +------+  Session   || \-------|-|Subscriber| |
                                ||         | |   Aware  |.....Internet
       |    +------+            || /-------|-|      NAT | |
   LAN +----|Bridge|------------+|-        | +----------+ |
       |    +------+  Session   |+---------+              |
                                |                         |
                                |                         |

   L2-Aware NAT can support a bridged connection whereby a number of
   hosts share a single session.  In this case each host should be
   assigned RFC 1918 addresses, and there is a requirement for hosts
   within a single session to have unique IP addresses.  There is no
   requirement for hosts in different sessions to have unique IP
   addresses and as a result the same RFC 1918 network may be re-used
   for different sessions within the L2-Aware NAT.

   While a bridge is commonly available, the L2-Aware NAT would be
   exposed to all link-layer addresses of hosts in the LAN segments and
   may need to field DHCP/Router Solicitation requests for said hosts.
   In it not uncommon for subscribers to install their own consumer NAT
   function in bridge topologies, degenerating this scenario to that
   described in section 4.2

Miles & Townsley        Expires September 4, 2008               [Page 7]

Internet-Draft              Layer2-Aware NAT                  March 2008

4.4.  Routed Home Network (NAT44)
                                |  Session                |
                                |Termination              |
       |    +------+            |+---------+              |
   LAN +----|Router|------------+|-        | +----------+ |
       |    +------+  Session   || \-------|-|Subscriber| |
                                ||         | |   Aware  |.....Internet
       |    +------+            || /-------|-|      NAT | |
   LAN +----|Router|------------+|-        | +----------+ |
       |    +------+  Session   |+---------+              |
                                |                         |
                                |                         |

   In the Routed Home Network, subscribers are free to choose their own
   IP address configuration within the LAN segment.  Because the address
   space in the home network is NATed, and hence not globally routable,
   there is no requirement for prefix-delegation or management of the
   address space used within the home network by the L2-Aware NAT.  The
   routing home gateway needs only to install a default route towards
   the Subscriber Aware NAT - there is no need for routing protocols
   between routing home gateway and Subscriber Aware NAT.

   This approach allows an operator to avoid NAT444 and provide a
   consistent and common NAT implementation across all subscribers.

   A router exists at the boundary of the home network that performs
   standard IPv4 routing of the LAN private address space towards the
   L2-Aware NAT device.  This device may have an IPv4 address assigned
   to its WAN interface as part of an IANA reserved network for L2-Aware
   NAT.  The L2-Aware NAT must allow any source IP from the LAN segment
   and rely on Session-ID for any downstream forwarding.

   It is intended that the router at the edge of the home network is of
   the same design as CPE of today but with the NAT function replaced
   with an IP Forwarding component.  While this is all using well-known
   capabilities, "consumer-grade" CPEs may not perform this function,
   though certainly small "enterprise grade" routers likely will.

5.  L2-Aware NAT Support

   To support L2-Aware NAT, the BNG (or session terminator) MUST allow
   different sessions to have the same IPv4 address(es).  As a result
   the management of sessions MUST NOT use IP address as a lookup key.
   Special consideration must be paid to forwarding behaviour between
   the L2-Aware NAT component and the session itself.  Forwarding based

Miles & Townsley        Expires September 4, 2008               [Page 8]

Internet-Draft              Layer2-Aware NAT                  March 2008

   on IP destination will be insufficient between these two functions as
   IP addresses are no longer unique identifiers.

6.  L2-Aware NAT Requirements

6.1.  IP Addressing

   L2-Aware NAT SHOULD use well-know IP addresses proposed in

6.2.  Inbound Connections

   As the L2-Aware NAT supports the BEHAVE drafts Internet Connectivity
   Establishment [I-D.ietf-mmusic-ice] methods of TCP and UDP hole-
   punching are supported.  Some IPv4 applications are reliant on
   accepting unsolicited inbound TCP or UDP sessions (commonly peer-to-
   peer or server applications) that may require an external port be
   opened on the NAT public address and mapped to an internal address
   and port within a single session.

   It is important to extend an aspect of control to the users/hosts for
   inbound mapping behaviour.  This control could be exercised through:

   o  An external management system that provisions permanent or
      temporary external address/port pair mappings to internal session,
      address and port tuples.  One could envisage this to be via web-
      based portal or similar.

   o  Extending the existing UPnP IGD and NAT-PMP protocols to allow
      hosts direct configuration of the L2-Aware NAT device

   o  Encouraging IPv6 transport for those services that may require
      inbound connections

   Inbound connections are typically used by peer-to-peer applications
   or by client-server services where the server is behind the L2-Aware
   NAT.  NAT studies [NAT analysis] suggest the majority of inbound
   connections are to peer-to-peer applications and these applications
   are ideal candidates for migration to IPv6 transport, and by using
   IPv6 the complexities of NAT and client-to-NAT protocol
   implementation can be avoided.

6.3.  UPnP and NAT-PMP

   It should be noted that certain session topologies may make the L2-
   Aware NAT router behave appear as the default router on a
   subscriber's home network.  In these cases it may be attractive to

Miles & Townsley        Expires September 4, 2008               [Page 9]

Internet-Draft              Layer2-Aware NAT                  March 2008

   allow [UPnP_IGD] or [I-D.cheshire-nat-pmp] protocols to operate
   between clients in the subscriber network and the L2-Aware NAT in the
   ISP.  In routed environments, or scenarios where the customer is
   performing a NAT function between home network and service provider,
   a helper function may be needed to relay or proxy UPnP or NAT-PMP
   protocols to the L2-Aware NAT device.

   Note that the [UPnP_IGD] protocol has a significant limitation as it
   does not have a facility to request a the assignment of a free port -
   it can only request explicit port numbers and be informed whether the
   mapping was successful or not successful.  [I-D.cheshire-nat-pmp] is
   not constrained in this way, and through NAT-PMP the L2-Aware NAT
   could return an available free port.  As L2-Aware NAT overloads many
   subscribers to a single IPv4 address it is inevitable that two UPnP
   or NAT-PMP clients may request an in-use port.  In these cases
   application developers may require guidance to retry additional
   ports, and/or introduce a port-randomisation algorithm into their
   port request.

   Some of these issues are not unique to L2-Aware NAT, but are a
   consequence of the NAT444 model.

7.  Forwarding

7.1.  Subscriber to Network

   A L2-Aware NAT MUST support the IP forwarding techniques of any
   underlying session or link-layer without change.  In links without
   link-layer addresses (such as PPP and L2TP) a client will send
   packets towards the L2-Aware NAT based on routing information or
   other reference.

   Where link-layer addresses exist on the session, next-hop link-layer
   resolution will be performed by the client without any change as a
   result of the L2-Aware NAT.  The L2-Aware NAT MUST present a next-hop
   IP interface towards the client that responds to any link-layer
   resolution protocols such as ARP.

   From the client perspective the intention is to avoid a change in
   upstream forwarding behaviour and link-layer resolution.  There may
   be other client impacts associated from the use of public, private or
   other types of address space, particularly on applications.

7.2.  Network to Subscriber

   When a packet reaches the L2-Aware NAT it is matched against an
   existing NAT mapping that returns inside IP, inside port and

Miles & Townsley        Expires September 4, 2008              [Page 10]

Internet-Draft              Layer2-Aware NAT                  March 2008

   session-ID.  The L2-Aware NAT translates the packet headers as
   indicated and forwards the translated packet to the appropriate
   session.  As IP addresses may overlap between sessions, the
   forwarding function MUST NOT forward based on destination IP.

8.  Operational Considerations

8.1.  In-band CPE Management

   In current ISP networks there may be in-band management of CPE
   through protocols like SNMP or [TR-69].  Both these protocol examples
   rely on the management server being able to connect over UDP or TCP
   directly to the device without solicitation from the CPE.  It is
   expected that most L2-Aware NAT deployments will require overlapping
   session IP addresses, making the identification of individual CPE by
   IP address impossible.  In instances where IPv6 cannot be used for
   CPE management the L2-Aware NAT may need to implement SNMP or TR-69
   helper or proxy functions whenever management of the CPE over IPv4 is

   [TR-69] is a HTTP-based management method that operates in two modes.
   CPE connection initiation, where the CPE connects to the management
   server (ACS), and; ACS connection initiation, where the management
   server (ACS) connects directly to the CPE.  The TR-69 specification
   does acknowledge that when an ACS is behind a NAT or firewall ACS
   connection initiation may not be possible.

   Because of the way ACS connection initiations are specified, each CPE
   generates a unique URL for incoming requests and notifies the ACS of
   this URL an initialisation time.  As the connection is made over HTTP
   it is feasible for a lightweight HTTP proxy function in the L2-Aware
   NAT to direct an ACS connection to the relevant CPE.  The extensions
   required to do this are outside the scope of this document.

8.2.  Logging and Accounting

   As the L2-Aware NAT is deployed within the ISP environment there is
   an onus on the ISP to maintain accurate records that enable
   identification of the source of the traffic for purposes of law
   enforcement.  A L2-Aware NAT, like any NAT that overloads external IP
   addresses, effectively obfuscates the original sender of traffic.

   Several approaches are possible within a L2-Aware NAT:

   1.  Either the L2-Aware NAT MUST create an accurate log, containing
       Subscriber-ID or unique inside IP, Inside Port, Protocol, Outside
       IP, Outside Port, Destination IP and timestamp every time a NAT

Miles & Townsley        Expires September 4, 2008              [Page 11]

Internet-Draft              Layer2-Aware NAT                  March 2008

       mapping is created or destroyed, or;

   2.  the L2-Aware NAT MUST fix a specific port-range mapping and
       specific external IP address to each unique session for the
       duration of said session.  This port-range must be logged along
       with information pertaining to the start, and stop of the

8.3.  External Port Limits

   In L2-Aware NAT the external IP addresses are shared among any number
   of sessions/subscribers.  As external ports are a finite resource a
   mechanism must exist to limit their consumption per session/
   subscriber and notify the subscriber when they are approaching this

   A L2-Aware NAT MUST implement per-session limits on the number of
   external ports that can be mapped to enable fair usage of available
   resources among subscribers.  These limits SHOULD be configurable per
   session/subscriber.  When an external port limit is reached for a
   session, a mapping MUST NOT be created and the L2-Aware NAT MUST
   follow [I-D.ietf-behave-nat-icmp] REQ-8: with respect to sending an
   ICMP destination unreachable message, with a code of 13
   (Communication administratively prohibited).

   In addition to a hard limit of external ports, a L2-Aware NAT SHOULD
   implement a threshold to allow notifications to the subscriber upon
   approaching the limit.  If thresholds are implemented they SHOULD be
   configurable per session/subscriber.

8.3.1.  HTTP Intercept and Redirect

   When either per-session limits or thresholds are reached it is
   advisable to interactively notify the subscriber.  One method to do
   so is to intercept any new outbound HTTP connections and present the
   user with a "Warning" page through an HTTP redirect.

   In the case of HTTP intercept when an external port warning threshold
   limit has been reached, the L2-Aware NAT MAY provide a "Warning"
   page, that is removed upon subscribers acknowledgment.  If
   implemented a mechanism to prevent display of the page on each
   outbound session initiation MUST be implemented.  Details of such
   mechanism are out of scope for this document.

   A L2-Aware NAT MUST NOT destroy any existing NAT mappings when a port
   limit is reached in an attempt to free ports.

Miles & Townsley        Expires September 4, 2008              [Page 12]

Internet-Draft              Layer2-Aware NAT                  March 2008

8.3.2.  Limit Override

   A L2-Aware NAT MAY implement Limit Overrides to allow specific IP
   destinations, ports/protocols, or a combination of the two to be
   excluded from the per-session External Port Limit.  An ISP may use
   this capability to allow access to the supporting HTTP server for
   HTTP intercepts, or to ISP provided services such as mail or account

9.  IPv6 Co-existance

   As L2-Aware NAT is an IPv4-only function, it can co-exist with IPv6
   services over the same session subject to the capabilities of the
   BNG.  It should be emphasised that L2-Aware NAT, and any IPv4 NAT,
   restricts the services available to the ISP subscriber population:
   the IETF, IANA and RIR community have clearly indicated that a
   migration to IPv6 must occur as a matter of urgency to alleviate
   these type of restrictions.

   L2-Aware NAT can also function as the NAT-component of Dual-Stack
   Lite [I-D.durand-dual-stack-lite].  In this case, the tunnel happens
   to be a Softwire transported over IPv6.  For the L2-Aware NAT
   perspective the underlying tunnel transport is not relevant, only the
   ability for the L2-Aware NAT device to address packets destined for a
   particular tunnel/softwire (based on Session ID).

10.  Contributors

   The authors would like to thank the following for their support: Mark
   Townsley, Steve Morin, Andrew Dolganow, Mickey Vucic and Philip

   Comments are solicited and should be addressed to the BEHAVE WG
   mailing list (behave@ietf.org) and/or the author.

11.  IANA Considerations

   This document proposes a new IANA managed IPv4 address from the
   current global address space.  The size of this address space should
   be a /30 and must not be part of RFC 1918, Class D, Class E or
   otherwise reserved address space.  This address space is used by any
   device behind a L2-Aware NAT where one IP is for hosts, and that IP+1
   is reserved for the L2-Aware NAT.

   L2-Aware NAT Reserved Address (Client): a.b.c.d

Miles & Townsley        Expires September 4, 2008              [Page 13]

Internet-Draft              Layer2-Aware NAT                  March 2008

   L2-Aware NAT Reserved Address (Default Router): a.b.c.d+1

12.  Security Considerations

   The operation of L2-Aware NAT is dependant on the unique
   identification of layer 2 or session parameters.  When layer 2
   information such as link-layer addresses are used in the creation of
   a L2-Aware NAT Session-ID mechanisms must exist to ensure link-layer
   address spoofing cannot occur between host and L2-Aware NAT.

   It is also imperative that any NAT mappings are destroyed when a
   Session is dropped - this will avoid a situation whereby Session-ID
   might be re-used within a single L2-Aware NAT and earlier mappings
   may still be active for a new Session.

13.  References

13.1.  Normative References

              Guha, S., Sivakumar, S., Ford, B., and P. Srisuresh, "NAT
              Behavioral Requirements for ICMP protocol", IETF-
              Draft ietf-behave-nat-icmp-09, September 2008.

              Guha, S., Biswas, K., Sivakumar, S., Ford, B., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP",
              IETF-Draft draft-ietf-behave-tcp-08, September 2008.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

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

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements", IETF RFC 4787,
              January 2008.

13.2.  Informative References

              Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port
              Mapping Protocol (NAT-PMP)", IETF
              Draft draft-cheshire-nat-pmp-03, April 2008.

Miles & Townsley        Expires September 4, 2008              [Page 14]

Internet-Draft              Layer2-Aware NAT                  March 2008

              Durand, A., Droms, R., Haberman, B., and J. Woodyatt,
              "Dual-stack lite broadband deployments post IPv4
              exhaustion", IETF Draft draft-durand-dual-stack-lite-01,
              November 2008.

              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", IETF
              Draft draft-ietf-mmusic-ice-19, October 2007.

              Nishitani, T., "Carrier Grade Network Address Translator
              (NAT) Behavioral Requirements for Unicast UDP, TCP and
              ICMP", IETF Draft draft-nishitani-cgn-00, July 2008.

              Shirasaki, Y., "ISP Shared Addresses after IPv4
              Exhaustion", IETF
              Draft draft-shirasaki-isp-shared-addr-00, June 2008.

   [TR-69]    The Broadband Forum, "CPE WAN Management Protocol",
              Technical Report TR-69, May 2004.

              Iyer, P. and U. Warrier, "Internet Gateway Device (IGD)
              Standardized Device Control Protocol V 1.0 -
              InternetGatewayDevice:1", UPnP
              Forum InternetGatewayDevice:1 Standardized DCP,
              November 2001.

Authors' Addresses

   David Miles (editor)
   L3 / 215 Spring St
   Melbourne, Victoria  3000

   Phone: +61 3 9664 3308
   Email: david.miles@alcatel-lucent.com

Miles & Townsley        Expires September 4, 2008              [Page 15]

Internet-Draft              Layer2-Aware NAT                  March 2008

   Mark Townsley
   Cisco Systems

   Email: townsley@cisco.com

Miles & Townsley        Expires September 4, 2008              [Page 16]

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