idnits 2.17.1 draft-zhao-lisp-mn-extension-02.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 (October 30, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'LISP-MS' is mentioned on line 327, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-08 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPSP Working Group Ningxia. Zhao 3 Internet-Draft Jiong. Shen 4 Intended status: Informational Mo. Sun 5 Expires: May 2, 2012 ZTE Corporation 6 October 30, 2011 8 LISP Mobile Node extension 9 draft-zhao-lisp-mn-extension-02 11 Abstract 13 LISP describes a network-based protocol that enables separation of IP 14 addresses into two new numbering spaces: Endpoint Identifiers (EIDs) 15 and Routing Locators (RLOCs). No changes are required to either host 16 protocol stacks or to the "core" of the Internet infrastructure. The 17 LISP Mobile Node extension design described in this document uses 18 standard LISP functionality to provide scalable mobility for LISP 19 mobile nodes. 21 This document extends the lisp, it introduces some contents that lisp 22 does not include but the author think it is important and 23 recommendation them to be considered in the lisp. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 2, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. new section . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. LISP Extension Operation . . . . . . . . . . . . . . . . . . . 7 60 4.1. EID-to-RLOC Mapping Update Operation . . . . . . . . . . . 7 61 4.2. Map-Unregister Operation . . . . . . . . . . . . . . . . . 7 62 5. LISP Extension Message . . . . . . . . . . . . . . . . . . . . 9 63 5.1. LISP Packet Type Allocations . . . . . . . . . . . . . . . 9 64 5.2. Map-Update Message Format . . . . . . . . . . . . . . . . 9 65 5.3. Map-Unregister Message Format . . . . . . . . . . . . . . 10 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 LISP defines protocol mechanisms for mapping from EIDs to RLOCs, the 77 lisp-MN specifies the behavior of the LISP Mobile Node, it has 78 introduced some aspects of lisp-MN, but there are some other 79 important areas have not considered. 81 The LISP Mobile Node extension design described in this document uses 82 standard LISP functionality to provide scalable mobility for the 83 mobile node in the LISP site. 85 o The EID-to-RLOC mapping update operation has not be considered. 86 When a MN in the LISP site roams onto a new network, it receives a 87 new RLOC, the lisp-MN Map-Registers it's new RLOC to its 88 configured Map-Server, then the lisp-MN sends packet to its peer 89 side by the new RLOC. But before the peer side receives the 90 packet the lisp-MN sent, the peer side will send packet to lisp-MN 91 by the old RLOC or the peer side must query the MS to obtain the 92 lisp-MN's RLOC and then the peer side updates its cache of the 93 EID-to-RLOC mapping and send packet by the new RLOC, this will 94 cause a problem, the packet the lisp-MN to receive from its peer 95 side will be missed or delayed when the LISP-MN roams onto a new 96 network. So how to update the previous EID-to-RLOC mapping cached 97 in the lisp-MN's peer side must be considered. 99 o The deregister has not be considered. When a MN in the lisp site 100 is shutdown or the user initiates to interrupt the network 101 connection or the contract is limited, the lisp-MN needn't 102 continue attach to the network, the lisp-MN or the network will 103 initiate the process of the Map-Unregister. 105 This document specifies the LISP-MN extension operation, which 106 includes two aspects, the EID-to-RLOC Mapping Update Operation and 107 the Map-Unregister Operation. 109 Design goals for the LISP-MN extension design include: 111 o The LISP-MN extension design described in this document based on 112 the Lisp, this document does not change any contents of the LISP. 114 o The LISP-MN extension design described in this document uses 115 standard LISP functionality. 117 o This document only do some extension of the lisp and only 118 introduces the contents the author think must be supplemented to 119 the lisp . 121 o The LISP-MN extension design is built from the existing LISP 122 components: the MN in lisp site, its corresponding side in 123 communication , the existing Map-Server [LISP-MS] and the 124 Interworking [LISP-INTERWORK] infrastructures. 126 2. new section 127 3. Terminology 129 This section defines the terms used in this document. 131 LISP Mobile Node (LISP-MN): A LISP capable fast roaming mobile hand- 132 set. 134 Endpoint ID (EID): This is the traditional LISP EID [LISP], and is 135 the address that a LISP mobile node uses as its address for transport 136 connections. A LISP mobile node never changes its EID, which is 137 typically a /32 or /128 prefix and is assigned to a loopback 138 interface. Note that the mobile node can have multiple EIDs, and 139 these EIDs can be from different address families. 141 Routing Locator (RLOC): This is the traditional LISP RLOC, and is in 142 general a routable address that can be used to reach a mobile node. 143 Note that there are cases in which an mobile node may receive an 144 address that it thinks is an RLOC (perhaps via DHCP) which is either 145 an EID or an RFC 1918 address [RFC1918][RFC1918]. This could happen 146 if, for example, if the mobile node roams into a LISP domain or a 147 domain behind a Network Address Translator (NAT). 149 Map-cache: A data structure which contains an EID-prefix, its 150 associated RLOCs, and the associated policy. Map-caches are 151 typically found in ITRs and PITRs. 153 Map Update: A Map update is the lisp-MN notifies the correspondent to 154 change the EID-to-RLOC mapping when the lisp-MN move to another 155 location in the communication process. 157 Map Unregister: A Map Unregister is the lisp-MN notifies the 158 MS[LISP-Map-Server] to unbind the EID-to-RLOC mapping when the 159 lisp-MN needn't to attached to the network. 161 4. LISP Extension Operation 163 The LISP Extension Operation described in this document uses the ETR/ 164 ITR or theLISP-MN to provide scalable fast mobility and the Map- 165 Unregister operation. 167 4.1. EID-to-RLOC Mapping Update Operation 169 This section provides the EID-to-RLOC mapping update operation. 171 After a roaming event, a LISP-MN must immediately register its new 172 EID-to-RLOC mapping with its configured Map-Server(s). In addition, 173 the Lisp-MN sends the EID-to-RLOC mapping update request to its peer 174 side to inform the peer side the LISP-MN which is ongoing 175 communication has moved to a new location and the Lisp-MN has 176 received a new RLOC, the EID-to-RLOC mapping update request message 177 carries the EID and the new RLOC of the Lisp-MN. After received the 178 EID-to-RLOC mapping update request, the peer side updates the EID-to- 179 RLOC mapping cached in its local, that is in the local cache use the 180 new RLOC instead of the old RLOC in the EID-to-RLOC mapping, then the 181 peer side returns he EID-to-RLOC mapping update response (Update 182 Response) message to the lisp-MN. The EID-to-RLOC mapping update 183 operation improves the efficiency of data transmission and decreases 184 the occurrence of packet latency and packet loss when a roaming event 185 occurs in communication . 187 4.2. Map-Unregister Operation 189 When the MN in a lisp site is shutdown or the user initiates to 190 interrupt the network connection, the MN needn't continue register to 191 the network, the lisp-MN will initiate the process of the Map- 192 Unregister. 194 The lisp-MN sends a map-unregister to its configured Map-Server(s) to 195 delete the EID-to-RLOC mapping stored in this MS. 197 After received the Map-Unregister Request, the MS removes the EID-to- 198 RLOC mapping stored in it and sends the Map-Unregister response to 199 the lisp-MN, the message in this process carries the instructions 200 indicates the success or failure of the Map-Unregister operation. 201 The Map-Unregister process is completed. 203 The Map-Unregister Operation also inclueds another scenario, when the 204 lisp network detects the contact of the host is limited (how does the 205 network detect the contact of the host is limited is out of this 206 scope), the network will initiate the process of the Map-Unregister. 208 When the lisp network detects the contact of the host is limited, the 209 network side informs the MS the host be listed in the black. Then 210 the MS removes the EID-to-RLOC mapping stored in it and sends a map- 211 unregister to the ETR and the ITR which communications with the 212 host， The MS can inform the ITR based on which has queried the 213 MS for the EID-to-RLOC mapping of the host and TTL has not expired. 215 After received the Map-Unregister Request, the ITR removes the EID- 216 to-RLOC mapping stored in its cache and sends the Map-Unregister 217 response to the MS, the ETR sets rules to prevent the flow to and 218 from the black host according to EID of the black host and sends the 219 Map-Unregister response to the MS.The Map-Unregister process is 220 completed. 222 5. LISP Extension Message 224 5.1. LISP Packet Type Allocations 226 This section will be the authoritative source for allocating LISP 227 Type values. Current allocations are: 229 o LISP Map-Update: 5 b'0101' 231 o LISP Map-Unregister: 6 b'0110' 233 5.2. Map-Update Message Format 235 The Map-Update message format is: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |Type=5 |P| Reserved | Record Count | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Nonce . . . | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | . . . Nonce | 245 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | Record TTL | 247 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 R | Locator Count | EID mask-len | ACT |A| Reserved | 249 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 c | Rsvd | Map-Version Number | EID-prefix-AFI | 251 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 r | EID-prefix | 253 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | /| Priority | Weight | M Priority | M Weight | 255 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | o | Unused Flags |L|p|R| Loc-AFI | 257 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | \| Locator | 259 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Mapping Protocol Data | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 1: Map-Update Message Format 265 Packet field descriptions: 267 Type: 5 (Map-Update) 268 The Map-Update message has the same contents as a Map-Register 269 message. See Map-Register section in LISP [LISP]for field 270 descriptions. 272 5.3. Map-Unregister Message Format 274 The Map-Unregister message format is: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 |Type=6 |P| Reserved | Record Count | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Nonce . . . | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | . . . Nonce | 284 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | | Record TTL | 286 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 R | Locator Count | EID mask-len | ACT |A| Reserved | 288 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 c | Rsvd | Map-Version Number | EID-prefix-AFI | 290 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 r | EID-prefix | 292 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | /| Priority | Weight | M Priority | M Weight | 294 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | o | Unused Flags |L|p|R| Loc-AFI | 296 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | \| Locator | 298 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Mapping Protocol Data | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Packet field descriptions: 304 Type: 6 (Map-Unregister) 306 The EID-prefix in this message including the length is zero and the 307 length in non-zero, when the length is zero, the EID-prefix just 308 equal to the EID. 310 Because one EID maybe mapping to multiple RLOCs, so the Map- 311 Unregister operation including two cases. One case is to remove all 312 the RLOC mapping to the EID when the Map-Unregister occurs, this time 313 the Map-Unregister Message Format does not contain the field of the 314 Locator. The second case is only remove one specific RLOC mapping to 315 the EID when the Map-Unregister occurs, this time the Map-Unregister 316 Message Format just contains the field of the Locator which must be 317 canceled. 319 The other field of the Map-Unregister message just has the same 320 contents as a Map-Register message. See Map-Register section in LISP 321 [LISP] for field descriptions. 323 6. Security Considerations 325 Security for the LISP-MN design builds upon the security fundamentals 326 found in LISP [LISP] for data-plane security and the LISP Map Server 327 [LISP-MS] registration security. Security issues unique to the 328 LISP-MN design are considered below. 330 7. IANA Considerations 332 This document creates no new requirements on IANA namespaces 333 .[RFC5226] 335 8. Acknowledgments 337 TBD 339 9. References 341 9.1. Normative References 343 [RFC1918] Rekhter, Y. and R. Moskowitz, "Address Allocation for 344 Private Internets", 1996. 346 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 347 IANA Considerations Section in RFCs", May 2008. 349 9.2. Informative References 351 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 352 "Locator/ID Separation Protocol (LISP)", April 2011. 354 [LISP-INTERWORK] 355 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 356 "Interworking LISP with IPv4 and IPv6", March 2011. 358 [LISP-Map-Server] 359 Farinacci, D. and V. Fuller, "LISP Map Server", 360 draft-ietf-lisp-ms-08 work in progress, June 2011. 362 Authors' Addresses 364 Ningxia Zhao 365 ZTE Corporation 366 4F,RD Building 2,Zijinghua Road No.68 367 Yuhuatai District,Nanjing 210012 368 P.R.China 370 Phone: +86-025-5287-7612 371 Email: zhao.ningxia@zte.com.cn 373 Jiong Shen 374 ZTE Corporation 375 4F,RD Building 2,Zijinghua Road No.68 376 Yuhuatai District,Nanjing 210012 377 P.R.China 379 Phone: +86-025-5287-7612 380 Email: wang.jun17@zte.com.cn 382 Mo Sun 383 ZTE Corporation 384 C1-04,RD Building 1,Zijinghua Road No.68 385 Yuhuatai District,Nanjing 210012 386 P.R.China 388 Phone: +86-025-5287-2045 389 Email: meng.yu@zte.com.cn