Subject: RE: IPv6 and Tiny Fragments

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 25 Nov 2005 00:53:37 -0800

Hi Janos,

I think that is the minimum Link MTU and not the smallest size non-last
fragment.

Can you point me to the RFC/ draft which says what you stated?

Thanks,
Vishwas
-----Original Message-----
From: Mohacsi Janos [mailto:[email-masked]] 
Sent: Friday, November 25, 2005 1:27 PM
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: IPv6 and Tiny Fragments

On Thu, 24 Nov 2005, Vishwas Manral wrote:

> Hi folks,
>
>
>
> I have been wondering how IPv6 will deal with the tiny fragment
attack,
> RFC1858.
>
>
>
> Is there a minimum non-last fragment size specified for IPv6? With so
> many extension headers a size of around 80bytes IP Header+ payload may
> not necessarily be right.
>

It is defined to be larger than 1280 octets.

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

>
>
> I think, we could specify something closer to 200 bytes, which would
> mean that we would certainly have the TCP header in the first
fragment.
> Thanks,
> Vishwas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 25 Nov 2005 11:41:53 +0200 (EET)

Hi,

> Can you point me to the RFC/ draft which says what you stated?

This is a good point.  Let me copy a part of Elwyn Davies's message on 
the list on September:

Date: Wed, 21 Sep 2005 23:14:26 +0100
From: Elwyn Davies <[email-masked]>
To: Bob Hinden <[email-masked]>, Brian Haberman <[email-masked]>
Cc: [email-masked]
Subject: Taking RFC2460 (base IPv6) spec to full standard - issues
outstanding
....
[outstanding issues in core IPv6 spec before moving to full standard]
?       Fragment reassembly algorithm - should explicitly forbid overlapped
         fragments and possibly require that non-final fragments are (say) at
         least 1024 bytes.

The minimum IPv6 fragment size is not specified AFAICT.

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

---

From: Stig Venaas <[email-masked]>
Date: Fri, 25 Nov 2005 10:46:54 +0100

> Can you point me to the RFC/ draft which says what you stated?

Yes, I believe that is the minimum link MTU. So, obviously one fragment
might be smaller. I haven't seen anything say which fragment (reasonable
that it is the last, but haven't seen anything saying it must be), and
nothing prohibiting leaving several fragments smaller.

Also, there is sadly nothing saying overlapping fragments are not
allowed.

Stig

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 25 Nov 2005 10:50:50 +0100 (CET)

On Fri, 25 Nov 2005, Pekka Savola wrote:

> This is a good point.  Let me copy a part of Elwyn Davies's message on the 
> list on September:
>
>

Let me copy my answer to question of Elwyn:

According the RFC2460 the minimal MTU must be 1280. So Each fragments -
except the last fragment packet should be at least 1280. - this is
implicitly written in RFC2460 spec: "The lengths of the fragments must be
chosen such that the resulting fragment packets fit within the MTU of the
path to the packets' destination(s)." I understand this, that each 
fragment packet should be aligned to MTU, which is at least 1280.

I think it is wise to make it more explicit.

Janos Mohacsi

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Nov 2005 11:54:37 +0100

> Also, there is sadly nothing saying overlapping fragments are not

I suppose people writing code are assumed to exercise common sense,
e.g. make the first fragment as large as possible and don't overlap
fragments. But neither is required to make reassembly work. (Nor
is out-of-order reception of fragments required.)

It isn't a requirement in the Internet that intermediate systems can
see the transport header, so none of this seems to me to be a bug
in RFC 2460. The Unfragmentable Part definition there seems correct
to me.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Nov 2005 11:54:55 +0100

I suppose people writing code are assumed to exercise common sense,
e.g. make the first fragment as large as possible and don't overlap
fragments. But neither is required to make reassembly work. (Nor
is in-order reception of fragments required.)

     Brian