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

[Pekka Savola <pekkas@netcore.fi>]

Hi,

Thanks for bringing this up.  The RFC is under revision, and this thing 
should probably be specified in more detail.

There are two-three distinct cases here (I think):

 1) "node receives packets from an unknown ("unconfigured") tunnel 
endpoint"

  ==> the node should _not_ "acknowledge" the existence of the tunnel,
otherwise this could be used to probe the acceptable tunnel endpoint
addresses.  That is, node should either silently discard the packet, or
send an ICMPv4 Protocol Unreachable message.  (I guess that depends on
what happens when a node receives a packet of an unknown protocol --
whether it sends anything back or not.)

 2) "node receives packets from a configured tunnel endpoint, but from the 
wrong direction (e.g. "internal IP address" from the direction of the 
Internet), if that kind of policing is implemented/enabled.

  ==> silently discard, I think.

 3) "node receives packets through a valid tunnel which fail IPv6 ingress
filtering tests"

 ==> silently discard, I think (if ingress filtering fails, the error 
won't probably get back anyway)

On Thu, 28 Aug 2003, 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
>  
>  
>  
>  
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings