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.