Stateless Source Address Mapping for ICMPv6 Packets
draft-ietf-v6ops-ivi-icmp-address-06

Network Working Group                                              X. Li
Internet-Draft                                                    C. Bao
Intended status: BCP                              CERNET Center/Tsinghua
Expires: March 15, 2013                                       University
                                                                 D. Wing
                                                        R. Vaithianathan
                                                                   Cisco
                                                               G. Huston
                                                                   APNIC
                                                      September 11, 2012

          Stateless Source Address Mapping for ICMPv6 Packets
                  draft-ietf-v6ops-ivi-icmp-address-06

Abstract

   A stateless IPv4/IPv6 translator may receive ICMPv6 packets
   containing non IPv4-translatable addresses as the source.  These
   packets should be passed across the translator as ICMP packets
   directed to the IPv4 destination.  This document presents
   recommendations for source address translation in ICMPv6 headers to
   handle 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 March 15, 2013.

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

Li, et al.               Expires March 15, 2013                 [Page 1]
Internet-Draft      Source Address Mapping for ICMPv6     September 2012

   (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.  Notational Conventions  . . . . . . . . . . . . . . . . . . . . 3
   3.  Problem Statement and Considerations  . . . . . . . . . . . . . 3
     3.1.  Considerations  . . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  Recommendations . . . . . . . . . . . . . . . . . . . . . . 4
   4.  ICMP Extension  . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Stateless Address Mapping Algorithm . . . . . . . . . . . . . . 4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6

Li, et al.               Expires March 15, 2013                 [Page 2]
Internet-Draft      Source Address Mapping for ICMPv6     September 2012

1.  Introduction

   [RFC6145] section 5.2 of the "IP/ICMP Translation Algorithm"
   document. states that "the IPv6 addresses in the ICMPv6 header may
   not be IPv4-translatable addresses and there will be no corresponding
   IPv4 addresses representing 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, Stateless Source Address Mapping for ICMPv6
   Packets, provides recommendations for this case.

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 and Considerations

   When a stateless IPv4/IPv6 translator receives an ICMPv6 message
   [RFC4443] (for example "Packet Too Big") sourced from an non-IPv4-
   translatable IPv6 address, bound for to an IPv4-translatable IPv6
   address, the translator needs to pick a source address with which to
   generate an ICMP message.  For the reasons discussed below, this
   choice is problematic.

3.1.  Considerations

   The source address used, should not cause the ICMP packet to be a
   candidate for discarding.  The possibility of uRPF filters in the
   path are a critical consideration [RFC3704] which precludes the use
   of private IPv4 address space [RFC1918] in this context.

   IPv4/IPv6 translation is intended for use in contexts where IPv4
   addresses may not be readily available, so it is not considered
   appropriate to assign IPv4-translatable IPv6 addresses for all
   internal points in the IPv6 network that may originate ICMPv6
   messages.

   Another consideration for source selection is that it be possible for
   the IPv4 recipients of the ICMP message to be able to distinguish
   between different IPv6 network origination of ICMPv6 messages, (for
   example, to support a traceroute diagnostic utility that provides
   some limited network level visibility across the IPv4/IPv6
   translator).  This consideration implies that an IPv4/IPv6 translator
   needs to have a pool of IPv4 addresses for mapping the source address

Li, et al.               Expires March 15, 2013                 [Page 3]
Internet-Draft      Source Address Mapping for ICMPv6     September 2012

   of ICMPv6 packets generated from different origins, or to include the
   IPv6 source address information for mapping the source address by
   others means.  Currently, the TRACEROUTE and MTR [MTR] are the only
   consumers of translated ICMPv6 messages that care about the ICMPv6
   source address.

3.2.  Recommendations

   The recommended approach to source selection is to use the a single
   (or small pool) of public IPv4 address as the source address of the
   translated ICMP message and leverage ICMP extension [RFC5837] to
   include IPv6 address as an Interface IP Address Sub-Object.

4.  ICMP Extension

   In the case of either a single public IPv4 address (the IPv4
   interface address or loopback address of the translator) or a pool of
   public IPv4 addresses, the translator SHOULD implement ICMP extension
   defined by [RFC5837].  The ICMP message SHOULD include the Interface
   IP Address Sub-Object, and specify the source IPv6 addresses of the
   original ICMPv6.  When an enhanced traceroute application is used, it
   can derive the real IPv6 source addresses which generated the ICMPv6
   messages.  Therefore, it would be able improve on visibility towards
   the origin rather than simply blackholing at or beyond the
   translator.  In the future, a new ICMP extension whose presence
   indicates that the packet has been translated and that the source
   address belongs to the translator, not the originating node can also
   be considered.

5.  Stateless Address Mapping Algorithm

   If a pool of public IPv4 addresses is configured on the translator,
   it is RECOMMENDED to randomly select the IPv4 source address from the
   pool.  Random selection reduces the probability that two ICMP
   messages elicited by the same TRACEROUTE might specify the same
   source address and, therefore, erroneously present the appearance of
   a routing loop.  An enhanced traceroute application is RECOMMENDED in
   order to obtain the IPv6 source addresses which generated the ICMPv6
   messages.

6.  Security Considerations

   This document recommends the generation of IPv4 ICMP messages from
   IPv6 ICMP messages.  These messages would otherwise have been
   discarded.  It is not expected that new considerations result from

Li, et al.               Expires March 15, 2013                 [Page 4]
Internet-Draft      Source Address Mapping for ICMPv6     September 2012

   this change.  As with a number of ICMP messages, a spoofed source
   address may result in replies arriving at hosts that did not expect
   them using the facility of the translator.

7.  IANA Considerations

   There is no consideration requested of IANA.

8.  Acknowledgments

   The authors would like to acknowledge the following contributors of
   this document: Kevin Yin, Chris Metz, Neeraj Gupta and Joel Jaeggli.
   The authors would also like to thank Ronald Bonica, Ray Hunter,
   George Wes, Yu Guanghui, Sowmini Varadhan, David Farmer, Fred Baker,
   Leo Vegoda, Joel Jaeggli, Henrik Levkowetz, Henrik Levkowetz, Randy
   Bush and Warren Kumari for their comments and suggestions.

9.  References

9.1.  Normative References

   [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.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC5837]  Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
              Rivers, "Extending ICMP for Interface and Next-Hop
              Identification", RFC 5837, April 2010.

   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", RFC 6145, April 2011.

Li, et al.               Expires March 15, 2013                 [Page 5]
Internet-Draft      Source Address Mapping for ICMPv6     September 2012

9.2.  Informative References

   [MTR]      "http://www.bitwizard.nl/mtr/".

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

   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 March 15, 2013                 [Page 6]
Internet-Draft      Source Address Mapping for ICMPv6     September 2012

   Geoff Huston
   APNIC

   Email: gih@apnic.net

Li, et al.               Expires March 15, 2013                 [Page 7]