[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
IPv6 Working Group                                          A. Matsumoto
Internet-Draft                                                       NTT
Expires: August 1, 2005                                      T. Fujisaki
                                                             H. Matsuoka
                                                                 J. Kato
                                                        January 31, 2005


      Source Address Selection Policy Distribution for Multihoming
               draft-arifumi-ipv6-sas-policy-dist-00.txt

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 August 1, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes a method for the distribution of source
   address selection policy from ISPs to gateway routers for consumers
   and from the gateways to end nodes.  This method is particularly
   effective when a consumer site has multiple address blocks.  Every
   end node is guided by the policy in selecting an appropriate source



Matsumoto, et al.        Expires August 1, 2005                 [Page 1]


Internet-Draft          SAS Policy Distribution             January 2005


   address for each destination address and every gateway is guided by
   the policy in forwarding packets to appropriate next-hop ISPs.  This
   makes it possible for an end node to set a connection up without
   being concerned about failures of transfer due to ingress filtering
   by the ISPs, for ISP operators to manage consumers' behavior and
   networking policy, and for consumers to be provided with networks
   that are almost automatically robust and reliable.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
     2.1   Ingress Filtering Problem  . . . . . . . . . . . . . . . .  3
     2.2   Closed Network Problem . . . . . . . . . . . . . . . . . .  4
   3.  Concepts of Our Proposal . . . . . . . . . . . . . . . . . . .  5
   4.  Proposal Overview For Each Case  . . . . . . . . . . . . . . .  7
     4.1   Case 1: Multihome Site with Global-Closed Mixed
           Connectivity . . . . . . . . . . . . . . . . . . . . . . .  7
       4.1.1   Description of Each Element  . . . . . . . . . . . . .  7
       4.1.2   Discussion . . . . . . . . . . . . . . . . . . . . . . 10
     4.2   Case 2: Host with Multiple Addresses and Connectivity
           to Two Global Networks . . . . . . . . . . . . . . . . . . 11
       4.2.1   Description of Each Element  . . . . . . . . . . . . . 11
       4.2.2   Discussion . . . . . . . . . . . . . . . . . . . . . . 13
     4.3   Case 3: A Host Directly Connected to Multiple ISPs . . . . 13
   5.  Who merges conflicting policies and how ?  . . . . . . . . . . 14
   6.  Failure Recovery . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1   Stop advertising . . . . . . . . . . . . . . . . . . . . . 14
     6.2   Address Revocation . . . . . . . . . . . . . . . . . . . . 15
     6.3   Policy Modification  . . . . . . . . . . . . . . . . . . . 15
   7.  Solution Comparison  . . . . . . . . . . . . . . . . . . . . . 15
     7.1   Site Local Address . . . . . . . . . . . . . . . . . . . . 15
     7.2   Router Selection . . . . . . . . . . . . . . . . . . . . . 16
     7.3   Routing Protocol Based Policy Distribution . . . . . . . . 16
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  Revision History . . . . . . . . . . . . . . . . . . . . . . . 16
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 16
   11.   Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . 17
   12.   References . . . . . . . . . . . . . . . . . . . . . . . . . 17
   12.1  Normative References . . . . . . . . . . . . . . . . . . . . 17
   12.2  Informative References . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
       Intellectual Property and Copyright Statements . . . . . . . . 19








Matsumoto, et al.        Expires August 1, 2005                 [Page 2]


Internet-Draft          SAS Policy Distribution             January 2005


1.  Introduction

   An IPv6 multihoming site has multiple nodes, each of which is
   assigned multiple IPv6 addresses by up-stream ISPs.  When there are
   multiple up-stream ISPs, the means of selection of the ISP for an
   outgoing packet is currently based on the destination address.  In
   general, however, each packet should have a source address that has
   been allocated by the selected up-stream ISP.  This is because the
   routers of ISPs may be configured to perform ingress filtering with
   the aim of blocking packets that have strange source addresses.

   In this document, we clarify the problems of source address
   selection, list up solutions for them, and propose our solution,
   which is a technique that is used both to distribute policy
   information for source address selection at end nodes and to
   establish a method for the forwarding of packets by routers.  This
   enables the control of incoming traffic from customer sites by ISPs,
   the selection of appropriate source addresses by end nodes, and the
   selection of outgoing ISPs in a way that is almost certain to produce
   successful connection setup.

2.  Problem Statement

2.1  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. 1]




