Summary and Status of Default Address Selection for IPv6

This page is an introduction of our "distributing mechanism of Default Address Selection Policy" and implementation status of "Default Address Selection for Internet Protocol version 6 (IPv6)" RFC 3484.

ChangeLog

• 2005.7.11 FreeBSD's support for 'Default Policy Table' was changed to (thanks to Hajime Umemoto's indication.)
• 2005.7.7 The initial version published.

RFC3484 Implementation Status on Major OSes

About default address selection rules, please refer to RFC 3484.
For now, we focus on implementation of Policy Table defined in RFC 3484.

Policy Table Implementation Status

OS	Configurable Table	Src Addr Selection	Dst Addr Selection	Zone Index	Default Policy Table
FreeBSD 5.3R				-
Windows XP SP2				-
Solaris 10		-	-	-
Linux 2.6.11
MacOSX Tiger

:

implemented

:

not implemented

-:

not confirmed

Configurable Table:

Whether this OS has user-configurable Policy Table or not.

Src Addr Selection:

Source address selection reflects Policy Table. (Rule5,6)

Dst Addr Selection:

Destination address selection reflects Policy Table. (Rule5,6)

Zone Index:

Policy Table can have address(prefix) with zone-index.

Default Policy Table:

Default Policy Table defined in RFC 3484 is implemented.

Testing Environment

We confirmed the results above by looking at OS source code and conducting a simple test. We checked OS source code of FreeBSD(5.3R) and Linux(2.6.11.8).

• Dst Addr Selection
  We conducted the two IPv6 addresses prioritization test in the following environment for all the OSes with Policy Table support. DNS returns two AAAA resource record of HTTP.

   +-----+    +------+ 2001:db8::80
   | DNS |    | HTTP | 3ffe:1800::80
   +----++    +--+---+
        |        |
  ------+---+----+-----
            |
      +-+---+--+
      | Router |
      +----+---+
           | 
  ------+--+------
        |
     +--+---+
     | Host | 2001:db8:a:1:EUI64
     +------+

  We applied the following policies to Host,

       Prefix        Precedence Label
       2001:db8::/32         10     1
       3ffe:1800::/32        20     2

  and confirmed that Host connect to 3ffe:1800::80 first. Then, changed to the following,

       Prefix        Precedence Label
       2001:db8::/32         20     1
       3ffe:1800::/32        10     2

  and confirmed that Host connect to 2001:db8::80 first. If these two are confirmed, the destination address selection is considered to reflect Policy Table.

• Src Addr Selection
  We conducted a test of source address selection in almost the same environment.

   +-----+    +------+ 2001:db8::80
   | DNS |    | HTTP |
   +----++    +--+---+
        |        |
  ------+---+----+-----
            |
      +-+---+--+
      | Router |
      +----+---+
           | 
  ------+--+------
        |
     +--+---+
     | Host | 2001:db8:a:1:EUI64
     +------+ 3ffe:1800:a:1:EUI64

  We applied the following policies to Host,

       Prefix        Precedence Label
       2001:db8::/32         10     1
       2001:db8:a:1::/64     10     1
       3ffe:1800::/32        10     2

  and confirmed that the source address of the first outgoing packet to HTTP was 2001:db8:a:1:EUI64. Then, changed to the following.

       Prefix        Precedence Label
       2001:db8::/32         10     1
       3ffe:1800::/32        10     2
       3ffe:1800:a:1::/64    10     1

  and confirmed that the source address of the first outgoing packet to HTTP was 3ffe:1800:a:1:EUI64. If these two are confirmed, the source address selection is considered to reflect Policy Table.

OS dependent notes

FreeBSD

• 4.x RELEASE
  • No commands, no kernel support by default.
  • You can use RFC3484 support by KAME patch.

• 5.x RELEASE
  • Merged RFC3484 support from KAME.
  • Policy Table can be configured by ip6addrctl(8).

    ip6addrctl [show]
    ip6addrctl add <prefix> <precedence> <label>
    ip6addrctl delete <prefix>
    ip6addrctl flush
    ip6addrctl install <configfile>

  • Default Policy Table can be enabled by adding

    ip6addrctl_enable="YES"

    to /etc/rc.conf.

Windows

• 2000 (Prior to XP)
  • doesn't have Policy Table.

