idnits 2.17.1 draft-sun-mif-address-policy-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 7 instances of too long lines in the document, the longest one being 2 characters 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 3484' is mentioned on line 89, but not defined ** Obsolete undefined reference: RFC 3484 (Obsoleted by RFC 6724) == Unused Reference: 'RFC1122' is defined on line 258, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 264, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'RFC2461' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'I-D.hui-mif-dhcpv4-routing-00' is defined on line 281, but no explicit reference was found in the text == Unused Reference: 'I-D.yang-mif-req' is defined on line 286, 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 (-03) exists of draft-hui-mif-dhcpv4-routing-00 Summary: 4 errors (**), 0 flaws (~~), 10 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 X. Duan 4 Expires: September 2009 China Mobile 5 March 10, 6 2009 8 Address Selection Policy Configuration by DHCPv6 Option 9 draft-sun-mif-address-policy-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 way is to select appropriate IP 49 address so that the packets can be sent to the corresponding 50 interface for forwarding. RFC 3484 defines a ''policy table'' for 51 default IP address selection. This document extends the DHCPv6 option 52 message so that the policy table can be dynamically updated. 54 Table of Contents 56 1. Introduction................................................2 57 2. Solutions...................................................4 58 2.1. Route Table Updation....................................4 59 2.2. The Option of DHCPv6....................... 60 2.3. Some Considerations of the DHCPv6 Option................6 61 2.3.1. Conflict of Route Rules............................6 62 2.3.2. Application Situations.............................6 63 2.3.3. Not Limited to DHCP Servers........................6 64 3. IANA Considerations.........................................6 65 4. Conclusions.................................... 66 5. References..................................................7 67 5.1. Normative References....................................7 68 5.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 the 89 IP address ''policy table'' defined in [RFC 3484] 90 To address multi-homed problems in a flexible way, [I-D-hui-mif- 91 dhcpv4-routing-00] extends DHCPv4 through introducing TOS and 92 specific routes into DHCP options. This document considers IPv6 93 situations. The approach presented in [I-D. sun-mif-route-config- 94 dhcp6-00] is an approach which extends DHCP option for sending route 95 information. The route table and the address selection policy table 96 can be used jointly to let multiple interfaces work simultaneously. 98 2. Solution of Multiple Interface Usage 100 The procedures of configuring policy table of address selection are 101 depicted in Figure 1. 103 The policy table configure procedures are shown as steps a1 to a3. 105 o a1) An interface sends Information-requirement when the connection 106 is established or when an existing connection receives 107 reconfiguration message from the server. 109 o a2) The server sends policy rults through DHCPv6 option as to be 110 defined in Section 3.2. 112 o a3) The policy rules received from the interface is used to 113 configure the policy table of the host. 115 The procedures that an application employs an interface for network 116 access are depicted in Figure 1 as steps b1 to b4. 118 o b1) An application calls sockets to build IP packets. 120 o b2) The socket determines the destination and selects source 121 address based on the policy table. 123 o b3) The socket sends packets to the corresponding interface. 125 o b4) The interface will forward the packets to the next hop (the 126 corresponding gateway). 128 +----+ a1 +---------+ b4 +-------+ 129 |DHCP|<--------- |Interface|--------->|Network| 130 +----+ --------> +---------+ +-------+ 131 a2 | | 132 | | 133 b3 | | 134 ^ | a3 135 | ----->----+ 136 | | 137 +-----------+ b1 +------+ +-----------+ 138 |Application|---->|Socket|<------|PolicyTable| 139 +-----------+ +------+ b2 +-----------+ 141 Figure 1 The procedures of updating a policy table and select an 142 interface for an application. 144 Notice that the approach proposed in this document is feasible under 145 the strong ES model as defined in RFC1122. 147 3. DHCPv6 Option Extensions 149 3.1. Host and Server Behavior 151 The host must include ''Option Request'' option to let the server know 152 the option the host interested. The request option code is set as the 153 ''Address Policy'' defined in 3.2. 155 The server constructs a Reply message to provide IP address policy 156 rules to the host. Also, a server may send a Reconfigure Message to 157 a host. The host may initiate a request when receiving the 158 Reconfigure message for the host. 160 3.2. Address Policy Option 162 The DHCPv6 option is extended to contain multiple pieces of default 163 address selection policy rules. Each piece of rules contains address, 164 preference and label which are properties defined in [RFC3484]. The 165 ADDRESS_POLICY option is depicted in Figure 2. 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | OPTION_ADDRESS_POLICY | option-len | IF-Based 1 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 + Add. Prefix Len 1 | Address Prefix 1 . 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 174 . . 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 + Preference 1 | Label 1 + 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 . . 179 . . 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 + IF-Based N | Add. Prefix Len N | Address Prefix N . 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 183 . . 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 + Preference N | Label N + 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 2 The Address Policy Option. 190 option-code OPTION_ ADDRESS_POLICY (should be defined by IANA). 192 option-len length of the route rule field in octets. 194 IF-Based N A flag used to indicate whether the Nth rule is 195 ''interface Based'' (=1) or ''host based'' (=0). 197 Address Prefix Len Length of an IPv6 destination address prefix, an 198 8-bit unsigned integer ranging from 0 to 128. 200 Address Prefix The address prefix 202 Preference A number identifies the priority of one type of IP address. 204 Label A number that used to mark the Nth rule correspondence 205 between source and destination address. 207 The ''IF-Based'' flag is used to indicate whether the rule applies only 208 to the interface that received the DHCP reply message or the rule is 209 ''host based'' and applies to all the interfaces. This flag is 210 introduced for merging route policies that received from multiple 211 interfaces. 213 3.3. Some Considerations of the DHCPv6 Option 215 3.3.1. Conflict of A Policy Table 217 For the situations where the rule in the policy table conflicts with 218 one previous policy table, the latter one will override the previous 219 rule. 221 3.3.2. Application Situations 223 There are two situations when DHCPv6 is applied, i.e., with or 224 without stateless autoconfiguration. For the stateless case, since 225 the address has been configured based on the link-local/site-local 226 address, the DHCPv6 is used to obtain options. 228 3.3.3. Not Limited to DHCP Servers 230 The solution presented in this document is with the context of DHCP 231 message. It should be pointed out that similar message may not be 232 conveyed by certain node in the network instead of a DHCP server. 233 Router solicitation and advertisement are also potential approach to 234 convey the 236 4. IANA Considerations 238 The option code of ADDRESS_POLICY will be defined by IANA. 240 5. Security Considerations 242 The security issues in this document are similar with those that have 243 been met when using DHCPv6 options. 245 The interface selection is affected by the routing and address 246 selection rules sent from servers. Therefore, incorrect information 247 received by hosts will cause improper interface selection leading to 248 bad user experiences. Attacks such as deny of services (DoS) or man- 249 in-the-middle may redirect host's solicitation, change the 250 information or flood the host with invalidate messages. Approaches to 251 guarantee the communication securities between hosts and servers 252 should be applied based on the network access types of the interfaces. 254 6. References 256 6.1. Normative References 258 [RFC1122] Braden, R., "Requirements for Internet Hosts - 259 Communication Layers", STD 3, RFC 1122, October 1989. 261 [RFC3484] R. Draves, "Default Address Selection for Internet Protocol 262 version 6 (IPv6)", RFC3484, February 2003. 264 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 265 and M. Carney, "Dynamic Host Configuration Protocol for 266 IPv6 (DHCPv6)", RFC 3315, July 2003. 268 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 269 More-Specific Routes", RFC 4191, November 2005. 271 6.2. Informative References 273 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 274 Discovery for IP Version 6 (IPv6)", RFC 2461, 275 December 1998. 277 [I-D. blanchet-mif-problem-statement] Blanchet, M., "Multiple 278 Interfaces Problem Statement", draft-blanchet-mif-problem- 279 statement-00 (work in progress), December 2008. 281 [I-D.hui-mif-dhcpv4-routing-00] Hui, M., and Deng, H. ''Extension of 282 DHCPv4 for policy routing of multiple interfaces terminal,'' 283 draft-hui-mif-dhcpv4-routing-00(work in progress), February 284 2009 286 [I-D.yang-mif-req] Yang, P., Seite, P., Williams, C., and J. Qin, 287 "Requirements on multiple Interface (MIF) of simple IP", 288 draft-yang-mif-req-00 (work in progress), March 2009. 290 [draft-fujisaki-dhc-addr-select-opt-07] Matsumoto, A., Niinobe, S., 291 Hiromi, R., and Kanayama, K., ''Distributing Address 292 Selection Policy using DHCPv6,'' draft-fujisaki-dhc-addr- 293 select-opt-07 (work in progress), March 2009. 295 Authors' Addresses 297 Tao Sun 298 China Moible 299 53A,Xibianmennei Ave., 300 Xuanwu District, 301 Beijing 100053 302 China 303 Email: suntao@chinamobile.com 305 Hui Deng 306 China Moible 307 53A,Xibianmennei Ave., 308 Xuanwu District, 309 Beijing 100053 310 China 311 Email: denghui@chinamobile.com 313 Xiaodong Duan 314 China Moible 315 53A,Xibianmennei Ave., 316 Xuanwu District, 317 Beijing 100053 318 China 319 Email: duanxiaodong@chinamobile.com