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:

>> While your draft is rather harmful than useless, I'm fine
>> if the following point of the draft:
>>
>>      >>   Originating sources MAY set the IPv4 ID field of atomic
>>      datagrams to any value.
>>
>> is changed to:
>>
>>      >>   Originating sources MUST set the IPv4 ID field of atomic
>>      datagrams to values as unique as possible.
>>
>> which is what the current BSD implementations do.
> 
> There are implementations that set DF=1 and ID=0 (cellphones).

They are broken implementations violating RFC791.

To quote from RFC1122:

   1.2  General Considerations

      There are two important lessons that vendors of Internet host
      software have learned and which a new vendor should consider
      seriously.


      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"


         The second part of the principle is almost as important:
         software on other hosts may contain deficiencies that make it
         unwise to exploit legal but obscure protocol features.  It is
         unwise to stray far from the obvious and simple, lest untoward
         effects result elsewhere.  A corollary of this is "watch out
         for misbehaving hosts"; host software should be prepared, not
         just to survive other misbehaving hosts, but also to cooperate
         to limit the amount of disruption such hosts can cause to the
         shared communication facility.

it is obvious that your draft violates the robustness principle.

> BSD does not make IDs as unique as possible; it selects them according
> to a pseudorandom algorithm that does not take into account the
> datagram's source IP, destination IP, or protocol. I.e., BSD code
> repeats the IDs more frequently than necessary when a host concurrently
> sources datagrams with different (srcIP, dstIP, proto) tuples.

You merely mean BSD code does not try to make ID unique for
the longest possible MSL and the fastest possible packet rate,
which is not my point.

As the uniqueness is broken at some MSL and rate anyway, the
current code is enough to be "as unique as possible".

						Masataka Ohta


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