• XP
  • Policy table can be configured by netsh command

    netsh interface ipv6 set prefixpolicy  <prefix> <precedence> ??
                   <label> [<store>=active|persistent]
    netsh interface ipv6 show prefixpolicy
    netsh interface ipv6 delete prefixpolicy

    By default, the following entries are listed:

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

    The first entry means Teredo. (Teredo server at microsoft seems not to be available now (2005-07-05).) Other entries are just the same as RFC 3484 default policy table. Please note that when you add a policy manually, all the default entries will be lost.
  • Please note that Privacy(Temporary) Address is enabled by default on XP XP's RFC 3484 implementation isn't appropriate in that a privacy address has higher precedence than a public address.

Solaris

• Solaris9 (prior to 10)
  • Policy Table isn't implemented.

• Solaris10
  • Detailed documentation can be found here(ipaddrsel(1M) and getaddrinfo(3SOCKET)).
    To show, to read configuration and to revert to the default configuration,

    /usr/sbin/ipaddrsel 
    /usr/sbin/ipaddrsel -f file 
    /usr/sbin/ipaddrsel -d

    The default configuration file (/etc/inet/ipaddrsel.conf) includes:

    # Prefix                  Precedence Label
    ::1/128                           50 Loopback
    ::/0                              40 Default
    2002::/16                         30 6to4
    ::/96                             20 IPv4_Compatible
    ::ffff:0.0.0.0/96                 10 IPv4

    Unlike other implementations, solaris10 uses string for Label value.

Linux

• Official Linux kernel or USAGI doesn't provide Policy Table implementation.
  • glibc provides getaddrinfo() with some destination address selection rules implemented, but this lacks Rule 5 and 6 reflecting Policy Table.

MacOSX

• No support, no individual patch.

Our Proposal

As described above, RFC 3484 address selection mechanism is implemented on major OSes. There is, however, no mechanism to automatically configure Policy Table like routing protocol for routing table. It is almost non-sense to force every user to configure Policy Table manually, to inform users of not small amount of policies and to make them change Policy Table configuration every time the backbone topology or address space changes. So we propose a mechanism to distribute address selection policy. Here, we describe the protocol of our mechanism first, and then illustrate practical examples that benefit from our proposing protocol.

DHCPv6 Default Address Selection Option

(Please refer to draft-fujisaki-dhc-addr-select-opt-00.txt for more information.)

Here describes a new Dynamic Host Configuration Protocol for the IPv6 (DHCPv6) option for distributing default address selection policy information to a client. Each end node is expected to configure its policy table, as described in RFC 3484, in a manner consistent with the Default Address Selection Policy option information.

• Packet Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          OPTION_DASP          |         option-len            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    label      |  precedence   |  zone-index   |   prefix-len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                   Prefix   (Variable Length)                  |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    label      |  precedence   |  zone-index   |   prefix-len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                   Prefix   (Variable Length)                  |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                                                               .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    label      |  precedence   |  zone-index   |   prefix-len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                   Prefix   (Variable Length)                  |
       |                                                               |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code:

OPTION_DASP (TBD)

option-len:

The total length of the label fields, precedence fields, zone-index fields, prefix-len fields, and prefix fields in octets.

label:

An 8-bit unsigned integer; this value is used to make a combination of source address prefixes and destination address prefixes.

precedence:

An 8-bit unsigned integer; this value is used for sorting destination addresses.

zone-index:

An 8-bit unsigned integer; this value is used to specify zones for scoped addresses.

prefix-len:

An 8-bit unsigned integer; the number of leading bits in the prefix that are valid. The value ranges from 0 to 128. The Prefix field is 0, 4, 8, 12, or 16 octets, depending on the length.

Prefix:

A variable-length field containing an IP address or the prefix of an IP address. IPv4-mapped address [mapped] must be used to represent an IPv4 address as a prefix value.

Practical Usage of Our Distribution Mechanism

This paragraph describes some practical usages of default address selection policy distribution mechanism proposed in the previous section. Default address selection policies are originated by ISPs or by network administrators and are delivered to each end node. These policies are stored at end nodes in the form of default address selection policy table. This mechanism is effective in many cases, such as IPv4 and IPv6 dual-stack environment and other multiple address environment. Every end node is guided by the policy in selecting an appropriate destination and source addresses.

Case1: IPv4 or IPv6 Prioritization

The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. There seems to be a lot of cases, however, where network administrators want to control end nodes address selection policy otherwise.

                     +---------+
                     | Tunnel  |
                     | Server  |
                     +--+---++-+
                        |   ||
                        |   ||
                 ===========||==
                 | Internet || |
                 ===========||==
                      |     ||
          10.2.0.0/16 |     ||
                 +----+-+   ||
                 | ISP  |   ||
                 +----+-+   ||
                      |     ||
        IPv4 (Native) |     || IPv6 (Tunnel)
         10.2.30.0/32 |     ||
                     ++-----++-+
                     | Gateway |
                     +----+----+
                          |  2001:db8:a:1::/64
                          |  192.168.0.0/24
                     DHCP |  
                ------+---+----------
                      |
                    +-+----+ 2001:db8:a:1:EUI64
                    | Host | 192.168.0.100
                    +------+

