rfc-6791

Stateless Source Address Mapping for ICMPv6 Packets

X. Li, C. Bao, D. Wing, R. Vaithianathan, G. Huston
date2012-11 streamIETF areaops wgv6ops statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc6791 doi10.17487/RFC6791
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. [STANDARDS-TRACK]

updates

Extracted elements (10)

design-rationale §3.1

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

ip, v6ops, nat

design-rationale §5

Random selection of IPv4 source address from a pool reduces the probability that two ICMP messages elicited by the same TRACEROUTE specify the same source address, which would erroneously present the appearance of a routing loop.

ip, v6ops

design-rationale §3.2

The recommended approach uses a single or small pool of public IPv4 addresses as the ICMP source and leverages RFC5837 ICMP extensions to include the original IPv6 source address, enabling traceroute visibility across the translator without requiring per-host IPv4 addresses.

ip, v6ops, nat

interoperability-note §3.1

Currently TRACEROUTE and MTR are the only consumers of translated ICMPv6 messages that care about the ICMPv6 source address; an enhanced traceroute application using RFC5837 extensions can recover the real IPv6 source addresses.

ip, v6ops

interoperability-note §1

This document updates RFC6145 by providing the stateless translation mechanism for ICMPv6 source addresses that RFC6145 Section 5.3 explicitly left as future work, covering the case where ICMPv6 source addresses are not IPv4-translatable.

ip, v6ops, nat

normative-requirement §5 RECOMMENDED

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 to reduce the probability of erroneously presenting the appearance of a routing loop in traceroute.

ip, v6ops, nat

normative-requirement §3.1 SHOULD NOT

The source address used for the translated ICMP message SHOULD NOT cause the ICMP packet to be discarded, and SHOULD NOT be drawn from RFC1918 or RFC6598 address space, because that space is likely subject to uRPF filtering.

ip, v6ops, nat

normative-requirement §4 SHOULD

The translator SHOULD implement the ICMP extension defined by RFC5837, and the ICMP message SHOULD include the Interface IP Address Sub-Object specifying the source IPv6 address of the original ICMPv6 message.

ip, v6ops, nat

protocol-element §4

The RFC5837 Interface IP Address Sub-Object is used within the translated ICMP message to carry the original IPv6 source address of the ICMPv6 packet, enabling reverse mapping by enhanced traceroute applications.

ip, v6ops

security-consideration §6

Translating ICMPv6 messages to IPv4 ICMP causes messages to be forwarded that would otherwise be discarded; a spoofed ICMPv6 source address may result in ICMP replies arriving at IPv4 hosts that did not expect them via the translator facility.

security, ip, v6ops