IETF IPv6 Working Group Haibo Wen Internet-Draft Alcatel Shanghai Bell Expires: October 27, 2006 March 28, 2006 Multi-homing Information option for Stateless Address Auto-Configuration draft-wen-ipv6-rsra-opt-multihoming-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. 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 October 27, 2006. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Wen Expires October 27, 2006 [Page 1] Internet-Draft Multi-homing option for RS/RA messages March 2006 Abstract This document makes an extension to the standard RS/RA messages for IPv6 network to solve some problems occurring in multi-homing evironment. A new options, that is, Multi-homing Information option is defined to help host do network selection and prefix selection. Conventions used in this document The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [3]. 1. Introduction Stateless Address Auto-Configuration (SAAC)[1] is a very important feature for IPv6 technology. In the standard IPv6 stateless configuration, a router sends periodical as well as solicited Router Advertisement (RA) messages out its advertising interfaces. When an interface of an IPv6 host becomes enabled, the host may be unwilling to wait for the next unsolicited RA message to locate default routers or learn prefixes, it will transimit Router Solicitation (RS) message to request RA message. IPv6 multi-homing environment is used to described this kind of IPv6 site that phsically or logically connects to more than one IP Service Provider (ISP). Multi-homing can be used for the purposes of redundancy, load-balancing, operational policy or cost. If the IPv6 multi-homing site uses provider-assigned address prefixes for every host's SAAC within the site, the host can obtain these prefixes assigend by different ISPs from RA messages, and then form its IPv6 global addresses. However, most ISPs may use ingress filtering, i.e., the ISP's edge router at the boundary of the chosen multi-homing site will check the source address of the packets routed from multi-homing site whether the prefix of its source address is assigned by the ISP, if not, the packets will be discarded. How to help host implement exit router selection and the associated prefix or address selection must be investigated. In the IPv6 multi-homing site, some hosts/terminals may want to connect to some specified ISPs. When these hosts/terminals send out RS messages, it's not necessary for all the edge router connecting to this site to respond with its RA message, and it's a better way that only the edge router of the specified ISP responds this RS message with an appropriate RA message. This can be called network sevice selection. This document defines an option, i.e., Multi-homing Information Wen Expires October 27, 2006 [Page 2] Internet-Draft Multi-homing option for RS/RA messages March 2006 option for Router Solicitation/Router Advertisement(RS/RA) messages which can be used to solve the problems above-mentiioned. 2. RS/RA message extension To decrease the solicited RA messages, RS message must contain some information to help router make the appropriate decision whether it should an approriate RA message to respond. In addition, RA message must contain some information related to the prefix assigned by the corresponding ISP, thus hosts can easily find the correct exit router , the associated prefix and also form their correct IPv6 addresses that should be used as source address for outgoing packets. Multi- homing Information option is defind for this purpose. 2.1 Multi-homing Information option Multi-homing Information option is used for both RS message and RA message. In upstream RS message, it can contain host's network service selection infromation, for example, it can have the name of the ISP subscribered by the host, or vendor class identifier, or other information. The option is used in RS message, and the corresponding router can respond it with an appropriate RA message containing the correct prefix information. In the downstream RA message, this option appears immediately prior to the corresponding Prefix Information option, i.e., in a pair form . This option is used to indicate that some specific ISP assigns the prefix in the immediately following Prefix Information option. It can help the host to do correct exit router selection and prefix selection. 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 | Sub-option Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Multi-homing Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Pad ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 8-bit identifier of the option type (TBD: IANA) Option Name Type Value Multi-homing Information option (TBD) Wen Expires October 27, 2006 [Page 3] Internet-Draft Multi-homing option for RS/RA messages March 2006 Length 8-bit unsigned integer. The length of the option (including the type and length fields) is in units of 8 octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. Sub-option indicator Each bit of this field is used for indicating some specific sub-option is included in this Multi- homing Information option. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. Currently only the least 5 bits are defined (refer to subsection 2.1.1). Multi-homing Data This field is used to contain the information related to multi-homing (e.g., the name of some specified ISP, or the vendor class identifier information, or any other information) for network service selection in RS message and for prefix/exit router selection in RA message. It can contain more than one Multi-homing-subopiton if required (the sub-options are shown in subsection 2.1.2). Pad Variable-length field. This field is used to align Multi-homing Information option in units of 8 octets. The content of Pad field is 0. That is, using the minimum octets with 0 to make sure the length of the whole option to be in units of 8 octets. Description When this option exists in RS and RA message for different purpose. In RS message, it help router decide whether it should respond. In RA message, it help host do correct selection of prefix exit router: the host can record each prefix and its associated information (e.g., the ISP that assigns this prefix, and the link-local address of the exit router that advertises this RA) and form feasible global IPv6 address as source address, and then forward parckets to the apporiate ISP. 2.1.1 Format for the field of Sub-option Indicator The format for the field of sub-option Indicator is shown below. Only 5 least bits are used for indicating some special information are Wen Expires October 27, 2006 [Page 4] Internet-Draft Multi-homing option for RS/RA messages March 2006 requsted from router or some special information is containing in the following Multi-homing Data field. The corresponding sub-options are explained in subsection 2.1.2. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved |S|D|E|V|I| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Reserved This 11-bit is currently unused. It must be set to 0. If required, other bit can be used. S If set to 1: (i) for RS message, it means that host is soliciting the address of SIP server in some ISP ; (ii) for RA message, it means there is a SIP server sub-option in the Multi-homing Data field. D If set to 1: (i) for RS message, it means that host is soliciting the address of DNS server in some ISP ; (ii) for RA message, it means there is a DNS server sub-option in the Multi-homing Data field. E If set to 1: (i) for RS message, it means that host is soliciting the address of the edage router of some ISP; (ii) for RA message, it means there is an edge-router addess sub-optiono in the Multi-homing Data field. V If set to 1, that means there is a Vendor class sub-option in Multi-homing Data field. I If set to 1, that means there is a ISP name sub- option in Multi-homing Data field. 2.1.2 Multi-homing sub-options Multi-homing sub-option will be used in the field of Multi-homing Data of Multi-homing Information 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Type | Length | Sub-option Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Wen Expires July 8, 2006 [Page 5] Internet-Draft Multi-homing option for RS/RA messages March 2006 Sub-Type 8-bit identifier of the type of sub-options Sub-Option Name value ISP name 1 Vendor Class 2 edge router address 3 DNS server address 4 SIP server address 5 Length 8-bit unsigned integer. The length of the field of Sub-option Data in octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an sub-option with length zero. Sub-option Data Variable-length field. Option-Type-specific data. This field is used to contain detailed information for network service selection. Depending on the value of Sub-Type field, Sub-option Data field can have different format. When Sub-Type is 1, the Sub-option Data field contains ISP name. For RS message, it contains the name of the desired ISP for the host. When Sub-Type is 2, the Sub-option Data field contains vendor class identifier, which may be used to identify the vendor and fuctionality of a device that iniates this RS message. The information is a variable length string of characters or octets which has a meaning specified by the vendor of the device. It's kind of the Vendor Class Identifier ( option 60) in DHCPv4. When Sub-Type is 3, the Sub-option Data field contains the global IPv6 address of the edge router , and this edge router is the nearest one close to this multi-homing site from the ISP that assigns the prefix to the multi-homing site. This global address MAY be used by hosts with Type 0 Routing Header for fast forwarding the packets to the desird ISP. Wen Expires October 27, 2006 [Page 6] Internet-Draft Multi-homing option for RS/RA messages March 2006 When Sub-Type is 4 or 5, the Sub-option Data field contains the corresponding address from the specific ISP, i.e., the DNS server address and SIP server address, respectively. It can simplify the process of host obtaining the addresses of DNS server and/or SIP server, for these information is piggyback on SAAC. Description The sub-options can be used in a combination if needed. The router, which can identify the sub- options and find the matchings in its own data base , will respond with corresponding information in a RA message. The router, which can not indentify the multi-homing infomration option will ignore this option. In additon, any other new sub-options can be defined to make new extention. For example, it can also be extended for access network to carry authentication information when access network requires simpler authentication without very strict secure request. For this case, to make the information far away from attack or snooping, IPv6 Encapsulating Security Payload Header option can be used. 3. Scenario for usage of new option for IPv6 SAAC in multi-homing environment In order to explain the usages of Multi-homing Information option more clearly, scenarios are shown in the following subsections. 3.1 Scenario 1: physically multi-homing site +-------+-------+ +-------+-------+ | DNS server 1 | | SIP server 2 | +-------+-------+ +-------+-------+ \ __________|_________ ________|___________ \ / \ / \ \ | ISP1 core network | | ISP2 core network | | \__________ _________/ \__________ _________/ | | / | ISP | / | network | / / +-------+-------+ +-------+-------+ / | edge router 1 | | edge router 2 | / +-------+-------+ +-------+-------+ Wen Expires October 27, 2006 [Page 7] Internet-Draft Multi-homing option for RS/RA messages March 2006 \ / \ \--------+--------/ \ | | multihoming +------------+--+--------------+ | site | | | | +-----+----+ +----+-----+ +-----+----+ / | host 1 | | terminal | ... | host n | / +----------+ +----------+ +----------+ / Figure 1: IPv6 multi-homing site with two exit routers Figure 1 illustrates an IPv6 multi-homing site with two exit routers. In this scenario, the site is physcially connected to more than one ISP core network through different edge router of the ISPs. Each ISP has its own DNS server and ISP server. The edge router will advertise RA message containing corresponding informtion. For the multi-homing site, the edge routers of ISPs are its exit router. Normally, the router advertises periodic RA message with Prefix Information option and Multi-homing Information option only including ISP name sub-options. When the interface of host is enabled, it will send out a RS message which will contain some inforamtion that the host shows interest in. If it wants to know other information (e.g., SIP server, DNS server), router will repond with corresponding information. Figure 2 shows the procedure of stateless auto-configuration in this multi-homing environment. Here, we assume the interface of host 1 is enabled, it wants service from ISP1, and in addition it wants to obtain the DNS server address of ISP1. +---------+ +-----------+ +-----------+ |User IPv6| | ISP1 edge | | ISP2 edge | | host 1 | | router1 | | router2 | +---------+ +-----------+ +-----------+ | | | (a) |---RS with Multi-homing Info. option---->| | | (including ISP name subopt. | | | & DNS server subopt.)| | | \this RS will reach the edge router2 of ISP2--->| | | (b) | edge router 1 of ISP1 sends out | |<--RA with Multi-homing Info. option-----| | (including ISP name subopt. | | & DNS server subopt.)| | and Prefix Info. option | Figure 2. Procedure of stateless auto-configuration for host 1 requiring RA message from ISP1 Wen Expires October 27, 2006 [Page 8] Internet-Draft Multi-homing option for RS/RA messages March 2006 The procedure consists of the following steps: Step (a) : IPv6 Host1 sends RS (Router Solicitation) message to get RA message. This RS message contains Multi-homing information option for ISP selection and configuration: ISP name sub-option with ISP1 name, and DNS server option with 0 filled in Sub-option Data field. This RS message will reach to all the edge routers that connect to this multi-homing site. Step (b) : According to the ISP name sub-option in the Multi-homing Information option, the edge router 1 of ISP1 knows that it should provide the appropriate information to respond this RS message: Prefix information, and the requested DNS server address. So it forms the RA message with correct pair.The Multi-homing Information option contains ISP name and DNS server address. Host 1 can obtain its desired prefix information and the exact associated exit router (its address is in the source address of RA message ). Then it can construct its IPv6 address via the method in [1]. Note: Though the edge router 2 of ISP2 has received the RS message too, it will not respond with a RA message because it knows the host is soliciting information from ISP1. 3.2 Scenario 2: Access network connecting multiple ISPs, layer3 CPE in subscriber network ____________________ ____________________ \ / \ / \ \ | ISP1 core network | | ISP2 core network | \ \__________ _________/ \__________ _________/ | | / | ISP | / | network | / / +-------+-------+ +-------+-------+ / | edge router 1 | | edge router 2 | / +-------+-------+ +-------+-------+ \ / \ ____\_________________/ \ / \ | | aggregation network | | \__________ ___________/ | | | access +-------+-------+ | network | layer 2 | | Wen Expires October 27, 2006 [Page 9] Internet-Draft Multi-homing option for RS/RA messages March 2006 | access node | | +-------+-------+ | | / |DSL to subscriber / |premises / | +------+------+ \ | layer3 CPE | \ | (routed-CPE)| \ +------+------+ | Subscriber | | network +------------+--------------+ | | | | | +-----+----+ +----+-----+ +-----+----+ / | host1 | | host2 | | hostn | / +----------+ +----------+ +----------+ / Figure 3: IPv6 access network with multi-homing environment Figure 3 illustrates the IPv6 access network with multi-homing environment via connecting to multiple ISPs. RS/RA messages are running between routed-CPE and hosts. The routed-CPE can obtain different prefix from the edge router of each ISP connecting to the access network. For the subscriber network, it's logically multi- homing. Routed-CPE must record the mapping information that some specific prefix is obtained from the specific edge router from the specific ISP. +---------+ +-----------+ +------------------+ |User IPv6| | routed | |ISP's edge router | | host | | CPE | | | +---------+ +-----------+ +------------------+ | | (a)|-RS with Multi-homing->| | Info. option | | | / Prefix delegation \ | (b)|<----|from desired ISP via | ----->| | \ DHCP or RADIUS / | (c)|<- RA with | Figure 4. Procedure of stateless auto-configuration for scenario 2 Figure 4 shows the procedure of stateless auto-configuration for this IPv6 access network in multi-homing environment. The procedure consists of the following steps: Wen Expires October 27, 2006 [Page 10] Internet-Draft Multi-homing option for RS/RA messages March 2006 Step (a) : IPv6 host sends RS message to solicite RA message. This RS message inlcudes Multi-homing Information option with ISP name sub-option. Step (b) : Routed CPE receives RS message. If the gateway hasn't obtained a prefix from desired ISP, it will request prefix delegation from desired ISP via DHCP or RADIUS or any other methods. Step (c) : Routed-CPE advertises the appropriate RA message based on the RS message to host. The RA message contains the appropriate multi-homing with ISP name and Prefix Information option. Then the host can select the appropriate prefix according to the ISP name to perform stateless address autoconfiguration. In addition, routed- CPE can know the global address of each edge router that connects to it. Then it can contain the edge-router address in Multi-homing Information option. Thus the host in the subscriber network can use Type 0 Routing Header[2] for fast forwarding the packets to the desird ISP. In this scenario, since the routed-CPE has recorded the mapping of prefix information and the ISP's edge router, if it addes function of forward the outgoing packets from the subscriber network based on the indiation of the source addresses (i.e., if the packet's source address is in the domain of the prefix that is assigned ISP1, the packet must be forwarded to the edge router of ISP1), it's not necessary for host to use Type 0 Routing Header. This procedure is also applicable for access node is a layer3 device while CPE is a layer2 device. For this case, RS/RA is running between access node and hosts. 3.3 Scenario 3: Layer2 access network and layer2 CPE in subscriber network In this scenario, the network architecture resembles the one in Figure 3 except that a layer2 CPE (or bridged-CPE) replacs the layer3 CPE (or routed-CPE) in the subscriber network. Access node is still a layer 2 device. Here, RS/RA messages are run between hosts/ terminals and the edge routers. Figure 5 shows the procedure of SAAC for this scenario. Wen Expires October 27, 2006 [Page 11] Internet-Draft Multi-homing option for RS/RA messages March 2006 +---------+ +-----------+ +------------------+ |User IPv6| | layer2 | |ISP's edge router | | host | |access node| | | +---------+ +-----------+ +------------------+ | | | (a)|-- RS with Multi -->| | | -homing Info. option | | (b)|----RS to the appropriate router-->| | | (c)|<---RA with | (d)|<-RA with | Figure 5. Procedure of stateless auto-configuration for scenario 3 The procedure consists of the following steps: Step (a) : IPv6 Host sends RS message to get RA message. This RS message network selection information in Multi-homing Information option. Step (b) : Base on the information in Multi-homing Information option , layer 2 access node can forward this RS to the correct edge router of the desired ISP without sending it to the router that will not respond this RS. Step (c) : Edge router forms the appropriate RA message according to the RS message. The RA message will containing the appropriate . Step (d) : Access node relays the RA message to the corresponding subscriber network. Then the host can select the appropriate prefix according to the ISP name to perform stateless address autoconfiguration. 4. Acknowledgements The author would like to thank Songwei Ma, David Watkinson and the other members in R&I access and edge group in lcatel Shanghai Bell for their comments and help. 5. References 5.1 Normative References Wen Expires October 27, 2006 [Page 12] Internet-Draft Multi-homing option for RS/RA messages March 2006 [1] S. Thomson, and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC2462, December 1998. [2] S. Deering, and R. Hiden, "Internet Protocol, Version 6 (IPv6) Specification", RFC2460, December 1998. [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Haibo Wen Alcatel Shanghai Bell Co., Ltd. 388#, NingQiao Road, Pudong Jinqiao Shanghai 201206 P.R. China Phone: +86 (21) 5854-1240, ext.: 9273 Email: Haibo.WEN@alcatel-sbell.com.cn Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2006). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any Wen Expires October 27, 2006 [Page 13] Internet-Draft Multi-homing option for RS/RA messages March 2006 kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Wen Expires October 27, 2006 [Page 14]