1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Internet Engineering Task Force (IETF) M. Liebsch, Ed.
Request for Comments: 6279 NEC
Category: Informational S. Jeong
ISSN: 2070-1721 ETRI
Q. Wu
Huawei
June 2011
<span class="h1">Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement</span>
Abstract
Proxy Mobile IPv6 is the IETF Standard for network-based mobility
management. In Proxy Mobile IPv6, mobile nodes are topologically
anchored at a Local Mobility Anchor, which forwards all data for
registered mobile nodes. The setup and maintenance of localized
routing, which allows forwarding of data packets between two mobile
nodes' Mobility Access Gateways without involvement of their Local
Mobility Anchor in forwarding, is not considered. This document
describes the problem space of localized routing in Proxy Mobile
IPv6.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6279">http://www.rfc-editor.org/info/rfc6279</a>.
<span class="grey">Liebsch, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions and Terminology .....................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Problem Statement for Localized Routing in PMIPv6 ...............<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. General Observation ........................................<a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. Use Cases Analysis .........................................<a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. IPv4 Considerations ........................................<a href="#page-8">8</a>
3.3.1. Localized Routing for Communication between
IPv4 Home Addresses .................................<a href="#page-8">8</a>
<a href="#section-3.3.2">3.3.2</a>. IPv4 Transport Network Considerations ...............<a href="#page-9">9</a>
<a href="#section-4">4</a>. Functional Requirements for Localized Routing ...................<a href="#page-9">9</a>
<a href="#section-5">5</a>. Roaming Considerations .........................................<a href="#page-10">10</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-11">11</a>
<a href="#section-7">7</a>. Acknowledgments ................................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. References .....................................................<a href="#page-13">13</a>
<a href="#section-8.1">8.1</a>. Normative References ......................................<a href="#page-13">13</a>
<a href="#section-8.2">8.2</a>. Informative References ....................................<a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The IETF has specified Proxy Mobile IPv6 (PMIPv6) [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] as the
base protocol for network-based localized mobility management
(NetLMM). The scope of the base protocol covers the setup and
maintenance of a tunnel between a Mobile Node's (MN's) Mobile Access
Gateway (MAG) and its selected Local Mobility Anchor (LMA). Data
packets will always traverse the MN's MAG and its LMA, irrespective
of the location of the MN's remote communication endpoint. Even
though an MN may be attached to the same MAG or a different MAG as
its Correspondent Node (CN) within the same provider domain, packets
being associated with their communication will traverse the MN's and
the CN's LMA, which can be located topologically far away from the
MN's and the CN's MAG or even in a separate provider domain.
<span class="grey">Liebsch, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
[<a id="ref-RFC5213">RFC5213</a>] addresses the need to enable local routing of traffic
between two nodes being attached to the same MAG, but does not
specify the complete procedure to establish such localized routing
state on the shared MAG.
The NetLMM Extensions (NetExt) Working Group has an objective to
design a solution for localized routing in PMIPv6. This objective
includes the specification of protocol messages and associated
protocol operation between PMIPv6 components to support the setup of
a direct routing path for data packets between the MN's and the CN's
MAG, while both hosts receive mobility service according to the
PMIPv6 protocol [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>]. As a result of localized routing, these
packets will be forwarded between the two associated MAGs without
traversing the MN's and the CN's LMA(s). In cases where one or both
nodes hand over to a different MAG, the localized routing protocol
maintains the localized routing path. Relevant protocol interfaces
may include the interface between associated MAGs, between a MAG and
an LMA, and between LMAs. The setup of localized routing with CNs
not registered with a PMIPv6 network is out of scope of the NetExt
solution and this problem statement.
This document analyzes and discusses the problem space of always
using the default route through two communicating mobile nodes' local
mobility anchors. Furthermore, the problem space of enabling
localized routing in PMIPv6 is analyzed and described, while
different communication and mobility scenarios are taken into
account. Based on the analysis, a list of key functional
requirements is provided, serving as input to the design of the
protocol solution.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions and Terminology</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
This document uses the terminology of [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>]. In addition, the
following terms are used in the context of this problem statement:
o Mobile Node (MN): Mobile Node without IP mobility support, which
is attached to a Mobile Access Gateway (MAG) and registered with a
Local Mobility Anchor (LMA) according to the PMIPv6 specification
[<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>].
<span class="grey">Liebsch, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
o Correspondent Node (CN): Correspondent Node according to its
definition in [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>] with or without IP mobility support. The
CN represents the communication peer of an MN that is attached to
a MAG and registered with an LMA according to the PMIPv6
specification.
o Localized Routing: Result of signaling to set up routing states on
relevant network entities to allow forwarding of data packets
between an MN and a CN, which are attached to MAGs sharing the
same provider domain, without intervention of the MN's LMA and the
CN's LMA in data forwarding.
o Localized Routing States: Information for localized routing on
relevant forwarding entities on the optimized data path between an
MN and a CN. Such information includes route entries and tunnel
endpoints and may include further information about the MN and the
CN, such as the communicating nodes' Mobile Node Identifier and
their assigned Home Network Prefix.
o Provider Domain: A network domain in which network components are
administered by a single authority, e.g., the mobile operator.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Problem Statement for Localized Routing in PMIPv6</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. General Observation</span>
The Mobile IPv6 (MIPv6) protocol [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>] has built-in mechanisms
for direct communication between an MN and a CN. Mechanisms for
route optimization in MIPv6 cannot be directly applied in PMIPv6.
Following the paradigm of PMIPv6, MNs are not involved in mobility
signaling and hence cannot perform signaling to set up localized
routes. Instead, the solution for localized routing must consider
functions in the network to find out whether or not a localized route
is to be used and then control the setup and maintenance of localized
routing states accordingly without any assistance from the MN and the
CN. In the case of communication between two nodes attached to the
PMIPv6 network infrastructure and where each node is registered with
an LMA, data packets between these two nodes will always traverse the
responsible LMA(s). At least some deployments would benefit from
having such communication localized, rather than having packets
traverse the core network to the LMA(s). In the context of this
document, such localized communication comprises offloading traffic
from LMAs and establishing an optimized forwarding path between the
two communication endpoints.
Localized routing is understood in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] as optimization of
traffic between an MN and a CN that are attached to an access link
connected to the same MAG. In such a case, the MAG forwards traffic
<span class="grey">Liebsch, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
directly between the MN and the CN, assuming the MAG is enabled to
support this feature (setting of the EnableMAGLocalRouting flag on
the MAG) and the MN's LMA enforces this optimization. [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] does
not specify how an LMA can enforce optimization for such local
communication. Maintaining local forwarding between the MN and the
regular IPv6 CN gets more complex in the case where the MN performs a
handover to a different MAG. Such a use case is not considered in
the specification and is out of scope of this problem statement.
This document focuses on use cases where both nodes, the MN and the
CN, are within a PMIPv6 network and served by an LMA in a domain of
LMAs.
With localized routing, operators have the possibility of offloading
traffic from LMAs and from the core network. Establishment of a
direct path between the MN's and the CN's MAG can be beneficial for
the following reasons: First, by limiting the communication to the
access nodes, the data traffic traversing the MAG - LMA path
(network) can be reduced. This is significant, considering that the
transport network between the access and the core is often the
bottleneck in terms of costs and performance. Second, there may be
performance benefits for data flows between the MN and the CN in
terms of delay and packet loss, especially when the MN and the CN are
attached to the same MAG and the LMA is topologically far away from
that MAG. Even when the MN and the CN are attached to different
MAGs, there could be benefit in limiting the communication to the
access network only, rather than traversing the transport network to
the LMA. Furthermore, offloading traffic from the LMA by means of
localized routing can improve scalability of the LMA, as it
represents a bottleneck for traffic being forwarded by many MAGs.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Use Cases Analysis</span>
This problem statement focuses on local communication between PMIPv6
managed nodes, which attach to MAGs sharing the same provider domain.
The following list analyzes different use cases, which consider the
existence of multiple LMAs. Figure 1 depicts a PMIPv6-based network
with two mobility anchors. According to [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], the MN moves in
the PMIPv6 domain being built by its LMA and MAG. The same applies
to the CN, which moves in the PMIPv6 domain built by the CN's LMA and
MAG. The analysis takes no assumption on whether the MN and the CN
share the same PMIPv6 domain or not.
<span class="grey">Liebsch, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
Internet Backbone
: :
+------------------+
| |
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
| |
| |
+----+------------------+----+
| |
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
: : :
+---+ +---+ +---+
|MN | |CN1| |CN2|
+---+ +---+ +---+
Figure 1: Reference Architecture for Localized Routing in PMIPv6
All "A" use cases below assume that both the MN and the CN are
registered with an LMA according to the PMIPv6 protocol. Whereas
MAG1 is always considered as the MN's current Proxy Care-of Address,
the CN can be either connected to the same MAG or to a different MAG
or LMA as the MN. Accordingly, these topological differences are
denoted as follows:
A[number of MAGs][number of LMAs]
A11: The MN and the CN (CN1) connect to the same MAG (MAG1) and are
registered with the same LMA (LMA). The common MAG may forward
data packets between the MN and the CN directly without forwarding
any packet to the LMA. [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] addresses this use case, but
does not specify the complete procedure to establish such
localized routing state on the shared MAG.
A12: The MN and the CN (CN1) connect to the same MAG (MAG1) and are
registered with different LMAs (LMA1 and LMA2). The common MAG
may forward data packets between the MN and the CN directly
without forwarding any packet to the LMAs. Following the policy
of [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] and enforcement of the setup of a localized
forwarding path, potential problems exist in the case where LMA1
and LMA2 differ in their policy to control the MAG.
A21: The CN (CN2) connects to a different MAG (MAG2) than the MN
(MAG1), but the MN and the CN are registered with the same LMA
(LMA1). The result of localized routing should be the existence
<span class="grey">Liebsch, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
of routing information at MAG1 and MAG2, which allows direct
forwarding of packets between the MN's MAG1 and the CN's MAG2. As
LMA1 is the common anchor for the MN and the CN and maintains
location information for both nodes, no major race condition and
instability in updating the states for localized routing is
expected.
A22: The CN (CN2) connects to a different MAG (MAG2) and a different
LMA (LMA2) than the MN (MAG1, LMA1). The result of localized
routing should be the existence of routing information at MAG1 and
MAG2, which allows direct forwarding of packets between the MN's
MAG1 and the CN's MAG2. As the location information of the CN and
the MN is maintained at different LMAs, both LMAs need to be
involved in the procedure to set up localized routing. In the
case of a handover of the MN and/or the CN to a different MAG,
non-synchronized control of updating the states for localized
routing may result in race conditions, superfluous signaling, and
packet loss.
The following list summarizes general problems with setting up and
maintaining localized routing between an MN and a CN. In the context
of this problem statement, the MN and the CN are always assumed to be
registered at an LMA according to the PMIPv6 protocol [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>].
o MNs do not participate in mobility management and hence cannot
perform binding registration at a CN on their own. Rather,
entities in the network infrastructure must take over the role of
MNs to set up and maintain a direct route. Accordingly, a
solution for localized routing in PMIPv6 must specify protocol
operation between relevant network components, such as between a
MAG and an LMA, to enable localized routing for data traffic
without traversing the MN's and the CN's LMA(s).
o In the case where the MN and the CN are both registered with
different LMAs according to the PMIPv6 protocol, relevant
information for the setup of a localized routing path, such as the
current MAG of the MN and the CN, is distributed between these
LMAs. This may complicate the setup and stable maintenance of
states enabling localized routing.
o In the case where localized routing between an MN and a CN has
been successfully set up and both nodes move and attach to a new
access router simultaneously, signaling the new location and
maintenance of states for localized routing at relevant routers
may run into a race condition situation. This can happen in the
case where coordination of signaling for localized routing and
provisioning of relevant state information is distributed between
different network entities, e.g., different LMAs. In such a case,
<span class="grey">Liebsch, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
as a result of the MN's handover, updated information about the
MN's location may arrive at the CN's previous MAG, while the CN
has already moved to a new MAG. The same applies to the other
direction, where the system may update the MN's previous MAG about
the CN's new location, while the MN has moved to a new MAG in the
meantime. The protocol solution must deal with such exceptional
handover cases efficiently to avoid or resolve such problems.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. IPv4 Considerations</span>
According to [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>], the basic configuration requirements for
supporting IPv4 in PMIPv6 are that LMAs and MAGs are both IPv4 and
IPv6 enabled. Also, LMAs and MAGs must have a globally unique IPv6
address configured, irrespective of enabled support for IPv6 routing
between these components. This requirement should also apply to
configuration requirements of localized routing.
Additional issues emerge when localized routing is considered for
PMIPv6 with IPv4 support. These can be classified into two general
groups: issues with localized routing between an MN's and a CN's IPv4
Home Addresses, and transport plane issues. The following
subsections analyze these two groups.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Localized Routing for Communication between IPv4 Home Addresses</span>
In the case where an LMA and a MAG hold a registration to support
IPv4 Home Address mobility for an MN, the MAG and the LMA must
support appropriate encapsulation of IPv4 packets. To enable
localized routing, the MN's MAG must encapsulate and forward routing
path optimized packets to the CN's MAG and needs to ensure that the
chosen encapsulation mode is supported by the correspondent MAG.
Incompatibility in a selected encapsulation mode causes failure in
setting up a localized route.
When localized routing is used for IPv4 traffic, the conceptual data
structures on associated MAGs must be augmented with appropriate
parameters for forwarding localized traffic. MAGs may need to
maintain a routing state for each MN-CN-pair and make routing
decisions for uplink traffic based on the packet's complete IPv4
source and destination address. Hence, conceptual data structures to
handle states for localized routes need to comprise this address
tuple for unique identification.
<span class="grey">Liebsch, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
As a known constraint, IPv4 addresses of two nodes that hold
addresses from a private address space may overlap. To uniquely
identify both nodes, the IPv4 address of the MN and the CN must not
overlap. To cope with overlapping address spaces, the localized
routing solution could use additional mechanisms to tag and uniquely
identify the MN and the CN.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. IPv4 Transport Network Considerations</span>
The transport network between the LMA and the MAG may be based on
IPv6 or IPv4. Deployments may ensure that the same transport
mechanism (i.e., IPv6 or IPv4) is used for operational consistency.
Similar to the encapsulation requirement stated in the previous
section, the IP version used for localized routing is also assumed,
by configuration, to be consistent across all MAGs within the
associated provider domain. The design of optional mechanisms for
negotiating the IP version to use as well as the encapsulation mode
to use are outside the scope of the NetExt WG's solution for
localized routing.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Functional Requirements for Localized Routing</span>
Several tasks need to be performed by the network infrastructure
components before relevant information for such direct communication
is discovered and associated states for localized routing can be set
up. The following list summarizes some key functions that need to be
performed by the PMIPv6-enabled network infrastructure to substitute
mobile nodes in setting up a direct route.
o Detection of the possibility to perform localized routing. This
function includes looking at a data packet's source and
destination address.
o Initiation of a procedure that sets up a localized routing path.
o Discovery of stateful entities (i.e., the LMA(s) and/or the
MAG(s)) that maintain and can provide relevant information needed
to set up a localized routing path. Such information may include
the routable address of an LMA or MAG, where one or both mobile
nodes are connected to and registered with that LMA or MAG.
o Control in setting up and maintaining (e.g., during handover) the
localized routing path. Control is also needed to terminate the
use of a localized routing path and to delete associated states,
whereas a trigger for the termination may come from a non-PMIPv6-
related component.
<span class="grey">Liebsch, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
o Enforcement of administrative policy rules to localized routing.
Such policies allow operators to have further control of the setup
of a localized route and enable the possibility to disallow
localized routing, for example, to ensure that traffic traverses
charging-related functions on the LMA. Explicit authorization of
localized routing is, for example, discussed in [<a href="#ref-PMIP6-LR" title=""Diameter Support for Proxy Mobile IPv6 Localized Routing"">PMIP6-LR</a>]. As a
further example, mobile-node- and operator-specific policy rules
can be established on PMIPv6 components during PMIPv6
bootstrapping according to [<a href="./rfc5779" title=""Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server"">RFC5779</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Roaming Considerations</span>
Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g.,
LMAs, MAGs) tied by the MN and the CN may be distributed between
different provider domains (i.e., domain A, B, C) and the MN and/or
CN moves from one provider domain to another one. In order to
support localized routing when roaming occurs, it is required that
MAGs to which the MN and CN connect be within the same provider
domain, and each MAG has a security relationship with the
corresponding LMA, which maintains the registration of the MN or the
CN, respectively.
According to the roaming model as depicted in Figure 2, the MN's
PMIPv6 domain is characterized by its MAG (MAG1/MAG1') and its LMA
(LMA1), whereas the CN's PMIPv6 domain is characterized by the CN's
MAG (MAG2/MAG2') and its LMA (LMA2/LMA2'). A solution for localized
routing cannot take any assumption about whether or not the MN and CN
share the same PMIPv6 domain; hence, MAG1/MAG1' may not share a
security association with LMA2/LMA2', and MAG2/MAG2' may not share a
security association with LMA1, respectively.
It is not required that LMAs, which hold the registration for the MN
and the CN, respectively, be part of the same provider domain as the
MAGs where the MN and CN attach. When the MN's MAG and LMA belong to
different provider domains (A and C), localized routing is subject to
policy governing the service level agreements between these domains.
The same applies to the provider domains that provide the CN's MAG
and LMA. Based on the above requirements, four PMIPv6 roaming and
non-roaming cases can be taken into account.
o Case 1: The MN's MAG (MAG1), the CN's MAG (MAG2), the MN's LMA
(LMA1), and the CN's LMA (LMA2) are located in the same provider
domain A.
o Case 2: The MN's MAG (MAG1), the CN's MAG (MAG2), and the MN's LMA
(LMA1) are located in the same domain A, while the CN's LMA
(LMA2') is located in provider domain B.
<span class="grey">Liebsch, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
o Case 3: The MN's MAG (MAG1') and the CN's MAG (MAG2') are located
in domain C, while the MN's LMA (LMA1) and the CN's LMA (LMA2) are
located in provider domain A.
o Case 4: The MN's MAG (MAG1') and the CN's MAG (MAG2') are located
in provider domain C, while the MN's LMA (LMA1) is located in
provider domain A and the CN's LMA (LMA2') is located in provider
domain B.
In these roaming cases, the MN can be allowed to roam within its
domain (e.g., the MN's home domain in which the MN's LMA is located)
or over different domains (e.g., the MN moves from its home domain to
a visited domain). During mobility, the CN and MN should remain
attached to MAGs of the same provider domain to maintain efficient
routing of traffic between their MAGs.
|
+-----+ +-----+ | +-----+
|LMA1 | |LMA2 | | |LMA2'|
+-----+ +-----+ | +-----+
|
|
|
|
+-----+ +-----+ |
|MAG1 | |MAG2 | |
+-----+ +-----+ |
|
|
Provider Domain A | Provider Domain B
------------------------------+-------------------------------
Provider Domain C
+-----+ +-----+
|MAG1'| |MAG2'|
+-----+ +-----+
Figure 2: PMIPv6 Roaming Cases Considered for Localized Routing
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
A protocol solution for localized routing in a PMIPv6 network must
counter unauthorized change of a routing path. In particular, the
control plane for localized routing must preclude the blocking or
hijacking of mobile nodes' traffic by malicious or compromised
network components. A security solution must support suitable
mechanisms for authentication of control plane components of the
localized routing functional architecture for both roaming and
<span class="grey">Liebsch, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
non-roaming scenarios. Any possibility for Internet hosts to
interfere with the localized routing procedure in a malicious manner
must be precluded.
Since network entities other than MNs and CNs perform signaling to
set up localized routing, the MIPv6 return routability test [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>]
is not suitable to authenticate associated signaling messages in
PMIPv6. Solutions for localized routing in PMIPv6 need to mitigate,
or to provide sufficient defense against, possible security threats.
When PMIPv6 participants are administered within the same domain,
infrastructure-based authorization mechanisms, such as IPsec, may be
usable to protect signaling for localized routing.
Existing security associations according to [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] can be re-used
to protect signaling for localized routing on the interface between a
MAG and an LMA. In the case where a protocol solution for localized
routing in PMIPv6 relies on protocol operation between MAGs, means
for protection of signaling between these MAGs must be provided. The
same applies for signaling on a possible protocol interface between
two LMAs of the same domain.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgments</span>
Many aspects of the problem space for route optimization in PMIPv6
have been discussed in the context of a PMIPv6 Route Optimization
Design Goals document, which was submitted to the NetLMM WG in
November 2007. This group of contributors includes Sangjin Jeong,
Christian Vogt, Ryuji Wakikawa, Marco Liebsch, Behcet Sarikaya,
Shinta Sugimoto, Long Le, Alice Qinxia, and Jaehwoon Lee. Many
thanks to Rajeev Koodli for his comments about the structure and
scope of this problem statement for the NetExt WG.
This problem statement reflects the results of the discussion in the
NetExt group. Many thanks to Hidetoshi Yokota, Carlos Bernardos,
Ashutosh Dutta, Sri Gundavelli, Mohana Jeyatharan, Jouni Korhonen,
Glen Zorn, Dirk von Hugo, Frank Xia, Xiangsong Cui, and Basavaraj
Patil for their comments and support to improve the quality of the
problem statement.
<span class="grey">Liebsch, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC5213">RFC5213</a>] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
<a href="./rfc5213">RFC 5213</a>, August 2008.
[<a id="ref-RFC5844">RFC5844</a>] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", <a href="./rfc5844">RFC 5844</a>, May 2010.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Informative References</span>
[<a id="ref-PMIP6-LR">PMIP6-LR</a>] Zorn, G., Wu, Q., Liebsch, M., and J. Korhonen, "Diameter
Support for Proxy Mobile IPv6 Localized Routing", Work
in Progress, May 2011.
[<a id="ref-RFC3775">RFC3775</a>] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", <a href="./rfc3775">RFC 3775</a>, June 2004.
[<a id="ref-RFC5779">RFC5779</a>] Korhonen, J., Ed., Bournelle, J., Chowdhury, K., Muhanna,
A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile
Access Gateway and Local Mobility Anchor Interaction with
Diameter Server", <a href="./rfc5779">RFC 5779</a>, February 2010.
<span class="grey">Liebsch, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6279">RFC 6279</a> PMIPv6 Localized Routing PS June 2011</span>
Authors' Addresses
Marco Liebsch (editor)
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
Phone: +49 6221 4342146
EMail: liebsch@neclab.eu
Sangjin Jeong
ETRI
218 Gajeongno, Yuseong
Daejeon 305-700
Korea
Phone: +82 42 860 1877
EMail: sjjeong@etri.re.kr
Qin Wu
Huawei Technologies Co., Ltd
101 Software Avenue, Yuhua District
Nanjing 210012
China
Phone: +86 25 56623633
EMail: sunseawq@huawei.com
Liebsch, et al. Informational [Page 14]
</pre>
|
