idnits 2.17.00 (12 Aug 2021) /tmp/idnits65229/draft-wu-mip4-ether-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 abstract seems to contain references ([RFC3344]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 12, 2009) is 4750 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) == Unused Reference: 'RFC2003' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'RFC2890' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC4448' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC4719' is defined on line 500, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Q. Wu, Ed. 3 Internet-Draft Huawei Technologies Co.,Ltd 4 Intended status: Standards Track S. Rahman 5 Expires: November 13, 2009 Ericsson 6 H. Deng 7 China Mobile 8 May 12, 2009 10 MIP Extension for Ethernet Service transport Support 11 draft-wu-mip4-ether-02 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 13, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 The IP Mobility Protocol [RFC3344] enables a mobile node maintain IP 50 connectivity when it changes its location. However, it is not enough 51 to enable the node to maintain L2 connectivity between mobile node 52 and Ethernet service provider in order to support Ethernet service 53 transport. This document describes "Ethernet Service Transport" 54 mobility option for mobile IPv4 that is intended to assist home agent 55 tunnel Ethernet packets from the home link to the FA on the foreign 56 link during the datagram delivery process. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Scenarios for MIP based Ethernet Services . . . . . . . . . . 4 63 3.1. Hybrid services transport . . . . . . . . . . . . . . . . 4 64 3.2. Native Ethernet Service Transport . . . . . . . . . . . . 5 65 3.3. VLAN Tag Support . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Multi-Host Support . . . . . . . . . . . . . . . . . . . . 6 67 4. Processing Consideration . . . . . . . . . . . . . . . . . . . 7 68 4.1. GRE Encapsulation Support . . . . . . . . . . . . . . . . 7 69 4.2. Ethernet Service Transport Support . . . . . . . . . . . . 7 70 5. Mobile Node Consideration . . . . . . . . . . . . . . . . . . 7 71 6. Foreign Agent Consideration . . . . . . . . . . . . . . . . . 8 72 6.1. Extension to registration tables for the Foreign Agent . . 8 73 6.2. Foreign Agent Operation . . . . . . . . . . . . . . . . . 8 74 7. Home Agent Consideration . . . . . . . . . . . . . . . . . . . 9 75 7.1. Extension to registration tables for the Home Agent . . . 9 76 7.2. Home Agent Operation . . . . . . . . . . . . . . . . . . . 9 77 8. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 10 78 8.1. Ethernet Extension Mobility Option . . . . . . . . . . . . 10 79 8.2. Vendor specific Extension Option . . . . . . . . . . . . . 10 80 8.3. GRE Extension option . . . . . . . . . . . . . . . . . . . 10 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 The IP Mobility Protocol[RFC3344]enables a mobile node maintain IP 91 connectivity when it changes its location. However, in some mobile 92 IPv4 scenarios, enabling the node maintain its L2 connectivity is 93 required to support forwarding Ethernet frames between mobile node 94 and Ethernet service provider (e.g. ASP), i.e. "Ethernet Service 95 Transport" support. 97 The capability to support Ethernet service can facilitate mobility 98 service providers to provider IP services as well as Ethernet 99 services concurrently over the same infrastructure within the same 100 mobility service subscription. For example: 102 o Provide end to end Ethernet connectivity from the mobile node 103 across access network to the ASP providing Ethernet services (e.g. 104 connectivity to DSL network with PPPoE). 106 o Ethernet service support within the access network, e.g., node 107 movement from one Ethernet segment to another within the same 108 access network. It allows transport Ethernet frame between mobile 109 node and the mobility anchor(e.g. FA). 111 o Provide Ethernet aggregation for the public access service which 112 imposes Ethernet frame to pass through ISP-head end to enable 113 accouting and enforce security policies. 115 This document describes Ethernet extension mobility option for mobile 116 IPv4 that is intended to assist home agent to tunnel Ethernet frame 117 on the home link to the FA in the foreign link during datagram 118 delivery process after the binding registration procedure. Ethernet 119 service support for mobile IPv4 may affect the home agent routing 120 decision, home address assignment polices and tunnel setup mechanism. 121 Support of Ethernet does not require a new network architecture or 122 any new functional entities in the network. The support of Ethernet 123 Services is smoothly integrated into the Mobile network architecture 124 and Ethernet services can be operated parallel to the IP Services in 125 the same network. 127 2. Terminology 129 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 The document uses the terminology specified in [RFC3344], In 134 addition, this document defines the following: 136 Ethernet service transport 138 Ethernet support for Mobile IPv4 that assists home agent to tunnel 139 Ethernet frame on the home link to the FA in the foreign link 140 during datagram delivery process after the binding registration 141 procedure. 143 GRE Extension 145 GRE Encapsulation support for Mobile IPv4 that is used to 146 differentiate between difference Ethernet services or flows. 148 3. Scenarios for MIP based Ethernet Services 150 In this section, four use cases are listed that are identified for 151 Ethernet service transport support. 153 3.1. Hybrid services transport 155 The figure 1 shows coexistence of IP services and Ethernet service 156 for the same mobile node in the same access network. In this 157 scenario, the ASP providing Ethernet service contains the bridging 158 function for forwarding Ethernet frames between MN and the Ethernet 159 Service provider while the MSP (Mobile service Provider) provides IP 160 service (e.g., Internet) delivered between the foreign agent or 161 mobile node and the home agent through the same access network to the 162 same mobile node. When Mobile IP is applied for dynamic tunnel 163 management between the foreign agent or the mobile node and the home 164 Agent, the GRE based tunnel enables the transport of Ethernet frames 165 in the payload. The Ethernet frames are forwarded based on the MN 166 MAC address. 168 | | | 169 | | | +----------------+ 170 | Access Network | +-+ASP providing | 171 +--+--+ //----\\ +-----+-+ | |Ethernet Service| 172 MN | FA | | | | HA | | +----------------+ 173 +--+--+ \\----// | +--------+ | 174 | +--|Ethernet| | +----------------+ 175 | |bridge +--+ |MSP providing | 176 | +--+-----+ +-+IP Service | 177 | | | +----------------+ 178 | | | 179 | | | 180 | | | 181 Figure 1 Coexistence of IP services and Ethernet 182 services for the same access network 184 3.2. Native Ethernet Service Transport 186 Figure 2 shows native Ethernet sevice transport over various access 187 networks in which it allows node movement from one Ethernet segment 188 to another within the same access network or across various access 189 networks. The Ethernet frames are distinguished by the bridging 190 function at the HA based on VSE(Vendor Specific Extension) or host 191 port and transport them over IP based tunnels between the foreign 192 agent or Mobile node and the home agent. 194 |Access Network1 195 --|--- 196 /// | \\\ | | 197 +--+ || +-|--+ | | | 198 |MN| | | FA | |\ | | 199 +--+ || +-|--+ | \ | | +----------------+ 200 \\\ | /// \ +----|---+ ---ASP Providing | 201 --|--- \ | HA | | |Ethernet Service| 202 /--|---\ / | +--------+ | +----------------+ 203 +--+ /// +-|--+ \\\ / +---|Ethernet| | 204 |MN| | | FA | | / |bridge --- 205 +--+ | +-|--+ |/ +|-------+ | 206 \\\ | /// | | 207 \--|---/ | | 208 |Access Network2 | | 209 | | | 210 Figure 2 Native Ethernet Service Transport 212 3.3. VLAN Tag Support 214 Figure 3 shows VLAN Tag Support. VLAN-IDs are used in many different 215 ways for segregating traffic of Ethernet services in the access 216 network. The L2FW function in the FA SHALL support the flexible use 217 of the VLAN-IDs by providing the following capabilities for each of 218 the service flows: 220 In downstream direction towards the MN: 222 The L2FW SHALL be able to remove VLAN tags if present. 224 In upstream direction from the MN: 226 The L2FW SHALL be able to insert VLAN tags and assign priority 227 bits in the VLAN tags. 229 Also the Ethernet bridge in the HA SHALL support VLAN tags process in 230 bidirection towards or from the FA. 232 | 233 | | 234 | ------ | 235 | /// \\\\ | 236 +---+-------+ // \ +-----+-----+ 237 +----+ | FA | | | |HA | 238 | MN | | +-+-------+-+| Access network | | +-------+--+ 239 +----+ | | || | | | | 240 +-+ L2FW | \\ // +---+ Ethernet | 241 | | \\\ /// | bridge | 242 +-+---------+ ------ +-+-----+--+ 243 | | | 244 | | +--+-------------+ 245 | | |ASP providing | 246 | | |Ethernet Service| 247 | | +----------------+ 248 Figure 3 VLAN Tags Support 250 3.4. Multi-Host Support 252 Figure 4 shows multi-host support. In the multi-host scenarios, 253 there are multiple devices connected to a bridge behind MR or RG. In 254 this sense, the MR/RG is not the end system but contains a bridge 255 forwarding to end systems behind the MR/RG, the downlink Ethernet 256 frames contain destination MAC addresses other than the MR or RG MAC 257 address, the Ethernet bridge attached to the home agent can learn the 258 MAC addresses of the hosts behind the MR and establish binding 259 between these MAC addresses and FA CoA when those hosts become active 260 and start sending uplink frames. 262 | | | 263 +-----+ | | | +----------------+ 264 |Host1|\ | | | |ASP providing | 265 +-----+ \ | | Access network | |Ethernet Service| 266 +-----+ \ +--+--+ +-+--+ //---\\ +---+-----+ +-------+--------+ 267 |Host2+-----|MR/RG| | FA | | | | HA | | 268 +-----+ / +--+--+ +-+--+ \\---// | +-----+--+ | 269 +-----+ / | | +---+Ethernet+-------| 270 |Host3| / | | |bridge | 271 +-----+ | | +--------+ 272 | | | 273 | | | 274 Figure 4 Multi-Host Support 276 4. Processing Consideration 278 4.1. GRE Encapsulation Support 280 [RFC2003]allows IP in an IP encapsulation which can be used to tunnel 281 traffic between the FA and the HA. However, this encapsulation 282 method is not enough to identify the destination of packets of a 283 specific flow within an IP-in-IP tunnel. 285 [RFC2890]describes one generic routing encapsulation method which can 286 be used to distinguish different flows in terms of GRE key. Thus, 287 GRE encapsulation is one best way to differentiate between different 288 Ethernet services or flows, i.e., during binding registration 289 procedure, the message exchange between the FA and the HA will be 290 used to negotiate downlink and uplink GRE keys which is used for 291 marking downlink and uplink traffic for a specific flow. 293 4.2. Ethernet Service Transport Support 295 In order to support Ethernet service delivery in mobile IPv4 296 scenario, the communication between the MN and the home agent needs 297 to be modified to support Ethernet frame transport. Ethernet frame 298 can be transported over IP tunnel between the foreign agent and the 299 home agent. During registration procedure, the MN or FA on behalf of 300 MN sends Registration Request message to the home agent with MN's MAC 301 address included in the Ethernet transport mobility option and MN's 302 port included in the VSE option, meanwhile the FA will bind MN's MAC 303 address, GRE key to the FA CoA in its own registration tables. Upon 304 receiving Registration Request, the home agent will establish binding 305 among MN's MAC address, port, GRE key and the FA CoA in its own 306 registration tables. It can also learn the MAC addresses of the 307 hosts behind the MN and establish binding between these MAC addresses 308 and FA CoA in its own registration tables when those hosts become 309 active and send some uplink frames. After successful registration, 310 the home agent will start capturing the Ethernet frames on the home 311 link destined to the registered MN's MAC address based on the host 312 port or VSE containing MN port and forward those frames to the FA via 313 GRE tunnel. 315 5. Mobile Node Consideration 317 If the mobile node is capable of supporting Ethernet service, it 318 should be authenticated for network access and authorized for the 319 specific Ethernet service. After that, a set of pre-provisioned 320 service flows for Ethernet service and IP service can be created, 321 admitted and activated between the MN and the foreign agent. 323 6. Foreign Agent Consideration 325 6.1. Extension to registration tables for the Foreign Agent 327 Every foreign agent maintains a registration table for each currently 328 attached mobile node, as explained in section 3.8.1 of the mobile 329 IPv4 specification [RFC3344]. To support this specification, the 330 conceptual registration table data structure must be extended with 331 the following additional fields: 333 The MN's MAC address 335 The MN's MAC address used to bind with FA CoA during binding 336 registration procedure and tunnel Ethernet frame to MN's MAC 337 address. such as Loss of HA-HELLO, Monitored Server Failure by the 338 Active HA, Routing Peer/ Link Failure. Each LMA should exchange 339 HA-HELLO (can be renamed as LMA-HELLO) for failure detection. 341 The host MAC addresses behind MN 343 The host MAC addresses behind MN used to bind with FA CoA when 344 learning those from uplink frames received from hosts behind MN. 346 The MN's GRE key 348 The MN's GRE key assigned by the FA and the HA and used to 349 distinguish the destination of packets of a specific flow which 350 include uplink GRE key and downlink GRE key. 352 6.2. Foreign Agent Operation 354 In the foreign agent care-of address mode[RFC3344], during binding 355 registration procedure, the FA starts the establishment of a dynamic 356 tunnel by sending or forwarding the Registration Request message to 357 the indicated HA. The Registration Request will contain the MN's 358 NAI[RFC2794], IPv4 home address field will be set to all zeros and 359 the MN's MAC address will be included in the new MIPv4 extension 360 called Ethernet extension. When the FA forwards the Registration 361 Request to the home agent with MN's MAC address carried in the 362 Ethernet extension mobility option, it will bind MN's MAC address, 363 GRE key to the FA CoA in its own registration tables. Also it 364 requests GRE encapsulation to differentiate between difference 365 Ethernet services or flows. In addition to setting Wu Expires 366 September 3, 2009 [Page 7] Internet-Draft MIP Extension for Ethernet 367 Service Support March 2009 the G flag in Registration Request 368 message, the FA will allocate the GRE key and will include it in the 369 GRE extension. 371 Upon receiving a frame tunneled by home agent on the home link after 372 binding registration, the FA will identify the MN to which the frame 373 must be delivered. The FA will not use the data from the inner 374 packet header (i.e. MAC addresses) to identify the corresponding MN. 375 The received GRE key will be used to identify the MN to which the 376 encapsulated payload must be delivered. This is advantageous in case 377 that there are multiple Ethernet devices connected to a bridge behind 378 the MN. 380 7. Home Agent Consideration 382 7.1. Extension to registration tables for the Home Agent 384 Every home agent maintains a registration table for each currently 385 attached mobile node, as explained in section 3.8.1 of the mobile 386 IPv4 specification [RFC3344]. To support this specification, the 387 conceptual registration table data structure must be extended with 388 the following additional fields: 390 The MN's MAC address 392 The MN's MAC address used to bind with FA CoA during binding 393 registration procedure and tunnel Ethernet frame to MN MAC 394 address. 396 The host MAC addresses behind MN 398 The host MAC addresses behind MN used to bind with FA CoA when 399 learning those from uplink frames received from hosts behind MN. 401 The MN's GRE key 403 The MN's GRE key assigned by the FA and the HA and used to 404 distinguish the destination of packets of a specific flow which 405 include uplink GRE key and downlink GRE key. 407 7.2. Home Agent Operation 409 When the home agent receives the Registration Request message from 410 the the foreign agent, it will bind the MN's MAC address contained in 411 the Ethernet extension to the FA CoA(i.e., IP address of FA). It 412 will also save the received GRE key as part of its mobility binding 413 context. Home agent will also allocate its own GRE key and send it 414 to FA in MIP Registration Reply. 416 After successful registration, the home agent will start capturing 417 the Ethernet frames on the home link destined to the registered MN's 418 MAC address and forwarding those frames to the FA via GRE tunnel. 419 The home agent must include the FA's GRE key in the GRE packet 420 header. In some cases, the bridge attached to the home agent can 421 learn the MAC addresses of the hosts behind the MN and establish 422 binding between these MAC addresses and FA CoA when those hosts 423 become active and send some uplink frames. Having learnt the 424 address(es) behind the MN, the bridge behind the home agent would 425 start tunneling the frames on the home link destined to those MAC 426 addresses over the established GRE tunnel, tagging the tunneled 427 packets with the GRE key associated with the MN. Upon receiving 428 frame in the uplink direction from the foreign agent, the home agent 429 will use the received GRE key (instead of the source address from the 430 inner header) to find the corresponding mobility context. 432 8. Message Format 434 8.1. Ethernet Extension Mobility Option 436 A new mobility option, the Ethernet Extension mobility option, is 437 defined for use in the Registration Request and Registration Reply 438 messages exchanged between the foreign agent and the home agent. 439 This option can be used for the home agent and the foreign agent to 440 identify the MN to which the frame must be delivered. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Type = TBD | Length | Reserved | 446 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | MN MAC Address 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 3 Ethernet Extension Mobility Option 452 8.2. Vendor specific Extension Option 454 A VSE option is defined in the Registration Request and Registration 455 Reply message. This option can be used to distinguish between IP 456 service and Ethernet service or between different Ethernet services. 457 The VSE can contain MN port and/or additional service parameters, 458 which is outside the scope of this document. 460 8.3. GRE Extension option 462 The details are defined in section 5 of 463 [draft-yegani-gre-key-extension]. 465 9. Security Considerations 467 The Ethernet Extension Mobility Option and the functionalities in 468 this document are protected by the Authentication Extensions 469 described in[RFC3344]]. The FA needs to have a security association 470 with the HA to register the MN's IP address. The security 471 association can be provisioned by the administrator, or dynamically 472 derived. 474 10. IANA considerations 476 TBA 478 11. References 480 11.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", March 1997. 485 [RFC3344] Perkin, C., "IP Mobility Support for IPv4", August 2002. 487 [RFC2003] Perkin, C. and J. Perkin, "IP Encapsulation within IP", 488 October 1996. 490 [RFC2794] Calhoun, P. and C. Perkin, "Mobile IP Network Access 491 Identifier Extension for IPv4", March 2000. 493 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 494 September 2000. 496 [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, 497 "Encapsulation Methods for Transport of Ethernet over MPLS 498 Networks", RFC 4448, April 2006. 500 [RFC4719] Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport 501 of Ethernet Frames over Layer 2 Tunneling Protocol Version 502 3 (L2TPv3)", RFC 4719, November 2006. 504 11.2. Informative References 506 [draft-yegani-gre-key-extension] 507 Yegani, P. and G. Dommety, "GRE Key Extension for Mobile 508 IPv4", draft-yegani-gre-key-extension-03 (work in 509 progress), June 2007. 511 Authors' Addresses 513 Qin Wu (editor) 514 Huawei Technologies Co.,Ltd 515 Site B,Floor 12F,Huihong Mansion, No.91 Baixia Rd. 516 Nanjing, Jiangsu 21001 517 China 519 Phone: +86-25-84565892 520 Email: Sunseawq@huawei.com 522 Shah Rahman 523 Ericsson 524 100 Headquarters Drive 525 San Jose, CA 95134 526 USA 528 Email: shah.rahman@ericsson.com 530 Hui Deng 531 China Mobile 532 53A, Xibianmennei Ave. Xuanwu District, 533 Beijing 100053 534 China 536 Email: denghui02@gmail.com