[6bone] Network Address translation question

[Mark Thompson]

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 <ajf101 at ecs.soton.ac.uk>
> 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.

> Linux:
>
>     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  
(s,d) sorting.
( 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)

Mark/