6to4/SIT and IP DF

6to4/SIT and IP DF

[David Stevens]

I was trying out 6to4 and noticed that the v4 encapsulating header has DF
set, which RFC3056 says should not be set.

Because ICMPv4 won't, in general, include enough packet to determine the
original v6 sender, end-to-end PMTU won't work. The possible use I could
see is if the tunnel MTU is modified based on the PTMU (I didn't check),
but  that's probably not a good idea for any tunnels  that have "any" as
the remote v4 address. Doing that would force all MTU's to the lowest of
any v4 destination's path.

So, I think it's appropriate to always clear IP DF in the IPv4 header
generated by SIT, but I thought I'd see if anyone else has a comment on
that before I submit the trivial patch. :-)

Any thoughts?

            +-DLS

Re: 6to4/SIT and IP DF

[Pekka Savola]

On Tue, 14 Oct 2003, David Stevens wrote:
> I was trying out 6to4 and noticed that the v4 encapsulating header has DF
> set, which RFC3056 says should not be set.
> 
> Because ICMPv4 won't, in general, include enough packet to determine the
> original v6 sender, end-to-end PMTU won't work. The possible use I could
> see is if the tunnel MTU is modified based on the PTMU (I didn't check),
> but  that's probably not a good idea for any tunnels  that have "any" as
> the remote v4 address. Doing that would force all MTU's to the lowest of
> any v4 destination's path.
> 
> So, I think it's appropriate to always clear IP DF in the IPv4 header
> generated by SIT, but I thought I'd see if anyone else has a comment on
> that before I submit the trivial patch. :-)
> 
> Any thoughts?

Seems like a good idea.  The only thing I'm worried about is when someone
is attached to a network of at least 1500 MTU (at IPv6 level), and uses
6to4 -- then basically every IPv6 packet over 1480 bytes will be
fragmented in the network, even though it could potentially be chopped to
smaller pieces already in the end-nodes.

Just wondering how our 6to4 implementation handles this case at the 
moment..

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

Re: 6to4/SIT and IP DF

[David Stevens]

Pekka Savola writes:
>Seems like a good idea.  The only thing I'm worried about is when someone
>is attached to a network of at least 1500 MTU (at IPv6 level), and uses
>6to4 -- then basically every IPv6 packet over 1480 bytes will be
>fragmented in the network, even though it could potentially be chopped to
>smaller pieces already in the end-nodes.
>
>Just wondering how our 6to4 implementation handles this case at the
>moment..

The tunnel device does subtract the enscapsulating header, so v6-only PMTU
should work
up to the tunnel endpoint, and a v6 source should only generate 1480
(because that's what the
tunnel endpoint MTU would be) if the entire path is 1500.

But if the destination path is something less than the tunnel endpoint's
MTU, then I expect
every packet bigger than that PMTU would be fragmented. I'm concerned that
with DF set, as
it is now, every packet in that range would be dropped, if the IPv4
Frag-Needed-But-DF-Set (FNBDFS :-))
does not include enough v6 header & payload  to identify the v6 sender.

I haven't looked enough at the this code to see what's done (if anything)
with PMTU in this case--
for example, if it tries to adjust the tunnel endpoint MTU, or translate
the v4 PMTU to v6 when there
is enough included. Or trigger a v6 PMTU message based on a v4 route's PMTU
and not the
tunnel's MTU.

I really don't know what it does now for this case, and it may be good
already, or some of those
options may be more appropriate-- really just seeing if anyone's been
through this already. :-)
The technical violation of setting DF may be better than not setting it, if
the right goodies are
already there-- anybody know?

                  +-DLS

Re: 6to4/SIT and IP DF

[David S. Miller]

On Wed, 15 Oct 2003 00:15:21 -0700
David Stevens <dlstevens@us.ibm.com> wrote:

> I'm concerned that with DF set, as it is now, every packet in that
> range would be dropped, if the IPv4 Frag-Needed-But-DF-Set (FNBDFS :-))
> does not include enough v6 header & payload  to identify the v6 sender.

Who cares?  The PMTU as seen by the SIT tunnel is apsect of the IPV4
path not the IPV6 one.  IPV6 is merely communicating over a device
having a particular MTU.

When the ipv4 ICMP arrives, the IPV4 route to the other end of the SIT
tunnel is updated as appropriate.  (this is what the comment in sit.c
saying "Soft state for pmtu is maintained by IP core."  is talking
about)

After this, the next time something is attempted to be sent over the
SIT tunnel, we'll see the updated PMTU for the ipv4 route to the
SIT tunnel destination and act accordingly.

If the IPV6 packet is too big for this new IPV4 PMTU, the SIT driver
will emit an ICMPV6_PKT_TOOBIG icmp6 message back to the ipv6 packet's
origin.  It's this piece of code in sit.c:ipip6_tunnel_xmit():

        if (skb->len > mtu) {
                icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, dev);
                ip_rt_put(rt);
                goto tx_error;
        }

In short I think all of the cases you're mentioning are taken care
of just fine.

Re: 6to4/SIT and IP DF

[David Stevens]

That doesn't sound terrible, but won't it have to drop a minimum of
2 packets per tunnel on an MTU change (or initial probe with a large
packet)?

So, it wouldn't be a good idea to connect multiple v6 clouds in series,
with
6to4 tunnels between them and decreasing MTU's and then try to send a
large packet from one end to the other; you might run out of retransmits
before
you get to the other end. :-)

But using v4 PMTU info is probably almost always better than fragmenting
everything. A "fragment, but tell me about it" ICMP message would come in
handy here. And a requirement that ICMPv4 with tunnels include encapsulated
headers +8.

Thanks, Dave,
                  +-DLS

Re: 6to4/SIT and IP DF

[David S. Miller]

On Wed, 15 Oct 2003 22:21:37 -0700
David Stevens <dlstevens@us.ibm.com> wrote:

> That doesn't sound terrible, but won't it have to drop a minimum of
> 2 packets per tunnel on an MTU change (or initial probe with a large
> packet)?

Welcome to the real world where most routers don't quote enough
information.  :) What we do is the only sane way to handle this
problem.

All of our ipv4 tunnels work this way due to that quoting size issue.

The "fragment but tell me about it" isn't such a great idea.  You'll
run into all kinds of difficult decisions about behavior in the cases
where a too-big packet overruns multiple hops on the path.  This is why
the original implementors didn't put this into the RFCs.