Network Working Group X. Li
Internet-Draft C. Bao
Intended status: Informational CERNET Center/Tsinghua University
Expires: February 24, 2011 D. Wing
R. Vaithianathan
Cisco
August 23, 2010
Stateless Source Address Mapping Algorithm for ICMPv6 Packets
draft-xli-behave-icmp-address-01
Abstract
For stateless IPv4/IPv6 translator, it may receive ICMPv6 packets
containing non IPv4-translatable addresses as the source. This
document defines a stateless address mapping mechanism for source
address translation in ICMPv6 headers for such cases.
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). 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 February 24, 2011.
Copyright Notice
Copyright (c) 2010 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
Li, et al. Expires February 24, 2011 [Page 1]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Analysis of the Possible Approaches . . . . . . . . . . . . . 4
4.1. Configure IPv6 Routers Using IPv4-translatable
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Use Public IPv4 Addresses . . . . . . . . . . . . . . 4
4.1.2. Use RFC1918 Addresses . . . . . . . . . . . . . . . . 4
4.2. Perform Stateful Source Address Mapping for ICMPv6
Packets . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2.1. Use Public IPv4 Addresses . . . . . . . . . . . . . . 4
4.2.2. Use RFC1918 Addresses . . . . . . . . . . . . . . . . 4
4.3. Use Translator's Interface Address to Represent Source
Address for ICMPv6 Packets . . . . . . . . . . . . . . . . 5
4.4. Comparisons . . . . . . . . . . . . . . . . . . . . . . . 5
5. Stateless Source Address Mapping Algorithms for ICMPv6
Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Choosing an IPv4 /24 Address Block . . . . . . . . . . . . 6
5.1.1. Use Public IPv4 Addresses . . . . . . . . . . . . . . 6
5.1.2. Use RFC1918 Addresses . . . . . . . . . . . . . . . . 6
5.1.3. Ask IANA for allocating an IPv4 Well-Known Prefix . . 6
5.2. Design an Algorithm to Generate the Last Octet of IPv4
/24 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. Randomly Generate the Last Octet . . . . . . . . . . . 7
5.2.2. Copy Hop Count into Last Octet . . . . . . . . . . . . 7
5.2.3. Hashing of the IPv6 address to generate Last Octet . . 8
5.3. Recommendations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Li, et al. Expires February 24, 2011 [Page 2]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
1. Introduction
The IP/ICMP translation document of IPv4/IPv6 translation
[I-D.ietf-behave-v6v4-xlate] states that "the IPv6 addresses in the
ICMPv6 header may not be IPv4-translatable addresses and there will
be no corresponding IPv4 addresses represented of this IPv6 address.
In this case, the translator can do stateful translation. A
mechanism by which the translator can instead do stateless
translation is left for future work. " This document defines such a
mechanism.
2. Notational Conventions
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
3. Problem Statement
As shown in the following figure, IPv6 host (H6) and IPv4 host (H4)
can communicate via a stateless translator (XLATE). H6 is configured
with an IPv4-translatable IPv6 address while IPv6 routers (R2, R3 and
R4) are configured with non IPv4-translatable addresses.
------ ------
| IPv4 | -- ----- -- -- -- | IPv6 |
| host |--|R1|----|XLATE|----|R2|--|R3|--|R4|--| host |
| H4 | -- ----- -- -- -- | H6 |
------ | ------
|
IPv4 --->|<---IPv6
Figure 1: Example topology of stateless translation
If a packet sent by H4 exceeds the link MTU between R3 and R4, then
R3 will generate a "Packet Too Big" ICMPv6 error message. In this
case, the destination address is IPv4-converted address of H4 and the
source address is non IPv4-translatable address of R3. Due to path
MTU discovery requirement, the ICMPv6 MUST be translated to ICMP by
XLATE. It is clear that the IPv4 source addresses of the ICMP
packets translated by the translator SHOULD be valid IPv4 addresses
in order not to be dropped alone the path, but who sends the ICMP
error message is not as important as the content itself.
Li, et al. Expires February 24, 2011 [Page 3]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
4. Analysis of the Possible Approaches
4.1. Configure IPv6 Routers Using IPv4-translatable Addresses
Stateless translation can be used for scenarios 1, 2, 5 and 6
[I-D.ietf-behave-v6v4-framework] and all of these scenarios are
concerning "an IPv6 network". Except for the case when "an IPv6
network" has multiple translators using different IPv6 prefixes, the
network administrator can configure IPv6 routers using IPv4-
translatable addresses and therefore the translator can translate the
source addresses of ICMPv6 packets generated by IPv6 routers to valid
IPv4 addresses. There are two variations of this method to form
IPv4-translatable IPv6 addresses based on the algorithm defined in
[I-D.ietf-behave-address-format].
4.1.1. Use Public IPv4 Addresses
The IPv6 routers in "an IPv6 network" can be configured using IPv4-
translatable addresses, which are based on public IPv4 addresses. In
this case, public IPv4 addresses will be wasted, since all interfaces
of all IPv6 routers require IPv4-translatable addresses.
4.1.2. Use RFC1918 Addresses
The IPv6 routers in "an IPv6 network" can be configured using IPv4-
translatable addresses, which are based on [RFC1918] addresses. In
this case, there is no waste of public IPv4 addresses.
This method is similar to an IPv4 network when the infrastructure is
using [RFC1918] addresses.
4.2. Perform Stateful Source Address Mapping for ICMPv6 Packets
When translator receives ICMPv6 containing non IPv4-translatable
address as the source, the translator can do stateful translation.
There are two variations of the stateful translation.
4.2.1. Use Public IPv4 Addresses
The translator can treat ICMPv6 packets the same as the ordinary IPv6
packets and performs stateful translation. However, this will
consume public IPv4 addresses in the address pool if a lot of ICMPv6
packets are received.
4.2.2. Use RFC1918 Addresses
The translator can do stateful translation, but map the source
addresses of the ICMPv6 packets to [RFC1918] addresses. This method
Li, et al. Expires February 24, 2011 [Page 4]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
does not consume public IPv4 addresses for the ICMPv6.
4.3. Use Translator's Interface Address to Represent Source Address for
ICMPv6 Packets
The translator can map non IPv4-translatable source addresses of the
ICMPv6 packets to the interface address of the translator. This
method does not waste public IPv4 addresses and is used in
[I-D.xli-behave-ivi].
4.4. Comparisons
The current approaches have their own drawbacks:
1. Configuring IPv6 routers using IPv4-translatable addresses may
involve the renumbering of all the IPv6 interface addresses in
all routers. In addition, if public IPv4 addresses are used, it
is a waste of the address resource. The major problem is that if
multiple translators with multiple prefixes are used, there is no
way to do so, since IPv4-translatable IPv6 addresses are prefix
dependent.
2. Performing stateful source address mapping for ICMPv6 Packets can
be used in an environment when the translator operates in
combined stateless/stateful modes, or in stateful-only mode.
However, for stateless-only translator, performing stateful
source address mapping for ICMPv6 Packets is not worth the cost.
3. Using translator's interface address to represent source address
for ICMPv6 Packets is the simplest method. However, different
non IPv4-translatable addresses will be mapped to same IPv4
address. In the case of traceroute, it may be confused as a
routing loop.
Therefore, it is desirable to define a new mapping mechanism.
5. Stateless Source Address Mapping Algorithms for ICMPv6 Packets
Based on above analysis, the requirements of stateless source address
mapping for ICMPv6 Packets are:
1. The ICMP that is translated from ICMPv6 by translator SHOULD not
be dropped by the IPv4 routers. This implies the source address
of the ICMP SHOULD use valid IPv4 address. In addition, the
source address SHOULD follow the uRPF policy if it is configured.
Li, et al. Expires February 24, 2011 [Page 5]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
2. Since it is impossible to uniquely map arbitrary IPv6 addresses
to different IPv4 addresses and content in the ICMP message is
more important than who generating the content, a unique reverse
mapping from these IPv4 addresses to the original IPv6 addresses
is not critical.
3. Public IPv4 addresses SHOULD not be wasted.
4. If possible, the source address of the ICMP MAY indicate that it
is translated from non IPv4-translatable IPv6 address by the
translator.
5. If possible, different non IPv4-translatable IPv6 addresses MAY
have different IPv4 address representations for a specific
application.
Therefore, we can use a small IPv4 address block as a to represent a
group of non IPv4-translatable IPv6 addresses. The next question is
how big of this small IPv4 address block. Consider a traceroute
application, in order to identify different routers alone a path an
IPv4 /24 is a reasonable size, since the maximum value of hop count
is 256 in IPv6.
5.1. Choosing an IPv4 /24 Address Block
5.1.1. Use Public IPv4 Addresses
The network administrator can allocate a public IPv4 /24 for the
source address mapping of ICMPv6 packets. The advantage is that it
is totally under network administrator's control. However, it wastes
public IPv4 addresses and except the network operator of this
network, no body knows that they are the holder of non IPv4-
translatable IPv6 addresses.
5.1.2. Use RFC1918 Addresses
An IPv4 /24 can be allocated from [RFC1918] address block. There is
no waste of public IPv4 addresses. However, if the organization's
network also uses RFC1918's block, it may cause confusion. In
addition, except the network operator of this network, no body knows
that they are the holder of non IPv4-translatable IPv6 addresses.
5.1.3. Ask IANA for allocating an IPv4 Well-Known Prefix
Allocating an IPv4 /24 as Well-Known Prefix by IANA for mapping
source address in ICMPv6 packet has several advantages.
Li, et al. Expires February 24, 2011 [Page 6]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
o There is no waste of public IPv4 addresses, since same IPv4 /24
can be used for different networks.
o The Well-Known Prefix can be used to identify the IPv4 addresses
are actually mapped from non IPv4-translatable addresses via IPv4/
IPv6 translator.
5.2. Design an Algorithm to Generate the Last Octet of IPv4 /24
5.2.1. Randomly Generate the Last Octet
The translator can randomly generates the Last Octet of the /24
prefix for different non IPv4-translatable addresses as shown in the
following figure
0 8 16 24 32
----------------------------+----------
| Prefix | Random |
----------------------------+----------
Figure 2: Randomly generated Last Octet
However, in this case the translator may need to maintain some states
to ensure same non IPv4-translatable IPv6 address maps to same IPv4
address.
5.2.2. Copy Hop Count into Last Octet
Routers typically emit ICMPv6 packets with the same hop count. Thus,
as the ICMPv6 packet is routed through the network its hop count is
decreased. Hence, the translator can copy the "Hop Count" in the
IPv6 header of the ICMPv6 to the Last Octet as shown in the following
figure.
0 8 16 24 32
----------------------------+----------
| Prefix |Hop Count |
----------------------------+----------
Figure 3: Copy Hop Count into Last Octet
If the routers emit ICMPv6 packets with different hop counts, it may
Li, et al. Expires February 24, 2011 [Page 7]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
give the appearance of a routing loop to tools such as traceroute.
That minor side-effect in that particular case cannot be avoided
while still being stateless.
5.2.3. Hashing of the IPv6 address to generate Last Octet
Hashing of the IPv6 address to generate a 8 bit value which will be
used to generate the last octet.
0 8 16 24 32
----------------------------+----------
| Prefix |Hashing |
----------------------------+----------
Figure 4: Hashing of the IPv6 address to generate Last Octet
The advantages of this approach are: No need to maintain expensive
states, except hashing table which should be simple with minimal
memory usage and consume minimal CPU cycles. If the hashing function
is good and there are limited number of IPv6 routers (< 256) on the
IPv6 side of the network, we will get unique IPv4 addresses to map
the addresses of the IPv6 routers with O(1) lookup.
5.3. Recommendations
According to above discussion, we suggest asking IANA for an IPv4 /24
as a "Well-Known Prefix" and give the routing administrators option
to configure one of the approaches:
1. Random Approach.
2. "Hop Count" approach.
3. Hashing approach.
6. Security Considerations
None.
7. IANA Considerations
This memo asks IANA for an IPv4 /24 as a "Well-Known Prefix".
Li, et al. Expires February 24, 2011 [Page 8]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are
required, or if those assignments or registries are created during
the RFC publication process. From the author's perspective, it may
therefore be removed upon publication as an RFC at the RFC Editor's
discretion.
8. Acknowledgments
The authors would like to acknowledge the following contributors of
this document: Kevin Yin, Chris Metz and Neeraj Gupta.
9. References
9.1. Normative References
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-10 (work in progress),
August 2010.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-10 (work in progress), July 2010.
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-10 (work in progress),
August 2010.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in
progress), August 2010.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Li, et al. Expires February 24, 2011 [Page 9]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
9.2. Informative References
[I-D.xli-behave-ivi]
Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
CERNET IVI Translation Design and Deployment for the IPv4/
IPv6 Coexistence and Transition", draft-xli-behave-ivi-07
(work in progress), January 2010.
Authors' Addresses
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 10-62785983
Email: xing@cernet.edu.cn
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 10-62785983
Email: congxiao@cernet.edu.cn
Dan Wing
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
USA
Email: dwing@cisco.com
Li, et al. Expires February 24, 2011 [Page 10]
Internet-Draft Source Address Mapping for ICMPv6 August 2010
Ramji Vaithianathan
Cisco Systems, Inc.
A 5-2, BGL 12-4, SEZ Unit,
Cessna Business Park, Varthur Hobli
Sarjapur Outer Ring Road
BANGALORE KARNATAKA 560 103
INDIA
Phone: +91 80 4426 0895
Email: rvaithia@cisco.com
Li, et al. Expires February 24, 2011 [Page 11]