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
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
|
Internet Engineering Task Force (IETF) S. Krishnan
Request for Comments: 6705 Ericsson
Category: Standards Track R. Koodli
ISSN: 2070-1721 Cisco Systems
P. Loureiro
NEC
Q. Wu
Huawei
A. Dutta
NIKSUN
September 2012
Localized Routing for Proxy Mobile IPv6
Abstract
Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
protocol that enables IP mobility for a host without requiring its
participation in any mobility-related signaling. PMIPv6 requires all
communications to go through the local mobility anchor. As this can
be suboptimal, Localized Routing (LR) allows Mobile Nodes (MNs)
attached to the same or different Mobile Access Gateways (MAGs) to
route traffic by using localized forwarding or a direct tunnel
between the gateways. This document proposes initiation,
utilization, and termination mechanisms for localized routing between
mobile access gateways within a proxy mobile IPv6 domain. It defines
two new signaling messages, Localized Routing Initiation (LRI) and
Local Routing Acknowledgment (LRA), that are used to realize this
mechanism.
Status of This Memo
This is an Internet Standards Track document.
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). Further
information on Internet Standards is available in Section 2 of
RFC 5741.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6705.
Krishnan, et al. Standards Track [Page 1]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. Initiation of Localized Routing .................................3
3.1. MAG Behavior ...............................................4
3.2. LMA Behavior ...............................................4
4. Teardown of Localized Routing ...................................4
5. Scenario A11: Two MNs Attached to the Same MAG and LMA ..........4
5.1. Handover Considerations ....................................6
6. Scenario A21: Two MNs Attached to Different MAGs but the
Same LMA ........................................................7
6.1. Handover Considerations ....................................9
6.2. Tunneling between the MAGs .................................9
7. Scenario A12: Two MNs Attached to the Same MAG with
Different LMAs .................................................10
7.1. Handover Considerations ...................................12
8. Scenario A22: Two MNs Attached to Different MAGs with
Different LMAs .................................................13
9. IPv4 Support in Localized Routing ..............................13
10. Message Formats ...............................................13
10.1. Localized Routing Initiation (LRI) .......................14
10.2. Localized Routing Acknowledgment (LRA) ...................15
11. New Mobility Option ...........................................16
11.1. MAG IPv6 Address .........................................16
12. Configuration Variables .......................................17
13. Security Considerations .......................................17
14. IANA Considerations ...........................................17
15. Contributors ..................................................18
16. Acknowledgments ...............................................18
17. References ....................................................19
17.1. Normative References .....................................19
17.2. Informative References ...................................19
Krishnan, et al. Standards Track [Page 2]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
1. Introduction
Proxy Mobile IPv6 [RFC5213] describes the protocol operations to
maintain reachability and session persistence for a Mobile Node (MN)
without the explicit participation from the MN in signaling
operations at the Internet Protocol (IP) layer. In order to
facilitate such network-based mobility, the PMIPv6 protocol defines a
Mobile Access Gateway (MAG), which acts as a proxy for the Mobile
IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA), which
acts similar to a Home Agent. The LMA and the MAG establish a
bidirectional tunnel for forwarding all data traffic belonging to the
Mobile Nodes. In the case where both endpoints are located in the
same PMIPv6 domain, this can be suboptimal and result in increased
delay and congestion in the network. Moreover, it increases
transport costs and traffic load at the LMA.
To overcome these issues, localized routing can be used to allow
nodes attached to the same or different MAGs to directly exchange
traffic by using localized forwarding or a direct tunnel between the
gateways. [RFC6279] defines the problem statement for PMIPv6
localized routing. This document describes a solution for PMIPv6
localized routing between two MNs in the same PMIPv6 domain. The
protocol specified here assumes that each MN is attached to a MAG and
that each MN's MAG has established a binding for the attached MN at
its selected LMA according to [RFC5213]. The protocol builds on the
scenarios defined in [RFC6279].
2. Conventions Used in This Document
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 [RFC2119].
This document also uses the terminology defined in Section 2 of
[RFC6279].
3. Initiation of Localized Routing
Since the traffic to be localized passes through both the LMA and the
MAGs, it is possible, at least in some scenarios, for either of them
to initiate Localized Routing (LR). In order to eliminate ambiguity,
the protocol described in this document selects the initiator of LR
based on the rules below.
Krishnan, et al. Standards Track [Page 3]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
3.1. MAG Behavior
The MAG MUST initiate LR if both of the communicating MNs are
attached to it and the MNs are anchored at different LMAs. The MAG
MUST NOT initiate LR in any other case.
3.2. LMA Behavior
The LMA MUST initiate LR if both of the communicating MNs are
anchored to it. The LMA MUST NOT initiate LR in any other case.
4. Teardown of Localized Routing
The use of localized routing is not persistent. Localized routing
has a defined lifetime as specified by the initiator; upon expiry,
the forwarding MUST revert to using bidirectional tunneling. When
localized routing ceases, the corresponding Localized Routing Entries
(LREs) MUST be removed.
If the initiator of LR wishes to terminate localized routing before
the expiry of the lifetime specified in the LRI message, it MUST do
so by sending a new LRI message with the lifetime set to zero.
5. Scenario A11: Two MNs Attached to the Same MAG and LMA
In this scenario, the two Mobile Nodes involved in communication are
attached to a single MAG and both are anchored at the same LMA as
shown in Figure 1.
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 1
Krishnan, et al. Standards Track [Page 4]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
The LMA initiates a localized routing session by detecting traffic
between two MNs attached to the same MAG. The exact traffic
identification mechanism is not specified in this document and is
left open for implementations and specific deployments. An example
trigger could be that an application-layer signaling entity detects
the possibility of localized routing and notifies the LMA about the
two endpoints, and the LMA determines that the two endpoints are
attached to the same MAG. Such a trigger mechanism offers localized
routing at the granularity of an individual application session,
providing flexibility in usage. It is also possible that one of the
mobility entities (LMA or MAG) could decide to initiate localized
routing based on configured policy. Please note that a MAG
implementing the protocol specified in this document will not
dynamically initiate LR in the same LMA case (i.e., by sending an
LRI), but can statically initiate LR based on the
EnableMAGLocalRouting configuration variable specified in [RFC5213].
+----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |LMA |
+----+ +----+ +----+ +----+
| | | |
| data | data |
|<--------------------->|<------------->|
| | | |
| | data | data |
| |<--------->|<------------->|
| | | LR decision
| | | LRI(Opt1) |
| | |<--------------|
| | | |
| | | LRA(Opt2) |
| | |-------------->|
| | | |
| data | |
|<--------------------->| |
| | | |
| | data | |
| |<--------->| |
| | | |
| | | |
Opt1: MN1-ID,MN1-HNP,MN2-ID,MN2-HNP
Opt2: U=0,MN1-ID,MN1-HNP,MN2-ID,MN2-HNP
where U is the flag defined in Section 10.2.
Figure 2
Krishnan, et al. Standards Track [Page 5]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
After detecting a possibility for localized routing, the LMA SHOULD
construct an LRI message that is used to signal the intent to
initiate localized routing and to convey parameters for the same.
This is a Mobility Header message and it MUST contain the MN-
Identifier (MN-ID) and the Home Network Prefix (HNP) (as Mobility
Header options) for each of the MNs involved. The LMA MUST then send
the LRI message to the MAG (MAG1) where the two MNs are attached.
The initiation of the LR procedure is shown in Figure 2.
The MAG (MAG1) MUST verify the attachment status of the two MNs
locally by checking the binding cache. The MAG MUST then verify if
the EnableMAGLocalRouting flag is set to 1. If it is not, the MAG
has not been configured to allow localized routing, and it MUST
reject the LRI and MUST send an LRA with Status code "Localized
Routing Not Allowed". Please note that this does not update behavior
specified in [RFC5213] but merely implements the LMA enforcement
specified in Section 6.10.3 of [RFC5213]. If the MAG is configured
to allow localized routing, it MUST then create LREs for each
direction of the communication between the two MNs. The exact form
of the forwarding entries is left for the implementations to decide;
however, they SHOULD contain the HNP corresponding to the destination
IP address and a next-hop identifier (e.g., the layer-2 address of
the next hop). These LREs MUST override the Binding Update List
(BUL) entries for the specific HNPs identified in the LRI message.
Hence, all traffic matching the HNPs is forwarded locally.
If the MAG is unable to deliver packets using the LREs, it is
possible that one of the MNs is no longer attached to the MAG.
Hence, the MAG MUST fall back to using the BUL entry, and the LMA
MUST forward the received packets using its Binding Cache Entry
(BCE).
After processing the LRI message, the MAG MUST respond with a Local
Routing Acknowledgment (LRA) message. This Mobility Header message
MUST also include the MN-ID and the HNP for each of the communicating
MNs, as well as an appropriate Status code indicating the outcome of
LRI processing. Status code 0 indicates localized routing was
successfully offered by the MAG. Any other value for Status code
indicates the reason for the failure to offer localized routing
service. When Status code is 0, the LMA sets a flag in the BCE
corresponding to the HNPs to record that localized routing is in
progress for that HNP.
5.1. Handover Considerations
If one of the MNs, say MN1, detaches from the MAG and attaches to
another MAG (say nMAG), the localized routing state needs to be
re-established. When the LMA receives the PBU from nMAG for MN1, it
Krishnan, et al. Standards Track [Page 6]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
will see that localized routing is active for MN1. The LMA MUST
hence initiate LR at nMAG and update the LR state of pMAG. After the
handover completes, LR will resemble Scenario A21. The pMAG MUST
follow the forwarding rules described in Section 6.10.5 of [RFC5213]
and decide that it will no longer perform LR for MN1.
6. Scenario A21: Two MNs Attached to Different MAGs but the Same LMA
The LMA may choose to support local forwarding to Mobile Nodes
attached to two different MAGs within a single PMIPv6 domain.
Internet
:
|
|
+-----+
| LMA |
+-----+
|
|
+----+-----+
| |
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 3
As earlier, the LMA initiates LR as a response to some trigger
mechanism. In this case, however, it MUST send two separate LRI
messages to the two MAGs. In addition to the MN-ID and the HNP
options, each LRI message MUST contain the IP address of the
counterpart MAG. When the MAG IP address option is present, each MAG
MUST create a local forwarding entry such that the packets for the MN
attached to the remote MAG are sent over a tunnel associated with
that remote MAG. The tunnel between the MAGs is assumed to be
established following the considerations mentioned in Section 6.2.
Krishnan, et al. Standards Track [Page 7]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG1| |MAG2| |LMA |
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data |
|<--------------------->|<----------------------->|
| | | | |
| | data | data |
| |<--------------------->|<----------->|
| | | | |
| | | | |
| | | LRI(Opt1) |
| | |<------------------------|
| | | | |
| | | | LRI(Opt2) |
| | | |<------------|
| | | | |
| | | LRA(Opt3) |
| | |------------------------>|
| | | | |
| | | | LRA(Opt4) |
| | | |------------>|
| | | | |
| | | | |
| | | | |
| data | data | |
|<--------------------->|<--------->| |
| | | | |
| | data | |
| |<--------------------->| |
| | | | |
| | | | |
Opt1: MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt2: MN2-ID,MN2-HNP,MAG1-IPv6-Address
Opt3: U=0,MN1-ID,MN1-HNP,MAG2-IPv6-Address
Opt4: U=0,MN2-ID,MN2-HNP,MAG1-IPv6-Address
where U is the flag defined in Section 10.2.
Figure 4
In this case, each MAG responds to the LRI with an LRA message. All
subsequent packets are routed between the MAGs locally, without
traversing the LMA. If one of the MAGs (say MAG1) responds with a
successful LRA (Status value is zero) and the other (say MAG2)
Krishnan, et al. Standards Track [Page 8]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
responds with an error (Status value is non-zero), LR will still be
performed in one direction (MN1->MAG1->MAG2->MN2), but the packets
flowing the other way will take the LMA path
(MN2->MAG2->LMA->MAG1->MN1).
The protocol does not require any synchronization between the MAGs
before local forwarding begins. Each MAG begins its local forwarding
independent of the other.
No synchronization between the MAGs is required because each MAG
initiates LR in one direction. After the LMA instructs MAG1 to
initiate LR, packets from MN1 to MN2 will take the path
MN1->MAG1->MAG2->MN2 while those from MN2 to MN1 will take the path
MN2->MAG2->LMA->MAG1->MN1 until the LMA instructs MAG2 to initiate LR
as well. A MAG will forward a packet towards either another MAG or
its own LMA; therefore, there would be no duplication of packets.
6.1. Handover Considerations
If one of the MNs, say MN1, detaches from its current MAG (in this
case MAG1) and attaches to another MAG (say nMAG1), the localized
routing state needs to be re-established. When the LMA receives the
PBU from nMAG1 for MN1, it will see that localized routing is active
for MN1. The LMA MUST then initiate LR at nMAG1 and update the LR
state of MAG2 to use nMAG1 instead of MAG1.
6.2. Tunneling between the MAGs
In order to support localized routing, both MAGs SHOULD support the
following encapsulation modes for the user packets, which are also
defined for the tunnel between the LMA and MAG:
o IPv4-or-IPv6-over-IPv6 [RFC5844]
o IPv4-or-IPv6-over-IPv4 [RFC5844]
o IPv4-or-IPv6-over-IPv4-UDP [RFC5844]
o TLV-header UDP tunneling [RFC5845]
o Generic Routing Encapsulation (GRE) tunneling with or without GRE
key(s) [RFC5845]
MAG1 and MAG2 MUST use the same tunneling mechanism for the data
traffic tunneled between them. The encapsulation mode to be employed
SHOULD be configurable. It is RECOMMENDED that:
Krishnan, et al. Standards Track [Page 9]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
1. As the default behavior, the inter-MAG tunnel uses the same
encapsulation mechanism as that being used for the PMIPv6 tunnel
between the LMA and the MAGs. MAG1 and MAG2 automatically start
using the same encapsulation mechanism without a need for a
special configuration on the MAGs or a dynamic tunneling
mechanism negotiation between them.
2. Configuration on the MAGs can override the default mechanism
specified in Option 1 above. MAG1 and MAG2 MUST be configured
with the same mechanism, and this configuration is most likely to
be uniform throughout the PMIPv6 domain. If the packets on the
PMIPv6 tunnel cannot be uniquely mapped onto the configured
inter-MAG tunnel, this scenario is not applicable, and Option 3
below SHOULD directly be applied.
3. An implicit or explicit tunnel negotiation mechanism between the
MAGs can override the default mechanism specified in Option 1
above. The employed tunnel negotiation mechanism is outside the
scope of this document.
7. Scenario A12: Two MNs Attached to the Same MAG with Different LMAs
In this scenario, both the MNs are attached to the same MAG, but are
anchored at two different LMAs. MN1 is anchored at LMA1, and MN2 is
anchored at LMA2. Note that the two LMAs are part of the same
Provider Domain.
Internet
: :
+------------------+
| |
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
| |
| |
+------------------+
|
|
|
+-----+
| MAG |
+-----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 5
Krishnan, et al. Standards Track [Page 10]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
Hence, neither LMA has a means to determine that the two Mobile Nodes
are attached to the same MAG. Only the MAG can possibly determine
that the two Mobile Nodes involved in communication are attached to
it. Therefore, localized routing MUST be initiated by the MAG.
The MAG sends an LRI message containing the MN-ID, HNP, and the
counterpart LMA address to each LMA. Each LMA makes a decision to
support local forwarding independently based on configured policy for
the corresponding LMA. Each LMA MUST respond to the LRI message with
an LRA message. If the initiation of LR on the LMA was successful,
the Status value in the received LRA would be set to zero. After the
MAG receives both the LRA messages, each with the Status value set to
zero (success) from the two different LMAs, the MAG will conclude
that it can provide local forwarding support for the two Mobile
Nodes.
Krishnan, et al. Standards Track [Page 11]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
+----+ +----+ +----+ +----+ +----+
|MN1 | |MN2 | |MAG | |LMA1| |LMA2|
+----+ +----+ +----+ +----+ +----+
| | | | |
| data | data | data |
|<--------------------->|<--------->|<----------->|
| | | | |
| | data | data |
| |<--------->|<----------------------->|
| | | | |
| | | | |
| | | LRI(Opt1) | |
| | |---------->| |
| | | | |
| | | LRI(Opt2) |
| | |------------------------>|
| | | | |
| | | LRA(Opt3) | |
| | |<----------| |
| | | | |
| | | LRA(Opt4) |
| | |<------------------------|
| | | | |
| | | | |
| | | | |
| data | | |
|<--------------------->| | |
| | | | |
| | data | | |
| |<--------->| | |
| | | | |
| | | | |
Opt1: MN1-ID,MN1-HNP
Opt2: MN2-ID,MN2-HNP
Opt3: U=0,MN1-ID,MN1-HNP
Opt4: U=0,MN2-ID,MN2-HNP
where U is the flag defined in Section 10.2.
Figure 6
7.1. Handover Considerations
If one of the MNs, say MN1, detaches from its current MAG (in this
case MAG1) and attaches to another MAG (say nMAG1), the current MAG
MUST immediately stop using the LRE and MUST send all packets
originated by the other MN (MN2) towards its LMA (in this case LMA2).
Krishnan, et al. Standards Track [Page 12]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
8. Scenario A22: Two MNs Attached to Different MAGs with Different LMAs
This scenario will not be covered in this document since PMIPv6 does
not define any form of inter-LMA communication. When a supported
scenario, such as Scenario A12, morphs into Scenario A22, the node
that initiated the localized routing session MUST tear it down in
order to prevent lasting packet loss. This can result in transient
packet loss when routing switches between the localized path into the
normal path through the LMAs. In applications that are loss
sensitive, this can lead to observable service disruptions. In
deployments where Scenario A22 is possible, the use of localized
routing is NOT RECOMMENDED when packet-loss-sensitive applications
are in use.
9. IPv4 Support in Localized Routing
PMIPv6 MNs can use an IPv4 Home Address (HoA) as described in
[RFC5844]. In order to support the setup and maintenance of
localized routes for these IPv4 HoAs in PMIPv6, the MAGs MUST add the
IPv4 HoAs into their LREs. The MAGs MUST also support encapsulation
of IPv4 packets as described in [RFC5844]. The localized routing
protocol messages MUST include an IPv4 HoA option in their signaling
messages in order to support IPv4 addresses for localized routing.
If the transport network between the PMIPv6 entities involved in
localized routing is IPv4-only, the LRI and LRA messages MUST be
encapsulated similar to the PBU/PBA messages as specified in
[RFC5844]. The encapsulation mode used SHOULD be identical to the
one used to transport PBU and PBA messages.
10. Message Formats
The localized routing messages use two new Mobility Header types (17
and 18). The LRI message requests creation or deletion of the
localized routing state, and the LRA message acknowledges the
creation or deletion of such localized routing state.
Krishnan, et al. Standards Track [Page 13]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
10.1. Localized Routing Initiation (LRI)
The LRI messages use a new Mobility Header type (17). The LMA sends
an LRI message to a MAG to request local forwarding for a pair of
MNs. The MAG may also send this message to request the two LMAs for
offering local forwarding as described in Section 7.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number: A monotonically increasing integer. Set by a
sending node in a request message and used to match a reply to the
request.
Reserved: This field is unused and MUST be set to zero.
Lifetime: The requested time, in seconds, for which the sender
wishes to have local forwarding. A value of 0xffff (all ones)
indicates an infinite lifetime. When set to 0, indicates a
request to stop localized routing.
Mobility Options: MUST contain two separate MN-ID options,
followed by one or more HNPs for each of the MNs. For instance,
for Mobile Nodes MN1 and MN2 with identifiers MN1-ID and MN2-ID,
and Home Network Prefixes MN1-HNP and MN2-HNP, the following tuple
MUST be present in the following order: [MN1-ID, MN1-HNP],
[MN2-ID, MN2-HNP]. The MN-ID and HNP options are the same as in
[RFC5213]. The LRI MAY contain the remote MAG IPv6 address
option, which is formatted identically to the HNP option, except
that it uses a different Type code and the Prefix Length is always
equal to 128 bits (see Section 10.1).
The LRI message SHOULD be re-transmitted if a corresponding LRA
message is not received within LRA_WAIT_TIME time units, up to a
maximum of LRI_RETRIES, each separated by LRA_WAIT_TIME time units.
Krishnan, et al. Standards Track [Page 14]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
10.2. Localized Routing Acknowledgment (LRA)
The LRA messages use a new Mobility Header type (18). A MAG sends an
LRA message to the LMA as a response to the LRI message. An LMA may
also send this message to a MAG as a response to the LRI message as
described in Section 7.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number: Copied from the sequence number field of the LRI
message being responded to.
'U' flag: When set to 1, the LRA message is sent unsolicited.
The Lifetime field indicates a new requested value. The MAG MUST
wait for the regular LRI message to confirm that the request is
acceptable to the LMA.
Reserved: This field is unused and MUST be set zero.
Status: 8-bit unsigned integer indicating the result of
processing the Localized Routing Acknowledgment message. Values
of the Status field less than 128 indicate that the Localized
Routing Acknowledgment was processed successfully by the mobility
entities(LMA or MAG). Values greater than or equal to 128
indicate that the Localized Routing Acknowledgment was rejected
by the mobility entities. The following Status values are
currently defined:
0: Success
128: Localized Routing Not Allowed
129: MN Not Attached
Lifetime: The time, in seconds, for which local forwarding is
supported. It is typically copied from the corresponding field
in the LRI message.
Krishnan, et al. Standards Track [Page 15]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
Mobility Options: When Status code is 0, MUST contain the
[MN-ID, HNP] tuples in the same order as in the LRI message.
When Status code is not 0, MUST contain only those [MN-ID, HNP]
tuples for which local forwarding is supported. The MN-ID and
HNP options are the same as those described in [RFC5213].
11. New Mobility Option
11.1. MAG IPv6 Address
The MAG IPv6 address mobility option contains the IPv6 address of a
MAG involved in localized routing. The MAG IPv6 address option has
an alignment requirement of 8n+4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MAG IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
51
Length
8-bit unsigned integer indicating the length of the option
in octets, excluding the type and length fields. This field
MUST be set to 18.
Reserved (R)
This 8-bit field is unused. The value MUST be initialized
to 0 by the sender and MUST be ignored by the receiver.
Address Length
This field MUST be set to 128.
Krishnan, et al. Standards Track [Page 16]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
MAG IPv6 Address
A 16-byte field containing the MAG's IPv6 address.
12. Configuration Variables
The LMA and the MAG must allow the following variables to be
configurable:
LRA_WAIT_TIME: This variable is used to set the time interval, in
seconds, between successive retransmissions of an LRI message.
The default value is 3 seconds.
LRI_RETRIES: This variable indicates the maximum number of times the
initiator retransmits an LRI message before stopping. The default
value for this variable is 3.
13. Security Considerations
The protocol inherits the threats to [RFC5213] that are identified in
[RFC4832]. The protocol specified in this document uses the same
security association as defined in [RFC5213] for use between the LMA
and the MAG to protect the LRI and LRA messages. This document also
assumes the preexistence of a MAG-MAG security association if LR
needs to be supported between them. Support for integrity protection
using IPsec is REQUIRED, but support for confidentiality is OPTIONAL.
The MAGs MUST perform ingress filtering on the MN-sourced packets
before encapsulating them into MAG-MAG tunnels in order to prevent
address spoofing.
14. IANA Considerations
The Localized Routing Initiation (described in Section 10.1) and the
Localized Routing Acknowledgment (described in Section 10.2) have
each been assigned a Mobility Header type (17 and 18, respectively)
from the "Mobility Header Types - for the MH Type field in the
Mobility Header" registry at
http://www.iana.org/assignments/mobility-parameters.
The MAG IPv6 Address has been assigned a Mobility Option type (51)
from the "Mobility Options" registry at
http://www.iana.org/assignments/mobility-parameters.
Krishnan, et al. Standards Track [Page 17]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
15. Contributors
This document merges ideas from five different draft documents
addressing the PMIP localized routing problem. The authors of these
drafts are listed below (in alphabetical order).
Kuntal Chowdhury <kchowdhury@starentnetworks.com>
Ashutosh Dutta <adutta@niksun.com>
Rajeev Koodli <rkoodli@starentnetworks.com>
Suresh Krishnan <suresh.krishnan@ericsson.com>
Marco Liebsch <marco.liebsch@nw.neclab.eu>
Paulo Loureiro <loureiro@neclab.eu>
Desire Oulai <desire.oulai@videotron.com>
Behcet Sarikaya <sarikaya@ieee.org>
Qin Wu <sunseawq@huawei.com>
Hidetoshi Yokota <yokota@kddilabs.jp>
16. Acknowledgments
The authors would like to thank Sri Gundavelli, Julien Abeille, Tom
Taylor, Kent Leung, Mohana Jeyatharan, Jouni Korhonen, Glen Zorn,
Ahmad Muhanna, Zoltan Turanyi, Dirk von Hugo, Pete McCann, Xiansong
Cui, Carlos Bernardos, Basavaraj Patil, Jari Arkko, Mary Barnes, Les
Ginsberg, Russ Housley, Carl Wallace, Ralph Droms, Adrian Farrel, and
Stephen Farrell for their comments and suggestions.
Krishnan, et al. Standards Track [Page 18]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
17. References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC
5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, June 2010.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.
17.2. Informative References
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based
Localized Mobility Management (NETLMM)", RFC 4832, April
2007.
[RFC6279] Liebsch, M., Ed., Jeong, S., and Q. Wu, "Proxy Mobile IPv6
(PMIPv6) Localized Routing Problem Statement", RFC 6279,
June 2011.
Krishnan, et al. Standards Track [Page 19]
^L
RFC 6705 PMIPv6 Localized Routing September 2012
Authors' Addresses
Suresh Krishnan
Ericsson
8400 Blvd Decarie
Town of Mount Royal, Quebec
Canada
Phone: +1 514 345 7900 x42871
EMail: suresh.krishnan@ericsson.com
Rajeev Koodli
Cisco Systems
EMail: rkoodli@cisco.com
Paulo Loureiro
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg
Germany
EMail: loureiro@neclab.eu
Qin Wu
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 21001
China
Phone: +86-25-56623633
EMail: sunseawq@huawei.com
Ashutosh Dutta
NIKSUN
EMail: adutta@niksun.com
Krishnan, et al. Standards Track [Page 20]
^L
|