Matsumoto, et al.        Expires August 1, 2005                 [Page 3]


Internet-Draft          SAS Policy Distribution             January 2005


   When a relatively small site, we call it "consumer network", is
   attached to two up-stream ISPs, each ISP delegates network address
   block, which is usually /48, and a host has multiple IPv6 addresses.

   When the source address of an outgoing packet isn't the one that is
   delegated by a transit ISP, the packet will be very probably dropped
   by ISP's ingress filter.  Ingress filtering is getting popular and
   popular among ISPs in order to mitigate the damage of DoS attacks.

   One possible solution for this problem is to adopt source address
   based routing at consumer site's gateway, but this new way of routing
   is not widely deployed yet.

2.2  Closed Network Problem

   You can see a second typical source address selection problem in a
   multihome 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)
                     +----+-+   +-+----+
                          |       |
          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. 2]




Matsumoto, et al.        Expires August 1, 2005                 [Page 4]


Internet-Draft          SAS Policy Distribution             January 2005


   This network environment isn't so uncommon as you might perhaps think
   of it.  The access-line to the ISP2 might be actually a VPN tunnel
   over ISP1 and the Internet.

   When Host-A starts connection to Host-B in ISP2, the source address
   of a sending packet will be the one delegated from ISP2, that is
   3ffe:1800:a:1:EUI64, because of rule 8 (longest matching prefix) in
   RFC 3484 [RFC3484].

   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, source address based routing alone described in the
   previous section doesn't solve the problem.  What is important is
   that each host chooses a correct source address for a given
   destination address as far as NAT doesn't exist in IPv6 world.

3.  Concepts of Our Proposal

   In this document, we propose a method by which an ISP can distribute
   source address selection policies to each end node at a customer
   site.  The policy information is particularly helpful to hosts in
   which multihoming is used, since an end node can use the destination
   address to select a source address that leads to a high probability
   of successful setup for the connection.

   An up-stream ISP is expected to use DHCPv6 Prefix Options [RFC3633]
   to delegate a certain portion of the IPv6 address space to its
   subscribers.  We propose a DHCPv6 new option, which contains a per-
   delegating-prefix address-selection policy.  By making use of this
   option, an ISP can inform its customers of an address block that can
   be reached through the ISP and of a corresponding source address of
   packets, that is, a source address that must be used to reach the
   given block.  This is simply achieved through delegation of the
   delegated source-address prefix and policy by the ISP.

   The gateway router of a customer's site receives the delegated prefix
   and address-selection policy mentioned above from its up-stream ISPs.
   The router in turn distributes this information to end nodes at the
   site.  Here, we propose an extension to the ND6 Router Advertisement
   Message [RFC2461] and a DHCPv6 [RFC3315] new option to cover delivery
   of address-selection policy to the end nodes.  The address-selection



Matsumoto, et al.        Expires August 1, 2005                 [Page 5]


Internet-Draft          SAS Policy Distribution             January 2005


   policy delivered to an end node is stored in the form of a Policy
   Table as defined in RFC 3484 [RFC3484].

   Once the above series of processes is complete, an end node can
   select an appropriate source address for a given destination address.
   Routing of an outgoing packet to the corresponding up-stream ISP can
   be implemented in several ways that avoids blocking of the packet by
   ingress filtering.  One way is a routing method guided by the source
   address of the packet, which is sometimes called "policy routing".
   Another method uses destination address based routing with the aid of
   additional routing information.

   This mechanism is particularly effective when a site subscribes to an
   ISP or VPN service that provides connectivity to a certain closed
   network as described in the previous section.  This is because
   selecting an appropriate source address for a given destination
   address is crucial in such a network environment.

   This approach gives end nodes an advance measure against connection
   setup failure.  At the same time, an ISP can control incoming traffic
   from customers' sites, and the network managers of customers' sites
   can reflect their networking policy to some extent by configuring
   DHCPv6 or ND6 RA settings on routers.  The last but not the least
   significant feature to note here is that this sequence of passing,
   processing, generation, and reflection of policy information can be
   made almost totally automatic from the viewpoint of customers.

























