INTERNET-DRAFT K. Ohira January 27, 2004 K. Ogata A. Matsumoto K. Fujikawa Y. Okabe M. Kozuka Kyoto University Y. Koyama Trans New Technology Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model Multi-Link Multihoming Site Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a method of automatic hierarchical IPv6 address assignment of a multi-link site with prefix delegation (PD) option enabled DHCPv6. This protocol is mainly designed to provide an effective list of addresses which a host will have for multi-address model multihome solutions. Ohira Expires on July 26, 2004 [Page 1] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 1. Introduction The site multihoming in IPv6 (multi6) WG explores scalable multi- homing solutions with minimum impacts on routing system and limited need for the number of prefixes advertised in the default-free zone. After long term discussions, multi-address model multihoming is watched with keen interest because it seems very scalable. Multi-address model multihoming makes good use of the advantage of IPv6: multiple addresses can be assigned to an interface. A host in a multihomed site has multiple addresses, one is delegated from a transit provider and another from another provider, and selects an address of the peer host and the host itself from candidate addresses. This solution gives multiple access paths without additional advertisement of prefixes in the default-free zone. As a multi-address multihoming solution, SCTP, TCP-MH (on the transport layer) and HIP, LIN6, MAST (on the shim layer which is between the network layer and the transport layer) are proposed. [ASL] describes that source address based routing is recommended to be used in a multihomed site in order to forward an outgoing packet to the proper transit provider. This protocol is designed to provide an effective list of addresses which a host will have for multi-address model multihome solutions. This document describes a way of automatic hierarchical IPv6 address assignment for a multi-link site with prefix delegation (PD) option enabled DHCPv6 [DHC, PDO]. 2. Terminology This document describes how to assign address prefixes in a multi- link multihomed site with "Prefix Option" enabled DHCPv6. Concerning about DHCPv6, this document uses the terminology defined in RFC 3315 [DHC] and RFC 3633 [PDO]. Concerning about site multihoming, this document uses the terminology defined in RFC 3582 [REQ]. Ohira Expires on July 26, 2004 [Page 2] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 3. Operation of Multihoming 3.1 Role of This Protocol Multi address model multihoming is, roughly speaking, the model in which a host has different addresses for each path. In this model, the number of addresses which a host has may increase to infinite. Furthermore, according to the increase of the number of addresses, the cost of management of those addresses also increase. Therefore, it becomes too complicated and troublesome to manage manually. This protocol proposes how to assign IP address prefix to each link in a site automatically. 3.2 Cooperation with Multi-Address aware Upper Layer Protocols The main feature of multihoming, redundancy and load sharing, will be taken by some multi address aware transport layer protocols (SCTP [SCT], TCP-MH [MHO],...) or shim layer protocols (HIP [HIP], LIN6 [LIN], MAST [MAS],...). Addresses which a node has may be renumbered. In order to be easy to rendezvous, it is recommended to use DDNS. After a connection has started, regardless of which upper layer protocol is used, the upper layer protocol should be able to handle the renumbering. In case that an authorized DNS server of a site itself is placed inside of the site, the DNS server is recommended to be placed on the first level link of a site exit router. This protocol does not prevent the use of MIP6 [MIP] for address portability. 4. Protocol Overview Basically, the format of messages passed between a delegating router and a requesting router in this protocol follows the definitions in RFC 3633 [PDO] or RFC 3315 [DHC]. This protocol defines only the usage of IPv6 address. The usage of IPv6 address is described in the section 4.1. In order addressing mechanism to take part in a routing mechanism, both delegating routers and requesting routers are assigned additional requirements besides the ones defined in RFC 3633 [PDO] or RFC 3315 [DHC]. The additional requirements are described in the Ohira Expires on July 26, 2004 [Page 3] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 section 4.2 and 4.3. In this section, an example network (figure 1) is considered. /~~~~~~~~\ /~~~~~~~~\ | ISP X | | ISP Y | \~~~~~~~~/ \~~~~~~~~/ | | -------------- | ---------------------- | --------------- | | | |site +------+ +------+ | | A | | B | V +------+ +------+ | | ======================== ========================= | | | | +------+ +------+ +------+ +------+ | C | | D | | E | | F | +------+ +------+ +------+ +------+ | | ======================== | +------+ | G | +------+ figure 1: An Example Network of a Site 4.1 Usage of IPv6 address According to [ADD], an IPv6 address is composed as shown in figure 2. This protocol describes how to assign "Subnet Identifier" for each link in a site and how to delegate IP address block for the next hop delegating router recursively. | n bits | m bits | 128-n-m bits | +------------------------+-----------+----------------------------+ | global routing prefix | subnet ID | interface ID | +------------------------+-----------+----------------------------+ figure 2: IPv6 Global Unicast Address In this protocol, subnet ID is splitted into four fields as shown in figure 3. Ohira Expires on July 26, 2004 [Page 4] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 | p bits | q bits | m-p-q bits | +--------------------+--------------------+-----------------------+ | delegated | delegating | link id | +--------------------+--------------------+-----------------------+ figure 3: Usage of Subnet Identifier The meaning of each field is as below. delegated : The subnet id part of prefix delegated to a delegating router. delegating : 0 - Room for subnet id of link itself. non-0 - A delegating router delegates to each requesting router. link id : Iff the delegating field is 0, this field has a meaning of link id. A delegating router assigns an id to each link of the delegating router. If the delegating field is non-0, this field has no specific meaning. For convenience of explanation, it is assumed that global routing prefix has 48 bits length and subnet id has 16 bits length (i.e. n=48, m=16) and every prefix delegating router sets the length of delegating field and link id field to 4 (i.e. q=4). As a result, subnet id field becomes as shown in figure 4. 4 5 6 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | delegating | Link ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ (a) at site exit router +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | delegated | delegating | Link ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ (b) at the 1st level delegating router +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | delegated | delegating | Link ID | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ (c) at the 2nd level delegating router figure 4: Example of Subnet Identifier Ohira Expires on July 26, 2004 [Page 5] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 As shown in figure 4, in this example, p=0 at site exit router, p=4 at the 1st level delegating router, p=8 at the 2nd level delegating router. As a result of prefix delegating, concerning about the prefix start with X::/48, the example network is addressed as shown in figure 5. /~~~~~~~~\ | ISP X | \~~~~~~~~/ | -------------- | --------------- | | |site +------+ site exit router | | A | X::/48 (0th level) V +------+ | ======================== X:0000::/64 ---- | -------- | -------------- +------+ +------+ | C | | D | X:1000::/52 1st level +------+ +------+ | ======================== X:1000::/64 ----------- | ------- | -------- +------+ +------+ X:1100::/56 | E | | G | 2nd level +------+ +------+ | ====================== X:1100::/64 ----- | -------- | ------------- +------+ +------+ | B | | F | 3rd level +------+ +------+ figure 5: Hierarchical expansion of the example network The Link ID field is needed for the case as shown in figure 6. Without Link ID field, two different links have to have the same Subnet Identifier but this is not allowed. Ohira Expires on July 26, 2004 [Page 6] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 | +------+ +-| H | X:2000::/52 | +------+ X:2000::/64 | | | X:2002::/64 =================== | =================================== | | | | | | | | X:2001::/64 | | | | | | | +------+ +------+ +------+ +------+ +------+ | a | | b | | I | X:2100::/56 | c | | d | +------+ +------+ +------+ +------+ +------+ | | H,I : router a-d : host figure 6: Usage of Link Identifier The prefix start with Y::/48 is assigned and delegated as similar as X::/48. 4.2 Delegating Router Behavior A delegating router can delegate address blocks to (2^q - 1) requesting routers. When a request from the (2^q)th requesting router, the delegating router will reject the request. In order to keep the management cost reasonable, it is recommended to set the number of delegated prefixes to each host to the following number: Preferred limit : 5 Maximum limit : 7. At the time when a delegating router has already delegate preferred limit numbers of prefix to a requesting host, if the requesting router wants to delegate another prefix which has higher priority than the prefixes which are already delegated, the delegating router must decrease the lifetime of the prefix which has the lowest priority of all delegated prefixes. A delegating router must not delegate more than the maximum limit numbers of prefixes to a requesting router in any case. The priority of delegated prefix is as below. 1. Shortest prefix length Ohira Expires on July 26, 2004 [Page 7] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 2. From different delegating router (from the nearest prior prefix) 3. Arrival order For the multihoming feature, this priority is calculated for each global routing prefix (/n). At the time of merging, even if the priority of a prefix is low, the most prior prefix of each global routing prefix should be delegated. Note that this is the reason why p bits length delegated subnet id is separately treated from n bit length global routing prefix. This ordering mechanism may be done with penalty based algorithm. First of all, pick up an address prefix with the shortest prefix length as the first prior prefix. Therefore, following the similarity with the first prior prefix, add penalty to the other prefixes and pick up a prefix with the least penalty as the second prior prefix. The third and less prior prefixes are picked up one after another. In order to prevent the loop of address assignment, a delegating router must not delegate smaller address block which is fully included into an address block which the delegating router itself has delegated. A son of site local address may be delegated and assigned. If [GLU] is used as son of site local address, a prefix and a global ID should be settled by only (candidates of) site exit routers. A multicast address must not be delegated by this protocol. Of course, link local address must not be delegated. 4.3 Requesting Router Behavior For calculating the priority of prefixes, a requesting router must hold the correspondence between a delegated prefix and a delegating router. For easy routing, it is recommended that a requesting router sets delegating router(s) as default next hop router(s). If a requesting router is delegated address prefixes from multiple delegating routers, then source address based routing should be put in operation at the requesting router. Ohira Expires on July 26, 2004 [Page 8] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 5. Considerations on RFC 3582 In this section, assessment how much this protocol meets the requirements described in RFC 3582 [REQ]. 5.1 Capabilities of IPv4 multihoming 5.1.1 Redundancy Every external connection is treated completely separate. Therefore, our proposing method is able to continue a connection unless all external connection fail. 5.1.2 Load Sharing A site is able to distribute both inbound and outbound traffic between multiple transit providers. 5.1.3 Performance No information between upstream ISPs is required. If a corresponding node can divide a stream into several destination addresses, we can accomplish to distribute inbound traffic. 5.1.4 Policy Policies of a site should be expressed as to assign or not to assign an address to a host. If a site does not want a host to use an external connection, the site can decide not to assign an address with the prefix specific to the external connection. If the site wants to shift traffic of a certain application to a specific ISP, the site should assign multiple addresses to a host and filter traffic whose source or destination has a specific pair of IP address and port number. Therefore the host knows the pair of IP address and port number is not usable and tries another pair. The behavior of a host should be defined in upper layer protocol, therefore it is out of scope of this proposal. 5.1.5 Simplicity It is recommended that routers are placed as balanced tree. Once topology of routers is fixed, addresses of each routers are Ohira Expires on July 26, 2004 [Page 9] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 automatically assigned. 5.1.6 Transport-Layer Survivability Answer of this issue is fully depend on what upper layer protocol will be used. This is out of scope of this proposal. 5.1.7 Impact on DNS Any change of external connections of a site cause change(s) of prefixes which the site has. Therefore, in the worst case, we may be required to change DNS information at every time. 5.1.8 Packet Filtering Our proposing method is designed to cooperate with ingress/egress filtering. If the source address of an IP packet is valid then the packet is forwarded to the proper next hop, otherwise the packet will be discarded. 5.2 Additional requirements 5.2.1 Scalability Only a Provider Aggregatable IP address block from upstream is required. This address is always aggregated at upstream, so even if the number of multihoming site with our proposing method increase, the number of routing information at default free zone. Still more, no AS number is required for a site to be multihomed. In these points, our proposing method is very scalable. 5.2.2 Impact on Routers Source address based routing is required for at least one router in a multihoming site. If there are some routers which cannot handle source address based routing, according to the position, routing loop may be occurred. The authors think that this requirement is relatively little because source address based routing is required only for default route entry. Ohira Expires on July 26, 2004 [Page 10] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 These modifications do not prevent normal single-homed operations. In a single-homed site, modified routers and unmodified routers can coexist. 5.2.3 Impact on Hosts Source address based routing is required for all end hosts who want to be fully multihomed. However, a legacy (without source address based routing) host can be obtain some functions of multihome. If you want to bind several IP addresses to a single TCP connection, TCP Extension for Multihoming may be useful. 5.2.4 Interaction between Hosts and the Routing System Information about proper next hop for each source address prefixes is needed to be exchanged. This interaction is quite simple and scalable. 5.2.5 Operations and Management Administrators of a site are completely capable to monitor the state or to configure parameters of multihoming. At this time, the administrators do not have to do any cooperative work with administrators of upstream. 5.2.6 Cooperation between Transit Providers Our proposing method does not require any cooperative work between upstream providers at all. 5.2.7 Multiple Solutions It is recommended that this protocol is used with a multiple address aware upper layer protocol on transport layer or shim layer. 6. Security Considerations Security considerations in DHCP are described in section 23, "Security Considerations" of RFC 3315 [DHC]. Security considerations in Prefix Options for DHCP are described in Ohira Expires on July 26, 2004 [Page 11] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 section 15, "Security Considerations" of RFC 3633 [PDO]. The use of this protocol does not introduce any additional known security concerns. 7. IANA Considerations There are no IANA considerations in this document. 8. References [REQ] J. Abley, et. al., "Goals for IPv6 Site-Multihoming Architectures", RFC3582, August 2003. [MAS] D. Crocker, "Multiple Address Service for Transport (MAST) : An Extended Proposal", Internet Draft (work in progress), draft-crocker-mast-proposal-01.txt, September 2003. [DHC] R. Droms, Ed., et. al., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC3315, July 2003. [GLU] R. Hinden, et. al., "Unique Local IPv6 Unicast Address", Internet Draft (work in progress), draft-ietf-ipv6-unique- local-addr-01.txt, September 2003. [ADD] R. Hinden, et. al., "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC3513, April 2003. [MIP] D. Johnson, et. al., "Mobility Support in IPv6", Internet Draft (work in progress), draft-ietf-mobileip-ipv6-24.txt, June 2003. [MHO] A. Matsumoto, et. al., "TCP Multi-Home Options", Internet Draft (work in progress), draft-arifumi-tcp-mh-00.txt, October 2003. [HIP] P. Nikander, et. al., "End-Host Mobility and Multi-Homing with Host Identity Protocol", Internet Draft (work in progress), draft-nikander-hip-mm-01,txt, December 2003. [ASL] K. Ohira, et. al., "IPv6 Address Assignment and Route Selection for End-to-End Multihoming", Internet Draft (work in progress), draft-ohira-assign-select-e2e-multihome-02.txt, October 2003. [SCT] R. Stewart, et. al., "Stream Control Transmission Protocol", RFC2960, October 2000. Ohira Expires on July 26, 2004 [Page 12] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 [LIN] F. Teraoka, et. al., "LIN6: A Solution to Multihoming and Mobility in IPv6", Internet Draft (work in progress, expired), draft-teraoka-multi6-lin6-00.txt, December 2003. [PDO] O. Troan, et. al., "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC3633, December 2003. 9. Authors' Addresses Kenji Ohira Graduate School of Informatics Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81-75-753-7468 Fax: +81-75-753-7472 Email: ohira@net.ist.i.kyoto-u.ac.jp Katsuya Ogata Graduate School of Informatics Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81-75-753-7468 Fax: +81-75-753-7472 Email: ogata@net.ist.i.kyoto-u.ac.jp Arifumi Matsumoto Graduate School of Informatics Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81-75-753-7468 Fax: +81-75-753-7472 Email: arifumi@net.ist.i.kyoto-u.ac.jp Kenji Fujikawa Graduate School of Informatics Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81-75-753-5387 Fax: +81-75-753-4961 Email: fujikawa@real-internet.org Ohira Expires on July 26, 2004 [Page 13] draft-ohira-multi6-multilink-auto-prefix-assign-00.txt January 27, 2004 Yasuo Okabe Academic Center for Computing and Media Studies Kyoto University Yoshida-Hommachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81-75-753-7458 Fax: +81-75-751-0482 Email: okabe@i.kyoto-u.ac.jp Masahiro Kozuka Faculty of Law, Kyoto University Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN Tel: +81 75-753-7468 Fax: +81 75-753-7472 Email: ma-kun@kozuka.jp Youichi Koyama Trans New Technology, Inc. Inohara BLDG. 2F, 72 Tanaka Monzencho, Sakyo, Kyoto 606-8225 JAPAN Tel: +81-75-706-9800 Fax: +81-75-706-9801 Email: koyama-y@trans-nt.com Ohira Expires on July 26, 2004 [Page 14]