[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[6bone] Network Address translation question
On 23 Jun 2005, at 15:50, Stig Venaas wrote:
> On Thu, Jun 23, 2005 at 03:42:51PM +0200, Stig Venaas wrote:
>> No idea. Don't know if any implementations allow it, and how is
>> implementation dependent. Would be quite interesting to know how
>> much of 3484 is implemented in different systems, and also how
>> to change policy if possible.
>> The most likely to have a way of installing policy is perhaps XP.
> I got the information below from Alan Ford <[email protected]>
> who is not on this list but. If you can help complete the survey,
> please mail him (or me and I will feed it back to him).
> FreeBSD 5.x: ip6addrctl(8), from KAME.
> Note: I can't get this to work, just trying to show the current table
> bales out with "sysctl(IPV6CTL_ADDRCTLPOLICY): Bad address" to me.
We're suspecting that the 5.2-RC1 box we have is a little
implementation-shy. 5.4 is installing as I type and will be used for
a couple of ULA-related policy tests.
> As far as I know, nothing is implemented by standard.
There's reference to a decision by folk at USAGI to go to source
address selection base on policy routing rather than 3484-style
labels. I've asked for clarification.
( http://www.linux-ipv6.org/ml/usagi-users/msg02929.html )
On the netdev list, there was some discussion - involving Pekka no
less - a couple of years back regarding kernel implementation of
( http://oss.sgi.com/projects/netdev/archive/2003-11/msg00340.html )
... and following that thread through reveals that Ulrich Drepper at
least instigated if not wrote a pass at RFC3484 sorting in glibc,
with the latest glibc as shipped with FC4 having the following natty
comment in ( glibc-20050524T1606/sysdeps/posix/getaddrinfo.c ):
/* XXX The system administrator should be able to install other
tables. We need to make this configurable. The problem is that
the kernel is also involved since it needs the same table. */
The source acknowledges the inability to apply rules 3 and 4 due to
only the kernel having the necessary information, and rule 7 due to a
lack of a user-space way of determining whether an address is
tunnelled or native.
It looks like all that is missing is the ability to change the
precedence ordering in glibc to get a passable implementation for our
needs in linux.
(Perhaps that was a bit of an aside - apologies if so)