Internet DRAFT - draft-arifumi-ipv6-policy-dist

draft-arifumi-ipv6-policy-dist






Network Working Group                                       A. Matsumoto
Internet-Draft                                               T. Fujisaki
Expires: December 21, 2006                                       J. Kato
                                                              S. Niinobe
                                                                     NTT
                                                           June 19, 2006


       Practical Usages of Address Selection Policy Distribution
                 draft-arifumi-ipv6-policy-dist-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes some practical usages of address selection
   policy distribution mechanism defined in another document.  Address
   selection policies are originated by ISPs or by network
   administrators and are delivered to each end host.  These policies
   are stored at end hosts in the form of default address selection
   policy table.  This mechanism enables central control of address



Matsumoto, et al.       Expires December 21, 2006               [Page 1]

Internet-Draft       Policy Table Distribution Usage           June 2006


   selection policy at end hosts, so it is essential or helpful in many
   cases, such as IPv4 and IPv6 dual-stack environment and ULA and
   Global address parallel-use environment.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Practical Use Example  . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Source Address Selection . . . . . . . . . . . . . . . . .  3
       2.1.1.  Multiple Routers on Single Interface . . . . . . . . .  4
       2.1.2.  Ingress Filtering Problem  . . . . . . . . . . . . . .  5
       2.1.3.  Half-Closed Network Problem  . . . . . . . . . . . . .  6
       2.1.4.  Combined Use of Global and ULA . . . . . . . . . . . .  7
       2.1.5.  Site Renumbering . . . . . . . . . . . . . . . . . . .  7
       2.1.6.  Multicast Source Address Selection . . . . . . . . . .  8
       2.1.7.  Temporary Address Selection  . . . . . . . . . . . . .  8
     2.2.  Destination Address Selection  . . . . . . . . . . . . . .  9
       2.2.1.  IPv4 or IPv6 prioritization  . . . . . . . . . . . . .  9
       2.2.2.  ULA and IPv4 dual-stack environment  . . . . . . . . . 10
       2.2.3.  ULA or Global Prioritization . . . . . . . . . . . . . 11
   3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   5.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 12
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Appendix A.  Revision History  . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15





















Matsumoto, et al.       Expires December 21, 2006               [Page 2]

Internet-Draft       Policy Table Distribution Usage           June 2006


1.  Introduction

   IPv6 is originally designed to be able to have multiple addresses on
   a network interface.  RFC 3484 [RFC3484] defines some default rules
   by which destination address and a source addresses are selected
   among two or more addresses.  Also, RFC 3484 address selection
   mechanism is implemented on major OSes.  However, we've found that
   some important cases where those default rules aren't enough or even
   evil.

   We published a problem statement Internet Draft [I-D.arifumi-v6ops-
   addr-select-ps] that illustrates various kinds of address selection
   related problems.  Almost all of these problems can be solved by a
   built-in feature called "policy table" that is already defined in RFC
   3484 and implemented in a lot of operating systems.

   What is missing here is a method to centrally control end-hosts'
   address selection behavior from outside of the host like routing
   protocol for routing table.  It is almost non-sense to force every
   user to configure policy table manually, to inform users of
   relatively large amount of policies and to make them change policy
   table configuration every time the backbone topology or address space
   changes.

   We've proposed a method [I-D.fujisaki-dhc-addr-select-opt] to
   distribute address selection policy to end-hosts, in the form of a
   new option for DHCPv6 [RFC3315].

   Our method is so versatile that can be used in a lot of environments
   for a lot of purposes.  This document describes some practical usages
   of our method.


2.  Practical Use Example

2.1.  Source Address Selection















Matsumoto, et al.       Expires December 21, 2006               [Page 3]

Internet-Draft       Policy Table Distribution Usage           June 2006