Matsumoto, et al.        Expires August 1, 2005                 [Page 6]


Internet-Draft          SAS Policy Distribution             January 2005


4.  Proposal Overview For Each Case

4.1  Case 1: Multihome Site with Global-Closed Mixed Connectivity

   Fig.  3 shows a multihome site that subscribes to two ISPs.  One ISP
   provides global network connectivity and the other provides
   connectivity to a closed network but not to the Internet.  This site
   has one border router, labeled Gateway here, and the router may be
   connected to up-stream ISPs through a physical or logical link, say
   PPPoE or an IPsec Tunnel.

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

                             [Fig. 3]


4.1.1  Description of Each Element

   i) ISP -> Gateway
      This figure shows that ISP1 has been allocated 2001:db8::/32 and
      ISP2 has been allocated 3ffe:1800::/32.  Each ISP delegates part
      of its address block, called the "provider aggregatable (PA)"
      block, to this customer site.  Here, ISP1 and ISP2 use DHCP-PD to
      delegate 2001:db8:a::/48 and 3ffe:1800:a::/48, respectively.

      In this document, we propose an extension to DHCP-PD, which is
      actually a new DHCP option and called DHCP-PD' here.  DHCP-PD'
      gives DHCP servers (ISPs) functionality for delivering an address-



Matsumoto, et al.        Expires August 1, 2005                 [Page 7]


Internet-Draft          SAS Policy Distribution             January 2005


      selection policy in combination with a delegated prefix to a
      client (gateway).  In this example, ISP2 includes

                Address               Addr. Sel. Policy
                3ffe:1800:a::/48 ---- 3ffe:1800::/32

      in the PD and address-selection policy options sent to the client.
      This means that the subscribers of ISP2 should use an address from
      the delegated range, that is, 3ffe:1800:a::/48, when communicating
      with 3ffe:1800::/32.

      Selection of an appropriate source address is very important, and
      this is particularly so when one of the subscribing networks is
      closed as in this example.  This is simply because a return packet
      from the closed network can't possibly reach the session-
      originating host if the return packet is destined for an address
      beyond the range available to the closed ISP.

      ISP1 also uses DHCP-PD', in this case to deliver its address-
      selection policy to its customers.  As ISP1 provides global
      network connectivity, the PD and policy options will take the
      following form.

                Address                Addr-Sel. Policy
                2001:db8:a::/48 --+--  2001:db8::/32
                                  +--  ::/0 (all address)

      This means that ISP1 can provide connectivity to 2001:db8::/32 and
      act as a transit point for any other address (::/0) in the
      Internet as long as the source address is that delegated by ISP1,
      namely 2001:db8:a::/48.

      Of course, ::/0 includes 2001:db8::/32, so 2001:db8::/32 isn't
      necessary information for down-stream users.  Like this way,
      however, by announcing more specific network block than ::/0 as a
      policy to down-stream, it is more likely to be adopted by
      down-stream nodes.  This is because conflicting policies will be
      probably discarded at end nodes and routers, as mentioned below in
      4.2.1, and ::/0 is much more likely to conflict with other ISP's
      policy than 2001:db8::/32.  ISPs often provides additional
      services, such as video streaming and homepage building tool, only
      to their customers.  This kind of access control is easily
      implemented by announcing ISP's specific network block in their
      address-selection policies.

      With regard to backward compatibility, a normal DHCP-PD packet,
      which does not carry address-selection policy information of the
      above type, should be deemed to have ::/0 as its policy field.



