httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Adopting mod_remoteip to modules/metadata/ ?
Date Wed, 08 Apr 2009 23:19:43 GMT
Colm MacCárthaigh wrote:
> 
> I don't think permitting hostname/number is a good idea, because a
> hostname can map to multiple IPs, and it gets confusing, it's
> non-standard :-) Right now the code just does a single lookup, and uses
> that - so where there are multiple A/AAAA records we'll have random
> behaviour.

Very true.  I'm now walking that lookup and have coded to prohibit
namedhost/scope syntax.

> I'm not sure that I think hard-coding RFC1918 addresses is a good idea.
> RFC3330 is more authoratitive for a start, and there's no correspending
> code for IPv6 (e.g. the documentation prefixes, link-local scope,
> site-local scope, and so on).

Reviewing the 3330 list - these are mostly either 'normal' or 'returning
to normal' deviations from 1918.  All we really seek to dodge are well
defined shared IP spaces, so I simplified this a bit.

>From http://www.iana.org/assignments/ipv6-address-space there appears to
be one and only one sensical assignment, the Global Unicast per note [3].

> Either way, I think it's inaccurate to assume that there is anything
> special about RFC1918 space, the user should be forced to configure
> those ranges. Many networks have differing levels of trust and
> overlapping usages for that space, and many others use globally-unique
> IPs in private contexts.

Exactly.  This is why we partition trusted (internet peer) from internal
(1918 intranet peer).  The typical trusted host might give us one of their
private addresses, we cannot use that because it isn't partnered with our
own private address space.  If an internal, intranet peer presents us with
such a remote host, we simply accept it.

Let's say you grant some special security to 10. for your intranet.  We
never want trusted but external peers polluting that space, nor would we
want to consider 10.0.1.15 at one peer to be identical to 10.0.1.15 at
yet another peer.

> Looks cool though. We might need to add some docs warning peolpe that
> the address might no longer match the address family of the actual socket.

That's already true ;-)  But you are right, we should note that.  AIUI, all
IPv4-over-v6 addresses decode into v4 form already for remote_host lookups.

Bill

Mime
View raw message