2.1.1.  Multiple Routers on Single Interface

                          ==================
                          |    Internet    |
                          ==================
                             |          |
               2001:db8::/32 |          | 3ffe:1800::/32
                        +----+-+      +-+----+
                        | ISP1 |      | ISP2 |
                        +----+-+      +-+----+
                             |          |
             2001:db8:a::/48 |          | 3ffe:1800:a::/48
                      +------+---+ +----+-----+
                      | Gateway1 | | Gateway2 |
                      +--------+-+ +-+--------+
                               |     |
             2001:db8:a:1::/64 |     | 3ffe:1800:a:1::/64
                               |     |
                        -----+-+-----+------
                             |
                           +-+----+ 2001:db8:a:1:EUI64
                           | Host | 3ffe:1800:a:1:EUI64
                           +------+

                                [Fig. 1]

   To avoid wrong address selection and connection failure, one approach
   is to configure correctly both the routing table and address policy
   table at Host.  You can use RFC 4191 [RFC4191] to deliver routing
   information to hosts.

   When the Host selects Gateway1 for its default route and each ISP
   distributes its address block,

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

   Another approach is to configure the gateways but not the Host and
   make use of packet redirection based on the source address between
   the gateways.









Matsumoto, et al.       Expires December 21, 2006               [Page 4]

Internet-Draft       Policy Table Distribution Usage           June 2006


2.1.2.  Ingress Filtering Problem

                        ==================
                        |    Internet    |
                        ==================
                             |       |
               2001:db8::/32 |       | 3ffe:1800::/32
                        +----+-+   +-+----+
                        | ISP1 |   | ISP2 |
                        +----+-+   +-+----+
                             |       |
             2001:db8:a::/48 |       | 3ffe:1800:a::/48
                            ++-------++
                            | Gateway |
                            +----+----+
                                 |  2001:db8:a:1::/64
                                 |  3ffe:1800:a:1::/64
                       ------+---+----------
                             |
                           +-+----+ 2001:db8:a:1:EUI64
                           | Host | 3ffe:1800:a:1:EUI64
                           +------+

                                [Fig. 2]

   In this example, as far as Gateway1 doesn't adopt source-address-
   based routing, the Host has to select an appropriate source address
   in accordance with Gateway's routing policy.  The Gateway can notify
   its routing policy in the form of policy table like below.  Here the
   Gateway selects ISP1 for its default route.


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















Matsumoto, et al.       Expires December 21, 2006               [Page 5]

Internet-Draft       Policy Table Distribution Usage           June 2006


2.1.3.  Half-Closed Network Problem

                           +--------+
                           | 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)
                        +----+-+   +-+----+
                             |       |
             2001:db8:a::/48 |       | 3ffe:1800:a::/48
                            ++-------++
                            | Gateway |
                            +----+----+
                                 |  2001:db8:a:1::/64
                                 |  3ffe:1800:a:1::/64
                       ------+---+----------
                             |
                          +--+-----+ 2001:db8:a:1:EUI64
                          | Host-A | 3ffe:1800:a:1:EUI64
                          +--------+

                                [Fig. 3]

   To avoid wrong address selection to Host-C, Gateway have to
   distribute the following policy to Host-A.  In this case The longest
   matching algorithm always chooses the wrong address.


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

   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.









Matsumoto, et al.       Expires December 21, 2006               [Page 6]

Internet-Draft       Policy Table Distribution Usage           June 2006


2.1.4.  Combined Use of Global and ULA

                           +--------+
                           | Host-C | 8000:db8::1
                           +-----+--+
                                 |
                        ============
                        | Internet |
                        ============
                              |
                              |
                         +----+----+
                         |   ISP   |
                         +----+----+
                              |
              2001:db8:a::/48 |
                         +----+----+
                         | Gateway |
                         +-+-----+-+
                           |     | 2001:db8:a:100::/64
          fd01:2:3:200:/64 |     | fd01:2:3:100:/64
                   -----+--+-   -+--+----
                        |           |
     fd01:2:3:200:EUI64 |           |        2001:db8:a:100:EUI64
                   +----+----+    +-+------+ fd01:2:3:100:EUI64
                   | Printer |    | Host-A |
                   +---------+    +--------+

                                [Fig. 4]

   In a few years the longest matching rule will not be able to choose
   the correct address anymore: the moment the assignment of those
   Global Unicast Addresses whose beginning bit is 1 starts.

   So, to avoid connection failure between Host-A and Host-C in this
   figure the site administrator should distribute the following policy.


        Prefix          Precedence    Label
        fd01:2:3::/48         20      1
        2001:db8:a::/48       10      2
        ::/0                  10      2

