Subject: Re: kernel ip_randomid() and libc randomid(3) still "broken"
To: None <jonathan@DSG.Stanford.EDU>
From: Jun-ichiro itojun Hagino <itojun@itojun.org>
List: tech-net
Date: 11/27/2003 06:09:55
> But you *are* breaking IP. For purposes of IP reassembly counts, TTL
> *IS* still a time-to-live, not a hopcount.

	where in RFC791 can i find statement that TTL field has to be used for
	reassembly buffer management?  i don't see any, therefore i understand
	TTL field as the lifetime during transit (defined as "seconds" in the
	past, used as "hop count" in reality).  "internet system" in the
	following statement does not include the reass buffer in the
	destination node, i assume.

> Consider a gigabit pipe filled with NFS-over-UDP traffic, which isnt
> at all hard to achieve (merely moderately expensive). With 32kbyte RPC
> payloads, that's 32 RPCs per megabyte, or 3,200 RPCs per second.  Even
> with per-(src,dst) ip_Id allocation, IDs will wrap about 20 seconds.
> This already causes signficant pucker-factor amongst people who think
> about the numbers. 

	have you experienced the scenario in reality, ever?

itojun


---
  Time to Live:  8 bits

    This field indicates the maximum time the datagram is allowed to
    remain in the internet system.  If this field contains the value
    zero, then the datagram must be destroyed.  This field is modified
    in internet header processing.  The time is measured in units of
    seconds, but since every module that processes a datagram must
    decrease the TTL by at least one even if it process the datagram in
    less than a second, the TTL must be thought of only as an upper
    bound on the time a datagram may exist.  The intention is to cause
    undeliverable datagrams to be discarded, and to bound the maximum
    datagram lifetime.