idnits 2.17.1 draft-sun-mif-route-config-dhcp6-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 27, 2010) is 5022 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-05 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF Working Group T. Sun 3 Internet-Draft H. Deng 4 Intended status: Standards Track D. Liu 5 Expires: January 28, 2011 China Mobile 6 July 27, 2010 8 Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces 9 draft-sun-mif-route-config-dhcp6-03 11 Abstract 13 Currently, more and more hosts have multiple interfaces such as GPRS, 14 WiFi etc. One key issue is how to make the applications on the host 15 access the network accordingly through the proper interfaces. The 16 approach presented in this document is to define new DHCPv6 option to 17 configure route tables of the hosts. In this way, the hosts can 18 select a appropriate route. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 28, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Scenario Descriptions . . . . . . . . . . . . . . . . . . 4 58 3. Route Information Option Format . . . . . . . . . . . . . . . 6 59 4. Route Information Option Format Usage . . . . . . . . . . . . 8 60 4.1. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . 8 61 4.2. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . 8 62 5. Implementation Considerations . . . . . . . . . . . . . . . . 9 63 5.1. Conflict of Route Rules . . . . . . . . . . . . . . . . . 9 64 5.2. Not Limited to DHCPv6 Servers . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Requirements Notation 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in [RFC2119]. 78 2. Introduction 80 2.1. Background 82 A host such as a laptop or a smart-phone may have multiple interfaces 83 for connections, e.g., a wired Ethernet LAN, a 802.11 LAN, a 3G 84 cellular network, one or multiple VPNs or tunnels. In view of more 85 and more versatile applications, users may expect a host to utilize 86 several interfaces simultaneously. Issues in such scenarios are 87 summarized in [I-D.blanchet-mif-problem-statement] . 89 An application uses certain interface through select the 90 corresponding source IP address. if the application does not specify 91 it, the transport layer must ask the IP layer. According to 92 [RFC1122] all the packets whose destination IP addresses are not 93 specified in the route table will be sent to the default gateway for 94 forwarding. Accordingly, the IP address corresponding to the default 95 gateway will be chosen as the source IP address. 97 To avoid all packets passing through the same interface corresponding 98 to the default gateway, the approach proposed in this document 99 configures certain routes in route tables of the host. The 100 configuration information is obtained through defining a new DHCPv6 101 option based on [RFC3315]. 103 An optional extension to Router Advertisement messages is described 104 in [RFC4191] for communicating default router preferences and more- 105 specific routes from routers to hosts. To address multi-homed 106 problems in a flexible way, [I-D.hui-mif-dhcpv4-routing-03] through 107 introducing TOS and specific routes into DHCPv4 options. This 108 document considers the situations for IPv6 cases. 110 2.2. Scenario Descriptions 112 The scenario addressed by the approach proposed in this document is 113 illustrated in Figure 1. In the figure, the MIF host have three 114 interfaces connected to the access network Ethernet, WiFi and 3G 115 respectively. 117 +---------+ 118 | 3G | 119 +---------+ 120 | 121 I3 | 122 ^ 123 | 124 +-----------+ I1 +--------+ I2 +-----------+ 125 | Ethernet |<------>|MIF Host|<------>| WiFi | 126 +-----------+ +--------+ +-----------+ 128 Figure 1: The MIF host scenario 130 The procedures that an application employs an interface for network 131 access are depicted in Figure 2 as steps a1) to a4). 133 a1) An application calls sockets to build IP packets. 135 a2) The socket selects source address based on the routing table. 137 a3) The socket sends packets to the corresponding interface. 139 a4) The interface will forward the packets to the next hop (the 140 corresponding gateway). 142 +---------+ b4 +-------+ 143 |Interface|--------->|Network| 144 +---------+ +-------+ 145 | 146 b3 | 147 ^ 148 | 149 +-----------+ b1 +------+ +-----------+ 150 |Application|---->|Socket|<------|Route Table| 151 +-----------+ +------+ b2 +-----------+ 153 Figure 2: The procedures of updating a routing table and select an 154 interface for an application 156 Notice that the approach proposed in this document is feasible under 157 the strong ES model as defined in [RFC1122]. 159 3. Route Information Option Format 161 The DHCPv6 option is extended to contain multiple pieces of route 162 information. Each piece of route information contains TOS, metric, 163 destination IP address and the next hop IP address. The ROUTE_INFO 164 option is depicted in Figure 3. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | OPTION_ROUTE_INFO | option-len | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Pref. 1 | TOS 1 | Metric 1 | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+- 173 | Dest.Pref.Len | | 174 +-+-+-+-+-+-+-+-+ | 175 | | 176 | Dest.Pref. | 177 | | 178 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | | | 180 +-+-+-+-+-+-+-+-+ | 181 | Next Hop Pref. | 182 | | 183 | | 184 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | 185 | | . 186 +-+-+-+-+-+-+-+-+ . 187 . . 188 . . 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Pref. N | TOS N | Metric N | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+- 192 | Dest.Pref.Len | | 193 +-+-+-+-+-+-+-+-+ | 194 | | 195 | Dest.Pref. | 196 | | 197 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | | 199 +-+-+-+-+-+-+-+-+ | 200 | Next Hop Pref. | 201 | | 202 | | 203 | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+ | 204 | | 205 +-+-+-+-+-+-+-+-+ 206 Figure 3: The Route Information Option 208 option-code:OPTION_ROUTE_INFO (should be defined by IANA). 210 option-len: length of the route rule field in octets. 212 Pref.N: An integer to indicate the priority of applying the Nth route 213 rule. The Preference identified the priority of a rule. if there are 214 conflictions, e.g., two rules have the same "Dest. Add. Pref." but 215 different "Next Hop IPv6 Address", the rule with high preference 216 SHOULD be applied by the host. 218 TOS N: The Nth TOS (Type-of-Service, 8 bits). 220 Metric N:The Nth route metric, an 16-bit unsigned integer ranging 221 from 1 to 9999. 223 Dest.Pref.Len: Length of the IPv6 destination subnet prefix, an 8-bit 224 unsigned integer ranging from 0 to 128. 226 Dest.Pref.: The IPv6 destination address prefix 228 Next Hop Pref.: A 128-bit IPv6 prefix that will be used as the next 229 hop when forwarding packets. 231 In the above, the "Preference" of one route rule comes before the 232 "metric." Namely, if there are conflict routes for one destination, 233 the one with highest preference value should be used. For example, 234 the network administrator may prefer one route in a connection for 235 security or reliability considerations, even though the metric of the 236 route is large. 238 4. Route Information Option Format Usage 240 4.1. DHCPv6 Client Behavior 242 The MIF host(DHCPv6 client) supports Route Information extension, 243 SHOULD send Option Request Option that includes OPTION_ROUTE_INFO to 244 indicate that Route Information Option is requested. The Route 245 Information option MUST NOT appear in any messages other than the 246 following ones : Solicit, Request, Renew, Rebind, Information- 247 Request. 249 If the MIF host receives no route information, it MAY try another 250 server or retransmit the ORO message. In this situation, the host 251 MUST limit the rate of the retransmition. 253 4.2. DHCPv6 Server Behavior 255 The DHCPv6 server MUST NOT send Route Option in messages other than 256 ADVERTISE or REPLY. 258 The maximum number of routing information in one DHCPv6 message 259 depend on the maximum DHCPv6 message size defined in [RFC3315]. 261 5. Implementation Considerations 263 5.1. Conflict of Route Rules 265 The host can use such information obtained from the DHCPv6 message to 266 build a "connection manager" on the host or to update the "Policy 267 Table" defined in [RFC3484]. For the situations where a route option 268 conflicts with one previous route rules, the latter one will override 269 the previous rule. 271 5.2. Not Limited to DHCPv6 Servers 273 The solution presented in this document is with the context of DHCPv6 274 message. It should be pointed out that similar message may not be 275 conveyed by certain node in the network instead of a DHCPv6 server. 276 Such a node, for example in mobile network, may be the "ANDSF (Access 277 Network Discovery and Selection function)" defined in TS 23.402. 279 6. IANA Considerations 281 The option code of OPTION_ROUTE_INFO will be defined by IANA. 283 7. Security Considerations 285 The interface selection is affected by the routing and address 286 selection rules sent from servers. Therefore, incorrect information 287 received by hosts will cause improper interface selection leading to 288 bad user experiences. Attacks such as deny of services (DoS) or man- 289 in-the-middle may redirect host's solicitation, change the 290 information or flood the host with invalidate messages. Approaches 291 to guarantee the communication securities between hosts and servers 292 should be applied based on the network access types of the 293 interfaces. 295 DHCP authentication option [RFC3118] MAY be used for security. 297 8. References 299 8.1. Normative References 301 [RFC1122] Braden, R., "Requirements for Internet Hosts - 302 Communication Layers", STD 3, RFC 1122, October 1989. 304 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 305 Requirement Levels", BCP 14, RFC 2119, March 1997. 307 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 308 Messages", RFC 3118, June 2001. 310 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 311 and M. Carney, "Dynamic Host Configuration Protocol for 312 IPv6 (DHCPv6)", RFC 3315, July 2003. 314 [RFC3484] Draves, R., "Default Address Selection for Internet 315 Protocol version 6 (IPv6)", RFC 3484, February 2003. 317 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 318 More-Specific Routes", RFC 4191, November 2005. 320 8.2. Informative References 322 [I-D.blanchet-mif-problem-statement] 323 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 324 Statement", July 2010, 325 . 327 [I-D.hui-mif-dhcpv4-routing-03] 328 Hui, M. and H. Deng, "Extension of DHCPv4 for policy 329 routing of multiple interfaces terminal", March 2010, 330 . 332 Authors' Addresses 334 Tao Sun 335 China Mobile 336 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 337 Beijing 100053 338 China 340 Email: suntao@chinamobile.com 342 Hui Deng 343 China Mobile 344 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 345 Beijing 100053 346 China 348 Email: denghui@chinamobile.com 350 Dapeng Liu 351 China Mobile 352 Unit2, 28 Xuanwumenxi Ave,Xuanwu District 353 Beijing 100053 354 China 356 Email: liudapeng@chinamobile.com