IPv6 Records on an IPv4 Network

Vyto Grigaliunas vyto at fnal.gov
Fri Jul 23 16:46:29 UTC 2010


Address selection configuration
In IPv6, each interface can have multiple addresses assigned to network and
tunneling interfaces intended for different purposes. For this reason,
RFC3484 provides a standardized method to choose source and destination IPv6
addresses with which to attempt connections. 


Indeed this RFC defines two algorithms: 


1) A destination address selection algorithm to sort the list of possible
destination addresses in order of preference. 


2) A source address selection algorithm to choose the best source address to
use with a destination address. 


This is implemented by the Operating System so applications do not need to
include their own address selection algorithms, reducing the development
burden on IPv6-capable applications. However, the algorithm can be
overridden by applications if either the source or destination address is
used rather its full qualified domain name (FQDN). 


In Windows XP, 2003 and Vista, to have administrative control over the
precedence of the source and/or destination addresses, the local prefix
policy table can be managed with the netsh command as follows: 


netsh interface ipv6 show prefixpolicy --> show the current local prefix
policy table 

netsh interface ipv6 add prefixpolicy --> add new entries in the local
prefix policy table 

netsh interface ipv6 set prefixpolicy --> set entries in the local prefix
policy table 

netsh interface ipv6 delete prefixpolicy --> delete entries in the local
prefix policy table 

Example 


C:\>netsh interface ipv6 show prefixpolicy 

Precedence Label Prefix 
5 5 2001::/32 
10 4 ::ffff:0:0/96 
20 3 ::/96 
30 2 2002::/16 
40 1 ::/0 
50 0 ::1/128 


The above prefix policy table shows the following: 


1) If native IPv6 is available on the host, any IPv6 destination has more
precedence than any IPv4 destination: 


10 4 ::ffff:0:0/96 ==> any IPv4 address (IPv4-mapped address) 
40 1 ::/0 ==> any IPv6 address 


2) If 6to4 is available on the host, any IPv6 destination has more
precedence than any IPv4 destination: 


10 4 ::ffff:0:0/96 ==> any IPv4 address (IPv4-mapped address) 
30 2 2002::/16 any 6to4 IPv6 address 


3) If Teredo is available on the host, any IPv4 destination has more
precedence than any IPv6 destination: 


5 5 2001::/32 ==> any Teredo IPv6 address 
10 40 ::ffff:0:0/96 ==> any IPv4 address (IPv4-mapped address) 


Changing the address selection precedence 


If you want to change the precedence of one prefix, for example Teredo
prefix over IPv4 addresses according to the above prefix policy table you
should use: 


C:\>netsh interface ipv6 set prefixpolicy prefix=2001::/32 precedence=15
label=5




> -----Original Message-----
> From: bind-users-bounces+vyto=fnal.gov at lists.isc.org [mailto:bind-
> users-bounces+vyto=fnal.gov at lists.isc.org] On Behalf Of Phil Mayers
> Sent: Friday, July 23, 2010 7:50 AM
> To: mayer at gis.net
> Cc: bind-users at lists.isc.org
> Subject: Re: IPv6 Records on an IPv4 Network
> 
> On 23/07/10 13:23, Danny Mayer wrote:
> > On 7/22/2010 11:33 AM, Phil Mayers wrote:
> >> On 22/07/10 12:19, Rock July wrote:
> >>> Windows Vista and 7 clients will query both type A and AAAA query
> even
> >>
> >> The OS might make the query, but the application will (should) be
> using
> >> getaddrinfo, and this will return the IPv4 addresses first, so it
> >> doesn't matter.
> >
> > This is untrue. IPv6 addresses are normally returned first though the
> > ordering depends on a) the order returned by the authorative
> nameserver
> > and b) by the resolving server and if it reorders the list returned.
> > There is no specific ordering of resource records specified in the
> > protocol and servers are free to order them in any way they want. It
> is
> > up to the application to specify what they need and to make decisions
> on
> > which ones they will use.
> 
> 
> Perhaps we are talking about two different things here?
> 
> Certainly there is no defined ordering of A versus AAAA records in DNS
> replies.
> 
> However, on Linux and Windows at least, the getaddrinfo C library call
> defaults to AI_ADDRCONFIG and RFC3484 address ordering rules; it does
> sort the results, and will present IPv4 results first if there is no
> local IPv6 global address present.
> 
> For example, in a Python interpreter session on a Windows XP machine:
> 
> 
>  >>> socket.getaddrinfo('wildfire.net.ic.ac.uk', 22)
> [(23, 0, 0, '', ('2001:630:12:1c2f:203:47ff:fee7:ddac', 22, 0, 0)), (2,
> 0, 0, '', ('155.198.51.19', 22))]
> 
>  >>> p = subprocess.call(['ipv6', 'uninstall'])
> 
>  >>> socket.getaddrinfo('wildfire.net.ic.ac.uk', 22)
> [(2, 0, 0, '', ('155.198.51.19', 22))]
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users




More information about the bind-users mailing list