Professional Documents
Culture Documents
rfc6296 NAPT v6
rfc6296 NAPT v6
Wasserman
Request for Comments: 6296 Painless Security
Category: Experimental F. Baker
ISSN: 2070-1721 Cisco Systems
June 2011
Abstract
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is Address Independence? . . . . . . . . . . . . . . 4
1.2. NPTv6 Applicability . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Terminology . . . . . . . . . . . . . . . . . 7
2. NPTv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. NPTv6: The Simplest Case . . . . . . . . . . . . . . . . . 7
2.2. NPTv6 between Peer Networks . . . . . . . . . . . . . . . 8
2.3. NPTv6 Redundancy and Load Sharing . . . . . . . . . . . . 9
2.4. NPTv6 Multihoming . . . . . . . . . . . . . . . . . . . . 9
2.5. Mapping with No Per-Flow State . . . . . . . . . . . . . . 10
2.6. Checksum-Neutral Mapping . . . . . . . . . . . . . . . . . 10
3. NPTv6 Algorithmic Specification . . . . . . . . . . . . . . . 11
3.1. NPTv6 Configuration Calculations . . . . . . . . . . . . . 11
3.2. NPTv6 Translation, Internal Network to External Network . 12
3.3. NPTv6 Translation, External Network to Internal Network . 12
3.4. NPTv6 with a /48 or Shorter Prefix . . . . . . . . . . . . 12
3.5. NPTv6 with a /49 or Longer Prefix . . . . . . . . . . . . 13
3.6. /48 Prefix Mapping Example . . . . . . . . . . . . . . . . 13
3.7. Address Mapping for Longer Prefixes . . . . . . . . . . . 14
4. Implications of Network Address Translator Behavioral
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Prefix Configuration and Generation . . . . . . . . . . . 15
4.2. Subnet Numbering . . . . . . . . . . . . . . . . . . . . . 15
4.3. NAT Behavioral Requirements . . . . . . . . . . . . . . . 15
5. Implications for Applications . . . . . . . . . . . . . . . . 16
5.1. Recommendation for Network Planners Considering Use of
NPTv6 Translation . . . . . . . . . . . . . . . . . . . . 17
5.2. Recommendations for Application Writers . . . . . . . . . 18
5.3. Recommendation for Future Work . . . . . . . . . . . . . . 18
6. A Note on Port Mapping . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Why GSE? . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Verification Code . . . . . . . . . . . . . . . . . . 25
1. Introduction
For reasons discussed in [RFC2993] and Section 5, the IETF does not
recommend the use of Network Address Translation technology for IPv6.
Where translation is implemented, however, this specification
provides a mechanism that has fewer architectural problems than
merely implementing a traditional stateful Network Address Translator
in an IPv6 environment. It also provides a useful alternative to the
complexities and costs imposed by multihoming using provider-
independent addressing and the routing and network management issues
of overlaid ISP address space. Some problems remain, however. The
reader should consider the alternatives suggested in [RFC4864] and
the considerations of [RFC5902] for improved approaches.
The fact that NPTv6 does not map ports and is checksum-neutral avoids
the need for an NPTv6 Translator to rewrite transport layer headers.
This makes it feasible to deploy new or improved transport layer
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. NPTv6 Overview
NPTv6 can also be used between two private networks. In these cases,
both networks may use ULA prefixes, with each subnet in one network
mapped into a corresponding subnet in the other network, and vice
versa. Or, each network may use ULA prefixes for internal addressing
and global unicast addresses on the other network.
So, the value 0xD550 is written in the 16-bit subnet area, resulting
in a mapped external address of 2001:0DB8:0001:D550::1234.
So the value 0x0001 is written into the subnet field, and the
internal value of the subnet field is properly restored.
For example, if the internal prefix is a /48 ULA and the external
prefix is a /56 provider-allocated prefix, the ULA becomes a /56 with
zeros in bits 48..55. For purposes of one's complement arithmetic,
they are then both zero-extended to 64 bits. A side effect of this
is that a subset of the subnets possible in the shorter prefix is
untranslatable. While the security value of this is debatable, the
administration may choose to use them for subnets that it knows need
no external accessibility.
We then find the first word in the IID that does not have the value
0xFFFF, trying bits 64..79, and then 80..95, 96..111, and finally
112..127. We perform the same calculation (with the same proof of
correctness) as in Section 3.6 but apply it to that word.
Note: This mechanism does involve modification of the IID; it may not
be compatible with future mechanisms that use unique IIDs for node
identification.
Because NPTv6 does not perform port mapping and uses a one-to-one,
reversible-mapping algorithm, none of the other NAT behavioral
requirements apply to NPTv6.
Many, but not all, of the applications that are adversely affected by
NPTv6 Translation are those that do "referrals" -- where an
application instance passes its own addresses, and/or addresses of
its peers, to other peers. (Some believe referrals are inherently
undesirable; others believe that they are necessary in some
circumstances. A discussion of the merits of referrals, or lack
thereof, is beyond the scope of this document.)
7. Security Considerations
8. Acknowledgements
9. References
[NIST] NIST, "Draft NIST Framework and Roadmap for Smart Grid
Interoperability Standards, Release 1.0", September 2009.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O.
Troan, "Basic Requirements for IPv6 Customer Edge
Routers", RFC 6204, April 2011.
visibly doing so and would be well served by any solution that gives
them address independence without the overhead of RIR membership and
BGP routing.
In other words, the structure of the network should allow for and
enable appropriate access control, but the structure of the network
should not inherently limit access.
The point is to
/*
* Copyright (c) 2011 IETF Trust and the persons identified as
* authors of the code. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* - Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
*
* - Neither the name of Internet Society, IETF or IETF Trust, nor
* the names of specific contributors, may be used to endorse or
* promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include "stdio.h"
#include "assert.h"
/*
* program to verify the NPTv6 algorithm
*
* argument:
* Perform negative zero suppression: boolean
*
* method:
* We specify an internal and an external prefix. The prefix
* length is presumed to be the common length of both and, for
* this, is a /48. We perform the three algorithms specified.
* The "datagram" address is in effect the source address
* internal->external and the destination address
* external->internal.
*/
unsigned short inner_init[] = {
0xFD01, 0x0203, 0x0405, 1, 2, 3, 4, 5};
unsigned short outer_init[] = {
0x2001, 0x0db8, 0x0001, 1, 2, 3, 4, 5};
unsigned short inner[8];
unsigned short datagram[8];
unsigned char checksum[65536] = {0};
result = number1;
result += number2;
if (suppress) {
while (0xFFFF <= result) {
result = result + 1 - 0x10000;
}
} else {
while (0xFFFF < result) {
result = result + 1 - 0x10000;
}
}
return result;
}
/*
* One's complement difference
* return number1 - number2
*/
unsigned short
sub1(number1, number2)
unsigned short number1;
unsigned short number2;
{
return add1(number1, ~number2);
}
/*
* return one's complement sum of an array of numbers
*/
unsigned short
sum1(numbers, count)
unsigned short *numbers;
int count;
{
result = *numbers++;
while (--count > 0) {
result += *numbers++;
}
if (suppress) {
while (0xFFFF <= result) {
result = result + 1 - 0x10000;
}
} else {
while (0xFFFF < result) {
result = result + 1 - 0x10000;
}
}
return result;
}
/*
* NPTv6 initialization: Section 3.1 assuming Section 3.4
*
* Create the /48, a source address in internal format, and a
* source address in external format. Calculate the adjustment
* if one /48 is overwritten with the other.
*/
void
nptv6_initialization(subnet)
unsigned short subnet;
{
int i;
unsigned short inner48;
unsigned short outer48;
/*
/*
* NPTv6 datagram from transit to edge: Section 3.3 assuming
* Section 3.4
*
* Overwrite the prefix in the destination address with the
* inner prefix and adjust the checksum.
*/
void
nptv6_outer_to_inner()
{
int i;
/*
* Main program
*/
main(argc, argv)
int argc;
char **argv;
{
unsigned subnet;
int i;
if (argc < 2) {
fprintf(stderr, "usage: nptv6 supression\n");
assert(0);
}
suppress = atoi(argv[1]);
assert(suppress <= 1);
checksum[subnet] = 1;
/*
* The resulting checksum should be the same as the inner
* address's checksum.
*/
if (sum1(datagram, 8) != sum1(inner, 8)) {
printf("inner->outer incorrect: "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
inner[0], inner[1], inner[2], inner[3],
inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8),
/*
* The returning datagram should have the same checksum it
* left with.
*/
if (sum1(datagram, 8) != sum1(inner, 8)) {
printf("outer->inner checksum incorrect: "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
datagram[0], datagram[1], datagram[2], datagram[3],
datagram[4], datagram[5], datagram[6], datagram[7],
sum1(datagram, 8), inner[0], inner[1], inner[2],
inner[3], inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8));
}
/*
* And every octet should calculate back to the same inner
* value.
*/
for (i = 0; i < 8; i++) {
if (inner[i] != datagram[i]) {
printf("outer->inner different: "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x "
"inner: %x:%x:%x:%x:%x:%x:%x:%x\n",
datagram[0], datagram[1], datagram[2],
datagram[3], datagram[4], datagram[5],
datagram[6], datagram[7], inner[0], inner[1],
inner[2], inner[3], inner[4], inner[5],
inner[6], inner[7]);
break;
}
}
}
}
Authors' Addresses
Margaret Wasserman
Painless Security
North Andover, MA 01845
USA
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
EMail: [email protected]