ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

2012-06-05 19:55:41
Hi,

On 6/3/2012 12:12 PM, Masataka Ohta wrote:
C. M. Heard wrote:

Existing routers, which was relying on ID uniqueness of atomic
packets, are now broken when they fragment the atomic packets.

Such routers were always broken.  An atomic packet has DF=0 and any
router fragmenting such a packet was and is non-compliant with
the relevant specifications (RFCs 791, 1122, 1812).

Thank you. I have overlooked that atomic implied DF=1.

But, then,

    >>  Sources emitting non-atomic datagrams MUST NOT repeat IPv4 ID
    values within one MSL for a given source address/destination
    address/protocol triple.

makes most, if not all, IPv4 hosts non compliant if MSL=2min.

This is already noted throughout this document, however there is little
impact to such non-compliance if datagrams don't persist that long.

Worse, without hard value of MSL, it is a meaningless
requirement. Note that MSL=2min derived from RFC793 breaks
150Mbps TCP.

It breaks at 6.4 Mbps for 1500 byte packets, as is already noted in the doc.

The proper solution, IMHO, to the ID uniqueness is to request
a destination host drop fragments from a source host after
it receives tens (or hundreds) of packets with different IDs
from the same source host.

That doesn't help ID uniqueness; it helps avoid fragmentation overload.
FWIW, such issues were discussed at length in the INTAREA WG when this
doc was developed.

A source host, then, is only required to remember the
previous ID used for each destination.

They don't do anywhere near that right now, but even if they did it
would still be prohibitive in speed (as per above).

Joe

<Prev in Thread] Current Thread [Next in Thread>