idnits 2.17.1 draft-liu-dmm-address-selection-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2012) is 4420 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) == Missing Reference: 'RFC3775' is mentioned on line 86, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Unused Reference: 'I-D.draft-seite-dmm-dma-00' is defined on line 277, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-seite-dmm-dma-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Liu 3 Internet-Draft H. Deng 4 Intended status: Standards Track China Mobile 5 Expires: September 13, 2012 J. Liu 6 ZTE 7 March 12, 2012 9 Address Selection for DMM 10 draft-liu-dmm-address-selection-01 12 Abstract 14 In DMM scenario, it is possible for the MN to have multiple mobility 15 anchor points and corresponding prefixes. In that case, MN needs to 16 know the type of the addresses then it can select the right one for 17 application to use. This document describes a mechnism to extend RA 18 message to carry a flag which can be used to identify the nature of 19 the prefix. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on September 13, 2012. 44 Copyright Notice 46 Copyright (c) 2012 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Problem of address selection for DMM . . . . . . . . . . . . . 3 62 2. Extension to Router Advertisment . . . . . . . . . . . . . . . 3 63 3. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . . 4 64 4. An Example of How This Draft Works . . . . . . . . . . . . . . 4 65 4.1. MN Handoffs From MAR to a Next MAR . . . . . . . . . . . . 5 66 4.2. MN Handoffs From MAR Back to Its Previous MAR . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Problem of address selection for DMM 77 As draft-liu-dmm-dynamic-anchor-discussion-00 introduced, there is a 78 address selection problem for DMM dynamic anchor solution. The 79 difficulty of this problem is: the MN does not know the difference 80 between the multiple prefixes. There is no way for the network to 81 tell the MN the nature of the different prefixes and there is no 82 standard mechnism for the MN to select the right prefix. 84 2. Extension to Router Advertisment 86 Mobile IPv6 [RFC3775] extend IPv6 router advertisement message for 87 movement detection and home agent information broadcasting. This 88 document proposes to further extend the IPv6 router advertisement 89 message to carry a flag to identify the nature of the prefix that it 90 is advertising. 92 +----------+---------+-------------------+ 93 | Type | Code | Checksum | 94 +----------+-+-+-+---+-------------------+ 95 |Hop Limit |M|O|H|Re-| Router Lifetime| 96 +----------+-+-+-+---+-------------------+ 97 | Reachable Time | 98 +----------------------------------------+ 99 | Retrans Timer | 100 +----------------------------------------+ 101 | Options | 102 +----------------------------------------+ 104 The H bit is used for indentify that the router advertisment is sent 105 by a home agent. 107 +-------------+------------+------------+-+-+-+--+---+ 108 | Type | Length |PrefixLength|L|A|R|T |R- | 109 +-------------+------------+------------+-+-+-+--+---+ 110 | Valid Lifetime | 111 +----------------------------------------------------+ 112 | Preferred Lifetime | 113 +----------------------------------------------------+ 114 | Reserved | 115 +----------------------------------------------------+ 116 | | 117 | Prefix | 118 +----------------------------------------------------+ 120 This document proposes to extend the prefix information option to add 121 a 'T' flag, its definition is as follows: 123 T (Type): 125 Type flag. This is a 2 bits flag indentifies the types of the 126 advertising prefix. The value of this flag could be: 128 00: Local home network prefix. It means that this prefix is 129 allocated and advertised by current router which the MN attaches to. 131 01 : Remote home network prefix. It means that this prefix is 132 allocated by another router instead of the router that the MN 133 currently attaches to. 135 10: Reserved. 137 11: Reserved. 139 The mechanism that used for the router to identify the types of the 140 prefix is out the scope of this document. As an example, the router 141 can query the policy server to know which router allocates a 142 particular prefix. 144 3. Mobile Node Operation 146 The mobile node knows the types of the prefixes from the T flag of 147 the router advertisment message. The applications on the mobile node 148 can use this information to select the right IP address. For 149 example, for on-going session, application always choose to use the 150 prefix that it used before it handovers to a new location. For the 151 newly initiate application, it will use the prefix that allocated by 152 current router, e.g. local home network prefix. The mobile node can 153 use advanced socket API to select the proper prefix, for example, 154 extension to RFC 5014.The detail mechanism is out the scope of this 155 document. 157 4. An Example of How This Draft Works 159 This section describes how the T flag specified above solves the 160 source address selection. Two different use cases are presented 161 below. 163 4.1. MN Handoffs From MAR to a Next MAR 165 _______ _______ _______ 166 | | | | | | 167 | CN1 | | CN2 | | CN3 | 168 |_______| |_______| |_______| 169 ' . . 170 Flow#1 ' Flow#2 . | Flow#3 171 ' ...'''''.'''''''.... . 172 ..''' . '''.. 173 .' ' IP network . '. 174 : ' . | : 175 '..' +-------+ . ..' 176 '''... | |.......''' 177 ' | MAR2 | \ . 178 ' | |. \ | 179 ' | | . \ . 180 ' +-------+\ .\ | 181 +-------+ HNP2(T=00) \ + ------+ 182 | | HNP1(T=01) \ | | HNP3(T=00) 183 | MAR1 |-----------------| MAR3 | HNP2(T=01) 184 | | ''''''''''''''''| | HNP1(T=01) 185 | |-----------------| | 186 +-------+ +-------+ 187 HNP1(T=00) ' . | 188 Flow#1 ' . . Flow#3 189 ' . | 190 +-----+ Flow#2 +-----+ 191 | MN | -----move-------> | MN | 192 +-----+ +-----+ 194 T=00: Local home network prefix 195 using common IP forwarding and routing mechanisms 197 T=01:Remote home network prefix 198 using mobility anchoring and tunneling to maintain communications 200 Figure 1: Source address selection in DMM 202 As shown in figure1, flow#1, flow#2 and flow#3 are initiated and 203 anchored at MAR1, MAR2 and MAR3 respectively. 205 When MN attaches to MAR1, MAR1 sends Router Advertisement 206 messages(RA) containing MN's home network prefix(HNP1) in Prefix 207 Information option with the Type flag (T) bit set to 00 as specified 208 in section 2. This indicates that HNP1 is local home network prefix 209 which is allocated and advertised by current router(MAR1). MN can 210 initiate a session with CN1 (i.e. flow#1 in figure1) by using IPv6 211 addresses derived from HNP1. Common IPv6 routing mechanism will be 212 applied for flow#1 as long as MN remains attached to MAR1. 214 When MN handoffs to MAR2(flow#1 continues while MN handoffs), MAR2 215 sends RA messages containing MN's new prefix(HNP2) in Prefix 216 Information option with the Type flag (T) bit set to 00 together with 217 old prefix (i.e. HNP1) with the Type flag (T) bit set to 01. MN 218 will learn that HNP2 is local home network prefix and HNP1 is remote 219 home network prefix. At this moment, MN can initiate a new sessions 220 with CN2 (i.e. flow#2 in the figure1) by using IPv6 addresses derived 221 from HNP2 as its source address. Because this IPv6 address is 222 derived from a local home network prefix (i.e. HNP2), common IPv6 223 routing mechanism will be applied for flow#2. For flow#1, MAR1 plays 224 role of LMA and MAR2 plays role of MAG. 226 When MN handoffs to MAR3(flow#1 and flow#2 continue while MN 227 handoffs), MAR3 sends RA messages containing MN's new prefix(HNP3) 228 and previous prefixes (HNP1 and HNP2) in Prefix Information option 229 with the Type flag (T) bit set to 00 for HNP3 and 01 for HNP1 and 230 HNP2. This indicates HNP3 is local home network prefix, and HNP1 and 231 HNP2 are remote home network prefixes. At this moment, MN can 232 initiates new sessions with CN3 (i.e. flow#3 in figure1) by using 233 IPv6 addresses derived from HNP3 as its source address. And Common 234 IPv6 routing mechanism will be applied for flow#3. 236 4.2. MN Handoffs From MAR Back to Its Previous MAR 238 MN could also handoff back from MAR3 to MAR2 again (assuming flow#1, 239 flow#2 and flow#3 continue while MN handoffs). 241 In this case, as described above, MAR2 will send RA messages 242 containing HNP1, HNP2 and HNP3 in Prefix Information option with the 243 Type flag (T) bit set to 00 for HNP2 and 01 for HNP1 and HNP3. This 244 indicates HNP2 is local home network prefix, HNP1 and HNP3 are remote 245 home network prefixes. 247 Assuming that MN initiates a new sessions with a new communication 248 node (e.g. with CN4 which is not shown in figure1) by using IPv6 249 addresses derived from HNP2 as its source address. Because this IPv6 250 address is derived from a local home network prefix (i.e. HNP2), 251 common IPv6 routing mechanism will be applied for this session. 253 5. IANA Considerations 255 This document makes no request of IANA. 257 Note to RFC Editor: this section may be removed on publication as an 258 RFC. 260 6. Security Considerations 262 TBD 264 7. Acknowledgements 266 TBD 268 8. References 270 8.1. Normative References 272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 273 Requirement Levels", BCP 14, RFC 2119, March 1997. 275 8.2. Informative References 277 [I-D.draft-seite-dmm-dma-00] 278 Seite, P. and P. Bertin, "Distributed Mobility Anchoring, 279 draft-seite-dmm-dma-00", February 2012. 281 Authors' Addresses 283 Dapeng Liu 284 China Mobile 285 32 Xuanwumen West Street 286 Beijng, Xicheng District, 100053 287 China 289 Phone: +86-13911788933 290 Email: liudapeng@chinamobile.com 292 Hui Deng 293 China Mobile 294 32 Xuanwumen West Street 295 Beijng, Xicheng District, 100053 100053 296 China 298 Email: denghui@chinamobile.com 299 Juan Liu 300 ZTE 301 No.68, Zijinhua RD,Yuhuatai District 302 Nanjing, Jiangsu 210012 303 China 305 Email: liu.juan45@zte.com.cn