Matsumoto, et al.        Expires August 1, 2005                 [Page 8]


   ii) Gateway -> Host
      A gateway router receives address-delegation information and
      address-selection policy from up-stream ISPs, in turn delivering
      both to down-stream nodes.  In this document, we propose DHCP new
      option and an extension to RA (Router Advertisement Message).  We
      refer to these as DHCP' and RA', respectively.  The gateway router
      combines information given by multiple up-stream ISPs and
      distributes the following information down-stream through DHCP' or
      RA'.


                        Address                 Addr. Sel. Policy
                1       2001:db8:a:1::/64  --+-- 2001:db8::/32
                                             +-- ::/0
                2       3ffe:1800:a:1::/64 ----- 3ffe:1800::/32

      This is just the combination of the information from the two up-
      stream elements in the previous section, except that each
      advertising address prefix is 64 bits long.

   iii) Host
      When a host receives an RA' or DHCP' message from the site
      gateway, it configures addresses for each receiving network
      interface and reflects address-selection policy in its
      RFC3484-based policy table.

      In this example, we propose that the policy table should be
      configured as follows, by making use of the Label field defined in
      RFC3484, and the relation between address prefix and address-
      selection policy should be kept in this table.

                Prefix                Pref.   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

      When this host sends a packet to, for example, 3ffe:1800:a::100,
      whose longest matching entry in this table is 3ffe:1800::/32, the
      host chooses the address beginning with 3ffe:1800:a:1:: as the
      source address.  The source-address selection algorithm will
      select the longest entry that is a candidate source-address range
      and has the same label as the longest matching address for the
      destination address.  In the same way, the source address of a
      packet destined for 2001:db8::/32 or 2002::/16 will be
      2001:db8:a:1:EUI64.

      Preference values are only used in the selection of destination
      addresses.  This document does not include an algorithm for



Matsumoto, et al.        Expires August 1, 2005                 [Page 9]


Internet-Draft          SAS Policy Distribution             January 2005


      determining preference values.

   iv) Gateway
      As well as delivering addresses and policy information to hosts
      through RA' or DHCP', the gateway is in charge of forwarding
      packets according to policy information distributed by up-stream
      ISPs.  One way of implementing such forwarding or routing, called
      policy routing, is based on the source addresses of out-going
      packets.  Policy routing is illustrated in the table below.

                Src.                     Next Hop
                2001:db8:a:1::/64        ISP1
                3ffe:1800:a:1::/64       ISP2

       This kind of routing method, however, isn't so common for
      consumer network routers.  Even if this technique is implemented,
      it may degrade packet forwarding performance seriously when it
      doesn't have hardware acceleration support.  One alternative for
      policy routing is to use a routing protocol or some similar
      protocols and give a consumer network gateway as much routing
      information as the gateway can do destination address based
      routing.  In this example, the routing table of the gateway looks
      like this.

                Dst.                     Next Hop
                2001:db8::/32            ISP1
                ::/0                     ISP1
                3ffe:1800::/32           ISP2


4.1.2  Discussion

   The benefits of this scheme are very clear.  Every end node can
   determine which source address should be used and can send packets
   without a risk of failure due to ingress filtering or the limited
   reachability of a closed network.

   What should be discussed from here is the need for and implementation
   of policy enforcement to end nodes and the process of combining
   multiple address-selection policies.  It's so hard to combine two
   policies automatically when a policy coming from an ISP conflicts
   with another ISP's policy.  We may also have to think about combining
   or pruning algorithm to contain too much policy information in one
   packet.







Matsumoto, et al.        Expires August 1, 2005                [Page 10]


Internet-Draft          SAS Policy Distribution             January 2005


