IP Fragmentation

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Fri Aug 29 17:19:31 UTC 2008


On Fri, 29 Aug 2008 05:44:28 +0530, Glen Kent said:
> I understand, but the question is what if they dont?

If it's an alleged router, and it doesn't know how to frag a packet, it's
probably so brain-damaged that it can't send a recognizable 'Frag Needed'
ICMP back either.  At that point, all bets are off...

> What do standard implementations do if they send a regular IP packet
> (no DF bit set) and receive an ICMP dest unreachable - Fragmentation
> reqd message back? Do they fragment this packet and then send it out
> again with the MTU reported in the ICMP error message, or is the ICMP
> error message silently ignored?

A quick perusal of the current Linux 2.6 net/ipv4/icmp.c source says this

        case ICMP_FRAG_NEEDED:
                if (ipv4_config.no_pmtu_disc) {
                        LIMIT_NETDEBUG(KERN_INFO "ICMP: " NIPQUAD_FMT ": "
                                                 "fragmentation needed "
                                                 "and DF set.\n",
                                       NIPQUAD(iph->daddr));
                } else {
                        info = ip_rt_frag_needed(net, iph,
                                                 ntohs(icmph->un.frag.mtu),
                                                 skb->dev);

In other words, if we're configured to do PMTU discovery, we cut back the MTU,
and if PMTUD is disabled, we make a note in the kernel log that something odd
happened and keep going.  Note that it's by definition "odd", because if PMTUD
is disabled, we didn't *send* a packet with the DF bit set, so any ICMP error
complaining about a DF bit we didn't set is considered spurious.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20080829/7e85a8ad/attachment.sig>


More information about the NANOG mailing list