2.1.5.  Site Renumbering

   It takes a long time to invalidate the old prefix.  Also you cannot
   stop routing to the old prefix because there could be a long-lived
   TCP or UDP session that uses the old prefix.



Matsumoto, et al.       Expires December 21, 2006               [Page 7]

Internet-Draft       Policy Table Distribution Usage           June 2006


                              +-----+---+
                              | Gateway |
                              +----+----+
                                   |  2001:db8:a:1::/64  (new)
                                   |  3ffe:1800:a:1::/64 (old)
                         ------+---+----------
                               |
                            +--+-----+ 2001:db8:a:1:EUI64  (new)
                            | Host-A | 3ffe:1800:a:1:EUI64 (old)
                            +--------+

                                [Fig. 5]


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

2.1.6.  Multicast Source Address Selection

   The longest matching algorithm selects a ULA [RFC4193] address if the
   sending host has both a ULA and a global address.  This behavior is
   not always desirable.  It depends on the usage and the routing policy
   of ULA.  If the source address of the multicast packets should not be
   ULA, you have to configure policy table accordingly.

   The policy below selects ULA for site-local multicast address and
   global unicast address for global-scope multicast address.


        Prefix        Precedence Label
        ff05::/16             10     1
        fc00::/7              10     1
        ff0e::/16             10     2
        2000::/3              10     2

2.1.7.  Temporary Address Selection

   For now you do not have a method to control usage policy of temporary
   address other than specifying a temporary address at 128bit prefix
   length and keeping the entry up-to-date according to the change of
   the temporary address.

   There are a lot of cases that we want to control the usage of
   temporary address more minutely, so it is desirable to make policy
   table support temporary address description.




Matsumoto, et al.       Expires December 21, 2006               [Page 8]

Internet-Draft       Policy Table Distribution Usage           June 2006


2.2.  Destination Address Selection

2.2.1.  IPv4 or IPv6 prioritization

   The default policy table gives IPv6 addresses higher precedence than
   IPv4 addresses.

                            +---------+
                            | Tunnel  |
                            | Service |
                            +--+---++-+
                               |   ||
                               |   ||
                        ===========||==
                        | 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
                                 |
                       ------+---+----------
                             |
                           +-+----+ 2001:db8:a:1:EUI64
                           | Host | 192.168.0.100
                           +------+

                                [Fig. 6]

   In the figure above, a site has native IPv4 and tunneled IPv6
   connectivity.  Therefore, the administrator may want to set a higher
   priority for using IPv4 than using IPv6 because the quality of the
   tunnel network seems to be worse than that of the native transport.


        Prefix          Precedence  Label
        ::/0            20          1
        ::ffff:0:0/96   10          2




Matsumoto, et al.       Expires December 21, 2006               [Page 9]

Internet-Draft       Policy Table Distribution Usage           June 2006


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

2.2.2.  ULA and IPv4 dual-stack environment

   When the Host below tries to connect to Host-C that has registered
   both A and AAAA records in the DNS, the host will choose AAAA as the
   destination address and ULA for the source address.  This will
   clearly result in a connection failure.

                           +--------+
                           | Host-C | AAAA = 2001:db8::80
                           +-----+--+ A    = 192.47.163.1
                                 |
                        ============
                        | Internet |
                        ============
                             |  no IPv6 connectivity
                        +----+-+
                        | ISP  |
                        +----+-+
                             |
                             | fd01:2:3::/48 (ULA)
                             | 10.2.0.0/16
                  IPv4 NAT  ++--------+
                            | Gateway |
                            +----+----+
                                 |  fd01:2:3:4::/64 (ULA)
                                 |  192.168.0.0/24
                       ------+---+----------
                             |
                           +-+----+ fd01:2:3:4::100 (ULA)
                           | Host | 192.168.0.100
                           +------+

                                [Fig. 7]

   The policy below enables IPv6 communication within the ISP.  Outside
   of the ISP IPv4 communication has highor priority than IPv6.


        Prefix          Precedence  Label
        fd01:2:3::/48   30          3
        ::ffff:0:0/96   20          2
        ::/0            10          1




Matsumoto, et al.       Expires December 21, 2006              [Page 10]

