[OpenAFS] Re: 1.6 clients: rx version pings
Mon, 5 Dec 2011 18:58:36 +0100
On Dec 5, 2011, at 14:59 , Gary Buhrmaster wrote:
> On Mon, Dec 5, 2011 at 02:58, Harald Barth <firstname.lastname@example.org> 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. 188.8.131.52
> and 184.108.40.206 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.
"Simply" making the feature work the way it was intended to is probably =
the best solution. If clients would only ping servers they actually have =
a business with, and did it only once every 20 seconds, I had never even =
A runtime switch to turn the pings off could still be useful if they do =
get in the way. A way to turn them off for a running client (with fs, or =
maybe even twiddle) would be even better - and would have saved me quite =
a bit of work.
> 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
> (*) Now that 220.127.116.11/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.
15738 Zeuthen, Germany