[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                  Hirotaka Matsuoka
Internet-Draft                                                  NTT West
Category: Proposed Standard
Created: April 8, 2009
Expires: October 8, 2009


             A Try and Error type approach for multihoming
               draft-matsuoka-multihoming-try-and-error-00


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and 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.




Abstract

   [RFC5220] describes the possible problems which an end host may
   experience, if the end host has multiple prefixes in a single
   physical link. This document proposes a solution of so-called "try
   and error" type about these problems originated in "Source Address
   Selection" which is described in [RFC5220]. A new mechanism to
   settle almost all of these problems is described in this document,
   but actually it is not effective in some particular cases. Thus it is
   necessary for every end user/host to be able to select on/off of this
   mechanism.







Matsuoka                 Expires October 8, 2009                [Page 1]


Internet-Draft A Try and Error type approach for multihoming  April 2009


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   1
   2.  Problems to be solved and preconditions . . . . . . . . . . .   3
   3.  Proposed mechanism
     3.1.  End host categorize source IP addresses
           as high/low priority  . . . . . . . . . . . . . . . . . .   3
     3.2.  End host detect invalid source IP address
           using ICMPv6 error message  . . . . . . . . . . . . . . .   4
   4.Requirements
     4.1.End host Requirements . . . . . . . . . . . . . . . . . . .   4
     4.2.ISP network requirements  . . . . . . . . . . . . . . . . .   5
   5. "prohibited address pair list" and "working address pair list"
     5.1.Overview  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.2. Prohibited address pair list . . . . . . . . . . . . . . .   6
     5.3. working address pair list  . . . . . . . . . . . . . . . .   7
   6. Security Considerations  . . . . . . . . . . . . . . . . . . .   7
   7. References . . . . . . . . . . . . . . . . . . . . . . . . . .   8


Requirements Language

   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 RFC 2119 [RFC2119].


1.  Introduction

   When an end host has multiple prefixes/addresses in a physical link,
   it is required for end node to use a specific source prefix/address
   which is allocated by the egress ISP network. Some types of problems
   in this situation are pointed out in [RFC5220]. Some kind of
   improvements in consumer premises equipment (CPE) router and/or an
   end host must be needed to fix these problems. [RFC5221] describes
   requirements for the mechanisms of solutions about these problems,
   and T.Fujisaki [draft-fujisaki-dhc-addr -select-opt-06] proposes a
   mechanism which ISP networks provide information to select a collect
   source prefix/address by using DHCPv6 option message.

   Actually, a perfect solution which can fix all problems originated in
   "Source Address Selection" may be needed in the future. On the other
   hand, a "Light type" solution which cannot fix a few, but can fix
   almost all problems is very useful. M.Bagnulo proposed "Try and
   Error" type approach [draft-ietf-6man-addr-select-sol-01], which
   end host re-tried to communicate with another source address if the
   end host detected communication failure that originates in source
   address miss-selection. It is important that in general most end host
   must not have so many prefix/addresses, but 2-3 or less. Based on
   this assumption, an end host will find a correct source
   prefix/address within two times attempt.


Matsuoka                 Expires October 8, 2009                [Page 2]


Internet-Draft A Try and Error type approach for multihoming  April 2009


   This document proposes a new "Try and Error" type solution. This
   document does not include solutions to fix every kind of problems
   originated in "Source Address Selection". The problems and
   precondition that this document mentions are described in Section 2.

   ICMPv6[RFC2463] can transmit the information of network state, and
   many documents define ICMPv6 message, and expected behavior of an end
   host which detects an icmpv6 message, respectively. Both the
   description of proposed solution and the arrangement of relationship
   in these documents are in Section 3. And the importance that an end
   host which receives a specific ICMPv6 message retries the
   communication immediately is also described in this section.
   Requirements for end hosts and network are in section 4, and the
   example of implementation is in section 5. The verification from the
   perspective of [RFC5221] is in section 6.


2. Problems to be solved and preconditions

   This document mainly describes the solution about the problem
   originated in "Source Address Selection" which is described in
   [RFC5220] section 2.1. On the other hand, this document doesn't
   describe the problems about routing, for example, some routers on a
   link don't cooperate each other, or a CPE router which has multiple
   ISP uplinks uses them in round robin manner, etc. This document is
   described on the assumption that correct routing information is
   configured manually or automatically in their routers, and end hosts
   will send packets to their default gateway router if an end host
   doesn't have specific routing information.


3. Proposed mechanism

3.1. End host categorize source IP addresses as high/low priority

   If "Try & Error" type approach is adopted, an end host has no need to
   recognize source IP address that can communicate to destination IP
   address before the communication starts. It is sufficient for an end
   host to select a suitable source IP address which based on a rule
   like [RFC3484] or others before the communication starts. When an end
   host recognizes communication failure because of source IP address
   miss-selection, an end host MUST memorize the source IP address that
   should not be used for communicating to the destination IP address
   "prohibited source address". An end host MUST reconnect to the
   destination IP address with using the most suitable source IP address
   except prohibited source addresses.

   ICMPv6 error message is suitable to transmit an end host the source
   address miss-selection. On the other hand, if an end host receives an
   incoming packet including TCP Syn+Ack, the end host MUST memorize the



Matsuoka                 Expires October 8, 2009                [Page 3]


Internet-Draft A Try and Error type approach for multihoming  April 2009


   working source and destination address pair which is used in the
   incoming packet, and the end host MUST use the pair of addresses for
   an outgoing packet by priority.

3.2. End host detect invalid source IP address using ICMPv6 error
 message

   [RFC2463]-Section3.1 defines ICMPv6 destination unreachable error
   messages "Type=1 Code=0-4" which are informed from a network node to
   an end host, and [RFC4443] defines informative subsets of "Type=1
   Code=1" as "Type=1 Code=5,6", respectively. But there is no
   requirement about behavior for end node which receive these ICMPv6
   error messages.

   [RFC1122] defines ICMPv4 destination unreachable message "Type=3
   Code=2-4" as Hard Error condition, and an end host which receives
   these ICMPv4 error messages must terminate the corresponding
   communication. F.Gont [RFC5461] describes ICMPv6 destination
   unreachable message "Type=1 Code=0,3" as Soft Error condition in
   comparison with the case in ICMPv4. According to these definition,
   ICMPv6 error messages "Type=1 Code=1,2,4,5,6" are classified into
   Hard Error condition, and an end host which receives these ICMPv6
   error messages MUST terminate the corresponding communication.

   [RFC4443] defines ICMPv6 error message "Type=1 Code=5" as follows.
   If the reason for the failure to deliver is that the packet with this
   source address is not allowed due to ingress or egress filtering
   policies, the Code field is set to 5.
   An end host which receives this type of error message MUST terminate
   the corresponding communication, because communication failure has
   occurred in source IP address miss-selection.


4.Requirements

4.1.End host Requirements

   a. Every end host MUST have "working address pair list" which
      described in Section 5. This list MUST be given priority than the
      mechanism of source IP address selection defined in [RFC3484].

   a-1. An end host which received an incoming packet including TCP
        Syn+Ack SHOULD memorize the source and destination IP addresses
        of an incoming packet as the destination and source IP addresses
        of "the working address pair list".

   b. Every end host MUST have "prohibited address pair list" which
      described in Section 5.2. This list MUST be given priority than
      both of "working address pair list" and the source IP address
      selection mechanism which is defined in [RFC3484].



Matsuoka                 Expires October 8, 2009                [Page 4]


Internet-Draft A Try and Error type approach for multihoming  April 2009


   b-1. An end host which received an ICMPv6 "Type=1 Code=5" packet MUST
        obtain the source and destination IP addresses which are
        indicated in the invoked packet information and MUST memorize
        them into "the prohibited address pair list".

   c. The end host which received ICMPv6 "Type=1 Code=5" MUST terminate
      the corresponding communication which was indicated in the invoked
      packet information, immediately. After memorizing the new entry
      into "the prohibited address pair list", the end host SHOULD retry
      to communicate to the same destination IP address. The most
      important thing is that "the prohibited address pair list" is
      given higher priority than both of "working address pair list" and
      the source IP address selection mechanism which is defined in
      [RFC3484]. As a result, the source IP address which has caused
      source address miss-selection will not be used.

   c-1. In the case using TCP protocol communication, kernel in an end
        host MUST edit "the prohibited address pair list" before
        retrying the communication to the same destination IP address.

   c-2. In the case using UDP protocol communication, kernel in an end
        host MUST edit "the prohibited address pair list" and MUST
        terminate the corresponding communication and inform error
        message to application. Afterwards, this host will try to
        communicate to the same destination IP address with another
        source IP address.

4.2.ISP network requirements

   a. An ISP network which is connected to end users directly MUST reply
      ICMPv6 "Type=1 Code=5" to the end host that tries to communicate
      with different source IP prefix that the ISP allocated to the end
      user.

   b. An ISP network which does not connect with end users directly MUST
      NOT reply ICMPv6 "Type=1 Code=5" to the end host. An ISP network
      which connects with end users directly SHOULD NOT transmit this
      kind of messages to end user hosts.


5. "prohibited address pair list" and "working address pair list"

5.1.Overview

   Every end node MUST have "prohibited address pair list" and "working
   address pair list" respectively. Some system MAY have these list
   separately, or MAY express them in one list. The most important thing
   is that the prohibited address pair list is given priority than the
   working address pair list, and it is possible to adjust to the
   composition change in the network, when a working address pair is



Matsuoka                 Expires October 8, 2009                [Page 5]


Internet-Draft A Try and Error type approach for multihoming  April 2009


   obsoleted.


               ====================================================
               |                      Internet                    |
               ====================================================
                   |                      |                      |
2001:db8:7000::/36 |   2001:db8:8000::/36 |   2001:db8:9000::/36 |
              +----+-+                +---+--+               +---+--+
              | ISP1 |                | ISP2 |               | ISP3 |
              +----+-+                +---+--+               +---+--+
                   |                      |                      |
2001:db8:7000::/48 |   2001:db8:8000::/48 |   2001:db8:9000::/48 |
             +-----+---+             +----+----+           +-----+---+
             | Router1 |             | Router2 |           | Router3 |
             +-------+-+             +------+--+           +-------+-+
                     |                      |                      |
2001:db8:7000:1::/64 | 2001:db8:8000:1::/64 | 2001:db8:9000:1::/64 |
                     |                      |                      |
               ------+----------------------+----------------------+--
                            |
                          +-+----+ 2001:db8:7000:1::abc
                          | Host | 2001:db8:8000:1::abc
                          +------+ 2001:db8:9000:1::abc

                                 [Figure 1]


5.2. Prohibited address pair list

   In this list, every record about a specific destination IP address
   can have multiple source IP addresses. Records generates
   automatically when the system accept ICMPv6 "Type=1 Code=5" error
   message, and records SHOULD be configured also manually. In the above
   figure, the list describes as below.

   +-----------------+----------------------------------------------+
   |Destination      |  Source IP Addresses                         |
   +-----------------+----------------------------------------------+
   |2001:db8:1:1::80 | 2001:db8:7000:1::abcd  2001:db8:8000:1::abcd |
   |2001:db8:2:2::80 | 2001:db8:8000:1::abcd  2001:db8:9000:1::abcd |
   |2001:db8:3:3::80 | 2001:db8:7000:1::abcd  2001:db8:9000:1::abcd |
   +-----------------+----------------------------------------------+

                                  [Table 1]


   These parameters in this list will change according to the network
   composition, so that it is necessary to keep appropriate TTL. It is
   preferable that TTL is less than 24 hours, and more than 60 seconds.



Matsuoka                 Expires October 8, 2009                [Page 6]


Internet-Draft A Try and Error type approach for multihoming  April 2009


5.3. working address pair list

   In this list, every record about a specific destination IP address
   can have single source IP address. Records generates automatically
   when the system accept incoming packets including Syn+Ack packet, and
   records SHOULD be configured also manually. In the above figure, the
   list describes as below.

        +-----------------+-----------------------+
        |Destination      |  Source IP Address    |
        +-----------------+-----------------------+
        |2001:db8:1:1::80 | 2001:db8:9000:1::abcd |
        |2001:db8:2:2::80 | 2001:db8:7000:1::abcd |
        |2001:db8:3:3::80 | 2001:db8:8000:1::abcd |
        +-----------------+-----------------------+

                                  [Table 2]


   The following record MUST be deleted or ignored if exists, because
   "prohibited address pair list" must be given priority than "working
   address pair list"

        +-----------------+-----------------------+
        |Destination      |  Source IP Address    |
        +-----------------+-----------------------+
        |2001:db8:1:1::80 | 2001:db8:8000:1::abcd |
        +-----------------+-----------------------+

                                  [Table 3]


   These records must keep appropriate TTL as the same with the case of
   prohibited address pair list.


6.  Security Considerations

   This document requires end hosts to abort a connection when it
   receives an ICMPv6 error message "Type=1, Code=5". Therefore, an
   attacker wishing to reset an ongoing valid connection can send a
   malicious ICMPv6 error message. In this point of view, ISPs which
   directly connects with end user should stop any kind of malicious
   ICMPv6 error message.









Matsuoka                 Expires October 8, 2009                [Page 7]


Internet-Draft A Try and Error type approach for multihoming  April 2009


7.  References

   [RFC5220]  A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama,
              "Problem Statement for Default Address Selection in
               Multi-Prefix Environments: Operational Issues of RFC 3484
               Default Rules", RFC5220, July 2008.

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

   [RFC5221]  A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama,
              "Requirements for Address Selection Mechanisms", RFC5221,
              July 2008.

   [RFC2463]  A. Conta, S. Deering, "Internet Control Message Protocol
              (ICMPv6) for the Internet Protocol Version 6 (IPv6)
              Specification", RFC2463, December 1998.

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

   [RFC4443]  A. Conta, S. Deering, M. Gupta, "Internet Control Message
              Protocol (ICMPv6) for the Internet Protocol Version 6
              (IPv6) Specification", RFC4443, March 2006.

   [RFC1122]  R. Bradden, "RFC1122 - Requirements for Internet Hosts
              - Communication Layers", RFC1122, October 1989.

   [RFC5461]  F. Gont, "TCP's Reaction to Soft Errors", RFC5461,
              February 2009.

   [draft-fujisaki-dhc-addr-select-opt-07]
              Fujisaki, T., "Distributing Default Address Selection
              Policy using DHCPv6",
              draft-fujisaki-dhc-addr-select-opt-07 (work in progress),
              March 2009.

   [draft-ietf-6man-addr-select-sol-01]
              A. Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama,
              "Solution approaches for address-selection problems",
              draft-ietf-6man-addr-select-sol-01.txt (work in progress),
              June 2008.











Matsuoka                 Expires October 8, 2009                [Page 8]


Internet-Draft A Try and Error type approach for multihoming  April 2009


Authors' Addresses

   Hirotaka Matsuoka
   NTT West
   3-15 Bamba-cho Chuo-ku, Osaka 540-8511
   Japan

   phone: +81 6 4793 3921
   Email: matsuoka.h@west.ntt.co.jp



Intellectual Property Statement

   The IETF Trust 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 any IETF 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.

   Copies of Intellectual Property 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
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and


Matsuoka                 Expires October 8, 2009                [Page 9]


Internet-Draft A Try and Error type approach for multihoming  April 2009


   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.





Disclaimer of Validity

   All IETF Documents and the information contained therein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST 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 THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s)
   controlling the copyright in such materials, this document may not
   be modified outside the IETF Standards Process, and derivative
   works of it may not be created outside the IETF Standards Process,
   except to format it for publication as an RFC or to translate it
   into languages other than English.














Matsuoka                 Expires October 8, 2009               [Page 10]

Internet-Draft A Try and Error type approach for multihoming  April 2009

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/