One document matched: draft-tremblay-pt66ac-00.txt
Behavior Engineering for Hindrance J. Tremblay
Avoidance Videotron
Internet-Draft S. Beuker
Intended status: Standards Track Shaw Communications
Expires: May 29, 2011 November 25, 2010
Addressing bit compression for stateless IPv6 prefix translation
draft-tremblay-pt66ac-00
Abstract
This document describes a method to extend IPv6 prefix translation
[NAT66] to statelessly translate between IPv6 prefixes of differing
lengths. This technique, called PT66 addressing bit compression
(PT66-AC), provides a way to map a shorter prefix (such as the fixed
[6to4] prefix) to a longer global unicast prefix, while avoiding
stateful translation. The difference between the prefix lengths is
compensated for by removing an unused string of subnetting bits, as
specified, from the addresses within the shorter prefix.
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.
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 May 29, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Tremblay & Beuker Expires May 29, 2011 [Page 1]
Internet-Draft PT66-AC November 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IPv6 Translator Model . . . . . . . . . . . . . . . . . . . . 3
3. IPv6 Prefix Translation with Addressing Compression . . . . . 5
3.1. Configuration Elements . . . . . . . . . . . . . . . . . . 6
3.2. Egress Translation Behavior for Compressed Bits . . . . . 7
3.3. Ingress Translation Behavior for Compressed Bits . . . . . 7
3.4. Translator Operation . . . . . . . . . . . . . . . . . . . 7
3.4.1. Egress Traffic Operation . . . . . . . . . . . . . . . 7
3.4.2. Ingress Traffic Operation . . . . . . . . . . . . . . 8
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. 6to4 Subnet Compression . . . . . . . . . . . . . . . . . 8
4.2. 6to4 IPv4 and Subnet Compression . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Informative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Tremblay & Beuker Expires May 29, 2011 [Page 2]
Internet-Draft PT66-AC November 2010
1. Introduction
Since IPv6 has become a standard, multiple transition mechanisms have
been proposed to stimulate the rate of IPv6 adoption. Some of these
mechanisms use specific addressing space and fixed lengths for
different types of prefixes. There is sometimes a need to translate
a protocol-specific addressing space into global unicast space to
improve the routing behavior. Of course, this improvement to routing
comes at the cost of lowered interoperability for some applications.
One issue with translating these prefixes is the challenge of
obtaining a globally unique prefix of appropriate size. However,
there are often a number of bits rarely used within the transition
protocol specific prefixes. Using an address translator with
addressing bit compression allows a deployment to drop these unused
bits and make more efficient usage of the public addressing space.
For example, the IPv6 transition protocol [6to4] statelessly maps 32
bit IPv4 addresses into the 2002::/16 prefix, to create a /48 IPv6
prefix for every IPv4 address. Normally, return traffic destined to
this prefix will be routed to the nearest 6to4 relay router. An ISP
may wish to gain control over return routing of the 6to4 traffic by
mapping their 6to4 address space into a globally unique IPv6 prefix.
Implementing this without addressing bit compression would require an
IPv6 /32 for every /16 of IPv4 global space assigned to an ISP.
Acquiring the required IPv6 space from a Regional Internet Registry
is therefore unrealistic in most cases. Using addressing bit
compression, an ISP can make better use of the globally unique IPv6
space by reducing the size of the 6to4 subnet available to each user.
2. IPv6 Translator Model
The current stateless IPv6 prefix translation model is described in
[NAT66]. In that model, IPv6 traffic is translated between an
internal network and an external network.
Tremblay & Beuker Expires May 29, 2011 [Page 3]
Internet-Draft PT66-AC November 2010
An IPv6 translator model described in [NAT66]:
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
|
|
+---------+
| PT66 |
| Device |
+---------+
|
|
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
This translation model may be represented in a generic fashion by
replacing the address characters with letters denoting the function
of those address bits. The representation below describes a single
translation mapping in a device that may implement several.
L - Internal (or "Local") network IPv6 prefix
E - External network IPv6 prefix
N - Subnet bits
I - Interface Identifier (IID) bits
A generic IPv6 translator model
External Network Prefix = EEEE:EEEE:EEEE:NNNN:IIII:IIII:IIII:IIII
--------------------------------------
|
|
+---------+
| PT66 |
| Device |
+---------+
|
|
--------------------------------------
Internal Network Prefix = LLLL:LLLL:LLLL:NNNN:IIII:IIII:IIII:IIII
In this figure, L represents the Internal or Local prefix to be
translated to the External prefix bits E. The number of L bits is
equal to the number of E bits. Subnet bits N and Interface-ID bits I
Tremblay & Beuker Expires May 29, 2011 [Page 4]
Internet-Draft PT66-AC November 2010
are not changed by the translator.
3. IPv6 Prefix Translation with Addressing Compression
It is implicit that any basic [NAT66] mapping must be between
prefixes of the same size, as each prefix of is overwritten by the
other as traffic passes through. The section below gives a
description of how to map internal and external networks of different
lengths. In this example, the internal prefix used is a larger /28,
while the external prefix used is a smaller /40.
L - Local or Internal network IPv6 prefix
E - External network IPv6 prefix
S - Shifted subnet bits
N - Unmodified subnet bits
C - Compressed (removed) bits
I - Interface Identifier (IID) bits
Generic Prefix Translator Model with Addressing Compression
External Network Prefix = EEEE:EEEE:EESS:SSSN:IIII:IIII:IIII:IIII
--------------------------------------
|
|
+----------+
| PT66-AC |
| Device |
+----------+
|
|
--------------------------------------
Internal Network Prefix = LLLL:LLLS:SSSS:CCCN:IIII:IIII:IIII:IIII
In this translation model, the N bits (4 bits represented) from the
internal subnet are left untouched. The C bits (12 bits represented)
are the compressed bits, not present in the external network prefix.
The S bits (20 bits represented) are bitwise shifted to the right by
the length of the C bits when translating from the internal network
to the external network. This compression of the subnet allows for
the adaptation from the larger prefix to the smaller prefix to be
made. The L bits (28 bits represented) are replaced by the E bits
Tremblay & Beuker Expires May 29, 2011 [Page 5]
Internet-Draft PT66-AC November 2010
(40 bits represented) when translating from the internal network to
the external network.
In this document, traffic received on the internal network interface
and forwarded by the external traffic interface is called egress
traffic. Inversely, any traffic received on the external network
interface and forwarded to the internal network interface is called
ingress traffic.
3.1. Configuration Elements
The IPv6 prefix translation with addressing compression model
(PT66-AC) makes use of the following variables:
L Length of the internal network prefix
E Length of the external network prefix
S Number of shifted bits
C Number of compressed bits
N Number of unchanged subnet bits
In order to avoid confusion and increase readability, both the full
name and variable notation of the above parameters are used
throughout this document.
In this translation model, the sum of the length of the internal
network prefix (L), of the number of shifted bits (S), of the number
of compressed bits (C) and of the number of unchanged bits (N) always
equals 64 (L + S + C + N = 64). As well, the sum of the length of
the external network (E), of the number of shifted bits (S) and of
the number of unchanged bits (N) always equals 64 (E + S + N = 64).
Hence the number of compressed bits (C) is always equal to the length
of the external prefix minus the length of the local prefix (C = E -
L). Only the length of each prefix need be defined, and the length
of the compressed bits (C) can be derived from those values.
Similarly, in order to know the number of shifted bits (S) and
unchanged bits (N), one of these two must be defined in the
configuration of the translation mapping. Therefore, the elements
that must be defined in a translation mapping with compression are
the internal network prefix and its length (L), the external network
prefix and its length (E) and either the number of shifted bits (S)
or unchanged bits (N).
With these configuration elements defined for each translation
Tremblay & Beuker Expires May 29, 2011 [Page 6]
Internet-Draft PT66-AC November 2010
mapping, an IPv6 translator can statelessly translate ingress and
egress traffic between prefixes of differing length.
3.2. Egress Translation Behavior for Compressed Bits
The value of the bits compressed is hereto referred to as the
'compressed bit pattern'. By default, any egress traffic MUST be
dropped if the compressed bit pattern is not equal to zero.
Optionally, a compressed bit pattern different from all zeros may be
defined by configuration and used to filter incoming traffic. The
compressed bit pattern length MUST be equal to the difference between
the length of the external prefix and the length of the internal
prefix (C must equal E - L).
The translation device SHOULD issue an ICMP type 1 (Destination
Unreachable) message with code 5 (Source address failed ingress/
egress policy) to the source address when dropping traffic for the
first time for each source address/destination address pair.
3.3. Ingress Translation Behavior for Compressed Bits
For traffic entering the external network interface of the
translator, the compressed bits MUST be restored with zeros by
default, unless a different compressed bit pattern has been
configured for the mapping. In such a case, the user-defined
compressed bit pattern MUST be used to restore the compressed bits.
3.4. Translator Operation
For traffic entering the external network interface of the
translator, the compressed bits MUST be restored with zeros by
default, unless a different compressed bit pattern has been
configured for the mapping. In such a case, the user-defined
compressed bit pattern MUST be used to restore the compressed bits.
3.4.1. Egress Traffic Operation
For each egress packet, the prefix translator MUST use the
appropriate translation mapping with the longest matching internal
prefix. The S bits of the IPv6 source address are shifted bitwise to
the right by the number of compressed bits (C). The leftmost bits of
the source address (L) are replaced by the bits of the external
network prefix (E). Unchanged bits (N) of the source address MUST
NOT be modified.
Tremblay & Beuker Expires May 29, 2011 [Page 7]
Internet-Draft PT66-AC November 2010
3.4.2. Ingress Traffic Operation
For each ingress packet, the prefix translator MUST use the
appropriate translation mapping. Selection of the appropriate
mapping is outside of the scope of this document. The behavior of
the translator when no mapping is matched is also out of scope for
this document. Asynchronous mappings between internal and external
prefixes, where an ingress source address translated does not in turn
translate back to the same destination address on egress traffic,
SHOULD be prevented.
Once a suitable mapping is found, the leftmost bits of the
destination address are replaced by the corresponding bits from the
local network prefix (L). Starting at the bit position equal to the
length of the external prefix (E), the Shifted bits are bitwise
shifted to the left by the number of compressed bits (C). The C bits
are restored with zeros, or the compressed bit pattern if set in the
mapping configuration. Unchanged bits (N) of the destination address
MUST NOT be modified.
4. Examples
4.1. 6to4 Subnet Compression
When an IPv6 prefix translator is used with a 6to4 prefix as the
internal network, it is possible to compress seldom-used subnet bits
in order to reduce the size of the external global unicast prefix.
As specified in [6to4], a 6to4 router will define a /48 for each IPv4
global unicast address. This provides 16 bits of subnet addressing
available to the user. The 6to4 protocol being often implemented by
residential gateways, only one LAN subnet (/64) is utilized in most
implementations. It is therefore possible to reduce the number of
available /64 subnets available from 65536 (16 bits) to 16 (4 bits)
or even a single one (0 subnet bits). The following example
compresses the 16 subnet bits to 4 bits, leaving room for 16 /64
subnets.
The prefix translation model for 6to4 is similar to the generic
model, with the internal network bits (L) being defined as 2002::/16.
The 32 bits of the 6to4 router IPv4 address are the shifted bits (S).
This example uses 192.0.2.1 as the 6to4 router IPv4 address and 2001:
DB0::/28 as the provider global unicast prefix. A single subnet
number 0001 is used. A single host exchanges traffic from Interface
ID ::A.
Tremblay & Beuker Expires May 29, 2011 [Page 8]
Internet-Draft PT66-AC November 2010
External Network Prefix = EEEE:EEES:SSSS:SSSN:IIII:IIII:IIII:IIII
2001:0DBC:0000:2011:0000:0000:0000:000A
--------------------------------------
|
|
+----------+
| PT66-AC |
| Device |
+----------+
|
|
--------------------------------------
Internal 6to4 Prefix = LLLL:SSSS:SSSS:CCCN:IIII:IIII:IIII:IIII
2002:C000:0201:0001:0000:0000:0000:000A
In this example, the ISP configures the PT66-AC with the following
mapping: 2002::/16, 2001:DB0::/28, C=12 (or N=4)
During operation, egress traffic from address 2002:C000:0201:1::A is
translated as follow:
2002:C000:0201:0001::A Egress packets source address
2002:C00C:0000:2011::A Shift S bits (32 bits) to the right
by C bits (12 bits)
2001:0DBC:0000:2011::A Replace L bits by E bits. This is the new
egress source address.
The inverse operations takes place for ingress traffic with
destinations within 2001:db0::/28:
2001:0DBC:0000:2011::A Incoming destination address
2002:0DBC:0000:2011::A Leftmost bits are replaced by the L bits
(16 bits)
2002:C000:0201:2011::A The 32 S bits are shifted to the left
by C bits (12 bits)
2002:C000:0201:0001::A The C bits are restored. This is the new
destination address on the local network
This example demonstrated how to compress the 12 first bits of the
6to4 subnet bits in order for an ISP to use a longer global unicast
prefix for the external network.
4.2. 6to4 IPv4 and Subnet Compression
As an improvement over the previous example, the ISP also has the
opportunity to compress the IPv4 prefix part of the IPv4 address in
the 6to4 prefix. That information is redundant, because it can be
Tremblay & Beuker Expires May 29, 2011 [Page 9]
Internet-Draft PT66-AC November 2010
recovered from the mapping when translating ingress traffic.
Omitting this allows the ISP to use an even smaller prefix on the
external interface.
This example is similar the previous one, with the addition that the
IPv4 prefix 192.0.2.0/24 will also be compressed. The external
prefix used by the ISP is now 2001:db8:FFFF:F000::/52. The 6to4
subnet remains compressed from 16 to 4 bits.
A translation mapping is configured as follow: 2002:C000:0200::/40,
2001:0DB8:FFFF:F000::/52, C=12 (or N=4)
External Network Prefix = EEEE:EEEE:EEEE:ESSN:IIII:IIII:IIII:IIII
2001:0DB8:FFFF:F011:0000:0000:0000:000A
--------------------------------------
|
|
+----------+
| PT66-AC |
| Device |
+----------+
|
|
--------------------------------------
Internal 6to4 Prefix = LLLL:LLLL:LLSS:CCCN:IIII:IIII:IIII:IIII
2002:C000:0201:0001:0000:0000:0000:000A
Egress operation:
2002:C000:0201:0001::A Egress packets source address
2002:C000:0201:0011::A Shift S bits (8 bits) to the
right by C bits (12 bits)
2001:0DB8:FFFF:F011::A Replace L bits by E bits. This
is the new egress source address.
Tremblay & Beuker Expires May 29, 2011 [Page 10]
Internet-Draft PT66-AC November 2010
Ingress operation for destinations within 2001:db8:FFFF:F000::/52:
2001:0DB8:FFFF:F011::A Incoming destination address
2002:C000:02FF:F011::A Leftmost bits are replaced
by the L bits (40 bits)
2002:C000:0201:F011::A The S bits (8 bits) are shifted to
the left by C bits (12 bits)
2002:C000:0201:0001::A The C bits are restored. This is the
new destination address on local network
This example demonstrates that both the IPv4 addressing and the
subnet parts of a 6to4 prefix can be compressed. It is therefore
possible to translate a provider's own 6to4 addressing subset (from
its own global IPv4 unicast space) to a set of global IPv6 unicast
prefixes that are small enough not to require an extremely large IPv6
global unicast assignment.
The resulting IPv6 unicast prefixes are also completely decoupled
from IPv4 and avoid the need for injection of IPv4 routing
information in the IPv6 routing table in order to achieve better
routing.
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
All of the security considerations of [NAT66] are still applicable
when address bit compression is applied. The stateless address
mapping of NAT66 allows for direct inbound connections to internal
nodes, something not present in NAT44.
In addition, an implementation of NAT66 with addressing bit
compression must be aware of the potential for a DOS attack against
the device by an internal node intentionally sending packets that do
not match the compressed bit pattern. This would force the
generation of ICMP unreachable messages to the source address, which
could be spoofed, and could potentially impact the operation of both
the NAT66 device and the legitimate user of the spoofed source
address. For this reason, it is recommended that the rate of ICMP
unreachable messages generated is limited.
Tremblay & Beuker Expires May 29, 2011 [Page 11]
Internet-Draft PT66-AC November 2010
Another possibility of resource exhaustion is to receive packets on
an interface that doesn't have any mapping for the source or
destination. For example, traffic with an internal destination
coming on the outside interface. Such traffic SHOULD be silently
dropped.
7. Acknowledgements
Thanks to the following people (in alphabetical order) for their
participation and review:
Victor Kuarsingh, Rogers Communications
Yiu Lee, Comcast
8. Informative References
[NAT66] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address
Translation (NAT66)", November 2008.
Appendix A. An Appendix
Authors' Addresses
Jean-Francois Tremblay
Videotron
150 Beaubien Ouest
Montreal, Quebec H2V 1C4
Canada
Email: jf@jftremblay.com
Scott Beuker
Shaw Communications
200 - 3636 23rd St NE
Calgary, Alberta T2E 8Z5
Canada
Email: Scott.Beuker@sjrb.ca
Tremblay & Beuker Expires May 29, 2011 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 09:41:31 |