In the figure above, a site has native IPv4 and tunneled IPv6 connectivity. So, the administrator of this site knows communication quality of IPv6 is much worse than IPv4. This kind of problem can be solved by applying the following policy table to hosts.

     Prefix        Precedence Label
     ::1/128               50     0
     ::/0                  40     1
     2002::/16             30     2
     ::/96                 20     3
     ::ffff:0:0/96        100     4

The administrator can indicate that IPv4 should take precendence over IPv6, while keeping to provide both IPv4 and IPv6 connectivity, by delivering DHCPv6 Default Address Selection Option that includes the policy above.

Case2: ULA or Global Prioritization

By default, the scope of these addresses is global. Also, unlike site-locals, a site may have more than one of these prefixes and use them at the same time.

By making use of this characteristics, you can achieve strong and simple access control. Like the figure below, a web server has both ULA and Global IPv6 addresses. A host in this site also has both addresses.

By configuring client address based access control at the web server, a client with ULA gets in internal only web pages and a client with Global address gets access to only public web pages. As it is relatively easy to reject packets with ULA source address getting into the site at border router, this kind of access control seems to be reliable.

                     +------+
                     | Host |
                     +-+--|-+
                       |  |
               ===========|==
               | Internet | |
               ===========|==
                     |    |
                     |    |   
                +----+-+  +-->+------+
                | ISP  +------+  Web | 2001:db8:a::80
                +----+-+  +-->+------+ fc12:3456:789a::80
 DHCP-PD             |    | 
     2001:db8:a::/48 |    |
 fc12:3456:789a::/48 |    |
                +----+----|+
                | Gateway ||
                +---+-----|+
                    |     |    2001:db8:a:100::/64
               DHCP |     |    fc12:3456:789a:100:/64
                  --+-+---|-----
                      |   |
                    +-+---|+ 2001:db8:a:100:EUI64
                    | Host | fc12:3456:789a:100:EUI64
                    +------+

If you want to make in-site hosts to get into internal web site, you should deliver the following policies to them from the gateway.

     Prefix        Precedence Label
     ::1/128               50     0
     fc00::/7              40     1
     ::/0                  30     2
     ::ffff:0:0/96         10     3

Case3: Multicast Source Address Selection

This case is an example of Site-local or Global prioritization. When you send a multicast packet across site-borders, the source address of the multicast packet has to be a global scope address. The longest matching algorithm, however, selects a ULA address, if a sending host has both an ULA and a global addresses.

The following policy fixes this incongruity. For site-scope multicast, the destination address is in ff05::/16, and the source address should be ULA. For global-scope multicast, the destination address is in ff0e::/16, and the source address will be global unicast address.

     Prefix        Precedence Label
     ff05::/16             10     5
     fc00::/7              10     5  
     ff0e::/16             10     6
     2000::/3              10     6

Case4: Global and Closed Mixed Connectivity

You can see another typical source address selection problem in a site with global-closed mixed connectivity like the figure below. In this case, Host-A is in a multihomed network and has two IPv6 addresses delegated from each of up-stream ISPs. Note that ISP2 is closed network and doesn't have connectivity to the Internet.

                       +--------+
                       | Host-C | 3ffe:503:c:1:EUI64
                       +-----+--+
                             |
                    ==============  +--------+
                    |  Internet  |  | Host-B | 3ffe:1800::EUI64
                    ==============  +--------+
                         |           |
           2001:db8::/32 |           | 3ffe:1800::/32
                    +----+-+   +-+---++
                    | ISP1 |   | ISP2 | (Closed Network / VPN tunnel)
                    +----+-+   +-+----+
                 DHCP-PD |       | DHCP-PD
         2001:db8:a::/48 |       | 3ffe:1800:a::/48
                        ++-------++
                        | Gateway |
                        +----+----+
                             |  2001:db8:a:1::/64
                             |  3ffe:1800:a:1::/64
                        DHCP |
                   ------+---+----------
                         |
                      +--+-----+ 2001:db8:a:1:EUI64
                      | Host-A | 3ffe:1800:a:1:EUI64
                      +--------+