Internet-Draft       Policy Table Distribution Usage           June 2006


2.2.3.  ULA or Global Prioritization

   ULA and IPv6 global address both have global scope, and default rules
   do not specify which address should be given priority.  This point
   makes IPv6 implementation of address-based service differentiation a
   bit harder.

                            +------+
                            | Host |
                            +-+--|-+
                              |  |
                      ===========|==
                      | Internet | |
                      ===========|==
                            |    |
                            |    |
                       +----+-+  +-->+------+
                       | ISP  +------+  DNS | 2001:db8:a::80
                       +----+-+  +-->+------+ fd01:2:3::80
                            |    |
            2001:db8:a::/48 |    |
             fd01:2:3:::/48 |    |
                       +----+----|+
                       | Gateway ||
                       +---+-----|+
                           |     |    2001:db8:a:100::/64
                           |     |    fd01:2:3:100:/64
                         --+-+---|-----
                             |   |
                           +-+---|+ 2001:db8:a:100:EUI64
                           | Host | fd01:2:3:100:EUI64
                           +------+

                                [Fig. 7]

   If you want to make in-site hosts to get information of DNS internal
   zone, you should deliver the following policies to them from the
   gateway.

        Prefix               Precedence Label
        fd01:2:3::/48              20     1
        ::/0                       10     2


3.  Security Considerations

   With regard to the possibility of traffic abduction through the
   announcement of a bogus policy, this scheme seems to neither lower



Matsumoto, et al.       Expires December 21, 2006              [Page 11]

Internet-Draft       Policy Table Distribution Usage           June 2006


   nor raise the security level obtained by the existing base-protocols,
   such as DHCP-PD, DHCP and RA.  However, it does raise the possibility
   of a new form of DoS attack on routers and hosts, in which large
   numbers of address-selection policies are generated by different
   source addresses.  We will have to discuss this and take
   precautionary measures in designing the protocol specification.


4.  IANA Considerations

   This document has no actions for IANA.


5.  Acknowledgement

   Many thanks to Tim Chown, Iljitsch, Changming and Shin Miyagawa for
   detailed feedbacks and discussions on this document.  We really
   appreciate all the members in our laboratory for their contributions.


6.  References

6.1.  Normative References

   [I-D.arifumi-v6ops-addr-select-ps]
              Matsumoto, A., "Problem Statement of Default Address
              Selection in Multi-prefix Environment:  Operational Issues
              of RFC3484 Default Rules",
              draft-arifumi-v6ops-addr-select-ps-00 (work in progress),
              June 2006.

   [I-D.fujisaki-dhc-addr-select-opt]
              Fujisaki, T., "Distributing Default Address Selection
              Policy using DHCPv6",
              draft-fujisaki-dhc-addr-select-opt-02 (work in progress),
              June 2006.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

6.2.  Informative References

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, November 2005.



Matsumoto, et al.       Expires December 21, 2006              [Page 12]

Internet-Draft       Policy Table Distribution Usage           June 2006


   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.


Appendix A.  Revision History
      00-version (2005.12.1): Initial version.

      01-version (2006.6.19): Some cases were added in accordance with
      the problem statement I-D.










































Matsumoto, et al.       Expires December 21, 2006              [Page 13]

Internet-Draft       Policy Table Distribution Usage           June 2006


Authors' Addresses

   Arifumi Matsumoto
   NTT PFLab
   Midori-Cho 3-9-11
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81 422 59 3334
   Email: arifumi@nttv6.net


   Tomohiro Fujisaki
   NTT PFLab
   Midori-Cho 3-9-11
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81 422 59 7351
   Email: fujisaki@lab.ntt.co.jp


   Jun-ya Kato
   NTT PFLab
   Midori-Cho 3-9-11
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81 422 59 2939
   Email: kato@syce.net


   Shirou Niinobe
   NTT PFLab
   Midori-Cho 3-9-11
   Musashino-shi, Tokyo  180-8585
   Japan

   Phone: +81 422 59 4949
   Email: nin@syce.net











Matsumoto, et al.       Expires December 21, 2006              [Page 14]

Internet-Draft       Policy Table Distribution Usage           June 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Matsumoto, et al.       Expires December 21, 2006              [Page 15]