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

[Fred Templin <ftemplin@iprg.nokia.com>]

On further consideration, isn't the situation here logically equivalent 
to the
case of  the filter occurring somewhere in the network between the IPv6 
source
and the tunnel decapsulator; for example, at a firewall? What do 
firewalls do
when they discard a packet due to filtering? I don't know this for 
certain, but
don't they simply do a silent discard w/no ICMP sent back to the source? In
any event, I don't see why the tunnel decapsulator should do anything
different. Your thoughts?

Fred
ftemplin@iprg.nokia.com

P.S. I could be wrong, but wouldn't sending back an ICMP DU run the risk
   of a reflection attack when the original packet uses a spoofed IPv6 
source
   address?


Follen, Stephen wrote:

> 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 <mailto:sfollen@enterasys.com>
>  
>  
>  
>