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

From: "Follen, Stephen" <[email-masked]>
Date: Thu, 28 Aug 2003 11:38:49 -0400

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
[email-masked]

---

From: "Jeroen Massar" <[email-masked]>
Date: Thu, 28 Aug 2003 18:40:20 +0200

-----BEGIN PGP SIGNED MESSAGE-----

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:

SixXS POPs have the following policy:
 - Unconfigured tunnels, thus if a 'tunnel' is not known
   to the POP return a proto 41 icmp unreachable (IPv4)
 - Configured tunnels, but with the wrong source prefix
   will return a IPv6 Administrative Filter. Note that
   if the OS of the POP doesn't support this it will
   be silently dropped, but that is currently only the
   case on of the POPs.

Thus the POPs cannot be used if they a tunnel is not configured.
And they can only be used then when the source prefix is correct
that is the prefix that was assigned to go over the tunnel.

Unfortunatly I know of a couple of tunnelbrokers that do
not filter based on source prefix allowing them to be used
for abusive means which cannot be tracked unless one checks
every hop's traffic stats and as these are unavailable...

Also read up in: http://ip6.de.easynet.net/ipv6-minimum-peering.txt
aka "Minimum Technical IPv6 Peering Requirements (MIPP)" by Robert Kiessling.

Greets,
 Jeroen

---

From: Fred Templin <[email-masked]>
Date: Thu, 28 Aug 2003 14:34:36 -0700

Are you suggesting perhaps that some additional specification is
needed in 'draft-ietf-v6ops-mech-v2-00.txt'?

Fred
[email-masked]

Follen, Stephen wrote:

> 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 
> 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:
>  
> 2. send a v4 ICMP, Destination Unreachable (DU) - this seems like a 
> poor approach since
>        (section 3.4 of RFC 2893 indicates that an encapsulating node 
> MAY generate
>     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 tunnel; a tunnel is effectively a link, so I see the filtering to 
> be similar to a broken link.
>  
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
>

---

From: Fred Templin <[email-masked]>
Date: Fri, 29 Aug 2003 13:34:45 -0700

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
[email-masked]

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?