Internet DRAFT - draft-arifumi-ipv6-nd-source-address-select

draft-arifumi-ipv6-nd-source-address-select




                                                    Arifumi Matsumoto
Internet-Draft                                      Tomohiro Fujisaki
Expires: July 26, 2005                              Hirotaka Matsuoka
                                                          Jun-ya Kato
                                                          NTT PF Lab.
                                                     January 26, 2005


              Configuring Source Address Selection Policy
                by Neighbor Discovery Protocol for IPv6
             draft-arifumi-ipv6-nd-source-address-select-02

Status of this Memo

   By submitting this Internet-Draft, we certify that any applicable
   patent or other IPR claims of which we are aware have been disclosed,
   or will be disclosed, and any of which we 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.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.


Abstract

   This document describes a Neighbor Discovery IPv6 Source Address
   Selection(SAS) Policy option for distributing of source address
   selection policies to end nodes.  This option is particularly
   effective when a consumer site has multiple address blocks.  Every
   end node is guided by such a policy in selecting an appropriate
   source address for each destination address.  This makes it possible



Arifumi                   Expires July 26, 2005                 [Page 1]

Internet-Draft                                              January 2005


   for an end node to set up a connection without concern for transfer
   failures due to ingress filtering by ISPs, for ISP operators to
   manage user behavior and networking policy, and for consumers to be
   provided with networks that are almost automatically robust and
   reliable.

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 current means of selecting the ISP for
   an outgoing packet is based on the destination address.  Actually, in
   general, 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 with illegal source addresses.

   In another Internet-Draft [1], we propose a technique that can be
   used both to distribute policy information for source address
   selection(SAS) at end nodes and to establish a method for packet-
   forwarding by routers.  This enables ISPs to control incoming traffic
   from customer sites and the end nodes to select appropriate source
   addresses. It also enables the selection of outgoing ISPs in a way
   that is almost certain to produce successful connection setups.

   In this document, we propose an extension to the Neighbor Discovery
   Router Advertisement Message [2].  In another draft, we propose a new
   option [5] for DHCPv6 [3,4] to handle delivery of address selection
   policies end nodes.  An address selection policy delivered to an end
   node is stored in the form of a policy table, as defined in RFC 3484
   [6].  These two drafts are protocol specifications implementing the
   multihome network technique proposed previously [1].


2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [7].


3. Message formats

3.1. Changes to Prefix Information option of Router Advertisement
   Message

   The change from Neighbor Discovery [2] section 4.6 is as follows:




Arifumi                   Expires July 26, 2005                 [Page 2]

Internet-Draft                                              January 2005


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Prefix Length |L|A|M|  SASID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Valid Lifetime                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Preferred Lifetime                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Reserved2                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                            Prefix                             +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   SASID
        A 5-bit unsigned integer; the identifier of the Source Address
        Selection (SAS) Policy option related to this Prefix Information
        option.  Each Prefix Information option can be linked with one
        SAS Policy option, as mentioned in the next paragraph.  If this
        Prefix Information option isn't bound with any SAS Policy
        option, the value of this field must be zero.  Otherwise, it
        will be the identifier of the corresponding SAS option.





















Arifumi                   Expires July 26, 2005                 [Page 3]

Internet-Draft                                              January 2005


3.2 Source Address Selection (SAS) Policy option

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |      Reserved       |  SASID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                                               |
   +-+-+-+-+-+-+-+-+          Prefix (Variable Length)             |
   |                                                               |
   |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               | Prefix Length |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Prefix (Variable Length)    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                    Prefix Length & Prefix ...                 .
   .                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                     |  Padding and End Marker |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Fields:

   Type     TBD

   Length   An 8-bit unsigned integer; the length of the option
           (including the Type and Length fields) in units of 8 octets.

   Reserved A 10-bit unused field.  This field MUST be initialized to
           zero by the sender and ignored by the receiver.

   SASID    A 5-bit unsigned integer; the identifier of the SAS Policy
           option.  A Router Advertisement Message cannot contain
           multiple SAS Policy options with the same SASID.  With this
           identifier, the SAS Policy options are linked with the Prefix
           Information option.  An SAS Policy option with no linked
           Prefix Information option will be discarded.

   Prefix Length
           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.  The Prefix Length field contains
           the number of valid leading bits in the prefix.  The bits in
           the Prefix after the prefix length (if any) MUST be



Arifumi                   Expires July 26, 2005                 [Page 4]

Internet-Draft                                              January 2005


           initialized to zero by the sender and ignored by the
           receiver.  Pairs of Prefix Length and Prefix field may follow
           here.

   Padding and End Marker  A variable-length padding field for 32-bit
           alignment.  This field also serves as a end marker and MUST
           be initialized to 1 by the sender and ignored by the
           receiver, in order not to be confused with Prefix field.

   This option appears only in Router Advertisement Message and has to
   have corresponding Prefix Information option within the same Router
   Advertisement Message.  Otherwise, this option MUST be ignored.

3.3 Discussion

   The SASID, mentioned above, is used to link the Prefix Information
   and a SAS Policy option.  This field occupies as much space as 5-bit
   reserved field in the Prefix Information option.  Instead of the
   SASID, an alternative method of linking is to copy the prefix of the
   corresponding Prefix Information option into the SAS Policy option,
   as shown in the figure below.  This method, however, is expected to
   consume more option space.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Prefix Length |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                            Prefix                             |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Length |                                               |
   +-+-+-+-+-+-+-+-+          Prefix (Variable Length)             |
   |                                                               |
   |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               | Prefix Length |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Prefix (Variable Length)    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            Prefix ...                         .
   .                                               +-+-+-+-+-+-+-+-+
   |                                               |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