4.2  Case 2: Host with Multiple Addresses and Connectivity to Two Global
    Networks


                     ==================
                     |    Internet    |
                     ==================
                          |       |
            2001:db8::/32 |       | 3ffe:1800::/32
                     +----+-+   +-+----+
                     | ISP1 |   | ISP2 |
                     +----+-+   +-+----+
                          |       |
          2001:db8:a::/48 |       | 3ffe:1800:a::/48
            (DHCP-PD')   ++-------++   (DHCP-PD')
                         | Gateway |
                         +----+----+
                              |  2001:db8:a:1::/64
                              |  3ffe:1800:a:1::/64
                              |        (RA'/DHCP')
                    ------+---+----------
                          |
                        +-+----+ 2001:db8:a:1:EUI64
                        | Host | 3ffe:1800:a:1:EUI64
                        +------+

                           [Fig. 4]

    Fig.  4 shows a host with multiple addresses that subscribes to two
   ISPs for connectivity to the Internet.  The manner of address
   delegation and allocation is as described in the previous example.

4.2.1  Description of Each Element

   i) ISP -> Gateway
      The difference between this and the previous example is that ISP2
      provides global network connectivity, so the DHCP-PD' address-
      selection policy option for ISP2 includes an additional entry.

                Address                 Addr. Sel. Policy
                3ffe:1800:a::/48 --+-- 3ffe:1800::/32
                                   +-- ::/0

   ii) Gateway -> Host
      As both ISPs provide global network connectivity, the policy for
      address-selection from the gateway router to the end nodes is of
      the form shown below.




Matsumoto, et al.        Expires August 1, 2005                [Page 11]


Internet-Draft          SAS Policy Distribution             January 2005


                        Address                  Addr. Sel. Policy
                1      2001:db8:a:1::/64  --+-- 2001:db8::/32
                                            +-- ::/0
                2      3ffe:1800:a:1::/64 --+-- 3ffe:1800::/32
                                            +-- ::/0  (deleted)

       Note that the gateway is notified of an address-selection policy
      that includes prefix ::/0 by both ISPs.  A policy table cannot
      have multiple entries whose prefixes are the same and labels
      aren't the same, which we call conflicting policies.

      Though the next section includes further statements about merging
      conflicting policies, there are basically two solutions for this
      issue: to remove all the conflicting policies or to choose one.
      Here, we continue the description of this example with the latter
      solution, so the second entry above is removed here and not
      forwarded down-stream.

   iii) Host
      Each end node will have the following address-selection policy
      table.

                Prefix.             Pref.     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

       It doesn't have any conflicting entries anymore, owing to the
      conflict removal at the gateway.  Thus, end nodes can determine a
      source address for any destination addresses without any trouble.

   iv) Gateway
      If you remove conflicting source address selection policies for
      ::/0 and choose one ::/0 policy, the gateway can do destination
      address based routing.  The routing table at the gateway looks
      like this.

                Dst.                     Next Hop
                2001:db8::/32            ISP1
                ::/0                     ISP1
                3ffe:1800::/32           ISP2

       Here, we assume that end nodes select an appropriate source
      address for any destination addresses by the aid of distributed
      source address selection policy.  So, destination address based
      routing suffices in this case.



Matsumoto, et al.        Expires August 1, 2005                [Page 12]


Internet-Draft          SAS Policy Distribution             January 2005


4.2.2  Discussion

   One of the benefits of having an ISP provide address-selection policy
   to its customers is that it can explicitly check incoming packets to
   see if it is delegated their source addresses.  Delivery of an
   address-selection policy makes the following mechanisms possible.

   -  Since end nodes and routers in a multihoming site are given some
      kind of routing information, they can select the route expected to
      be optimal.  In the above example, end nodes can communicate with
      servers of the ISPs without any circumvention.
   -  Another possible usage of this framework is notification of
      security policy.  ISPs commonly apply IP-address-based filtering
      to packets that attempt access to their services, such as POP,
      SMTP and Web content, partly for security reasons and partly as a
      value- added service for their customers.