Host-C is located somewhere in the Internet and has an IPv6 address 3ffe:503:c:1:EUI64. When Host-A sends a packet to Host-C, longest matching algorithm chooses 3ffe:1800:a:1:EUI64 for the source address. In this case, the packet goes through ISP1 and may be filtered by ISP1's ingress filter. Even if the packet isn't filtered by ISP1 fortunately, a return packet from Host-C won't possibly reach at Host-A, because the return packet is destined for 3ffe:1800:a:1:EUI64, which is closed from the Internet.

In this case, the source address selection problem will be solved, if Host-A has the following policy table and the gateway has an appropriate routing table.

     Prefix        Precedence    Label
     2001:db8::/32         10      100
     ::/0                  10      100
     2001:db8:a:1::/64     10      100
     3ffe:1800::/32        10      200
     3ffe:1800:a:1::/64    10      200

Only the ISP1 and ISP2 know what policy Host-A should have, so we propose that ISPs should deliver their policy information to their customers in the form of DHCPv6 option that we stated above.

Case5: Renumbering Site Prefix

This mechanism is useful for smooth IPv6 address renumbering.

Standardization History

RFC3484

• 1999 April, draft-draves-ipngwg-simple-srcaddr-00
  • initial draft from Richard Draves.
• 1999 Oct, draft-ietf-ipngwg-default-addr-select-00
  • Algorithm for destionaion address selection included.
• 2002 Mar, draft-ietf-ipv6-default-addr-select-07
  • Moved to ipv6 wg.
• 2002 Aug, draft-ietf-ipv6-default-addr-select-09
  • Final draft.
• 2003 Feb, RFC3484 Default Address Selection for Internet Protocol version 6 (IPv6)

Policy Table Distribution

• 2004 Oct, draft-arifumi-multi6-sas-policy-dist-00.txt
• 2004 Oct, draft-arifumi-ipv6-nd-source-address-selection-opt-00.txt
• 2004 Oct, draft-hirotaka-dhc-source-address-selection-opt-00.txt
  • We proposed a solution that makes use of RFC 3484 Policy Table for one of IPv6 multihoming problems.
  • Source address selection policy is carried in the form of options for RA and DHCPv6.
• 2005 Feb, draft-arifumi-ipv6-sas-policy-dist-00.txt
• 2005 Feb, draft-arifumi-ipv6-nd-source-address-select-02.txt
• 2005 Feb, draft-hirotaka-dhc-source-address-selection-opt-01.txt
  • We moved the concept draft to ipv6 wg, in which we clarified problem statement, considerations about policy merging and comparisons with other methods.
• 2005 June, draft-fujisaki-dhc-addr-select-opt-00.txt
  • We changed the concept of our proposal not only for multi-homing issues but also for more generic multi-addressing issues. This option carries not source address selection policy, but default address selection policy defined in RFC 3484 itself.
• 2005 Dec, draft-fujisaki-dhc-addr-select-opt-01.txt
  • Some minor changes from 00 version.
• 2005 Dec, draft-arifumi-ipv6-policy-dist-00.txt
  • This document describes some practical usages of default address selection policy distribution mechanism defined in draft-fujisaki-dhc-addr-select-opt-01.txt.
• 2006 Jun, draft-arifumi-v6ops-addr-select-ps-00.txt
  • This is a problem statement draft that describes a lot of address selection related problems in multi-prefix environment.
• 2006 Jun, draft-fujisaki-dhc-addr-select-opt-02.txt
  • Some minor changes from 01 version.
• 2006 Jun, draft-arifumi-ipv6-policy-dist-01.txt
  • Some more cases are added in accordance with the problem statement I-D.
• 2006 Aug, draft-arifumi-v6ops-addr-select-ps-01.txt
  • Solutions and Security Considerations section re-written reflecting Pekka Savola's comments.
• 2006 Nov, draft-arifumi-v6ops-addr-select-req-00.txt
  • Requirements draft for address selection policy distribution mechanisms.
• 2006 Nov, draft-ietf-v6ops-addr-select-ps-00.txt
  • Approved as a v6ops working item.
• 2006 Nov, draft-ietf-v6ops-addr-select-req-00.txt
  • Approved as a v6ops working item.
• 2006 Dec, draft-fujisaki-dhc-addr-select-opt-03.txt
  • Some considerations included, such as the maximum number of policies and address type dependent address selection.

Contacts

  Tomohiro Fujisaki
  Jun-ya Kato
  Shirou Niinobe
  Arifumi Matsumoto

  NTT PF Lab
  3-9-11 Midori-Cho
  Musashino-shi, Tokyo  180-8585
  Japan
  Phone: +81 422 59 7351