[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Sorry for letting this thread grow cold, but see below:

Pekka Savola wrote:

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)


In case 3) above, send an ICMPv6 DU to the originating source.

It might not get back, but may very well help the situation
in the decapsulator for the next time around...

Fred
ftemplin@iprg.nokia.com

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