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

Re: [RRG] Re: [RAM] Tunneling overheads and fragmentation



On 9/12/07, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> I just re-read RFC 2460 section 5. Admittedly things are less
> clear for IPv4, but it seems clear that IPv6 senders should not
> exceed 1280 bytes (pre-encapsulation) unless they have succeeded
> in discovering a larger path MTU.

Hi Brian,

Hmm. I read it and it says, "a minimal IPv6 implementation [...] MAY
simply restrict itself to sending packets no larger than 1280 octets
and omit implementation of Path MTU Discovery." Then it strongly
recommends RFC1981.

Section 4 of RFC1981 describes a similar PMTUD as IPv4 except for:

"After receiving a Packet Too Big message, a node MUST attempt to
avoid eliciting more such messages in the near future. [...] Since
each of these messages (and the dropped packets they respond to)
consume network resources, the node MUST force the Path MTU Discovery
process to end. [...] An attempt to detect an increase (by sending a
packet larger than the current estimate) MUST NOT be done less than 5
minutes after a Packet Too Big message has been received for the given
path."

This suggests that after receiving a Packet Too Big it should drop the
MTU to 1280 and then later try to step it back up until it reaches the
real path MTU. The RFC without the snips kind of has a roundabout way
of saying it, though.

Other portions of text in the same document imply half a dozen
different ways that a Packet Too Big message that doesn't make sense
should be treated as a DOS and discarded. What does a host do if it
sees a Path Too Big message containing a packet it couldn't have sent?

Here's one:

"A node MUST NOT increase its estimate of the Path MTU in response to
the contents of a Packet Too Big message.  A message purporting to
announce an increase in the Path MTU might be a stale packet that has
been floating around in the network, a false packet injected as part
of a denial-of-service attack, or the result of having multiple paths
to the destination, each with a different PMTU."

I interpret this to mean that if the host sends a 1490 byte packet and
receives a "Packet Too Big" message reporting a PMTU of 1500 bytes,
the host will completely ignore the message treating it as if it had
not been received.

I didn't find anything in section 5 saying what to do if you try to
step up the PMTU and don't receive any message in return. I think it
might die a flaming death since PMTUD happens at a level that's
divorced from the higher-level retransmission algorithms.

I wonder how all of this has actually been implemented in the deployed
IPv6 stacks.

Regards,
Bill Herrin



-- 
William D. Herrin                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg