Re: kern/44943: 2002::/16 (6to4) addresses are preferred over native IPv6 transport]

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR misc/44943; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/44943: 2002::/16 (6to4) addresses are preferred over native
 IPv6 transport]
Date: Sat, 14 May 2011 17:25:43 +0000

 (not sent to gnats)
 
    ------
 
 From: George Michaelson <ggm%pobox.com@localhost>
 To: netbsd-bugs%netbsd.org@localhost
 Subject: Re: kern/44943: 2002::/16 (6to4) addresses are preferred over native
        IPv6 transport
 Date: Mon, 9 May 2011 00:31:07 +0000 (UTC)
 
 Ahem.
 
 I believe there is an RFC, or draft RFC expectation that tunnelled IP is 
 de-preferenced to native when both exist.
 
 So, NetBSD may not have that logic in kernel, but the RFCs specify that 
 if a longest-match rule is used, with weightings, you should be able to 
 avoid using 2002::/16 source IPs except when you have a working binding, 
 and are sending packets to a 2002::/16 destination address.
 
 I don't have the docs to hand, but skimming discussion on IETF v6 working 
 groups leads me to believe there is a pretty clear understanding you 
 shouldn't preference a 6to4 route if you have native V6.
 
 Is that kind of route preference ordering not something we would want in 
 NetBSD? Is there any way to weight preference in routes other than 
 longest match? If its longest match, then the order you apply route 
 statements might influence route preference, but there is this niggle in 
 my mind about INADDR_ANY and what source IP selection you wind up with..
 
 (reading http://www.ietf.org/rfc/rfc5014.txt makes me think Erik Nordmark 
 coded some of this in the socket() preferences section)
 
 -G