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

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

 



Joe Touch wrote:

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

> The recommendation in this doc - that such sources MUST rate-limit - is
> to comply with the ID uniqueness requirements already in RFC791 that
> this doc does not deprecate - e.g., its use to support fragmentation.

It means that the uniqueness requirements must be loosened.

Another example is that, when route changes, routers
fragmenting atomic packets may change, which means rate
limiting does not guarantee ID uniqueness.

> We all recognize that there are plenty of non-compliant NAT boxes

Rest of my examples are plain routers, which has been fully
compliant.

>>    Is there some document provided to obsolete the following:
>>
>>      The IPv6 fragment header is present
>>
>>      when the source has received
>>      a "packet too big" ICMPv6 error message when the path cannot support
>>      the required minimum 1280-byte IPv6 MTU and is thus subject to
>>      translation
>>
>>    which is meaningless from the beginning, because length of
>>    IPv6 ID is 32 bit, from which it is impossible to generate
>>    unique IPv4 ID.
> 
> None of which I am aware.

There should be. May I volunteer?

						Masataka Ohta


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]