idnits 2.17.1 draft-korhonen-mobopts-mobility-policy-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 765. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 778. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 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 (October 2007) is 6038 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) -- Obsolete informational reference (is this intentional?): RFC 4423 (ref. '4') (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. '5') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-sgundave-mip6-proxymip6-01 == Outdated reference: A later version (-10) exists of draft-leung-mip4-proxy-mode-02 -- Obsolete informational reference (is this intentional?): RFC 4140 (ref. '11') (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '13') (Obsoleted by RFC 5268) == Outdated reference: A later version (-07) exists of draft-ietf-mip4-fmipv4-03 == Outdated reference: A later version (-10) exists of draft-ietf-mip4-dsmipv4-01 -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '21') (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4006 (ref. '22') (Obsoleted by RFC 8506) -- Obsolete informational reference (is this intentional?): RFC 4005 (ref. '23') (Obsoleted by RFC 7155) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Korhonen 3 Internet-Draft TeliaSonera 4 Expires: April 3, 2008 V. Devarapalli 5 Azaire 6 G. Giaretta 7 Telecom Italia 8 R. Koodli 9 Nokia 10 October 2007 12 IP Mobility and Policy Control 13 draft-korhonen-mobopts-mobility-policy-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 3, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 The IETF has developed many IP Mobility protocols, some of which have 47 been successfully deployed. There has also been work done on 48 enabling fast and efficient handovers at L3 and extensions to access 49 control protocols to enable fast handovers. One aspect that has not 50 been considered so far is the policies that a user is subjected to 51 when accessing a subscribed network. These policies, defined by the 52 network operator, have a significant impact on the user's mobility 53 experience. This document aims to provide a discussion document on 54 policy control and IP Mobility in controlled operator networks. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. IP Mobility in IETF . . . . . . . . . . . . . . . . . . . . . 5 61 4. Policies in Operator Controlled Environments . . . . . . . . . 6 62 4.1. Policy Taxonomy . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Firewall Protected Networks . . . . . . . . . . . . . . . 7 64 4.3. Deployment Model Originating Restrictions . . . . . . . . 7 65 4.4. Controlled Access to Services . . . . . . . . . . . . . . 8 66 4.5. Service Access Through Multiple Accesses . . . . . . . . . 9 67 4.6. Location of the Policy Enforcement . . . . . . . . . . . . 9 68 4.7. Example - 3GPP PCC Architecture . . . . . . . . . . . . . 9 69 5. Issues in Integrating IP Mobility and Policies . . . . . . . . 13 70 5.1. Mandatory Reverse Tunneling through the Mobility Anchor . 13 71 5.2. Firewalling at Multiple Layers . . . . . . . . . . . . . . 13 72 5.3. Binding of Service Flows . . . . . . . . . . . . . . . . . 14 73 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Intellectual Property and Copyright Statements . . . . . . . . . . 19 83 1. Introduction 85 The IETF has developed many IP Mobility protocols, some of which have 86 been successfully deployed. There has also been work done on 87 enabling fast and efficient handovers at L3 and extensions to access 88 control protocols to enable fast handovers. One aspect that has not 89 been considered so far is the policies that a user is subjected to 90 when accessing a subscribed network. These policies, defined by the 91 network operator, have a significant impact on the user's mobility 92 experience. 94 The policies configured on a network may govern what kind of service 95 the user is allowed, which access network the user is allowed to 96 attach to, enforce a particular quality of service (QoS) and restrict 97 the user to certain mobility protocols. The main purpose of this 98 document is to describe the problems encountered when applying IP 99 Mobility protocols to networks where such policies and the resulting 100 constraints exist. This would be useful to protocol designers who 101 can make better choices when designing IP Mobility protocols and to 102 network designers who develop the policy architecture and configure 103 the policies. 105 This document also includes a case study on a well known policy 106 architecture, developed by 3GPP, that is expected to be deployed in 107 various architectures developed in different standards organizations. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [1]. 115 Application Function (AF) 117 A service such as a SIP application server. 119 Home PCEF (H-PCEF) 121 A PCEF located in the Home PLMN. 123 General Packet Radio Service (GPRS) 125 GPRS is a mobile data service available to users of GSM and IS-136 126 mobile phones. 2G cellular systems combined with GPRS are often 127 described as "2.5G", that is, a technology between the second (2G) 128 and third (3G) generations of mobile telephony 130 IP Connectivity Access Network (IP-CAN) 132 The collection of network entities and interfaces that provide the 133 underlying IP transport connectivity for the mobile node. 135 Policy and Charging Enforcement Function (PCEF) 137 A policy enforcement point like entity in the 3GPP Policy and 138 Charging Control framework that encompasses service IP flow 139 detection, policy enforcement and IP flow based charging 140 functionalities. 142 Policy and Charging Rules Function (PCRF) 144 A policy decision point like entity in the 3GPP Policy and 145 Charging Control framework that encompasses policy control 146 decision and IP flow based charging control functionalities. 148 Subscription Profile Repository (SPR): 150 A logical entity that contains all subscriber & subscription 151 related information needed for subscription-based policies and 152 access level policy and charging rules by the PCRF. 154 Visited PCEF (V-PCEF) 156 A PCEF located in the Visited PLMN. 158 Policy Decision Function (PDF) 160 A point where policy decisions are made. 162 Policy Enforcement Point (PEP) 164 A point where the policy decisions are actually enforced. 166 Public Land Mobile Network (PLMN) 168 A telecommunications network providing mobile cellular services. 170 3. IP Mobility in IETF 172 This section reviews a few IP Mobility solutions being developed in 173 IETF. 175 IP Mobility support may be divided into several technical layers and 176 also categories depending on the nature of mobility. In this 177 document, we consider mobility solutions and protocols starting from 178 the network layer (layer 3 in the OSI stack) and up. 180 Mobility is inherently tied with the way nodes are addressed in a 181 distributed network. In this document, we present two different ways 182 to address mobile nodes: addresses with combined location and 183 identity, and addresses with a distinct locator and an identity. 184 There is a third way, content-based addressing [2][3], however that 185 is not typically within the scope of IETF. The first addressing 186 model is traditionally used by the IP based protocols. The second 187 model is an extension of the first and used, for example, in the Host 188 Identity Protocol (HIP) [4]. 190 The most fundamental host controlled network-level protocols for 191 supporting mobile hosts are the family of Mobile IP protocols ( 192 Mobile IPv4 [5] and Mobile IPv6 [6]). Another related network-level 193 solution reusing Mobile IP signaling is Network Mobility (NEMO) [7], 194 in which complete subnetworks may change location as well as single 195 hosts. It is also possible manage the IP Mobility completely on the 196 access network side without mobile host's involvement. In this case 197 mobility could also be handled locally, typically within one 198 administrative domain. Network based Localized Mobility management 199 (NetLMM) is a recent such example. Protocol proposals exist for both 200 Mobile IPv6 based solution [8] and Mobile IPv4 based solution [9]. 202 It is also possible to have mobility handled on the transport layer. 203 Transport Layer Seamless Handover (TraSH), Datagram Congestion 204 Control Protocol (DCCP) and mobile-SCTP are recent examples of such 205 solutions. Yet another way of managing host mobility is the mobility 206 aware Virtual Private Network (VPN) such as MOBIKE [10] based IPSec 207 VPN. Protocols such as the Session Initiation Protocol (SIP) may 208 provide fine-grained mobility at the application level and they do 209 not assume underlying transport or network level mobility support. 211 There has been recent work on various enhancements to the existing IP 212 mobility protocols. Hierarchical Mobile IP (HMIPv6) [11] and Mobile 213 IPv4 Regional Registration [12] are examples of such protocol 214 enhancements that attempt to reduce signaling latencies based on 215 localized mobility agents. Furthermore, Fast Handovers for Mobile IP 216 (FMIPv6 [13] and FMIPv4 [14]) minimize the period during the handover 217 to a new access router where the MN is not able to send and/or 218 receive IP packets due to the normal handover procedures. These 219 handover procedures include the Mobile IP based location update, IP 220 address configuration and movement detection. 222 Mobile IP for IPv4 and IPv4 are separate protocols, and in order to 223 solve the IP version migration there is ongoing work to introduce 224 dual-stack extensions to both Mobile IPv4 [15] and Mobile IPv6 [16]. 225 The rationale for dual-stack solutions have been that MNs will anyway 226 have dual-stack support once Mobile IP gets deployed in large scale 227 and the IP version migration is more of an access network problem. 228 Depending what is the selected mobility management protocol version 229 these solutions function more efficiently in terms of tunneling 230 overhead and available functionality, such as route optimization, 231 over their native IP version in the access network. In case of IP 232 version migration the network controlled mobility management approach 233 could have less impact on MNs. They just use their native IP version 234 and the access network takes care of the migration. However, in this 235 approach the impact on the access networks is huge and unavoidable. 237 4. Policies in Operator Controlled Environments 239 Operator networks are typically well managed and controlled 240 networking environments. The cellular operators especially have 241 great interest in "managing" their subscribers access and services. 242 This has both regulatory and charging based background in general. 244 This section discusses some background related to the policies in 245 mobile operator type of network deployments. We also provide 246 examples of existing policy control frameworks that have been defined 247 for mobile operator space. 249 4.1. Policy Taxonomy 251 More text TBD. 253 Bearer Binding - The association between a service data flow and the 254 IP-CAN bearer transporting that service data flow. 256 Binding Mechanism - The method for creating, modifying and deleting 257 bindings. The binding mechanism is the procedure that associates 258 a service data flow, to the IP-CAN bearer deemed to transport the 259 service data flow. Thus, the binding mechanism shall associate 260 the application/service session information with the IP-CAN bearer 261 that is intended to carry the service data flow 263 authorized QoS - The maximum QoS that is authorized for a service 264 data flow. In case of an aggregation of multiple service data 265 flows within one IP-CAN bearer, the combination of the Authorized 266 QoS information of the individual service data flows is the 267 "Authorized QoS" for the IP-CAN bearer. 269 service data flow - An aggregate set of packet flows. 271 packet flow - A specific user data flow carried through the policy 272 enforcement point. A packet flow can be an IP flow. 274 IP CAN bearer - An IP transmission path of defined capacity, delay 275 and bit error rate, etc. 277 4.2. Firewall Protected Networks 279 Today in typical operator network deployments everything is protected 280 with firewalls operating at various OSI layers. Even the so-called 281 public hotspot and residential broadband accesses are protected from 282 unknown inbound traffic from the Internet towards the access network 283 and the mobile node respectively. Issues regarding firewalls and 284 Mobile IPv6 have been discussed in detail in [17] and [18]. 286 Furthermore, as a general case, discarding inbound IP-in-IP tunneled 287 and ESP encapsulated traffic is common even if the mobile node inside 288 the firewall protected network initiates the communication. This has 289 lead to the use of various UDP based NAT traversal solutions to solve 290 firewall issues as well. 292 It is becoming common in operator networks to extend the firewall 293 from the OSI layer-3 to upper layers. This leads quickly to cases 294 where, for example, the application layer protocol uses mobile node's 295 HoA for something and embeds the actual IP address inside the 296 protocol payload or header. Now if the firewall compares the outmost 297 IP addresses of the IP flow and those IP addresses embedded inside 298 the upper layer protocol it is possible there is a mismatch and the 299 firewall discards the packet. 301 4.3. Deployment Model Originating Restrictions 303 Original triangular routing of IP packets in case of Mobile IP was 304 soon enhanced with a capability to reverse tunnel all IP packets 305 through the Home Agent (HA). In general, reverse tunneling prohibits 306 the natural IP routing even more than the triangular routing as all 307 IP packets must always go through the HA regardless of the 308 topological location of the HA. Reverse tunneling option remains 309 even in Mobile IPv6, which specifies a route optimization mode. 310 However, in commercial operator management networks there is no 311 urgency seen to deploy any of the available solutions that would 312 allow IP packets to bypass the HA, either to downlink or to uplink. 314 There are no insurmountable technical reasons to restrict the Mobile 315 IP deployment models to HA-centric one. The reason is basically the 316 same in case of Mobile IP that has hindered the deployment and the 317 use of visited PLMN GGSNs in GPRS networks [19]. Operators desire 318 control over the media flows that are related to their services and 319 offerings. Eventually, it is the requirement from an operator to 320 control access to services and bill for those services that appears 321 to dominate over technically superior solutions. If all IP packets 322 must be routed through a central controlling gateway (in this context 323 the HA) then the operator has total control and does not possibly 324 need to depend on visited networks and roaming partners when it comes 325 to billing information and services policy enforcement. 327 4.4. Controlled Access to Services 329 Some wireless access technologies, such as GPRS, allow services 330 categorization and access control based on the requested and the 331 initiated service. Eventually the selected service affects the 332 routing decision in the operator service selection gateway and also 333 allows binding service related policies to the specific access or the 334 IP flow. 336 It can be questioned whether this kind of approach is actually 337 feasible anymore in multi-radio terminals and in generic 338 heterogeneous networking environment where the operator might not be 339 the sole owner of all provided access technologies and services. In 340 such a multi-access environment, there is no uniform way of 341 performing service selection during the network access establishment 342 across different access technologies. Also, binding service level 343 policies to a specific access type in an access specific gateway 344 might not meet all new multi-access requirements where changing the 345 access technology during the application session is highly probable. 346 Furthermore, it is likely that the terminal runs multiple 347 applications and services simultaneously, and each of them having 348 different requirements for their access. Thus, binding policies to a 349 single access based on a single application's needs is unlikely to 350 work flawlessly. 352 4.5. Service Access Through Multiple Accesses 354 Most of the existing policy control mechanisms has been designed with 355 static service scenario in mind. With static we mean that the MN's 356 IP address remains constant during the user session, and once 357 activated through some access (i.e. bearer) it is assumed that the 358 bearer does not change. If the bearer changes mid session, the 359 policy framework is likely to fall back to a default behavior rather 360 than attempt any optimization. It is also possible that the policy 361 control mechanism in question supports mid session updates on 362 policies. 364 4.6. Location of the Policy Enforcement 366 In many mobile networks a logical place for the Policy Enforcement 367 Point (PEP) is the gateway that terminates the user plane traffic. 368 Depending on the network deployment, there might be a number of 369 gateways terminating the user plane traffic. This is especially the 370 case in heterogeneous networks with multiple access technologies and 371 multihomed terminals. With multiple PEPs, policy enforcement for 372 service flows is obviously more challenging. For one IP flow one PEP 373 is active at given time. 375 The location of the PEP also matters in inter-operator roaming cases. 376 As mentioned earlier operators prefer to have total control over 377 their subscribers' service flows. This has lead to a situation where 378 basically all IP traffic gets forcibly routed back to home network's 379 anchoring gateways, even if the MN is roaming on the other side of 380 the world. Allowing the visited network also to apply policy rules 381 on behalf of the home operator is something that should be carefully 382 considered as a part of the general policy framework design. 384 4.7. Example - 3GPP PCC Architecture 386 Figure 1 shows overall architecture of 3GPP defined Policy and 387 Charging Control (PCC) (roaming) architecture that was defined for 388 the 3GPP Release-7 [20]. The solution has yet since raised interest 389 also outside 3GPP for other networking systems as a generic policy 390 framework. The PCC architecture makes extensive use of Diameter [21] 391 and especially the Credit Control [22] and NASREQ application 392 commands [23]. However, the usage of Diameter in the PCC has heavily 393 been altered and is basically 3GPP specific application [24][25] at 394 the moment. The PCC aims to be access technology agnostic but as of 395 its current state it requires more abstraction or either more 396 possibilities how to handle different types of access technologies. 397 From 3GPP point of view one of the issues is that the PCC needs also 398 address the policy solutions defined in earlier releases of the 399 general architecture [26]. 401 +--------------------------+ +--------------------------+ 402 | +--------+ | | +--------------+ | 403 | | Proxy |--------------------------------------| OCS | | 404 | | OCS | | | | | | 405 | +--------+ | | +----+ +--------------+ | 406 | | | | | AF | | 407 | | | | +----+ | 408 | | | | | | 409 | | | | | | 410 | | +--------+ | | +--------+ +-----+ | 411 | | | V-PCRF |----------------| H-PCRF |--| SPR | | 412 | | +--------+ | | +--------+ +-----+ | 413 | | | | | | 414 | | | | | | 415 | +----------------------+ | | | 416 | | V-PCEF & GW | | | | 417 | +----------------------+ | | | 418 | | | | | 419 | | | | | 420 | +------+ +--------+ | | +--------+ | 421 | | OFCS |------| BSyst |----------------| BSyst | | 422 | +------+ +--------+ | | +--------+ | 423 | | | | 424 +--------------------------+ +--------------------------+ 426 Figure 1: Logical PCC Architecture when the PCEF is in visited 427 network 429 Another issue that needs to be kept in mind concerning the policy 430 frameworks relates to generic access network deployments and inter- 431 operator connectivity. Typically, for example, GSM (GPRS) operators 432 have had a total control over the access networks, and the 433 interconnection and roaming traffic. This can still be seen from the 434 PCC framework. Today, GSM operators are connected through isolated 435 roaming and interconnection IP backbone network [27] with strict 436 Service Level Agreements (SLA) and rules that define how the roaming 437 must be deployed. This model works for services that are all within 438 the control of operators (mobile networks or even external networks 439 in some cases). 441 Within the PCC framework there are numerous different signaling 442 scenarios depending on for example: 444 o Who initiates the bearer setup and/or update. 446 o Which node terminates session. 448 o Whether event notifications are used. 450 o Whether application function affects policies. 452 This document does not try to go through them all. Consult [20] and 453 [28] for more details. Figure 2 shows one example signaling 454 sequences for a policy download to the policy enforcement point after 455 the MN has established IP connectivity to the networking and service 456 system. The same signaling sequence can also be applied almost as is 457 to bearer update procedures. 459 +------------+ +--------+ +-----+ +-----+ +-----+ 460 | GW & PCEF | | PCRF | | SPR | | AF | | OCS | 461 +------------+ +--------+ +-----+ +-----+ +-----+ 462 | | | | | 463 | | (1. App & Serv | info) | | 464 | |<------------------------| | 465 | | | | | 466 | | (2. Ack) | | | 467 3. Bearer | |------------------------>| | 468 signaling req | | | | | 469 --------------->| | | | | 470 | 4. Request or | | | | 471 | Indication | | | | 472 |-------------->| | | | 473 | | (5. Event info)| | | 474 | |------------------------>| | 475 | | | | | 476 | | (6. Ack) | | | 477 | |<------------------------| | 478 | | | | | 479 | | (7. Profile | req) | | 480 | |--------------->| | | 481 | | | | | 482 | | (8. Profile | rep) | | 483 | |<---------------| | | 484 | | | | | 485 | +--------------+ | | | 486 | | 9. Policy | | | | 487 | | decision | | | | 488 | | | | | | 489 | +--------------+ | | | 490 | | | | | 491 | 10. Ack & push| | | | 492 | policies | | | | 493 |<--------------| | | | 494 | | | | | 495 | 11. Credit req| | | | 496 |------------------------------------------------->| 497 | | | | | 498 | 12. Credit rep| | | | 499 |<-------------------------------------------------| 500 11. rep | | | | | 501 <---------------| | | | | 502 | | | | | 504 Figure 2: An overall 3GPP PCC signaling overview 506 The first two steps assume that the MN has already established 507 connectivity and the initial policy might also have been established. 508 These step are relevant when the application function (e.g. some SIP- 509 based service) needs to update policies for a reason or another. 511 1) The application function provides service related information to 512 the PCRF (PDF). The trigger for the application function to 513 originates from the applications that the MN is using. 515 2) The PCRF (PDF) stores the service related information and 516 acknowledges the application function. 518 Rest of the signaling sequence details TBD later. 520 5. Issues in Integrating IP Mobility and Policies 522 This section discussed about identified issues when it comes to 523 policies and IP mobility. The background is mostly based on the 524 operator and network architecture assumptions discussed in previous 525 chapters. 527 5.1. Mandatory Reverse Tunneling through the Mobility Anchor 529 As already briefly discussed earlier mobile network operators prefer 530 routing all service relates IP traffic through their home network 531 independent where the MN is located. In IP Mobility sense this means 532 all IP traffic must traverse through the HA to both uplink and 533 downlink directions. 535 The model of described here has a number of issues. Firstly, 536 mandatory reverse tunneling effectively prohibits for example Mobile 537 IPv6 Route Optimization. The implications of this will be discussed 538 in more detail in section TBD. Secondly, another related issue is 539 the desire to use the mobility anchor located in the home network. 540 This kind of deployment decision affects inter-operator roaming cases 541 and effectively prohibits the use of local breakouts in the visited 542 networks. The implications of this issue will be discussed further 543 in section TBD. 545 5.2. Firewalling at Multiple Layers 547 In operator network environments it is common that firewalling is not 548 only applied to application level user traffic. Especially in inter- 549 operator roaming cases it is typical that operator also do rather (or 550 try to) intense packet analysis on received traffic. It is not 551 entirely clear what are the implications of this, if any, when MNs 552 and possibly visited network gateways providing proxy mobility 553 services [8] for MNs change their point of attachment to the network 554 frequently. 556 More text TBD. 558 5.3. Binding of Service Flows 560 Policies that are tightly integrated to a specific access or a bearer 561 might make handovers rather inefficient. All service flows are bound 562 to a specific bearer and the binding needs to be updated when a 563 handover takes place. The update mechanism is typically reactive, 564 which means that both PEP and PDF react after the bearer has changed. 565 At least this could be the case for host controlled mobility, where 566 the policy update is partially triggered at the application rather 567 than only at the access level. After that the service flows need to 568 re-bound to the new bearer. Clearly this is not the most optimal 569 possible approach. 571 As mentioned earlier the trigger to update policies and binding may 572 also originate from the application (and application server). 573 However, if the mobility management functionality keeps the IP layer 574 intact the application does not really have a simple uniform way to 575 discover the change of bearer. Based on this, it is highly possible 576 that the trigger to update policies and binding always originates 577 from the gateway/mobility management function, after the handover has 578 taken place. 580 If the PEP and gateway functionality are separated from the first 581 user plane termination point and the access network specific 582 information gets abstracted completely away some new signaling is 583 required to inform the mobility management entity (e.g. the HA) about 584 the characteristics of the new bearer. Currently Mobile IP does not 585 have this functionality. This issue is discussed further in section 586 TBD. 588 6. Conclusions 590 TBD 592 7. IANA Considerations 594 This document does not define any new name spaces to be managed by 595 IANA. This document does not either reserve any new numbers or names 596 under any existing name space managed by IANA. 598 8. Security Considerations 600 TBD 602 9. Acknowledgments 604 TBD 606 10. References 608 10.1. Normative References 610 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 611 Levels", RFC 2119, March 1997. 613 10.2. Informative References 615 [2] Carzaniga, A., Rosenblum, D., and A. Wolf, "Achieving 616 expressiveness and scalability in an internet-scale event 617 notification service", Nineteenth ACM Symposium on Principles 618 of Distributed Computing (PODC2000), July 2000. 620 [3] Muhl, G., Ulbrich, A., Herrman, K., and T. Weis, "Disseminating 621 information to mobile clients using publish/subscribe", IEEE 622 Internet Computing 46-53, May 2004. 624 [4] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) 625 Architecture", RFC 4423, May 2006. 627 [5] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 628 August 2002. 630 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 631 IPv6", RFC 3775, June 2004. 633 [7] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 634 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 635 January 2005. 637 [8] Gundavelli, S., "Proxy Mobile IPv6", 638 draft-sgundave-mip6-proxymip6-01 (work in progress), 639 January 2007. 641 [9] Leung, K., "Mobility Management using Proxy Mobile IPv4", 642 draft-leung-mip4-proxy-mode-02 (work in progress), 643 January 2007. 645 [10] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 646 RFC 4555, June 2006. 648 [11] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, 649 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 650 RFC 4140, August 2005. 652 [12] Fogelstroem, E., "Mobile IPv4 Regional Registration", 653 draft-ietf-mip4-reg-tunnel-04 (work in progress), October 2006. 655 [13] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 656 July 2005. 658 [14] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 659 draft-ietf-mip4-fmipv4-03 (work in progress), February 2007. 661 [15] Tsirtsis, G., "Dual Stack Mobile IPv4", 662 draft-ietf-mip4-dsmipv4-01 (work in progress), December 2006. 664 [16] Soliman, H. and G. Tsirtsis, "Problem Statement: Dual Stack 665 Mobility", draft-ietf-mip6-dsmip-problem-03 (work in progress), 666 January 2007. 668 [17] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile IPv6 669 and Firewalls: Problem Statement", RFC 4487, May 2006. 671 [18] Chen, X., "Problem Statement for MIPv6 Interactions with GPRS/ 672 UMTS Packet Filtering", draft-chen-mip6-gprs-07 (work in 673 progress), February 2007. 675 [19] 3GPP, "General Packet Radio Service (GPRS); Service 676 description; Stage 2", 3GPP TS 23.060 7.2.0, September 2006. 678 [20] 3GPP, "Policy and charging control architecture", 3GPP 679 TS 23.203 7.0.0, October 2006. 681 [21] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 682 "Diameter Base Protocol", RFC 3588, September 2003. 684 [22] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 685 Loughney, "Diameter Credit-Control Application", RFC 4006, 686 August 2005. 688 [23] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter 689 Network Access Server Application", RFC 4005, August 2005. 691 [24] 3GPP, "Policy and charging control over Gx reference point", 692 3GPP TS 29.212 1.0.0, December 2006. 694 [25] 3GPP, "Policy and charging control over Rx reference point", 695 3GPP TS 29.214 1.0.0, December 2006. 697 [26] 3GPP, "Policy control over Go interface", 3GPP TS 29.207 6.5.0, 698 September 2005. 700 [27] GSM Association, "Inter-PLMN Backbone Guidelines", Public 701 Reference Document IR.34, April 2006. 703 [28] 3GPP, "Policy and charging control signalling flows and Quality 704 of Service (QoS) parameter mapping", 3GPP TS 29.213 1.0.0, 705 December 2006. 707 Authors' Addresses 709 Jouni Korhonen 710 TeliaSonera 711 P.O. Box 970 712 FIN-00051 Sonera 713 Finland 715 Email: jouni.korhonen@teliasonera.com 717 Vijay Devarapalli 718 Azaire Networks 719 4800 Great America Pkwy 720 Santa Clara, CA 95054 721 USA 723 Email: vijay.devarapalli@azaire.com 725 Gerardo Giaretta 726 Telecom Italia 727 via Reiss Romoli 274 728 Torino 10148 729 Italy 731 Email: gerardo.giaretta@gmail.com 732 Rajeev Koodli 733 Nokia 734 313 Fairchild Drive 735 Mountain View, CA 94043 736 USA 738 Email: rajeev.koodli@nokia.com 740 Full Copyright Statement 742 Copyright (C) The IETF Trust (2007). 744 This document is subject to the rights, licenses and restrictions 745 contained in BCP 78, and except as set forth therein, the authors 746 retain all their rights. 748 This document and the information contained herein are provided on an 749 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 750 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 751 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 752 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 753 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 754 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 756 Intellectual Property 758 The IETF takes no position regarding the validity or scope of any 759 Intellectual Property Rights or other rights that might be claimed to 760 pertain to the implementation or use of the technology described in 761 this document or the extent to which any license under such rights 762 might or might not be available; nor does it represent that it has 763 made any independent effort to identify any such rights. Information 764 on the procedures with respect to rights in RFC documents can be 765 found in BCP 78 and BCP 79. 767 Copies of IPR disclosures made to the IETF Secretariat and any 768 assurances of licenses to be made available, or the result of an 769 attempt made to obtain a general license or permission for the use of 770 such proprietary rights by implementers or users of this 771 specification can be obtained from the IETF on-line IPR repository at 772 http://www.ietf.org/ipr. 774 The IETF invites any interested party to bring to its attention any 775 copyrights, patents or patent applications, or other proprietary 776 rights that may cover technology that may be required to implement 777 this standard. Please address the information to the IETF at 778 ietf-ipr@ietf.org. 780 Acknowledgment 782 Funding for the RFC Editor function is provided by the IETF 783 Administrative Support Activity (IASA).