4.3  Case 3: A Host Directly Connected to Multiple ISPs


                     ==================
                     |    Internet    |
                     ==================
                          |       |
            2001:db8::/32 |       | 3ffe:1800::/32
                          |       |
          2001:db8:a::/48 |       | 3ffe:1800:a::/48
          (DHCP-PD') +----+-+   +-+----+  (DHCP-PD')
                     |  GW1 |   | GW2  |
                     +----+-+   +-+----+
        2001:db8:a:1::/64 |       | 3ffe:1800:a:1::/64
        (RA'/DHCP')       |       |        (RA'/DHCP')
                     -----+---+---+-----
                              |
       2001:db8:a:1:EUI64  +--+---+ 3ffe:1800:a:1:EUI64
                           | Host |
                           +------+

                           [Fig. 5]

    This example shows an end node directly connected to two ISPs, both
   of which provide global network connectivity.  This case also has
   source address selection problem.  Even if a host has enough
   knowledge about up-stream network addresses and routes, a host in
   this site cannot select an appropriate source address for a given
   destination address, as we've mentioned in the problem statement
   section.




Matsumoto, et al.        Expires August 1, 2005                [Page 13]


Internet-Draft          SAS Policy Distribution             January 2005


   [I-D.ietf-ipv6-router-selection] defines another Neighbor Discovery
   Router Advertisement option for distributing routing information.  In
   a case that a host has two network interfaces and is connected to
   gateways on a separate link, routing information suffices for
   choosing a correct source address.  In a site like this, however, a
   host should store relationships between routing information and
   source address selection.  So, in this kind of site, it seems to be
   better to use both router-selection mechanism, for distributing
   routing information, and our mechanism, for distributing source
   address selection policy.

   In case gateways are under your control, there is one alternative
   approach.  It is to redirect packets with a wrong source address at
   gateways.

5.  Who merges conflicting policies and how ?

   Another discussion topic should be about merging method of
   conflicting policies and who merges them.  As far as an end node
   cannot have or make use of multiple source address selection policy
   entry for the same prefix, somebody has to merge them into one
   policy.  There may be three cases for this issue; the site exit
   gateway does the merging job, end nodes do and both gateways and end
   nodes do.

   The management cost of a site might be relatively low, if you let a
   gateway to decide which policy to choose, in that you have only to
   configure the gateway.

   In contrast, if you give end nodes all the information the gateway
   received, you can let each end node to choose which source address
   selection policy to apply and to select which access-line to use.
   This means, at the same time, you have to configure each end node.

   Even in such a site that a gateway removes policy conflicts, an end
   node should be capable of receiving and manipulating conflicting
   policies in case that an additional gateway gets into a local link.

6.  Failure Recovery

   When one of the links to up-stream ISPs has network trouble and the
   consumer gateway detects it, the gateway can take the following
   responses.

6.1  Stop advertising

   "Stop advertising IPv6 address prefix of the ISP in trouble."




Matsumoto, et al.        Expires August 1, 2005                [Page 14]


Internet-Draft          SAS Policy Distribution             January 2005


   If the address is assigned by Router Advertisement, this doesn't have
   effects on source address selection immediately, because IPv6 address
   has relatively long valid and preferred lifetime.

6.2  Address Revocation

   "Revoke an address delegated by an ISP in trouble."

   If IPv6 address is assigned to end nodes by DHCPv6, the gateway
   (DHCPv6 Server) can revoke those addresses that is delegated by a
   troubled ISP in a reasonably short time.

6.3  Policy Modification

   "Distribute modified source address selection policy that prevents
   end nodes from using a certain address."

   By distributing, for example, the following source address selection
   policy to end nodes, the gateway can control end hosts' address
   selection quickly.

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

    In this case, this host doesn't use the address 3ffe:1800:a:1:EUI64,
   except when it communicate with hosts on the same link.

   You may argue that Router Advertisement is essentially a rather
   static protocol and isn't suitable for this kind of dynamic
   configuration modification.  However, it seems also to be true that
   these failure recovery methods are useful enough.  We basically leave
   this topic to an operational issue.

7.  Solution Comparison

