RFC 2893 Question - Ingress Filtering of IPv6-in-IPv4

["Follen, Stephen" <sfollen@enterasys.com>]

Title: Message

A question related to Ingress Filtering of decapsulated [tunneled] IPv6-in-IPv4 packets:

 

Section 3.6 of RFC 2893, IPv6 Transition Mechanisms, indicates that "... a decapsulated packet MUST NOT be forwarded unless the node has been explicitly configured to forward such packets ..." and in section 4.3 "The decapsulating node MUST verify that the tunnel source address is acceptable before forwarding decapsulated packets ..."

(the more recent draft-ietf-v6ops-mech-v2-00.txt, Basic IPv6 Transition Mechanisms provides similar guidance in sections 3.6, 3.9 and 4.1)

 

The question is what to do in the case that the packets are filtered / not forwarded:

 

1. silently drop the packet - simple, but provides no feedback of the "broken link" (see below);

 

2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a poor approach since

   (a) the IPv4 [tunnel endpoint] address was reached and

   (b) a response may never get back to the originating IPv6 host

       (section 3.4 of RFC 2893 indicates that an encapsulating node MAY generate

       a v6 ICMP when it gets a v4 ICMP back);

 

3. send a v6 ICMP DU - this probably won't get back to the originating host either since

    its unlikely that there's a path back to it (the do not forward decision occurred because

    the tunnel was not set up);

 

4. send a ICMPv6 DU encapsulated in IPv4 - there is enough information in the incoming

    IPv6-in-IPv4 packet to generate this, and it would likely get back to the originating host,

    but to do so would effectively send a packet via a tunnel which had not been configured.

 

"broken link" - [in the case of legitimate traffic] the filtering which would occur here is not

the result of a specifically configured ingress filter, rather, it is the result of not fully configuring

the tunnel; a tunnel is effectively a link, so I see the filtering to be similar to a broken link.

 

Any thoughts would be greatly appreciated.  - Thank you

 

Steve Follen

sfollen@enterasys.com