idnits 2.17.1 draft-sun-mif-route-config-dhcp6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 1122' is mentioned on line 81, but not defined == Missing Reference: 'RFC 4191' is mentioned on line 92, but not defined == Missing Reference: 'I-D-hui-mif-dhcpv4-routing-00' is mentioned on line 94, but not defined == Unused Reference: 'RFC1122' is defined on line 261, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 267, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 271, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 276, but no explicit reference was found in the text == Unused Reference: 'I-D.blanchet-mif-problem-statement' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'I-D.hui-mif-dhcpv4-routing-00' is defined on line 284, but no explicit reference was found in the text == Unused Reference: 'I-D.dec-dhcpv6-route-option-00' is defined on line 289, but no explicit reference was found in the text == Unused Reference: 'I-D.yang-mif-req' is defined on line 293, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-01) exists of draft-blanchet-mif-problem-statement-00 == Outdated reference: A later version (-03) exists of draft-hui-mif-dhcpv4-routing-00 == Outdated reference: A later version (-05) exists of draft-dec-dhcpv6-route-option-00 Summary: 3 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 T. Sun 2 Internet Draft H. Deng 3 Intended status: Informational China Mobile 4 Expires: September 2009 March 10, 5 2009 7 Route Configuration by DHCPv6 Option for Hosts with Multiple 8 Interfaces 9 draft-sun-mif-route-config-dhcp6-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This Internet-Draft will expire on September 10, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents carefully, 42 as they describe your rights and restrictions with respect to this 43 document. 45 Abstract 46 For hosts with multiple interfaces, the problem is how to make it run 47 several applications simultaneously on variant interfaces such as 48 GPRS, Wifi etc. To achieve this, one key issue here is to select 49 appropriate route according to RFC 1122. The approach presented in 50 this document is extending DHCPv6 option to configure route tables of 51 the hosts. 53 Table of Contents 55 1. Introduction................................................2 56 2. Solution of Multiple Interface Usage.........................3 57 3. DHCPv6 Option Extensions.....................................4 58 3.1. Host and Server Behavior................................4 59 3.2. Route Information Option................................4 60 3.3. Some Considerations of the DHCPv6 Option................6 61 3.3.1. Conflict of Route Rules............................6 62 3.3.2. Application Situations.............................6 63 3.3.3. Not Limited to DHCP Servers........................6 64 4. IANA Considerations.........................................6 65 5. Security Considerations......................................6 66 6. References..................................................7 67 6.1. Normative References....................................7 68 6.2. Informative References..................................7 70 1. Introduction 72 A host such as a laptop or a smart-phone may have multiple interfaces 73 for connections, e.g., a wired Ethernet LAN, a 802.11 LAN, a 3G cell 74 network, one or multiple VPNs or tunnels. In view of more and more 75 versatile applications, users may expect a host to utilize several 76 interfaces at the same time. 78 If the source IP address is selected and bind by an application, then 79 the application can use certain interface in this way. However, 80 source IP addresses are generally added by sockets in IP layer. 81 According to [RFC 1122], all the packets whose destination IP 82 addresses is not specified in the route table will be send to a 83 default gateway for forwarding. Accordingly, the IP address 84 corresponding to the default gateway is chosen as the source IP 85 address. 87 To avoid all packets passing through the same interface corresponding 88 to the default gateway, the approach in this document configures 89 certain routes in route tables of hosts. The configuration 90 information is sent through extending DHCPv6 option. 92 In [RFC 4191], multiple default routers and specific routes are used 93 to handle multi-homed scenarios. To address multi-homed problems in a 94 flexible way, [I-D-hui-mif-dhcpv4-routing-00] extends DHCPv4 through 95 introducing TOS and specific routes into DHCP options. This document 96 considers IPv6 situations. Similar approach was presented in [I-D- 97 dec-dhcpv6-route-option-00] where TOS and metrics information have 98 not been involved. 100 2. Solution of Multiple Interface Usage 102 The procedures of configuring routing information and selecting 103 interface are depicted in Figure 1. 105 The routing configure procedures are shown as steps a1 to a3. 107 o a1) An interface sends Information-requirement when the connection 108 is established or when an existing connection receives 109 reconfiguration message from the server. 111 o a2) The server sends routing information through DHCPv6 option as 112 to be defined in Section 3.2. 114 o a3) The routing information received from the interface is used to 115 configure the routing table of the host. 117 The procedures that an application employs an interface for network 118 access are depicted in Figure 1 as steps b1 to b4. 120 o b1) An application calls sockets to build IP packets. 122 o b2) The socket selects source address based on the routing table. 124 o b3) The socket sends packets to the corresponding interface. 126 o b4) The interface will forward the packets to the next hop (the 127 corresponding gateway). 129 +----+ a1 +---------+ b4 +-------+ 130 |DHCP|<--------- |Interface|--------->|Network| 131 +----+ --------> +---------+ +-------+ 132 a2 | | 133 | | 134 b3 | | 135 ^ | a3 136 | ----->----+ 137 | | 138 +-----------+ b1 +------+ +-----------+ 139 |Application|---->|Socket|<------|Route Table| 140 +-----------+ +------+ b2 +-----------+ 142 Figure 1 The procedures of updating a routing table and select an 143 interface for an application. 145 Notice that the approach proposed in this document is feasible under 146 the strong ES model as defined in RFC1122. 148 3. DHCPv6 Option Extensions 150 3.1. Host and Server Behavior 152 The host must include "Option Request" option to let the server know 153 the option the host interested. The request option code is set as the 154 "Route Information" defined in 3.2. 156 The server constructs a Reply message to provide route information to 157 the host. Also, a server may send a Reconfigure Message to a host. 158 The host may initiate a request when receiving the Reconfigure 159 message for the host. 161 3.2. Route Information Option 163 The DHCPv6 option is extended to contain multiple pieces of route 164 information. Each piece of route information contains TOS, metric, 165 destination IP address and the next hop IP address. The ROUTE_INFO 166 option is depicted in Figure 2. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | OPTION_ROUTE_INFO | option-len | Preference 1 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 + TOS 1 | Metric 1 | Dest. Add. Pref. Len| Dest. Add. Pref. | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 175 . . 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 + Next Hop IPv6 Address . 178 . . 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 . . 181 . . 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 + Preference N | TOS N | Metric N | Dest. Add. Pref. Len | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 + Dest. Add. Pref. . 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 + Next Hop IPv6 Address . 188 . . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 2 The Route Information Option. 193 option-code OPTION_ROUTE_INFO (should be defined by IANA). 195 option-len length of the route rule field in octets. 197 Preference N An integer to indicate the priority of applying the Nth 198 route rule. 200 TOS N The Nth TOS (Type-of-Service, 8 bits). 202 Metric N The Nth route metric ranging from 1 to 9999. 204 Dest. Add. Prefix Len Length of the IPv6 destination address prefix, 205 an 8-bit unsigned integer ranging from 0 to 128. 207 Dest. Add. Prefix The IPv6 destination address prefix 209 Next Hop IPv6 Address A 128-bit IPv6 address that will be used as the 210 next hop when forwarding packets. 212 In the above, the "Preference" of one route rule comes before the 213 "metric." Namely, if there are conflict routes for one destination, 214 the one with highest preference value should be used. For example, 215 the network administrator uses one route in a connection for security 216 or reliability considerations, even though the metric of the route is 217 large. 219 3.3. Some Considerations of the DHCPv6 Option 221 3.3.1. Conflict of Route Rules 223 For the situations where a route option conflicts with one previous 224 route rules, the latter one will override the previous rule. 226 3.3.2. Application Situations 228 There are two situations when DHCPv6 is applied, i.e., with or 229 without stateless autoconfiguration. For the stateless case, since 230 the address has been configured based on the link-local/site-local 231 address, the DHCPv6 is used to obtain options. 233 3.3.3. Not Limited to DHCP Servers 235 The solution presented in this document is with the context of DHCP 236 message. It should be pointed out that similar message may not be 237 conveyed by certain node in the network instead of a DHCP server. 239 4. IANA Considerations 241 The option code of ROUTE RULE will be defined by IANA. 243 5. Security Considerations 245 The security issues in this document are similar with those that have 246 been met when using DHCPv6 options. 248 The interface selection is affected by the routing and address 249 selection rules sent from servers. Therefore, incorrect information 250 received by hosts will cause improper interface selection leading to 251 bad user experiences. Attacks such as deny of services (DoS) or man- 252 in-the-middle may redirect host's solicitation, change the 253 information or flood the host with invalidate messages. Approaches to 254 guarantee the communication securities between hosts and servers 255 should be applied based on the network access types of the interfaces. 257 6. References 259 6.1. Normative References 261 [RFC1122] Braden, R., "Requirements for Internet Hosts - 262 Communication Layers", STD 3, RFC 1122, October 1989. 264 [RFC3484] R. Draves, "Default Address Selection for Internet Protocol 265 version 6 (IPv6)", RFC3484, February 2003. 267 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 268 and M. Carney, "Dynamic Host Configuration Protocol for 269 IPv6 (DHCPv6)", RFC 3315, July 2003. 271 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 272 More-Specific Routes", RFC 4191, November 2005. 274 6.2. Informative References 276 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 277 Discovery for IP Version 6 (IPv6)", RFC 2461, 278 December 1998. 280 [I-D.blanchet-mif-problem-statement] Blanchet, M., "Multiple 281 Interfaces Problem Statement", draft-blanchet-mif-problem- 282 statement-00 (work in progress), December 2008. 284 [I-D.hui-mif-dhcpv4-routing-00] Hui, M., and Deng, H. "Extension of 285 DHCPv4 for policy routing of multiple interfaces terminal," 286 draft-hui-mif-dhcpv4-routing-00(work in progress), February 287 2009 289 [I-D.dec-dhcpv6-route-option-00] Dec, W., and Johnson, R, "DHCPv6 290 Route Option," draft-dec-dhcpv6-route-option-00(work in 291 progress), February 2009 293 [I-D.yang-mif-req] Yang, P., Seite, P., Williams, C., and J. Qin, 294 "Requirements on multiple Interface (MIF) of simple IP", 295 draft-yang-mif-req-00 (work in progress), March 2009. 297 Authors' Addresses 299 Tao Sun 300 China Moible 301 53A,Xibianmennei Ave., 302 Xuanwu District, 303 Beijing 100053 304 China 305 Email: suntao@chinamobile.com 307 Hui Deng 308 China Moible 309 53A,Xibianmennei Ave., 310 Xuanwu District, 311 Beijing 100053 312 China 313 Email: denghui@chinamobile.com