7.1  Site Local Address

   One alternative method for this approach is to use site-local address
   for closed network ISP.  The site-local address, however, is
   deprecated and isn't recommended to use anymore.  The newly proposed
   site-local address, what we call Unique Local IPv6 Unicast Address
   [I-D.ietf-ipv6-unique-local-addr], isn't appropriate for such kind of
   use as this, because the address block size of it (/48) is too small
   for ISPs to delegate a certain size of IPv6 address block to each



Matsumoto, et al.        Expires August 1, 2005                [Page 15]


Internet-Draft          SAS Policy Distribution             January 2005


   customer.

7.2  Router Selection

   Router Selection [I-D.ietf-ipv6-router-selection] internet-draft is a
   proposal for introducing new options for Router Advertisement.  As it
   is mentioned in section 4.3, this is a solution especially for those
   IPv6 nodes that has multiple network interfaces and assigned one IPv6
   address for each network interface.  Our proposal and this draft
   surely has close relationship with each other, but our scope of
   problem cannot be resolved only by this mechanism.

7.3  Routing Protocol Based Policy Distribution

   Another alternative might be such a modified form of routing
   protocol, so that it can store relationships of routes and source
   address selection policy.  However, it seems to be a big drawback
   that consumer site gateway has to support a dynamic routing protocol.
   This can bring a big impact on both consumer site gateways and a
   provider edge routers.

8.  Security Considerations

   With regard to the possibility of traffic abduction through the
   announcement of a bogus policy, this scheme seems to neither lower
   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.

9.  Revision History

   The previous revision of this document is
   "draft-arifumi-multi6-sas-policy-dist-00.txt".
   [I-D.arifumi-multi6-sas-policy-dist] Here lists differences from it.

   o  Section 2,5,6,7,9 are added.
   o  We removed descriptions that show dependency on source address
      base routing.
   o  3rd case in section 4 is changed to one network interface host
      from two.
   o  A little description about merging conflicting policies is added
      to 2nd case in section 4.

10.  IANA Considerations




Matsumoto, et al.        Expires August 1, 2005                [Page 16]


Internet-Draft          SAS Policy Distribution             January 2005


   This document has no actions  for IANA.

11.  Acknowledgement

   Many thanks to 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.

12.  References

12.1  Normative References

   [I-D.ietf-ipv6-router-selection]
              Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", draft-ietf-ipv6-router-selection-07
              (work in progress), January 2005.

   [I-D.ietf-ipv6-unique-local-addr]
              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
              progress), January 2005.

   [RFC2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

   [RFC2991]  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
              Multicast Next-Hop Selection", RFC 2991, November 2000.

   [RFC2992]  Hopps, C., "Analysis of an Equal-Cost Multi-Path
              Algorithm", RFC 2992, November 2000.

   [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.

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

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

12.2  Informative References

   [I-D.arifumi-multi6-sas-policy-dist]
              Matsumoto, A., "Source Address Selection Policy
              Distribution for Multihoming",



Matsumoto, et al.        Expires August 1, 2005                [Page 17]


Internet-Draft          SAS Policy Distribution             January 2005


              draft-arifumi-multi6-sas-policy-dist-00 (work in
              progress), October 2004.


Authors' Addresses

   Arifumi Matsumoto
   NTT PFLab
   Midori-Cho 3-9-11
   Mitaka City, Tokyo Prefecture  180-8585
   JP

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


   Tomohiro Fujisaki
   Midori-Cho 3-9-11
   Mitaka City, Tokyo Prefecture  180-8585
   JP

   Phone: +81 422 59 7351
   EMail: fujisaki@syce.net


   Hirotaka Matsuoka
   Midori-Cho 3-9-11
   Mitaka City, Tokyo Prefecture  180-8585
   JP

   Phone: +81 422 59 4949
   EMail: matsuoka@syce.net


   Jun-ya Kato
   Midori-Cho 3-9-11
   Mitaka City, Tokyo Prefecture  180-8585
   JP

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










Matsumoto, et al.        Expires August 1, 2005                [Page 18]


Internet-Draft          SAS Policy Distribution             January 2005


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 (2005).  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 August 1, 2005                [Page 19]