Internet DRAFT - draft-penno-softwire-sdnat
draft-penno-softwire-sdnat
Internet Engineering Task Force R. Penno
Internet-Draft A. Durand
Intended status: Standards Track Juniper Networks
Expires: September 12, 2012 A. Clauberg
Deutsche Telekom AG
L. Hoffmann
Bouygues Telecom
March 11, 2012
Stateless DS-Lite
draft-penno-softwire-sdnat-02
Abstract
This memo define a simple stateless and deterministic mode of
operating a carrier-grade NAT as a backward compatible evolution of
DS-Lite.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 12, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Penno, et al. Expires September 12, 2012 [Page 1]
Internet-Draft Stateless DS-Lite March 2012
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Stateless DS-Lite CPE . . . . . . . . . . . . . . . . . . . . 4
2.1. Learning external IPv4 address . . . . . . . . . . . . . . 4
2.2. Learning external port range . . . . . . . . . . . . . . . 4
2.3. Stateless DS-Lite CPE operation . . . . . . . . . . . . . 5
2.4. Host-based Stateless DS-Lite . . . . . . . . . . . . . . . 5
3. Stateless AFTR . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Anycast IPv6 address for Stateless AFTR . . . . . . . . . 5
3.2. Stateless AFTR IPv4 address pool . . . . . . . . . . . . . 5
3.3. Stateless AFTR per-subscriber mapping table . . . . . . . 5
3.4. Stateless AFTR decapsulation rules . . . . . . . . . . . . 6
3.5. Stateless AFTR encapsulation rules . . . . . . . . . . . . 6
3.6. Redundancy and fail over . . . . . . . . . . . . . . . . . 7
3.7. SD-AFTR stateless domain . . . . . . . . . . . . . . . . . 7
4. Backward compatibility with DS-Lite . . . . . . . . . . . . . 7
5. ICMP port restricted message . . . . . . . . . . . . . . . . . 8
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Source port restricted ICMP . . . . . . . . . . . . . . . 8
5.3. Host behavior . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative references . . . . . . . . . . . . . . . . . . . 10
8.2. Informative references . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Penno, et al. Expires September 12, 2012 [Page 2]
Internet-Draft Stateless DS-Lite March 2012
1. Introduction
DS-Lite [RFC6333],is a solution to deal with the IPv4 exhaustion
problem once an IPv6 access network is deployed. It enables
unmodified IPv4 application to access the IPv4 Internet over the IPv6
access network. In the DS-Lite architecture, global IPv4 addresses
are shared among subscribers in the AFTR, acting as a Carrier-Grade
NAT (CGN).
[I-D.ietf-softwire-public-4over6] extends the original DS-Lite model
to offer a mode where the NAT function is performed in the CPE. This
simplifies the AFTR operation as it does not have to perform the NAT
function anymore, however, the flip side is that the address sharing
function among subscribers was no longer available.
[I-D.cui-softwire-b4-translated-ds-lite] introduces port
restrictions, but does not completely specifies how the CPE acquires
the information about its IPv4 address and its port range. More
importantly, that draft does not explain how this solution can be
deployed in a regular DS-Lite environment. This memo addresses these
issues and clarifies the operation model.
Other approaches like variations of 4rd allows also for a full
stateless operation of the decapsulation device. By introducing a
strong coupling between the IPv6 address and the derived IPv4
address, they get rid of the per-subscriber state on the
decapsulation devices. The approach take here argues that such per-
subscriber state is not an issue as it is easily replicated among all
decapsulation devices. Eliminating the strong coupling between IPv6
and IPv4 derived addresses, the approach presented here enables
service providers a greater flexibility on how their limited pool of
IPv4 addresses is managed. It also provide greater freedom on how
IPv6 addresses are allocated, as sequential allocation is no longer a
pre-requisite.
The approach presented here is stateless and deterministic. It is
stateless is NAT bindings are maintained on the CPE, not on the AFTR.
It is deterministic as no logs are required on the AFTR to identify
which subscriber is using an external Ipv4 address and port.
The stateless DS-Lite architecture has the following characteristics:
o Backward compatible with DS-Lite. A mix of regular DS-Lite CPE
and stateless DS-Lite CPEs can interoperate with a stateless DS-
Lite AFTR.
o Zero log: Because the AFTR relies only on a per-subscriber mapping
table that is reversible, the ISP does not need to keep any NAT
binding logs.
Penno, et al. Expires September 12, 2012 [Page 3]
Internet-Draft Stateless DS-Lite March 2012
o Stateless AFTR: There is no per-session state on the AFTRs. By
leveraging this stateless and deterministic mode of operation, an
ISP can deploy any number of AFTRs to provide redundancy and
scalability at low cost. Because there is no per-flow state to
maintain, AFTR can implement the functionality in hardware and
perform it at high speed with low latency.
o Flexibility of operation: The ISP can add or remove addresses from
the NAT pool without having to renumber the access network.
o Leverage IPv6: This stateless DS-Lite model leverage the IPv6
access network deployed by the ISPs.
2. Stateless DS-Lite CPE
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].
A Stateless DS-Lite CPE operates in similar fashion than a regular
DS-Lite CPE, where the NAT function is re-introduced in CPE with a
modification on how ports are managed.
2.1. Learning external IPv4 address
A stateless DS-Lite CPE MUST implement the DHCPv4 client relay option
defined in [I-D.ietf-dhc-dhcpv4-over-ipv6] to learn is external IPv4
address. Other mechanism, such as manual configuration or TR69, MAY
be implemented.
2.2. Learning external port range
A stateless DS-Lite CPE MUST implement the ICMP "port restricted"
option defined later in this memo.
At boot time and later at intervals of 1h +/- a random number of
seconds between 0 and 900), the stateless DS-Lite CPE MUST send
packets with source port 0, source IPv4 address of the B4 element,
destination IPv4 address 192.0.0.1 (the AFTR well-known IPv4 address)
destination port 0, for each of the supported transport protocols
(usually TCP and UDP). This will trigger an ICMP "port restricted"
message from the AFTR.
After validating the content of the "ICMP port restricted" message,
the stateless DS-Lite CPE MUST configure its port pool with it. If
existing connections were using source ports outside of that range,
the stateless DS-Lite CPE MUST terminate them.
Penno, et al. Expires September 12, 2012 [Page 4]
Internet-Draft Stateless DS-Lite March 2012
2.3. Stateless DS-Lite CPE operation
The stateless DS-Lite CPE performs IPv4 NAPT from the internal
RFC1918 addresses to the IPv4 address configured on the WAN
interface, restricting its available ports to the range obtained as
described above.
2.4. Host-based Stateless DS-Lite
Any host initiating directly a DS-Lite IPv4 over IPv6 tunnel can
benefit from this techniques by implementing a 'virtual' stateless
DS-Lite CPE function within its IP stack.
3. Stateless AFTR
3.1. Anycast IPv6 address for Stateless AFTR
All stateless AFTRs associated to a domain (or group of subscribers)
will be configured with the same IPv6 address on the interface facing
IPv6 subscribers. A route for that IPv6 address will be anycasted
within the access network.
3.2. Stateless AFTR IPv4 address pool
All stateless AFTRs associated to a domain (or group of subscribers)
MUST be configured with the same pool of global IPv4 addresses.
Routes to the pool of global IPv4 addresses configured on the
stateless AFTRs will be anycasted by the relevant AFTRs within the
ISP routing domain.
3.3. Stateless AFTR per-subscriber mapping table
Stateless AFTRs associated to a domain (or group of subscribers) MUST
be configured with the same per-subscriber mapping table, associating
the IPv6 address of the subscriber CPE to the external IPv4 address
and port range provisioned for this subscriber.
Because the association IPv6 address --- IPv4 address + port range is
not tied to a mathematical formula, the ISP maintains all flexibility
to allocate independently IPv6 address and IPv4 addresses. In
particular, IPv6 addresses do not have to be allocated sequentially
and IPv4 resources can be modified freely.
Penno, et al. Expires September 12, 2012 [Page 5]
Internet-Draft Stateless DS-Lite March 2012
+--------------+------------+----------+
| IPv6 address |IPv4 address|port-range|
+--------------+------------+----------+
|2001:db8::1 | 1.2.3.4 | 1000-1999|
|2001:db8::5 | 1.2.3.4 | 2000-2999|
|2001:db8::a:1 | 1.2.3.4 | 3000-3999|
+--------------+------------+----------+
Figure 1: Per-subscriber mapping table example
This per-subscriber mapping table can be implemented in various ways
which details are out of scope for this memo. In its simplest form,
it can be a static file that is replicated out-of-band on the AFTRs.
In a more elaborated way, this table can be dynamically built using
radius queries to a subscriber database.
3.4. Stateless AFTR decapsulation rules
Upstream IPv4 over IPv6 traffic will be decapsulated by the AFTR.
The AFTR MUST check the outer IPv6 source address belongs to an
identified subscriber and drop the traffic if not. The AFTR MUST
then check the inner IPv4 header to make sure the IPv4 source address
and ports are valid according to the per-subscriber mapping table.
If the inner IPv4 source address does not match the entry in the per-
subscriber mapping table, the packet MUST be discarded and an ICMP
'administratively prohibited' message MAY be returned.
If the IPv4 source port number falls outside of the range allocated
to the subscriber, the AFTR MUST discard the datagram and MUST send
back an ICMP "port restricted" message to the IPv6 source address of
the packet.
Fragmentation and reassembly is treated as in DS-Lite [RFC6333].
3.5. Stateless AFTR encapsulation rules
Downstream traffic is validated using the per-subscriber mapping
table. Traffic that falls outside of the IPv4 address/port range
entries in that table MUST be discarded. Validated traffic is then
encapsulated in IPv6 and forwarded to the associated IPv6 address.
Fragmentation and reassembly is treated as in DS-Lite [RFC6333].
Penno, et al. Expires September 12, 2012 [Page 6]
Internet-Draft Stateless DS-Lite March 2012
3.6. Redundancy and fail over
Because there is no per-flow state, upstream and downstream traffic
can use any stateless AFTR.
3.7. SD-AFTR stateless domain
Using the DHCPv6 DS-Lite tunnel-end-point option, groups of
subscribers and can be associated to a different stateless AFTR
domain. That can allow for differentiated level of services, e.g.
number of ports per customer device, QoS, bandwidth, value added
services,...
4. Backward compatibility with DS-Lite
A number of service providers are, or are in the process of,
deploying DS-Lite in their network. They are interested in evolving
their design toward a stateless model. Backward compatibility is a
critical issue, as, from an operational perspective, it is difficult
to get all CPEs evolve at the same time.
So AFTRs have to be ready to service CPEs that are pure DS-Lite, some
that are implementing only DHCPv4 over IPv6 and handle the NAT on the
full IPv4 address themselves and some that also implement port
restrictions via the ICMP message described here. For this reason, a
AFTR operating in backward compatibility mode MAY decide to re-NAT
upstream packets which source port number do not fall into the
predefined range instead of simply dropping the packets.
The operating model is the following:
o Stateless DS-Lite: for CPEs that pre-NAT and pre-shape the source
port space into the range assigned to the subscriber: decapsulate,
check per-subscriber mapping, forward.
o B4-translated DS-Lite: for CPEs that performs NAT before
encapsulation and are allocated a full IPv4 address: decapsulate,
check per-subscriber mapping, forward.
o Re-shaper DS-Lite: for CPEs that pre NAT but fail to restrict the
source ports: decapsulate, check per-subscriber mapping, re-NAT
statefully the packets into the restricted port range, mark range
as 'stateful', forward.
o Regular DS-Lite: for regular DS-Lite CPEs that do not pre-NAT:
decapsulate, NAT statefully, forward.
Penno, et al. Expires September 12, 2012 [Page 7]
Internet-Draft Stateless DS-Lite March 2012
In such a backward compatibility mode, the AFTR is only operating
statelessly for the stateless DS-Lite CPEs. It needs to maintain
per-flow state for the regular DS-Lite CPEs and the non-ICMP port
restricted compliant CPEs. In this legacy mode where per-flow state
is required, the simple anycast-based fail-over mechanism is no
longer available.
5. ICMP port restricted message
Note: this section may end-up being a separate Internet draft.
5.1. Introduction
In the framework of A+P RFC 6346 [RFC6346], sources may be restricted
to use only a subset of the port range of a transport protocol
associated with an IPv4 address. When that source transmit a packet
with a source outside of the pre-authorized range, the upstream NAT
will drop the packet and use the ICMP message defined here to inform
the source of the actual port range allocated.
This memo defines such ICMP messages for TCP and UDP and leaves the
definition of the ICMP option for other transport protocol for future
work.
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].
5.2. Source port restricted ICMP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min Port | Max Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Original Internet Headers + 64 bits of Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Source Port Restricted ICMP
Type: TBD for Source Port Restricted
Checksum: The checksum is the 16-bit ones's complement of the one's
complement sum of the ICMP message starting with the ICMP Type. For
Penno, et al. Expires September 12, 2012 [Page 8]
Internet-Draft Stateless DS-Lite March 2012
computing the checksum , the checksum field should be zero. This
checksum may be replaced in the future.
Code: 6 for TCP, 17 for UDP
Min Port: The lowest port number allocated for that source.
Max Port: The highest port number allocated for that source.
5.3. Host behavior
A host receiving an ICMP type TBD message for a given transport
protocol SHOULD NOT send packets sourced by the IP address(es)
corresponding to the interface that received that ICMP message with
source ports outside of the range specified for the given transport
protocol.
Packets sourced with port numbers outside of the restricted range MAY
be dropped or NATed upstream to fit within the restricted range.
A host MUST NOT take port restriction information applying to a given
IP address and transport protocol and applies it to other IP
addresses on other interfaces and/or other transport protocols.
If Min Port = 0 and Max Port = 65535, it indicates that the entire
port range for the given transport protocol is available. If such
'full range' messages are received for all transport protocols, the
host can take this as an indication that its IP address is probably
not shared with other devices.
In order to mitigate possible man in the middle attacks, a host MUST
discard ICMP type TBD messages if the associated port range (Max Port
- Min Port) is lower than 64.
6. IANA Considerations
IANA is to allocated a code point for this ICMP message type.
7. Security Considerations
This ICMP message type has the same security properties as other ICMP
messages such as Redirect or Destination Unreachable. A man-in-the-
middle attack can be mounted to create a DOS attack on the source.
Ingress filtering on network boundary can mitigate such attacks.
However, in case such filtering measures are not enough, the
additional provision that a host MUST discard such ICMP message with
Penno, et al. Expires September 12, 2012 [Page 9]
Internet-Draft Stateless DS-Lite March 2012
a port range smaller than 64 can mitigate even further such attacks.
As described in [RFC6269], with any fixed size address sharing
techniques, port randomization is achieved with a smaller entropy.
Recommendations listed in [RFC6302] applies.
8. References
8.1. Normative references
[I-D.ietf-dhc-dhcpv4-over-ipv6]
Lemon, T., Cui, Y., Wu, P., and J. Wu, "DHCPv4 over IPv6
Transport", draft-ietf-dhc-dhcpv4-over-ipv6-00 (work in
progress), November 2011.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
8.2. Informative references
[I-D.cui-softwire-b4-translated-ds-lite]
Boucadair, M., Sun, Q., Tsou, T., Lee, Y., and Y. Cui,
"Lightweight 4over6: An Extension to DS-Lite
Architecture", draft-cui-softwire-b4-translated-ds-lite-05
(work in progress), February 2012.
[I-D.ietf-pcp-base]
Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R.
Penno, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-23 (work in progress), February 2012.
[I-D.ietf-softwire-public-4over6]
Cui, Y., Wu, J., Wu, P., Metz, C., Vautrin, O., and Y.
Lee, "Public IPv4 over Access IPv6 Network",
draft-ietf-softwire-public-4over6-00 (work in progress),
September 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
Penno, et al. Expires September 12, 2012 [Page 10]
Internet-Draft Stateless DS-Lite March 2012
June 2011.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging Recommendations for Internet-Facing Servers",
BCP 162, RFC 6302, June 2011.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011.
Authors' Addresses
Reinaldo Penno
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA 94089-1206
USA
Email: rpenno@juniper.net
Alain Durand
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA 94089-1206
USA
Email: adurand@juniper.net
Alex Clauberg
Deutsche Telekom AG
GTN-FM4
Landgrabenweg 151
Bonn, CA 53227
Germany
Email: axel.clauberg@telekom.de
Penno, et al. Expires September 12, 2012 [Page 11]
Internet-Draft Stateless DS-Lite March 2012
Lionel Hoffmann
Bouygues Telecom
TECHNOPOLE
13/15 Avenue du Marechal Juin
Meudon 92360
France
Email: lhoffman@bouyguestelecom.fr
Penno, et al. Expires September 12, 2012 [Page 12]
