On Mon, Dec 5, 2011 at 02:58, Harald Barth <h...@kth.se> wrote: ... > IMHO it should be disabled completely if there are no RFC1918 > interfaces on the client and enabled if there are such interfaces. > A command line flag to override in either direction would help > as well (for debugging, testing and strange deployments).
No RFC1918 addresses does not mean no NAT (for a lot of bad reasons, some providers used what was considered, at the time, to be unused IP address ranges for their local space. 1.1.1.0 and 1.2.3.0 are common examples(*), and some people took them as canon; and some places decided to overload their internal addresses too for historical (bad?) reasons (and with IPv4 address exhaustion pending, perhaps for some pragmatic reasons), and some providers reuse their internal address space again and again in different regions with multiple NAT gateways (and there is a proposal in the IETF to formalize a "shared transition space" of a /10 to avoid the RFC1918 conflicts)). And no RFC1918 address does not mean no stateful firewall (with (especially) UDP timeouts) in the path between the client and the server. The rx version pings deal with more than just a simple home RFC1918 address sharing gateway... "Real" networks are more complex and varied than any sort of idealized view of what a network could be. There are heuristics that attempt to determine if the user is behind a stateful firewall (and for most values, although not all, NAT uses stateful firewalls as part of the common implementation; but there are 1-to-1 NATs in use), and such detection (if such code would be contributed) might be a good determiner to decide if rx version pings could be optionally turned off on a particular path, at least until the next stateful firewall probe (network paths also change over time). Gary (*) Now that 1.0.0.0/8 have been assigned by IANA, APNIC is probably going to have to "reserve" a few of the worst offending /24s to avoid known issues. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info