idnits 2.17.1 draft-gundavelli-netext-extensions-motivation-00.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 : ---------------------------------------------------------------------------- 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 05, 2009) is 5462 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC-3344' is mentioned on line 158, but not defined ** Obsolete undefined reference: RFC 3344 (Obsoleted by RFC 5944) == Missing Reference: 'RFC-4301' is mentioned on line 494, but not defined == Missing Reference: 'GTP' is mentioned on line 393, but not defined == Unused Reference: 'RFC3344' is defined on line 723, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- No information found for draft-ietf-monami6-multicoa - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG S. Gundavelli 3 Internet-Draft Cisco 4 Intended status: Informational May 05, 2009 5 Expires: November 6, 2009 7 Extensions to Proxy Mobile IPv6 - Motivation 8 draft-gundavelli-netext-extensions-motivation-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 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 November 6, 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 in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Proxy Mobile IPv6 is a network-based mobility management protocol 47 standardized in IETF and is being specified in various system 48 architectures as a protocol for building a common and access 49 independent mobile core. Currently, there are number of proposals 50 and a huge amount of interest in NETEXT working group for extending 51 the protocol to support various mobility extensions. This document 52 identifies some of the critical extensions that are absolutely 53 required and builds a case as why these extensions have to be 54 supported. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. The Client-based and Network-based Mobility Management 63 Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Mobile IPv6 Client Stack Support . . . . . . . . . . . . . . . 7 67 5. Proxy Mobile IPv6 Extensions & Motivation . . . . . . . . . . 9 68 5.1. Mobile Device and Networks Characteristics . . . . . . . . 9 69 5.2. Mobility Requirements . . . . . . . . . . . . . . . . . . 9 70 5.3. Protocol Assumptions on the Host Capabilities . . . . . . 10 72 6. Response to draft-tsirtsis-netext-controversy . . . . . . . . 12 73 6.1. PMIP with Host Signaling & Historic Reasons - 74 Clarification . . . . . . . . . . . . . . . . . . . . . . 13 75 6.2. MAG ... the new FA ? . . . . . . . . . . . . . . . . . . . 14 76 6.3. The Internet, the Interface, and the Host . . . . . . . . 15 77 6.4. What is wrong with PMIP so far ? Nothing ! . . . . . . . . 15 78 6.5. Its not a Tool Proliferation ! . . . . . . . . . . . . . . 16 80 7. Conclusions & Recommendations . . . . . . . . . . . . . . . . 18 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 88 11. Informative References . . . . . . . . . . . . . . . . . . . . 23 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Introduction 94 The NETEXT working group was created recently in IETF to work on 95 specifying extensions to the Proxy Mobile IPv6 protocol [RFC-5213]. 96 There is large amount of interest from the IETF community for 97 extending the protocol to support some real, practical and immediate 98 use-cases. These extensions are primarily for enabling the mobile 99 node to perform flow management and have the ability for it to 100 express attachment, handoff and flow preferences to the network. 101 However, there is also some resistance from a small group of people 102 who believe that the client-based mobility solution should be the 103 only option for solving these use-cases. This document analyses 104 these extensions in question and makes a case as why extensions are 105 critical and why these work items have to be adopted. The structure 106 of this document is as specified below. 108 The introductory sections of this document provide a brief history on 109 the evolution of two different mobility management approaches, the 110 client-based and the network-based mobility management. It provides 111 some background and the current trends in the industry with respect 112 to the solution preference. 114 Next, the draft reviews the deployment configurations and maps the 115 mobility requirements. It identifies the basic and the minimal 116 constructs required for the host to operate in a Proxy Mobile IPv6 117 network, and the resulting benefits of choosing that network-based 118 mobility management approach. It also reminds that the protocol 119 benefits from having the host to have the basic capability of 120 providing attachment, handoff and flow preferences to the network and 121 points to the MN-AR Interface document 122 [draft-ietf-netlmm-mn-ar-if-03]. 124 The draft in Section 6.0, responds to the comments made in 125 [draft-tsirtsis-netext-controversy], which opposes many of the 126 proposed new extensions to Proxy Mobile IPv6, and tags them as 127 "controversial". This draft in a good faith attempts to understand 128 the concerns raised in that document and provides a response to those 129 comments. This draft also identifies the fundamental flaws in the 130 arguments presented in that document and reminds that similar 131 arguments have been made prior to the standardization of a network- 132 based mobility approach, however, the IETF community did not agree to 133 those comments and decided to design a protocol based on this 134 approach. This draft provides the reasoning as why these extensions 135 backed by the large internet community are non-controversial, how 136 they align perfectly well with the Internet or the host design 137 principles and why these extensions are needed for the advancement of 138 the Proxy Mobile IPv6 technology. 140 Finally, in the concluding section, this draft makes certain 141 recommendations to NETEXT working group. It asks for reviving the 142 MN-AR interface [draft-ietf-netlmm-mn-ar-if-03] document as initially 143 planned, and for adopting flow mobility and inter-technology handoff 144 extensions into the charter on a faster track. It emphasizes that 145 the MN-AR interface was always factored in to design of Proxy Mobile 146 IPv6 [RFC-5213] and is required not only for supporting any new 147 extensions, but also for having a non-SDO specific interface between 148 the mobile node and the mobile access gateway. 150 2. Conventions 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC-2119]. 156 3. The Client-based and Network-based Mobility Management Approaches 158 Mobile IP protocol [RFC-3344] was designed in the mid 90s' and the 159 early protocol in the absence of any data on how the protocol will be 160 used, restricted itself to a single design approach, client-based 161 mobility management. As part of any protocol evolution, the work was 162 later specified for IPv6 and thus Mobile IPv6 protocol [RFC-3775] 163 with the same approach of host-based mobility was standardized. 165 However, the Mobile IP as a technology was not a phenomenal success, 166 compared to MPLS or other technologies that were designed around that 167 period. The protocol was not adopted by large cellular standard 168 bodies, such as in 3GPP and was also not leveraged in enterprise 169 wireless architectures for solving the micro-mobility problems. The 170 protocol largely existed in CDMA/Flarion world, and remained as a 171 topic of fundamental interest to many graduate students in 172 Universities, almost for a decade. The reason for this limited 173 adoption is mostly to do with the design approach of, "client-based" 174 mobility, requiring the client to perform all aspects of mobility 175 management and requiring massive amount of software logic and system 176 resources on the tiny mobile devices. 178 The IETF community pushed for a slightly modified model, a network- 179 based mobility management approach, with minimal client 180 participation. Some of the SDO bodies already support such models 181 and also have made formal requests to IETF, for standardizing such 182 approaches. As a result of this, the Proxy Mobile IPv6 [RFC-5213], a 183 network-based mobility management protocol was standardized in 2008. 184 The protocol largely leveraged all the signaling and messaging 185 semantics from the Mobile IPv6 protocol, but chose the approach of 186 network-based mobility management. The protocol was designed with 187 the goal that the network will perform the mobility management on 188 behalf of the client, it will keep the client involvement to minimal 189 proportions, such as allowing it to perform inter-technology handoffs 190 or allowing it to express handoff or flow preferences. This design 191 choice resulted in a simple client with minimal software 192 requirements, such as a connection manager which can perform these 193 minimal required functions. The protocol was quickly adopted in 3GPP 194 and in WiMAX architectures on various interfaces and now many 195 extensions are being planned. 197 4. Mobile IPv6 Client Stack Support 199 For attempting to understand why there is a large internet community 200 and vendor backing behind network-based mobility approaches, such as 201 Proxy Mobile IPv6 [RFC-5213] or Generic Tunneling Protocol (GTP), it 202 is important to review the current deployment and tool availability 203 status of one of the key components in the client-based mobility 204 management protocol, the Mobile IPv6 client [RFC-3775]. Following 205 are the author's own observations: 207 o The Mobile IP client, Mobile IPv4 or Mobile IPv6, is not shipped 208 to-date as part of any of the major Operating Systems. To name a 209 few, its not part of any of the Microsoft Windows released 210 versions, its not shipped with MAC OS/X, its not shipped with any 211 of the standard Linux distributions (Fedora, Redhat, ubuntu ..) 212 and is not shipped as part of any of the BSD distributions. 214 o Looking beyond the default Operating System shipments, there are 215 close to zero, or may be one or two commercial stack vendors. 216 Further, expecting these vendors to release Mobile IPv6 [RFC- 217 3775], Dual-Stack Mobile IPv6 [ID-DSMIP6], MCoA [ID-MCOA6], IKEv2 218 [RFC-4306], IPsec [RFC-4301] on all variants of Windows, Android, 219 iPhone, Linux and BSD systems requires lot of efforts, patience, 220 faith and hope. However, to give a fair perspective, it may be 221 supported in some of the wireless chipsets, by at least one chip 222 vendor, but that represents a low and insignificant adoption rate. 223 Furthermore, having such mobility function in a common radio 224 layer, restricts the host from using any of its interfaces that 225 are outside the common radio layer for its mobility support and 226 does not qualify as a true mobility client. 228 o So, it is reasonable to assume that there are significant 229 challenges in pushing a client-based mobility management approach 230 which requires massive amount of development efforts and $$ 231 investment. Given the fact that there is no vendor commitment, no 232 tools in the market and considering the number of years since some 233 of these specs have been standardized, it is unreasonable to 234 continue to force the client-based mobility management approach as 235 the only solution and without giving any alternative choices. 236 Given the multitude of operating systems and variants, it is not a 237 trivial task to have a Mobile IPv6 client that includes IKEv2, 238 IPSec, Dual-Stack Mobile IPv6 and MCOA, and have it tested across 239 all these platforms and be available in the time frame when the 240 industry needs this work. This may happen eventually, but for the 241 current time frame, the market is looking for other solutions and 242 network-based mobility is the preferred approach which requires 243 minimal host support with a small application module that any 244 vendor can develop in no time. This fact needs to be realized and 245 appreciated. 247 5. Proxy Mobile IPv6 Extensions & Motivation 249 This section provides the motivation behind the proposed new 250 extensions. It maps these requirements from the potential deployment 251 configurations and the use-cases. 253 5.1. Mobile Device and Networks Characteristics 255 Most of the mobile devices that are available today in the market are 256 equipped with multiple radio interfaces, such as LTE, WiMAX, eHRPD, 257 WiFi etc, and in any combination. So, it is reasonable to assume 258 that a mobile nodes can potentially attach to the network using one 259 or more interfaces and be using all of those interfaces 260 simultaneously for its data sessions. 262 It is given that the networks in which these mobile nodes are attach 263 will be a true heterogeneous networks with multiple access 264 technologies. A mobile operator can potentially be managing more 265 than one access technology in their core network. Or, they may have 266 partnerships with other operators that support a different access 267 technology. Even for other reasons such as during migration, an 268 operator may support nation wide 3G network with one access 269 technology and be supporting a different access technology while 270 bringing up the 4G network in some pockets; this would be the natural 271 migration for CDMA operators from eHRPD to LTE. Or, for the most 272 obvious reason of a dual-mode LTE/WiFI, or WiMAX/WiFI handset 273 operating in multiple access networks. 275 5.2. Mobility Requirements 277 The above described mobile device capabilities coupled with the 278 availability of a heterogeneous network with multiple access 279 technologies, requires some special support for providing any 280 reasonable end-user experience. These requirements are very obvious 281 and is a basic expectation from any mobility protocol. Following are 282 the some of the key mobility related considerations: 284 1. Roaming in a homogeneous network - A mobile node should have the 285 ability to seamlessly roam and change its point of attachment 286 within a single access domain. 288 2. Roaming between heterogeneous networks - A mobile node should 289 have the ability to seamlessly roam between two different access 290 networks. For example, a mobile node initially attached to an 291 LTE network, later when in the vicinity of a WiFi network, should 292 have the ability to perform an inter-technology handoff and move 293 its IP address configuration and all its network sessions to the 294 WiFi interface. Or, to support handoffs such as between eHRPD/ 295 LTE, LTE/WiFI, WiMAX/WiFI or WiMAX/LTE. 297 3. Multihoming Support - A mobile node should have the ability to 298 attach to network using multiple interfaces and be able to use 299 any one or more of its interfaces for network connectivity. 301 4. Flow Mobility Support - A mobile node should have the ability to 302 move the flows between interfaces on a selective basis. For 303 example, a mobile node initially attached to an LTE network, 304 later when in the vicinity of a WiFi network, should have the 305 ability to move certain high bandwidth intensive flows to the 306 WiFI network. The 3GPP is exploring such uses cases and are 307 documented in [3GPP-TR-23.861]. 309 The base Proxy Mobile IPv6 base specification has support for some of 310 the above requirements and the new proposals are intended for 311 supporting the remaining requirements and in a more complete and 312 explicit way. 314 5.3. Protocol Assumptions on the Host Capabilities 316 For supporting the above requirements, the protocol places certain 317 assumptions on the multihomed host. Typically, all multihomed hosts 318 in the considered operating environment are required to have an 319 application module, such as a connection manager. The requirement 320 for this module is not a Proxy Mobile IPv6 requirement, but rather 321 the requirement of a multihomed host. This module essentially will 322 have the user specified policies with respect to network attachment 323 or flow mobility preferences, and may need these minor extensions. 325 o The ability for the host to notify if the current attachment over 326 a given interface is as a result of inter-technology handoff, or 327 for the bringup of a new interface. In most cases, the network 328 can derive this information and project the right prefixes, but 329 this can be certainly be an explicit notification from the client. 331 o The host identifying the flows that it chooses to move between 332 interfaces and notifying to the network. This semantic may not be 333 needed if the flow policies are synchronized between the host and 334 the network. 336 o The use of virtual interface configuration for supporting inter- 337 technology handoffs. In most systems, this is matter of running a 338 tool to keep the physical interfaces in a bridged mode and using a 339 single virtual interface for its address configuration. 341 So, it is reasonable to state that we need a connection manager on 342 the host that can potentially manage the user preferences with 343 respect to network attachment, flow management and for it to manage 344 the interface configuration and express these preferences to the 345 network, such as in [draft-ietf-netlmm-mn-ar-if-03], using a SDO 346 specific interface. 348 6. Response to draft-tsirtsis-netext-controversy 350 The [draft-tsirtsis-netext-controversy] argues that IETF should not 351 allow the proposed new extensions to Proxy Mobile IPv6. It is 352 unfortunate that the draft was not written in a constructive and an 353 impartial manner. Its clear, the basic purpose of the draft is to 354 favor client-based solution. That is fine. One can certainly 355 disregard these comments as one's opinion, affiliation or attachment 356 to a specific technology as the reason for strong and a one sided 357 view. But, to an innocent reader who may not know all the technical 358 details may be misled reading such views. So, its important to 359 respond to these comments. 361 The draft mostly argues on legal grounds and makes number of 362 assumptions which are incorrect and continues to build the case based 363 on those assumptions and finally arrives at its own conclusions. To 364 state a few: 366 o The draft assumes that the mobile node in a Proxy Mobile IPv6 367 domain has no ability, or it should not be able to express 368 attachment, handoff or flow preferences to the network. The 369 document builds the entire case based on this argument. It 370 completely ignores the operating environment and does not even 371 mention about the MN-AR Interface document 372 [draft-ietf-netlmm-mn-ar-if-03], or the SDO specific interfaces, 373 which was always considered in the protocol design. 375 o The draft fails to differentiate between a mobile node expressing 376 minimal hints to the network, such as attachment, connection or 377 flow preferences, to a full blown mobile node with all the complex 378 software requiring massive system resources and performing all 379 aspects of mobility management. It equates both as one and the 380 same with the conclusion that any software on the host is the same 381 as client-based mobility. But, it does not see the difference, 382 boiling a glass of water to boiling an ocean. 384 o The draft reviews some of the multihoming and flow mobility 385 scenario's and makes a case that it is not possible to perform 386 flow mobility or support complex handoff scenario's without the 387 mobile node being aware and which is correct. Ack ! But, again 388 it ignores the MN-AR Interface or SDO specific layer which can be 389 used for such purpose. 391 o The draft ignores the market direction and the industry 392 preferences for network-based mobility management, either in the 393 form of Proxy Mobile IPv6 or Generic Tunneling Protocol [GTP], and 394 the resulting benefits in that approach. 396 o The draft disregards the amount of scrutiny, reviews and the 397 external validations that went into the base protocol design for 398 ensuring the protocol followed the IETF design principles. 400 The following sections respond to more specific comments, on section 401 by section basis. 403 6.1. PMIP with Host Signaling & Historic Reasons - Clarification 405 There is a comment, a mobile node in a Proxy Mobile IPv6 domain is 406 not allowed to have any intelligence. And there will point you to 407 some incomplete and ambiguous line in the charter that was never ever 408 discussed widely during the formation of NETLMM working group and 409 which went practically unnoticed. Even if it did, it does not mean 410 much and is not relevant. In any case, following is the response to 411 that comment. 413 Proxy Mobile IPv6 was certainly created with the goal that the mobile 414 node will not perform any mobility signaling with its local mobility 415 anchor. So far it is correct. However, no where in the base 416 protocol specification, it ever stated and assumed that: 418 o that the mobile node that attached to a Proxy Mobile IPv6 domain 419 will be a dumb and a stupid terminal which can do only a single 420 attachment, cannot dynamically manage its interfaces or cannot 421 configure an address dynamically on a real or on a virtual 422 interface. 424 o that it will be disallowed from providing handoff, attachment or 425 flow preferences to the network, through a SDO specific interface 426 layer. 428 o that an operator cannot install any intelligent application 429 software, such as connection manager which using the configured 430 policies or user inputs, makes the network attachment decisions. 432 o that it will be disallowed from being aware of the operating 433 environment. 435 These restrictions do not make any sense and are not needed. 436 Providing attachment and handoff preferences was always factored in 437 to the design. The MN-AR Interface document 438 [draft-ietf-netlmm-mn-ar-if-03] which was a working document prior to 439 the adoption of the initial Proxy Mobile IPv6 document, was specified 440 for that purpose. The protocol also allowed this interface to be 441 defined in a SDO specific manner, specifying the protocol between the 442 network nodes only by reacting to the provided events. This is not a 443 design flaw, but allowing the room for all the extensions to come in 444 place in a evolutionary manner. 446 An application software such as connection manager is a basic host 447 requirement for any multihomed terminal and is not a Proxy Mobile 448 IPv6 requirement. This component cannot be avoided on any multihomed 449 host. The behavior of any host will be unpredictable and unreliable 450 with respect to the choices it makes for all its network connections. 451 Proxy Mobile IPv6 only requires few additional hooks on such software 452 module, that too for supporting some features. 454 6.2. MAG ... the new FA ? 456 Section 5.2.2 of [draft-tsirtsis-controversy-00] tries hard to imply 457 that functional element, mobile access gateway is the same as foreign 458 agent in Mobile IPv4, with the objective to prove that any software 459 requirement on the client maps to Mobile IPv4 model. Sure, the 460 models map in the mobility element count, but there are role 461 differences in each of those models and the argument completely 462 discounts this aspect. 464 In a network-based mobility model, there is an element on the network 465 that is designated to perform the mobility management functions. We 466 can call this a foreign agent, mobile access gateway or a mobility 467 proxy, but the functional role has a specific purpose and the model 468 is not Mobile IPv4. The functional role of the mobile node is not 469 beyond than managing its interfaces, address configuration and 470 expressing handoff and flow preferences to the network. It plays a 471 mere passive role and allowing the mobile access gateway to play the 472 active role on the aspects of mobility management. So, there is a 473 fundamental difference between this when compared to the Mobile IPv4. 474 In any case, the comparison that is needed is in relation to client- 475 based mobility. Following are the fundamental differences between 476 all the three models: 478 o In Mobile IPv4 (FA-CoA Mode), the mode of active client and 479 passive network node, the mobile node plays an active role, 480 performs all aspects of mobility management, while the foreign 481 agent plays mere passive role 483 o In Proxy Mobile IPv6, the mode of passive client and active 484 network node, the mobile node plays a mere passive role in the 485 mobility management. It does not perform any mobility signaling 486 with the local mobility anchor. It is only expected to provide 487 attachment, handoff and flow preferences to the network, while the 488 mobile access gateway is responsible for performing all aspects of 489 mobility management. 491 o In Mobile IPv6, the mode of active client, the mobile node plays 492 the active role and performs all aspects of mobility management. 493 It requires Mobile IPv6 client [RFC-3775], DSMIP6 [ID-DSMIP6], 494 MCOA [ID-MCOA6], IKEv2 [RFC-4306] and IPsec [RFC-4301] stacks. 495 Its requires significant amount of software and system resources 496 on the client. 498 6.3. The Internet, the Interface, and the Host 500 And we got a ticket ! We are breaking the Internet building blocks. 501 Section 3.0 of [draft-tsirtsis-controversy-00] is not clear on what 502 the concern is. Following are the clarifications. 504 o The IP mobility is above network layer, it is a service layer and 505 as specified in Section 6.6 of [RFC-5213], a mobile node on 506 attaching to the Proxy Mobile IPv6 network is required to present 507 its identify. So, the mobile access gateway has a clear relation 508 between a mobile node's identify, its link-layer identifier and on 509 the offered mobility service along with the assigned prefix. But, 510 this relation is preserved in an application layer and at the IP 511 layer its just the standard protocol operation confirming to all 512 the standard IETF protocols. 514 o When looked at from the perspective of IP layer, the MN-AR link is 515 any other IP link. Its a point-to-point link and with the mobile 516 access gateway functioning as the IPv6 router on the link. The 517 prefix set that it projects on the link is always tied to that 518 mobile node's interface, but that relation is preserved in 519 application layer and the network layer has no understanding of 520 any of this relation. Its a normal IPv6 link with the presence of 521 two nodes on the link and a set of hosted IPv6 prefixes. 523 o The comment on NDP operation for multihomed hosts is not 524 applicable. The MN-AR link is a point-to-point link, with only 525 one interface of the mobile node, either real or a virtual 526 interface, is present. So, the protocol does not modify the low 527 level building blocks of the Internet and so the allegation is not 528 correct. 530 6.4. What is wrong with PMIP so far ? Nothing ! 532 Clarifications to Section 4.0 of [draft-tsirtsis-controversy-00] in 533 the same order. 535 1. The absence of MN-AR interface, as an IETF specified interface 536 does not imply the protocol is broken. For example, the IP layer 537 is built with the assumption that the layer-2 driver for a given 538 access technology will provide the required hooks for the IP 539 layer. Its the same thing here. A given SDO can define such 540 interface. 542 2. It is indeed correct that there is no concept of a MAC address in 543 certain link-layer technologies, but that's only in CDMA and in 544 LTE. The absence of such semantic in these two technologies is 545 not a problem for the current operating environment. 547 - the protocol uses the Access Technology Type for the 548 uniqueness and for a dual-mode terminal that are going to be 549 in the market, it is highly unlikely there are multiple 550 radio's of the same type. 552 - even otherwise, a simple semantic allowing the mobile node 553 to present an identifier as part of the attachment preferences 554 will be just fine. 556 3. The use of virtual interfaces is a host specific semantic. It is 557 perfectly valid for a host to use the physical interfaces in a 558 bridged mode and present a virtual link-layer identifier. This 559 is perfectly valid and many protocols such as HRRP or VRRP use 560 such mode. This has no implication on the IPv6 link or on the 561 link neighbors. 563 4. It is true that the mobile node can potentially specify if the 564 given attachment is due to an handoff or as result of a new 565 interface bringup. But, the absence of such event is fine in 566 most cases. The network through context transfer procedures or 567 through other means, can derive that information. We can 568 certainly add this in the IETF specified MN-AR interface layer. 570 6.5. Its not a Tool Proliferation ! 572 A comment was made in Section 5.2.3 of 573 [draft-tsirtsis-controversy-00], that allowing host participation in 574 any level, is equivalent to client performing all aspects of mobility 575 management and results in redundant tool proliferation. 577 Its not always a binary logic. No host involvement in mobility 578 management does not imply the host has zero awareness of the 579 operating environment, or that it is disallowed from running any 580 intelligent software such as connection manager, or that is a 581 violation for it express its connection or flow preferences to the 582 network. That was never a basis for the design of the Proxy Mobile 583 IPv6 protocol. Allowing the host to have such capabilities only 584 improves the protocol and cannot be considered as a tool 585 proliferation. 587 Even otherwise, new ideas, fresh discoveries on how to deploy a 588 technology in a real-world network and when coupled by urgent 589 customer needs, always can re-shape a technology. A technology 590 solution that start with Protocol-A need not be restricted to that 591 protocol, but instead can go with Protocol-B, if that happens to be a 592 better protocol and if market wants that solution. There are many 593 instances in IETF, where it allowed multiple technologies to co-exist 594 and let the market adopt what is right, to name a few: 596 o (Mobile IPv4 + DSMIP4) vs. (Mobile IPv6 + DSMIP6). (Note: the 597 author and some of the reviewers of 598 [draft-tsirtsis-controversy-00] have authored both these competing 599 DSMIP standards.) 601 o CMOT Abandoned and SNMP Moves On .. 603 o SCTP in the presence of the giant TCP, 605 o OSPF vs. Dual IS-IS 607 o RTP vs. DCCP 609 o MOBIKE Overlap with Mobile IP, for the mobile VPN solution 611 o ... the list goes on ... 613 It is in this context that I'd like to point to [RFC-5218] ("What 614 Makes for a Successful Protocol?"), No where in that, it said, the 615 success of a protocol depends on eliminating or restricting better or 616 alternative approaches for solving a given problem. But, rather win 617 by market acceptance and make the competing standard and a mere 618 document. 620 This is by no means to imply that a solution based on network-based 621 mobility is better than client-based mobility solution, or other way 622 around. The author of this document has interest in both the 623 technologies. We are not competing. The point is about the need to 624 allow both the protocols to shape-up and find its place, its not up 625 to IETF to decide the market for these protocols. 627 7. Conclusions & Recommendations 629 This draft makes the following recommendations to the NETEXT working 630 group and asks the IESG to give a careful consideration to the 631 following points. 633 o The client-based and network-based mobility management protocols 634 are two different approaches adopted equally widely by the 635 industry. These protocols are not mutually exclusive. Success of 636 one protocol does not diminish the value of the other protocol. 637 Both the protocols can co-exist and have their respective places. 638 Its not the business of the IETF to endorse one to the other, as 639 there are business implications. IETF as a neutral body should 640 not favor one, specially, when both the solutions are adopted by 641 different SDO bodies and when it is impossible to compare and 642 qualify one as a better protocol to the other. Let both the 643 protocols evolve, be feature-rich, as per the interests of the 644 large internet community and mobility experts, let deployments 645 pick the one that best suits their operating environment. 647 o Multihoming and Inter-technology handoffs are the integral part of 648 the Proxy Mobile IPv6 protocol and is the basis for its existence. 649 The protocol was designed primarily for solving inter-technology 650 handoffs and for a multihomed terminal, such as handoff between 651 various access technologies, WiMAX, eHRPD, LTE and WiFI. The 652 working group should ensure any new extensions are intended only 653 to improve on these aspects, fix any missing gaps, but not create 654 some artificial restrictions. 656 o Improve the host awareness with respect to its presence in the 657 Proxy Mobile IPv6 environment. 659 o Revive the MN-AR Interface document [draft-ietf-netlmm-mn-ar-if]. 660 The document was a working group document, however, due to lack of 661 reviewers at the time when the working group was busy with the 662 base protocol design, the NETLMM Chairs decided to take that work 663 out of the charter. There was minimal or not much thought that 664 went into this decision. It was a quick decision that largely 665 went unnoticed. Extend the MN-AR Interface document with the 666 required handoff hints for supporting inter-technology handoffs as 667 required in the base Proxy Mobile IPv6 and for supporting any new 668 extensions such as, flow mobility support. 670 o Make it clear in the charter that it is perfectly reasonable and 671 valid to require changes on the host in the form of application 672 requirements for supporting inter-technology handoffs or any other 673 extensions that helps the protocol or its deployments. There are 674 many other protocols in IETF that constantly evolve the client 675 stacks and any special restrictions only to this protocol is not 676 needed. It is to be noted that the change here is more from the 677 perspective of its ability to manage its interfaces, connections 678 and the ability to convey the connection and flow preferences to 679 the network. However, the working group should be conscious to 680 keep these requirements as minimal as possible and not to loose 681 the strategic advantage of a network-based mobility protocol, with 682 minimal host support requirements. The assumptions and the 683 requirements on the host in the form of connection manager at the 684 minimum can be limited to: 686 1. Interface management/Address Configuration on the interface, 688 2. Exchanging the attachment, handoff and flow preferences with 689 the network 691 3. Understanding the operating environment 693 Bottom line: The industry needs this work and in a timely fashion. 694 Delaying this work only hurts the mobility technology and its 695 adoption. Right when SDO bodies are exploring the solutions for 696 supporting inter-technology handoffs, such as WiMAX/WiFI, LTE/WiFI, 697 WiMAX/LTE, LTE/eHRPD, its is important to realize that the proposed 698 work items, such as multihoming and flow mobility, and with massive 699 community backing, are critical and are the key requirements for the 700 protocol adoption and should be taken up on a fast track. 702 8. IANA Considerations 704 This specification does not require IANA actions. 706 9. Security Considerations 708 This document does not require any security considerations. 710 10. Acknowledgements 712 The author would like to acknowledge the prior discussions on this 713 topic in the netext mailing list. Thanks to Fred Baker, for citing 714 some of the many instances where IETF allowed multiple solutions for 715 the same problem. Also, thanks to Mohana Jeyatharan for providing 716 the 3GPP specific flow mobility requirements. 718 11. Informative References 720 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 724 August 2002. 726 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 727 IPv6", RFC 3775, June 2003. 729 [RFC-5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 730 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 732 [RFC-5218] Thaler, D. and B. Aboba, "What Makes for a Successful 733 Protocol?", July, 2008. 735 [RFC-4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 736 4306, December 2005. 738 [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack 739 Hosts and Routers (DSMIPv6)", 740 draft-ietf-mext-nemo-v4traversal-10.txt, April 2009. 742 [ID-MCOA6] R. Wakikawa et al, "Multiple Care-of Addresses 743 Registration", draft-ietf-monami6-multicoa-13.txt, April 2009. 745 [draft-ietf-netlmm-mn-ar-if-03] Laganier, J., Narayanan, S. and P. 746 McCann, "Interface between a Proxy MIPv6 Mobility Access Gateway and 747 a Mobile", February, 2008. 749 [draft-yokota-netlmm-pmipv6-mn-itho-support-01.txt] Yokota, H., 750 Gundavelli, S., and Leung, K., "Inter-Technology Handoff support in 751 Mobile Node for Proxy Mobile IPv6", April 2009. 753 [draft-jeyatharan-netext-pmip-partial-handoff-00.txt], M. Jeyatharan 754 et al, "Partial Handoff Support in PMIPv6", March 2009. 756 [draft-jeyatharan-netext-multihoming-ps-01], M. Jeyatharan et al 757 "Multihoming Problem Statement in NetLMM", March 2009. 759 [3GPP-TR-23.861] "Multi access PDN connectivity and Flow Mobility". 760 3GPP TR 23.861, May 2009. 762 Author's Address 764 Sri Gundavelli 765 Cisco 766 170 West Tasman Drive 767 San Jose, CA 95134 768 USA 770 Email: sgundave@cisco.com