Arifumi                   Expires July 26, 2005                 [Page 5]

Internet-Draft                                              January 2005


4. Specifications

4.1 Router Specification

    - The SAS Policy option MUST NOT appear in anything other than a
      Neighbor Discovery Router Advertisement Message.

    - Multiple Prefix Information options can share the same SASID.

    - When a router has too much information to make into one packet
      (1280 bytes), the incident SHOULD be reported or logged.

4.2 Host Specification

    - An SAS Policy option in anything other than a Neighbor
      Distribution Router Advertisement Message MUST be ignored.

    - Each SAS Policy option is linked with one or more Prefix
      Information options.  This tuple will be kept in a policy table,
      as defined in RFC 3484, Section 2.1 [6].  Assume that a host
      receives the following tuples:

            Prefix            SAS

            2001:1:1:1::/64 - SAS1 (2001:1::/16, 2001:2::/16)
            2001:2:2:2::/64 - SAS1 (2001:1::/16, 2001:2::/16)
            2002:3:3:3::/64 - SAS2 (::/0)

                                Table 1

      Then, these tuples are stored in a policy table like that shown
      below.

            Prefix           Precedence  Label

            2001:1:1:1::/64  undefined   10
            2001:2:2:2::/64  undefined   10
            2001:1::/16      undefined   10
            2001:2::/16      undefined   10
            2002:3:3:3::/64  undefined   20
            ::/0             undefined   20

                                Table 2

      The first two tuples in Table 1 are linked with the same SAS
      Policy option (SAS1), so they are also linked with each other, and
      thus, they have the same Label value in Table 2.




Arifumi                   Expires July 26, 2005                 [Page 6]

Internet-Draft                                              January 2005


    - When two Prefixes contained in different SAS Policy options are
      the same, the Prefixes will be ignored.

    - Each SAS Policy option has a lifetime, which is the valid lifetime
      of the corresponding Prefix Information option.  When an SAS
      Policy option is related to multiple Prefix Information options,
      its lifetime will be the maximum lifetime among those of all the
      Prefix Information options.

5. Security Considerations

   With regard to the possibility of traffic abduction by announcing a
   bogus policy, this scheme seems to neither lower nor raise the
   security level obtained with the existing base protocol, namely,
   Neighbor Discovery Router Advertisement.  It does, however, 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.


6. IANA Considerations

   This document defines a new ICMP option type.  This must be assigned
   ICMPv6 type number.


7. Revision History

   - Unit of Source Address Selection Policy Option's Length field was
     changed to 8 octets in conformance with RFC 2461.

   - The length of SASID field in Prefix Information Option and Source
     Address Selection Policy Option reduced to 5 bits for the support
     of R flag defined by MobileIPv6 [8].

   - The field name 'padding' was changed to 'padding and end marker' to
     clarify that it isn't just a padding.


8. Normative References

   [1]    Matsumoto, A., Fujisaki, T., Matsuoka. H and J. Kato, "Source
          Address Selection Policy Distribution for Multihoming",
          Internet-Draft, January 2005, draft-arifumi-ipv6-sas-policy-
          dist-00.txt. (Work In Progress)

   [2]    Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery



Arifumi                   Expires July 26, 2005                 [Page 7]

Internet-Draft                                              January 2005


          for IP Version 6 (IPv6)," RFC 2461, December 1998.

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

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

   [5]    Matsuoka, H., Fujisaki, T., Kato, J. and A. Matsumoto, "Source
          Address Selection Option DHCPv6," Internet-Draft, October
          2004, draft-hirotaka-dhcp6-sas-option-00.txt.

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

   [7]    S. Bradner, "Key words for use in RFCs to Indicate Requirement
          Levels", BCP 14, RFC 2119, March 1997.

   [8]    D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6",
          RFC 3775, June 2004.


Authors' Addresses

   Arifumi Matsumoto
   Nippon Telegraph and Telephone Corporation
   Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585 Japan
   Phone: +81-422-59-3334
   E-Mail: matsumoto.arifumi@lab.ntt.co.jp

   Tomohiro Fujisaki
   Nippon Telegraph and Telephone Corporation
   Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585 Japan
   Phone: +81-422-59-7351
   E-Mail: fujisaki.tomohiro@lab.ntt.co.jp

   Hirotaka Matsuoka
   Nippon Telegraph and Telephone Corporation
   Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585 Japan
   Phone: +81-422-59-4949



Arifumi                   Expires July 26, 2005                 [Page 8]

Internet-Draft                                              January 2005


   E-Mail: matsuoka.hirotaka@lab.ntt.co.jp

   Jun-ya Kato
   Nippon Telegraph and Telephone Corporation
   Information Sharing Platform Laboratories
   3-9-11 Midori-cho
   Musashino-shi, Tokyo 180-8585 Japan
   Phone: +81-422-59-2939
   E-Mail: kato.junya@lab.ntt.co.jp


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  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.

   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.

Intellectual Property

   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.



Arifumi                   Expires July 26, 2005                 [Page 9]