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
draft-miles-behave-l2nat-00
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-
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 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.
Abstract
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
[I-D.durand-dual-stack-lite].
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
table.
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
[I-D.shirasaki-isp-shared-addr].
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
function.
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
[I-D.durand-dual-stack-lite].
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
[I-D.shirasaki-isp-shared-addr].
Note that the presence of a NAT device in front of Session-Aware NAT
creates a double-NAT environment and has all the implications
thereof.
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
[I-D.durand-dual-stack-lite].
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
required.
[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
session.
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
limit.
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
management.
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
Matthews.
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
[I-D.ietf-behave-nat-icmp]
Guha, S., Sivakumar, S., Ford, B., and P. Srisuresh, "NAT
Behavioral Requirements for ICMP protocol", IETF-
Draft ietf-behave-nat-icmp-09, September 2008.
[I-D.ietf-behave-tcp]
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
[I-D.cheshire-nat-pmp]
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
[I-D.durand-dual-stack-lite]
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.
[I-D.ietf-mmusic-ice]
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.
[I-D.nishitani-cgn]
Nishitani, T., "Carrier Grade Network Address Translator
(NAT) Behavioral Requirements for Unicast UDP, TCP and
ICMP", IETF Draft draft-nishitani-cgn-00, July 2008.
[I-D.shirasaki-isp-shared-addr]
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.
[UPnP_IGD]
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)
Alcatel-Lucent
L3 / 215 Spring St
Melbourne, Victoria 3000
Australia
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
Paris,
France
Phone:
Email: townsley@cisco.com
Miles & Townsley Expires September 4, 2008 [Page 16]