Subject: RE: 6to4 default MTU [was Re: (ngtrans) 6to4 MRU - need WG consensus]

From: "Tony Hain" <[email-masked]>
Date: Tue, 10 Sep 2002 08:44:10 -0700

kre wrote:
> Actually, no it isn't, and this is the point.   Packets 
> exceeding the MRU
> generally just get dropped (unless something implements the 
> idea that Christian suggested, which currently, I know of 
> nothing that does). No ICMP gets sent back.
> 
> That is, PMTUD doesn't find this problem, what happens is a 
> black hole.

An apparently false assumption on my part was that implementations had a
black-hole detector tied to their PMTU discovery process. At least for
TCP the stack should know that the small packets through SYN-ACK worked,
so if large ones are failing, it would seem logical to shrink them
before trying again, then try to grow them over time. 

Short of that, I agree it makes the most sense to require a 6to4
receiver to send an IPv6 MTU exceeded message when reassembly fails due
to size. It will have the necessary information, and as a router its job
is to inform the upstream node when a link capacity is being exceded.
The unusual aspect of this case is that the link is a logical one inside
the router between IPv4 and IPv6, and the failure notice is coming from
the inbound IPv6 interface rather than an outbound one. The more I think
about it, this would be a reasonable requirement for all inbound IPv6
interfaces, because we may end up with the same kinds of MTU/MRU
mismatch issues we found with FDDI-Ethernet bridges as we move into gigE
...

Tony

---

From: Robert Elz <[email-masked]>
Date: Wed, 11 Sep 2002 15:41:39 +0700

Date:        Tue, 10 Sep 2002 08:44:10 -0700
    From:        "Tony Hain" <[email-masked]>
    Message-ID:  <036601c258e0$e83dd480$011aa8c0@eagleswings>

  | An apparently false assumption on my part was that implementations had a
  | black-hole detector tied to their PMTU discovery process.

One might hope that they do, but it isn't a nice way of discovering the
PMTU, so I don't think that's something that anyone would want to depend
upon working.   That is, I don't think I'd be increasing the MTU of a
tunnel, and just hoping that all of the users' implementations will do
the right thing if the tunnel recipient happens to discard the packet -
sticking at the guaranteed working MTU would be the safe approach.

  | Short of that, I agree it makes the most sense to require a 6to4
  | receiver to send an IPv6 MTU exceeded message when reassembly fails due
  | to size.

That's basically Christian's idea, and is fine - but requires that
the 6to4 implementation can get inside the IPv4 fragmentation code,
which isn't always going to be possible.   But I'd expect that should
not be a problem on any node that can't just allow a "reasonable"
reassembly buffer size (MRU).   Which is why I believe a mandated MRU
in the 4K area (like 4664) should cause no problems.

  | It will have the necessary information, and as a router its job
  | is to inform the upstream node when a link capacity is being exceded.

Yes, though 6to4 can also be done in nodes that one wouldn't normally
consider to be routers and so for which access to much of this kind of
info isn't always easy to get.

  | The unusual aspect of this case is that the link is a logical one inside
  | the router between IPv4 and IPv6, and the failure notice is coming from
  | the inbound IPv6 interface rather than an outbound one.

yes, if the packet (conceptually) ever gets that far.   Usually in this
situation, that IPv6 is being carried inside the v4 packet won't even have
been noticed when the packet is discarded.   Rather, either the v4 frag offset
plus packet length of an incoming frag will total more than the max
permitted packet to be reassembled, and the thing will simply be discarded,
along with any other frags for the same packet that happened to be in
the queue already (ie: obviously too big, don't waste time on it).

  | The more I think
  | about it, this would be a reasonable requirement for all inbound IPv6
  | interfaces, because we may end up with the same kinds of MTU/MRU
  | mismatch issues we found with FDDI-Ethernet bridges as we move into gigE
  | ...

Yes, no problem with that, a "packet too big" whenever a packet that is
too bug has been detected.   No guarantees that it can always be implemented
though, some "smart" interfaces, detect that the packet is too big for the
buffer, perhaps count it (and maybe interrupt to indicate it happened) but
just discard the packet without giving the software a chance to see it at
all (if it was copied into RAM as it arrived, the next arriving packet is
liable to be copied into the same RAM, so you can't safely even look there).

kre