idnits 2.17.1 draft-yegin-l2-triggers-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2002) is 7979 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) -- Possible downref: Normative reference to a draft: ref. 'REQ' ** Obsolete normative reference: RFC 2002 (ref. 'MIPV4') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-17 -- No information found for draft-ietf-mobileip-lowlatencyhandoffs-v4 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FMIPV4' -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FMIPV6' ** Obsolete normative reference: RFC 2402 (ref. 'AUTH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'ENCR') (Obsoleted by RFC 4303, RFC 4305) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Alper E. Yegin 3 Document: draft-yegin-l2-triggers-00.txt DoCoMo USA Labs 4 Expires: December 2002 June 2002 6 Link-layer Triggers Protocol 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. This is an individual 12 draft for consideration by the PILC Working Group. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 Wireless and mobile hosts are subject to changing their point of 32 attachment from one access network to another. These changes result 33 in link-layer events such as link up and link down. Information on 34 these events can be conveyed to interested parties in the form of 35 link-layer triggers. Primary consumers of this information are the 36 modules implementing mobility related network-layer protocols. When 37 provider and consumer of this information are co-located on the same 38 IP node, required communication can take place via internal 39 mechanisms. But when they are separate, as in the case of networks 40 using wired-to-wireless bridges, a transport mechanism is needed to 41 convey link-layer triggers. This draft defines a UDP based client- 42 server protocol for transporting link-layer triggers between two IP 43 nodes. 45 Table of Contents 47 1.0 Introduction.................................................2 48 2.0 Protocol Overview............................................4 49 3.0 Protocol Details.............................................5 50 3.1. Hello Message.............................................6 51 3.2. Registration Message......................................6 52 3.3. Trigger Message...........................................7 53 3.4. Query Message.............................................9 54 4.0 Security Considerations.....................................10 55 5.0 IPR Statement...............................................10 56 6.0 Acknowledgements............................................11 57 7.0 References..................................................11 58 8.0 Author's Addresses..........................................11 59 9.0 Full Copyright Statement....................................12 61 1.0 Introduction 63 Wireless and mobile hosts are subject to changing their point of 64 attachment from one access network to another. This process is 65 called a handover. Handovers involve a change in link-layer 66 connectivity, and sometimes in network-layer connectivity as well. A 67 host has to identify a new attachment point, disassociate from the 68 current link, and associate with a new link. After this process, 69 depending on whether the new link is still part of the same network 70 subnet as the previous link, host may also need to take actions to 71 re-establish network-layer connectivity. 73 Link-layer of a host and the access node on the access network has 74 knowledge and control on the link-layer events. These events may 75 include anticipation and execution of a host associating/ 76 disassociating with the link. While information on these events is 77 already available to the link-layer of involved parties, they are 78 transparent to the network-layers. [REQ] identifies scenarios where 79 availability of this information at the network-layer is required 80 for re-establishing network-layer connectivity. Certain protocols 81 rely on this information to function [FMIPV4] [FMIPV6] and others 82 perform better when this information is available [MIPV4] [MIPV6]. 83 Link-layer events are communicated to the network-layer in the form 84 of link-layer (L2) trigger. [REQ] identifies the type of information 85 that needs to be carried in L2 triggers. 87 Link-layer and network-layer of a host are co-located on the same IP 88 node in a standard network stack implementation. Therefore L2 events 89 take place on the same node and network-layer can be notified via 90 internal mechanisms. A simple interface between two modules running 91 on the same IP node should be sufficient. 93 ~~~~~~~~~~~~~~~~~~ 94 \|/ wireless \|/ 95 | link | 96 +------+ wired +----+---+ +---+----+ wired +--------+ 97 | | link | access | | access | link | | 98 | host +---------+ device | | point +---------+ access | 99 | | |(bridge)| |(bridge)| | router | 100 +------+ +--------+ +--------+ +--------+ 102 Figure 1. Host connecting via wireless bridges 104 A problem arises when wireless bridges are used in connecting hosts 105 to networks. Figure 1 illustrates a host connecting to an access 106 router via wireless bridges. Wireless bridges are connected to each 107 other via a wireless link which is defined by its two end points. As 108 an example, a laptop might be using a cell phone to associate with a 109 wireless link. Similarly an access router might be using a base 110 station to provide service over the wireless link. In this case, 111 only the bridges can know when a host is associated/disassociated 112 with the link. Neither the host nor the access router can use an 113 internal method to get informed about the L2 events associated with 114 the wireless link. This is where a new transport is needed to 115 convey L2 trigger information between two IP nodes (i.e., from 116 bridges to the interested parties). 118 ~~~~~.. ..~~~~~ 119 \|/ \|/ 120 link | | link 121 +------+ down +----+---+ +---+----+ down +--------+ 122 | | <------ | access | | access | ------> | | 123 | host +---------+ device | | point +---------+ access | 124 | | |(bridge)| |(bridge)| | router | 125 +------+ +--------+ +--------+ +--------+ 127 Figure 2. Link down triggers sent when host disassociates 129 This new transport is defined as L2 triggers protocol in this draft. 130 This is a UDP based client-server protocol to transport L2 event 131 information from access devices/points to other IP nodes such as 132 mobile hosts and access routers. 134 2.0 Protocol Overview 136 In this protocol, bridges are the servers that have firsthand 137 knowledge on the L2 events, and hosts and routers using these 138 bridges are the clients that are interested in these L2 events. 139 Bridges must be capable of running IP and UDP in order to use this 140 protocol. 142 ~~~~~~~~~~~~~~~~~~ 143 \|/ wireless \|/ 144 | link | 145 +------+ wired +----+---+ +---+----+ wired +--------+ 146 | | link | access | | access | link | | 147 | host +---------+ device | | point +---------+ access | 148 | | |(bridge)| |(bridge)| | router | 149 +------+ +--------+ +--------+ +--------+ 151 client <-------> server server <-------> client 153 Figure 3. Clients and servers of L2 triggers protocol 155 First thing is the identification of servers by the clients. This 156 can happen either by manual configuration, or by dynamic discovery. 157 Clients can discover servers on the same subnet by multicasting a 158 Hello message to a well-known IP address. Servers must respond to 159 this message by a unicast Hello message sent back. A client may 160 periodically send these multicast Hello messages to keep track of 161 active servers. It can also send a unicast Hello message to learn if 162 a server is still alive. When a server starts, it must multicast a 163 Hello message to announce its service. A client must not respond to 164 this unsolicited Hello message. 166 Once a client identifies a server to receive L2 triggers from, it 167 must register with the server. Client must send a Registration 168 message to the server and the server must send back a Registration 169 Acknowledgement message. Each registration has a lifetime and must 170 be renewed before expiration. After this point server will be 171 notifying the client about the L2 events that take place on the 172 server. Client can de-register from the server at any time by 173 sending a Registration message with 0 lifetime, and the server must 174 send back a Registration Acknowledgement message with 0 lifetime. 176 When a L2 event takes place on the server, it must send a Trigger 177 message to every one of the registered clients. Server may choose to 178 combine more than one L2 trigger in a single message, which is 179 subject to local policy. Server may also request an acknowledgement 180 from the client, and client must send back a Trigger 181 Acknowledgement. L2 triggers include Link Down, Link Up, Source Pre- 182 trigger, Target Pre-trigger, and Mobile Pre-trigger as defined in 183 [REQ]. Additionally server may send a Pre-trigger Cancel in the 184 Trigger message to indicate conditions leading to an earlier sent 185 Pre-trigger has changed and that pre-trigger must be disregarded. 187 In addition to getting notified of the L2 events, clients can query 188 the server for the status of a specific link. A host can query its 189 access device to learn if it is still associated to a specific 190 access point. Similarly, an access router can query its access point 191 to learn if a specific host is still associated with it. Clients 192 send a Query Request message to the server, and server replies with 193 a Query Response. 195 3.0 Protocol Details 197 L2 triggers protocol is a UDP based client-server protocol. Both 198 clients and servers join a well-known multicast group (TBD) and 199 listen on a well-known port (TBD). Protocol format is as follows: 201 IP fields: 203 Source Address 204 Typically the interface address from which the message is 205 sent. 207 Destination Address 208 Typically the interface address to which the message is 209 sent. TBD when the Hello message is multicasted. 211 Time-to-live 212 Always set to 255 when sent. The receiver must verify this 213 value to limit use of this protocol to nodes on the same IP 214 link. 216 UDP fields: 218 Source Port 219 Variable, when not sent as a response. TBD when sent as a 220 Response to an incoming message. 222 Destination Port 223 Copied from the incoming message's source port when sent as 224 a response, TBD otherwise. 226 The UDP header is followed by the protocol fields shown below: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | Data ... ~ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Type 234 1 Hello 235 2 Registration 236 3 Trigger 237 4 Query 239 Data 240 Data specific to a given Type. 242 3.1. Hello Message 244 This message is used by clients to discover servers, and by servers 245 to announce their availability. 247 The UDP header is followed by the following protocol fields for a 248 Hello message. 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type |C| Reserved | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Type 257 1 Hello 259 C 260 Client bit. Set to 1 when Hello message is sent by a client, 261 set to 0 otherwise. 263 Reserved 264 Reserved bits, sent as 0. 266 3.2. Registration Message 268 Clients use this message for registering with the servers. Servers 269 start delivering L2 triggers to registered clients. Same message is 270 used for both Registration Request and Registration 271 Acknowledgements. 273 The UDP header is followed by the following protocol fields for a 274 Registration message. 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 |R| Reserved | Lifetime | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Type 283 2 Registration 285 R 286 Request bit. Set to 1 when this is a Registration Request 287 message, set to 0 when this is a Registration Acknowledgement 288 message. 290 Reserved 291 Reserved bits, sent as 0. 293 Lifetime 294 The number of seconds remaining before the registration 295 is considered expired. This field is set to the requested 296 lifetime value by the client, and granted lifetime value by 297 the server. A value of zero indicates a request for 298 deregistration. A value of 0xffff indicates infinity. 300 3.3. Trigger Message 302 This message is used by servers to deliver L2 event notifications to 303 the clients. 305 The UDP header is followed by the following protocol fields for a 306 Trigger message. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Type |A| Reserved | Identification | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Data ... ~ 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Type 317 3 Trigger 319 A 320 Acknowledge request bit. When set, the client must send back 321 an acknowledgement. Client sends back a Trigger message with 322 A bit set to zero, Identification copied from the incoming 323 Trigger message, and no data to acknowledge receipt of a 324 Trigger message. 326 Reserved 327 Reserved bits, sent as 0. 329 Identification 330 A 16-bit number, constructed by the server, used for 331 matching Trigger messages with Trigger Acknowledgement 332 messages. 334 Data 335 L2 event specific data. Server can send information relating 336 to one or more L2 events. 338 Data field can contain a stream of L2 event related data. Each L2 339 event data is carried in the following format: 341 0 1 2 3 342 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 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Event Type | Data Length | Event Data ... ~ 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Event Type 348 1 Link Up 349 2 Link Down 350 3 Source Pre-trigger 351 4 Target Pre-trigger 352 5 Mobile Pre-trigger 354 Data Length 355 Length of Event Data field in bytes. 357 Event Data 358 Event Data includes a single L2 address for Link Up, Link 359 Down, and Mobile Trigger events. When a host receives a Link 360 Up trigger, L2 address specified in the Event Data field 361 indicates the link-layer address of the newly associated 362 access point. Similarly, when an access router receives a 363 Link Up trigger, L2 this address indicates the link-layer 364 address of the newly associated access device. 366 Event Data includes two L2 addresses for Source Trigger and 367 Target Trigger messages. First one is the L2 address of an 368 access point, and the second one is the L2 address of an 369 access device. When an access router receives a Source 370 Trigger, first L2 address indicates the anticipated 371 destination access point of an access device which is 372 identified by the second L2 address. Similarly, when an 373 access router receives a Target Trigger, first L2 address 374 indicates the source access point of an anticipated access 375 device which is identified by the second L2 address. 377 Since Pre-triggers are based on anticipation but not actual 378 events, they might need to be cancelled in case conditions 379 leading to their anticipation change. In this case, servers 380 send another Pre-trigger and set the L2 address field of 381 access point to 0, and specify the access device in the 382 second L2 address field. Client must be able to identify an 383 earlier sent L2 trigger based on the L2 address of the access 384 device and disregard the previous event. Similarly L2 address 385 set to 0 indicates a Pre-trigger cancellation for Mobile 386 Pre-triggers. 388 A L2 address is specified in variable length field. The 389 content and format of this field (including byte and bit 390 ordering) is expected to be specified in specific documents 391 that describe how IP operates over different link layers. 393 Both access routers and hosts can receive Link Up, Link Down. 394 Only hosts can receive Mobile Pre-trigger, and only access 395 routers can receive Source Pre-trigger and Target 396 Pre-trigger. 398 3.4. Query Message 400 This message is used by clients for querying state of a given link. 402 The UDP header is followed by the following protocol fields for a 403 Query message. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Type |R| Reserved |A| Reserved | L2 Address .. ~ 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Type 412 4 Query 414 R 415 Request bit. Set to 1 when this is a Query Request message, 416 Set to 0 when this is a Query Response message. 418 Reserved 419 Reserved bits, sent as 0. 421 A 422 Association bit. Set to 0 when sent in a Query Request and 423 ignored upon receipt. Set to 1 in a Query Response message if 424 the queried L2 address is still associated, 0 otherwise. 426 Reserved 427 Reserved bits, sent as 0. 429 L2 Address 430 L2 address of the wireless link remote end-point queried by 431 the sender of a Query Request message. If Query Request is 432 sent by a host, this field contains L2 address of an access 433 point. If Query Request is sent by an access router, this 434 field contains L2 address of an access device. The Query 435 Response must copy this field from the incoming Query 436 Request, set the R bit to 1, and specify the A bit according 437 to the link state. 439 L2 address is specified in variable length field. The content 440 and format of this field (including byte and bit ordering) is 441 expected to be specified in specific documents that describe 442 how IP operates over different link layers. 444 4.0 Security Considerations 446 L2 triggers are used in making routing decisions as stated in [REQ]. 447 As such, their misuse can lead to undesirable side effects and 448 therefore must be prohibited. 450 The time-to-live field of messages sent are set to 255 and verified 451 by the receivers. Therefore nodes that are not on the same IP link 452 cannot use this protocol. This method provides protection against 453 unauthorized use of protocol by off-link nodes. 455 Protection against unauthorized use by on-link nodes can be 456 accomplished by using IPsec [AUTH] [ENCR]. Hello messages do not 457 have to be secured. But Registration, Trigger, and Query messages 458 can be secured by using IPsec. IPsec can provide both authentication 459 and privacy when needed. Required security associations among 460 clients and servers need to be established in advance. 462 5.0 IPR Statement 464 The IETF has been notified of intellectual property rights claimed 465 in regard to some or all of the specification contained in this 466 document. For more information consult the online list of claimed 467 rights. 469 6.0 Acknowledgements 471 Author of this draft would like to thank Carl Williams, Daichi 472 Funato, and Youngjune Gwon for their valuable comments and 473 discussions. 475 7.0 References 477 [REQ] J. Kempf, et. al. Supporting Optimized Handover for IP 478 Mobility - Requirements for Underlying Systems (work in 479 Progress). draft-manyfolks-l2-mobilereq-02.txt, June 2002. 481 [MIPV4] C. Perkins. IP Mobility Support. Request for Comments 482 (Proposed Standard) 2002, Internet Engineering Task Force, 483 October 1996. 485 [MIPV6] D. Johnson, C. Perkins and J. Arkko. Mobility Support in 486 IPv6 (work in progress). draft-ietf-mobileip-ipv6-17.txt, 487 May 2002. 489 [FMIPV4] K. El-Malki, et. al., Low Latency Handoff in Mobile IPv4 490 (work in progress). 491 draft-ietf-mobileip-lowlatencyhandoffs-v4-01.txt. 493 [FMIPV6] G. Dommety, et. al. Fast Handovers for Mobile IPv6 494 (work in progress). draft-ietf-mobileip-fast-mipv6-04.txt, 495 March 2002. 497 [AUTH] S. Kent and R. Atkinson. IP Authentication Header. Request 498 for Comments (Proposed Standard) 2402, Internet Engineering 499 Task Force, November 1998. 501 [ENCR] S. Kent and R. Atkinson. IP Encapsulating Security Payload 502 (ESP). Request for Comments (Proposed Standard) 2406, 503 Internet Engineering Task Force, November 1998. 505 8.0 Author's Addresses 507 Alper E. Yegin 508 DoCoMo Communications Laboratories USA, Inc. 509 181 Metro Drive, Suite 300 Phone: +1 408 451 4743 510 San Jose, CA 95110 Fax: +1 408 451 1090 511 USA email: alper@docomolabs-usa.com 512 9.0 Full Copyright Statement 514 Copyright (C) The Internet Society (2002). All Rights Reserved. 516 This document and translations of it may be copied and furnished 517 to others, and derivative works that comment on or otherwise 518 explain it or assist in its implementation may be prepared, copied, 519 published and distributed, in whole or in part, without 520 restriction of any kind, provided that the above copyright notice 521 and this paragraph are included on all such copies and derivative 522 works. However, this document itself may not be modified in any 523 way, such as by removing the copyright notice or references to the 524 Internet Society or other Internet organizations, except as needed 525 for the purpose of developing Internet standards in which case the 526 procedures for copyrights defined in the Internet Standards 527 process must be followed, or as required to translate it into 528 languages other than English. 530 The limited permissions granted above are perpetual and will not 531 be revoked by the Internet Society or its successors or assigns. 533 This document and the information contained herein is provided on 534 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 535 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 536 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 537 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 538 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.