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
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
|
<pre>Internet Engineering Task Force (IETF) A. Muhanna
Request for Comments: 5845 M. Khalil
Category: Standards Track Ericsson
ISSN: 2070-1721 S. Gundavelli
K. Leung
Cisco
June 2010
<span class="h1">Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6</span>
Abstract
This specification defines a new mobility option for allowing the
mobile access gateway and the local mobility anchor to negotiate
Generic Routing Encapsulation (GRE) encapsulation mode and exchange
the downlink and uplink GRE keys that are used for marking the
downlink and uplink traffic that belong to a specific mobility
session. In addition, the same mobility option can be used to
negotiate the GRE encapsulation mode without exchanging the GRE keys.
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 <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/rfc5845">http://www.rfc-editor.org/info/rfc5845</a>.
Copyright Notice
Copyright (c) 2010 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
<span class="grey">Muhanna, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
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-3">3</a>
<a href="#section-2">2</a>. Conventions and Terminology . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Conventions . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.2">2.2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. GRE Encapsulation and Key Exchange . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. GRE Encapsulation Overview . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. GRE Encapsulation Mode Only . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. GRE Encapsulation and Key Exchange . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3.1">3.3.1</a>. Initial GRE Key Exchange . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3.2">3.3.2</a>. GRE Key Exchange during Binding Re-Registration . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. Mobile Access Gateway Considerations . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.1">4.1</a>. Extensions to the Conceptual Data Structure . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. Operational Summary . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. Local Mobility Anchor Considerations . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Extensions to the Binding Cache Entry . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.2">5.2</a>. Operational Summary . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6">6</a>. Message Formats . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.1">6.1</a>. GRE Key Option . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.2">6.2</a>. Proxy Binding Update Message Extension . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6.3">6.3</a>. Proxy Binding Acknowledgement Message Extension . . . . . <a href="#page-14">14</a>
<a href="#section-6.4">6.4</a>. Status Codes . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. Data Packets Processing Considerations . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-7.1">7.1</a>. Tunneling Format . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-7.2">7.2</a>. TLV-Header Tunneling Negotiation . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-7.3">7.3</a>. Mobile Access Gateway Operation . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7.3.1">7.3.1</a>. Sending and Receiving Data Packets . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-7.4">7.4</a>. Local Mobility Anchor Operation . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-7.4.1">7.4.1</a>. Sending and Receiving Data Packets . . . . . . . . . . <a href="#page-20">20</a>
<a href="#section-8">8</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-10">10</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
<span class="grey">Muhanna, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Proxy Mobile IPv6 specification [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] and IPv4 Support for
Proxy Mobile IPv6 [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>] allow the use of IPv6 and IPv4
encapsulation modes as specified in [<a href="./rfc2473" title=""Generic Packet Tunneling in IPv6 Specification"">RFC2473</a>] and [<a href="./rfc2003" title=""IP Encapsulation within IP"">RFC2003</a>] for the
tunneled traffic between the local mobility anchor (LMA) and the
mobile access gateway (MAG). There are scenarios where these
encapsulation modes are not sufficient to uniquely identify the
destination of packets of a specific mobility session. Thus, there
is a need for an encapsulation mode with richer semantics. The
Generic Routing Encapsulation (GRE) [<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>], and the Key extension
as defined in [<a href="./rfc2890" title=""Key and Sequence Number Extensions to GRE"">RFC2890</a>], has the required semantics to allow such a
distinction for use in Proxy Mobile IPv6.
This specification defines the GRE Key option to be used for the
negotiation of GRE encapsulation mode and exchange of the uplink and
downlink GRE keys. The negotiated downlink and uplink GRE keys can
be used for marking the downlink and uplink traffic for a specific
mobility session. In addition, this specification enables the mobile
access gateway and the local mobility anchor to negotiate the use of
GRE encapsulation mode without exchanging the GRE keys.
This specification has no impact on IPv4 or IPv6 mobile nodes.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions and Terminology</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Conventions</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
specification are to be interpreted as described in <a href="./rfc2119">RFC 2119</a>
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Terminology</span>
All the general mobility-related terminology and abbreviations are to
be interpreted as defined in the Mobile IPv6 [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>], Proxy Mobile
IPv6 [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], and IPv4 Support for Proxy Mobile IPv6 [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]
specifications. The following terms are used in this specification.
Downlink Traffic
The traffic in the tunnel between the local mobility anchor and
the mobile access gateway, heading towards the mobile access
gateway and tunneled at the local mobility anchor. This traffic
is also called forward direction traffic.
<span class="grey">Muhanna, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
Uplink Traffic
The traffic in the tunnel between the mobile access gateway and
the local mobility anchor, heading towards the local mobility
anchor and tunneled at the mobile access gateway. This traffic is
also called reverse direction traffic.
Downlink GRE Key
The GRE key is assigned by the mobile access gateway and used by
the local mobility anchor to mark the downlink traffic that
belongs to a specific mobility session as described in this
specification.
Uplink GRE Key
The GRE key is assigned by the local mobility anchor and used by
the mobile access gateway to mark the uplink traffic that belongs
to a specific mobility session as described in this specification.
A Policy Check
When a local mobility anchor receives an initial, handoff-
triggered Binding Lifetime Extension, or Binding Lifetime
Extension Proxy Binding Update for a mobility session, the local
mobility anchor determines if the GRE encapsulation mode only or
GRE encapsulation and GRE keys are required based on a policy
check. This policy could be a per-MAG-LMA pair, a per-LMA local
policy, a per-MN policy, or the combination of any of them.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. GRE Encapsulation and Key Exchange</span>
This section describes how GRE encapsulation mode is negotiated and
the GRE keys are dynamically exchanged using Proxy Mobile IPv6
protocol [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] signaling.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. GRE Encapsulation Overview</span>
Using the GRE Key option defined in this specification, the mobile
access gateway and the local mobility anchor can negotiate GRE
encapsulation mode only or GRE encapsulation mode and exchange the
GRE keys for marking the downlink and uplink traffic. In the case
when GRE encapsulation mode only is negotiated between the mobile
access gateway and the local mobility anchor, then no GRE keys are
used.
<span class="grey">Muhanna, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
However, once the GRE keys have been exchanged between the mobile
access gateway and the local mobility anchor as per this
specification, the mobile access gateway will use the uplink GRE key
that is assigned by the local mobility anchor in the GRE header of
the uplink payload packet. Similarly, the local mobility anchor will
use the downlink GRE key as negotiated with the mobile access gateway
in the GRE header of the downlink payload packet.
The following illustration explains the use of GRE encapsulation mode
and the GRE keys for supporting the usecase where overlapping IPv4
private address [<a href="./rfc1918" title=""Address Allocation for Private Internets"">RFC1918</a>] allocation is in use.
+------------+
| Operator-A |
| |
| 10.x.0.0/16|
+------------+
/
+------+ +------+ /
| | ========================== | | /
MN-1---| | / \ | | / Key-1
| M | / ---Flows with GRE Key-1 ---- \ | L | / Traffic
MN-2---| A |--| |--| M |-
| G | \ ---Flows with GRE Key-2 ---- / | A | \ Key-2
MN-3---| | \ / | | \Traffic
| | ========================== | | \
MN-4---| | Proxy Mobile IPv6 Tunnel | | \
+------+ +------+ \
\
Operator-C: Access Network +------------+
| Operator-B |
| |
| 10.x.0.0/16|
+------------+
Figure 1: GRE Tunneling for IPv4 Private Address Space Overlapping
Figure 1 illustrates a local mobility anchor providing mobility
service to mobile nodes that are from different operators and are
assigned IPv4 addresses from overlapping private address space. In
this scenario, the mobile access gateway and the local mobility
anchor must be able to distinguish flows belonging to different
operators.
The mobile nodes MN-1 and MN-2 are visiting from Operator-A, and the
mobile nodes MN-3 and MN-4 are visiting from Operator-B. The mobile
access gateway and the local mobility anchor exchange a specific pair
<span class="grey">Muhanna, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
of downlink and uplink GRE keys and save them as part of the mobile
node's binding to be used for identifying the flows belonging to each
mobile node.
The LMA and the MAG will be able to distinguish each mobile node
flow(s) based on the GRE key present in the GRE header of the
tunneled payload packet, and route them accordingly. However, the
GRE keys, as in this specification, apply to the individual mobility
binding updated by the Proxy Binding Update but not to all bindings
that the mobile may have registered following procedures described in
[<a href="./rfc5648" title=""Multiple Care-of Addresses Registration"">RFC5648</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. GRE Encapsulation Mode Only</span>
In order for the mobile access gateway to request GRE encapsulation
mode only without exchanging the GRE keys, the mobile access gateway
MUST include the GRE Key option but omit the GRE Key Identifier field
in the Proxy Binding Update.
If the local mobility anchor supports GRE encapsulation and the
received Proxy Binding Update contains the GRE Key option but the GRE
Key Identifier field is omitted, the mobile access gateway is
requesting GRE encapsulation without exchanging the GRE keys
dynamically. If the Proxy Binding Update processing is successful,
the local mobility anchor sends a successful Proxy Binding
Acknowledgement message with the GRE Key option but the GRE Key
Identifier field is omitted.
When the mobile access gateway and the local mobility anchor
successfully negotiate the GRE encapsulation mode only, then no GRE
keys are used.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. GRE Encapsulation and Key Exchange</span>
The following subsections describe how the mobile access gateway and
the local mobility anchor negotiate GRE encapsulation and exchange
downlink and uplink GRE keys using the Proxy Mobile IPv6 registration
procedure.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Initial GRE Key Exchange</span>
When the mobile access gateway determines, based on, e.g., private
IPv4 address support [<a href="./rfc1918" title=""Address Allocation for Private Internets"">RFC1918</a>], the mobile access gateway local
policy, or the MAG-LMA peer agreement, that GRE encapsulation is
needed and GRE keys are required, the mobile access gateway MUST
include the GRE Key option in the initial Proxy Binding Update
<span class="grey">Muhanna, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
message sent to the local mobility anchor. The mobile access gateway
MUST include the downlink GRE key in the GRE Key Identifier field of
the GRE Key option.
After the local mobility anchor successfully processes the initial
Proxy Binding Update and accepts the GRE encapsulation request and
the downlink GRE key based on a policy check, the local mobility
anchor MUST include the GRE Key option with the uplink GRE key in the
GRE Key Identifier field in a successful Proxy Binding
Acknowledgement and send it to the mobile access gateway.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. GRE Key Exchange during Binding Re-Registration</span>
If the local mobility anchor has successfully negotiated and
exchanged the initial GRE keys with the mobile access gateway for a
specific mobile node's mobility session, the local mobility anchor
MUST maintain the same negotiated uplink GRE key for the lifetime of
that mobility session. However, for administrative reasons, e.g.,
local mobility anchor reboot, the local mobility anchor MAY change
the uplink GRE key for the mobility session. In that case, some
packet loss may be experienced.
If the mobile access gateway has successfully negotiated and
exchanged the initial GRE keys with the local mobility anchor for a
specific mobile node's mobility session, the mobile access gateway
MUST include the GRE Key option with the downlink GRE key in the
Proxy Binding Update that is used to request a Binding Lifetime
Extension. In this case, if the local mobility anchor successfully
processes the Proxy Binding Update message, the local mobility anchor
MUST return the same uplink GRE key that was exchanged with the
mobile access gateway in the last successful Proxy Binding Update for
the same mobility session in the GRE Key option in a successful Proxy
Binding Acknowledgement message.
However, during inter-MAG handoff and if the new mobile access
gateway determines, based on, e.g., private IPv4 address support, the
mobile access gateway local policy, the MAG-LMA peer agreement, or an
indication during the handoff process, that GRE encapsulation and GRE
keys exchange are required, the new mobile access gateway MUST
include the GRE Key option with the downlink GRE key in the Proxy
Binding Update that is used to request an after-handoff Binding
Lifetime Extension. In this case, the new mobile access gateway may
either pick a new downlink GRE key or use the downlink GRE key that
was used by the previous mobile access gateway for the same binding.
For the new mobile access gateway to know the downlink GRE key used
by the previous mobile access gateway, it may require transfer of
<span class="grey">Muhanna, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
context from the previous mobile access gateway to the new mobile
access gateway during a handoff. Such mechanisms are out of scope
for this specification.
If the local mobility anchor successfully processes a handoff-
triggered Binding Lifetime Extension Proxy Binding Update message
that contains a GRE Key option with a downlink GRE key included, the
local mobility anchor MUST return the same uplink GRE key that was
exchanged with the previous mobile access gateway for the same
mobility session in the GRE Key option in a successful Proxy Binding
Acknowledgement.
If the local mobility anchor receives a handoff-triggered Binding
Lifetime Extension Proxy Binding Update message without the GRE Key
option for a Binding Cache entry (BCE) that is using GRE keys and GRE
encapsulation, the local mobility anchor makes a policy check
regarding GRE encapsulation and GRE key exchange. If, according to
the policy check, GRE encapsulation and GRE key exchange are
required, the local mobility anchor MUST reject the Proxy Binding
Update by sending a Proxy Binding Acknowledgement message with the
Status field set to GRE_KEY_OPTION_REQUIRED as defined in
<a href="#section-6.4">Section 6.4</a>. Otherwise, the local mobility anchor SHOULD accept the
Proxy Binding Update, and if it is processed successfully, the local
mobility anchor MUST return a successful Proxy Binding
Acknowledgement without including the GRE Key option.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Mobile Access Gateway Considerations</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Extensions to the Conceptual Data Structure</span>
Every mobile access gateway maintains a Binding Update List (BUL)
entry for each currently attached mobile node, as explained in
<a href="#section-6.1">Section 6.1</a> of the Proxy Mobile IPv6 specification [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>]. To
support this specification, the conceptual Binding Update List entry
data structure must be extended with the following four new
additional fields.
o A flag (GRE-encapsulation-enabled) is used for indicating whether
GRE encapsulation is enabled for the mobile node's traffic.
o The downlink GRE key used in the GRE encapsulation header of the
tunneled payload packet from the local mobility anchor to the
mobile access gateway that is destined to the mobile node. This
GRE key is generated by the mobile access gateway and communicated
to the local mobility anchor in the GRE Key option in the Proxy
Binding Update message.
<span class="grey">Muhanna, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
o The uplink GRE key used in the GRE encapsulation header of the
tunneled payload packet from the mobile access gateway to the
local mobility anchor that is originating from the mobile node.
This GRE key is obtained from the GRE Key Identifier field of the
GRE Key option present in the received Proxy Binding
Acknowledgement message sent by the local mobility anchor as
specified in this document.
o A flag indicating whether UDP-based TLV-header format
(<a href="#section-7.2">Section 7.2</a>) is enabled for the mobile node's traffic. This flag
is TRUE only when UDP tunneling as in [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>] and GRE
encapsulation as in this specification are both enabled for this
mobility session.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Operational Summary</span>
o If the mobile access gateway determines that GRE encapsulation
mode only is required, the mobile access gateway MUST include the
GRE Key option but omit the GRE Key Identifier field in the Proxy
Binding Update message that is sent to the local mobility anchor.
o If the mobile access gateway determines that GRE encapsulation and
GRE keys are required, the mobile access gateway MUST include the
GRE Key option with the downlink GRE key in the GRE Key Identifier
field in the Proxy Binding Update message that is sent to the
local mobility anchor.
o After receiving a successful Proxy Binding Acknowledgement message
with the GRE Key option with the GRE Key Identifier field omitted,
the mobile access gateway MUST update the mobile node's Binding
Update List entry described in <a href="#section-4.1">Section 4.1</a> by only setting the
GRE-encapsulation-enabled flag.
o After receiving a successful Proxy Binding Acknowledgement message
with the GRE Key option and the uplink GRE key included in the GRE
Key Identifier field, the mobile access gateway MUST update the
related fields in the mobile node's Binding Update List entry
described in <a href="#section-4.1">Section 4.1</a>. Additionally, the mobile access gateway
MUST use the assigned uplink GRE Key for tunneling all the traffic
that belongs to this mobile node BUL entry and that originated
from the mobile node before forwarding the tunneled traffic to the
local mobility anchor.
o If the mobile access gateway includes the GRE Key option in the
Proxy Binding Update for a specific mobile node and the local
mobility anchor accepts the Proxy Binding Update by sending a
Proxy Binding Acknowledgement with a success status code (less
than 128) other than GRE_KEY_OPTION_NOT_REQUIRED, but without the
<span class="grey">Muhanna, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
GRE Key option, then the mobile access gateway MUST consider that
the local mobility anchor does not support the GRE Key option as
per this specification. The mobile access gateway SHOULD NOT
include the GRE Key option in any subsequent Proxy Binding Update
message that is sent to that local mobility anchor.
o If the mobile access gateway sent a Proxy Binding Update message
without the GRE Key option, but the received Proxy Binding
Acknowledgement has the status code GRE_KEY_OPTION_REQUIRED,
indicating that GRE encapsulation and GRE keys are required, the
mobile access gateway SHOULD resend the Proxy Binding Update
message with the GRE Key option. If the mobile access gateway
does not support the GRE Key option, it MAY log the event and
possibly raise an alarm to indicate a possible misconfiguration.
o If the mobile access gateway sent a Proxy Binding Update message
with the GRE Key option and the downlink GRE key included and
received a successful Proxy Binding Acknowledgement message with
the status code GRE_KEY_OPTION_NOT_REQUIRED, the mobile access
gateway MUST consider that GRE encapsulation and GRE keys are not
required for this specific mobility session. The mobile access
gateway follows procedures in the Proxy Mobile IPv6 specification
[<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] for the handling of uplink and downlink traffic and MUST
NOT include the GRE Key option in any subsequent Proxy Binding
Update message that is sent to the local mobility anchor for this
mobility session.
o If the mobile access gateway has successfully negotiated GRE
encapsulation and exchanged the GRE keys with the local mobility
anchor for a specific mobility session, the mobile access gateway
SHOULD NOT include the GRE Key option in the de-registration Proxy
Binding Update.
o On receiving a packet from the tunnel with the GRE header, the
mobile access gateway MUST use the GRE key present in the GRE
extension header as an additional identifier to determine to which
mobility session this packet belongs. The GRE header is removed
before further processing takes place.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Local Mobility Anchor Considerations</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Extensions to the Binding Cache Entry</span>
When the local mobility anchor and the mobile access gateway
successfully negotiate GRE encapsulation and exchange downlink and
uplink GRE keys, the local mobility anchor MUST maintain the downlink
and uplink GRE keys as part of the mobile node's BCE. This requires
the BCE described in <a href="#section-5.1">Section 5.1</a> of the Proxy Mobile IPv6
<span class="grey">Muhanna, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
specification [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] to be extended. To support this
specification, the BCE must be extended with the following four
additional fields.
o A flag indicating whether GRE encapsulation is enabled for the
mobile node's traffic flows.
o The downlink GRE key, assigned by the mobile access gateway and
used in the GRE encapsulation header of the tunneled payload
packet from the local mobility anchor to the mobile access
gateway.
o The uplink GRE key, assigned by the local mobility anchor and used
in the GRE encapsulation header of the tunneled payload packet
from the mobile access gateway to the local mobility anchor.
o A flag indicating whether UDP-based TLV-header format
(<a href="#section-7.2">Section 7.2</a>) is enabled for the mobile node's traffic. This flag
is TRUE only when UDP tunneling as in [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>] and GRE
encapsulation as in this specification are both enabled for this
mobility session.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Operational Summary</span>
o If the local mobility anchor successfully processes a Proxy
Binding Update message with the GRE Key option, but the GRE Key
Identifier field is omitted for initial GRE key exchange, the
local mobility anchor MUST include the GRE Key option but omit the
GRE Key Identifier field when responding with a successful Proxy
Binding Acknowledgement message.
o If the local mobility anchor successfully processes a Proxy
Binding Update message with the GRE Key option and the downlink
GRE key included in the GRE Key Identifier field for initial GRE
key exchange as in <a href="#section-3.3.1">Section 3.3.1</a>, the local mobility anchor MUST
include the GRE Key option with the uplink GRE key included in the
GRE Key Identifier field when responding with a successful Proxy
Binding Acknowledgement message.
o If the GRE tunneling is negotiated and the downlink and uplink GRE
keys have been exchanged between the mobile access gateway and the
local mobility anchor for a specific mobility session, the local
mobility anchor MUST use the negotiated downlink GRE key in the
GRE header of every packet that is destined to the mobile node of
this specific mobility session over the GRE tunnel to the mobile
access gateway.
<span class="grey">Muhanna, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
o If the received Proxy Binding Update message does not contain the
GRE Key option, and if the local mobility anchor based on a policy
check determines that GRE encapsulation and GRE keys are required,
e.g., overlapping IPv4 private addressing is in use, a local
mobility anchor local policy, or LMA-MAG peer agreement, the local
mobility anchor MUST reject the request and send a Proxy Binding
Acknowledgement message to the mobile access gateway with the
status code GRE_KEY_OPTION_REQUIRED as defined in <a href="#section-6.4">Section 6.4</a>.
This indicates that GRE encapsulation and GRE keys are required.
o If, after receiving and successfully processing a Proxy Binding
Update message with the GRE Key option, the local mobility anchor
determines, based on a policy check, that GRE encapsulation and
GRE keys are not required for this specific binding, e.g., private
IPv4 addressing is not in use, the local mobility anchor SHOULD
send a successful Proxy Binding Acknowledgement message to the
mobile access gateway with the status code
GRE_KEY_OPTION_NOT_REQUIRED. In this case, the local mobility
anchor MUST NOT include the GRE Key option in the Proxy Binding
Acknowledgement.
o If the local mobility anchor successfully processes a de-
registration Proxy Binding Update message, the local mobility
anchor follows the same de-registration process as described in
the Proxy Mobile IPv6 specification [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] to clean the Binding
Cache entry and all associated resources including the downlink
and uplink GRE keys.
o On receiving a packet from the tunnel with the GRE header, the
local mobility anchor MUST use the GRE key in the GRE extension
header as an additional identifier to determine to which mobility
session this packet belongs. The GRE header is removed before
further processing takes place.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Message Formats</span>
This section defines an extension to the Mobile IPv6 protocol
[<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>] messages. The use of the GRE Key option for supporting GRE
tunneling and GRE key exchange for Proxy Mobile IPv6 is defined in
this specification.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. GRE Key Option</span>
A new mobility option, the GRE Key option, is defined for use in the
Proxy Binding Update and Proxy Binding Acknowledgement messages
exchanged between the mobile access gateway and the local mobility
anchor. This option can be used for negotiating GRE encapsulation
mode only or GRE encapsulation and exchanging the downlink and uplink
<span class="grey">Muhanna, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
GRE keys. These GRE keys can be used by the peers in all GRE
encapsulated payload packets for marking that specific mobile node's
data traffic.
The alignment requirement for this option is 4n.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GRE Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GRE Key Option
Type
33
Length
An 8-bit unsigned integer indicating the length in octets of the
option, excluding the Type and Length fields. If the Length field
is set to 2, it indicates that the GRE Key Identifier field is not
being carried in the option. If the Length field is set to a
value of 6, it means that either the downlink or the uplink GRE
key is carried.
Reserved
These fields are unused. They MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
GRE Key Identifier
A 32-bit field containing the downlink or the uplink GRE key.
This field is present in the GRE Key option only if the GRE keys
are being exchanged using the Proxy Binding Update and Proxy
Binding Acknowledgement messages.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Proxy Binding Update Message Extension</span>
This specification extends the Proxy Binding Update message as
defined in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] with the new TLV-header format (T) flag. The
new (T) flag is described below and shown as part of the Proxy
Binding Update message as in Figure 3.
<span class="grey">Muhanna, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|F|T| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Proxy Binding Update Message
TLV-header format (T)
When set, this flag indicates that the mobile access gateway
requests the use of the TLV header for encapsulating IPv6 or IPv4
packets in IPv4. The TLV-header format is described in
<a href="#section-7.2">Section 7.2</a>. None of the other fields or flags in the Proxy
Binding Update are modified by this specification.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Proxy Binding Acknowledgement Message Extension</span>
This specification extends the Proxy Binding Acknowledgement message
as defined in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] with the new TLV-header format (T) flag. The
new (T) flag is described below and shown as part of the Proxy
Binding Acknowledgement message as in Figure 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|T| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Proxy Binding Acknowledgement Message
TLV-header format (T)
When set, this flag indicates that the sender of the Proxy Binding
Acknowledgement, the LMA, supports tunneling IPv6-or-IPv4 in IPv4
using TLV-header format. None of the other fields or flags in the
Proxy Binding Acknowledgement are modified by this specification.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. Status Codes</span>
The following status code values are defined for use in the Binding
Acknowledgement message when using Proxy Mobile IPv6.
<span class="grey">Muhanna, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
GRE_KEY_OPTION_NOT_REQUIRED (2)
When the local mobility anchor receives a Proxy Binding Update
with the GRE Key option, and based on a policy check it determines
that GRE encapsulation is not required for this specific mobility
session, it uses this code to indicate to the mobile access
gateway that the Proxy Binding Update has been processed
successfully but GRE encapsulation and GRE keys are not required.
GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED (3)
If the local mobility anchor receives a Proxy Binding Update with
the GRE Key option and TLV-header format (T) flag set, the local
mobility anchor uses this code to indicate to the mobile access
gateway that GRE encapsulation has been successfully negotiated
but TLV-header format is NOT supported.
GRE_KEY_OPTION_REQUIRED (163)
When the local mobility anchor receives a Proxy Binding Update
without the GRE Key option while based on a policy check, the
local mobility anchor determines that GRE encapsulation is
required for this specific mobility session and uses this code to
reject the Proxy Binding Update and indicate to the mobile access
gateway that GRE encapsulation and GRE keys are required.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Data Packets Processing Considerations</span>
This section describes how the local mobility anchor and mobile
access gateway encapsulate and decapsulate data packets when GRE
encapsulation and GRE keys are used for tunneling the mobile node's
data traffic between these two mobile nodes.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Tunneling Format</span>
When GRE encapsulation is used, the mobile access gateway is allowed
to use various tunneling formats depending on the mobile access
gateway location and the network capabilities between the mobile
access gateway and the local mobility anchor. Using GRE
encapsulation, as described in [<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>] and [<a href="./rfc2890" title=""Key and Sequence Number Extensions to GRE"">RFC2890</a>], the mobile
access gateway can tunnel the IPv6-or-IPv4 payload packet in IPv6 or
in IPv4 following the rules in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] and [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>].
If UDP-based tunneling is used in conjunction with GRE encapsulation
between the mobile access gateway and the local mobility anchor, the
TLV-header UDP tunneling format as shown in Figure 5 MUST be used.
<span class="grey">Muhanna, et al. Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
[IPv4 Header]
[UDP Header]
[TLV Header]
[GRE Header]
[Payload - IPv6 or IPv4 Header]
Upper Layer protocols
Figure 5: TLV-Header UDP-Based Encapsulation Header Order
When a UDP-based tunneling format is used between the mobile access
gateway and the local mobility anchor, the use of the TLV header is
negotiated during the Proxy Binding Update/Acknowledgement exchange
as described in Sections <a href="#section-7.3">7.3</a> and <a href="#section-7.4">7.4</a>. If the TLV-header format is
agreed upon between the mobile access gateway and local mobility
anchor, the local mobility anchor expects the TLV header to follow
the UDP header as shown in Figure 5. The TLV header contains the
Type field, the following payload packet header type, and its length.
The Type field in the TLV header is always set to a value of 0 to
enhance the processing of the received packet by ensuring that the
receiver can differentiate whether what came after the UDP header is
a TLV-header Type field or an IP version field of an IP header.
Hence, the TLV header can carry traffic other than IP as indicated in
the Next Header field. The distinction between IP and TLV
encapsulation is needed, because the Proxy Binding Update (IP packet)
and the data packets (GRE packets) can be sent over the same UDP
tunnel.
When processing a UDP packet with the TLV-header format, if the
receiving node found that the payload packet length as calculated
from the UDP header length field is different than its length as
calculated from the TLV-header length field, the receiving node MUST
discard the received IP packet.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. TLV-Header Tunneling Negotiation</span>
The mobile access gateway negotiates the format for tunneling payload
traffic during the Proxy Mobile IPv6 registration procedure. If the
mobile access gateway is required to use the TLV-header UDP
encapsulation format, the mobile access gateway MUST set the TLV-
header format (T) flag in the Proxy Binding Update message sent to
the local mobility anchor. If the local mobility anchor supports the
TLV-header UDP tunneling format, the local mobility anchor SHOULD set
the TLV-header format (T) flag in the Proxy Binding Acknowledgement.
<span class="grey">Muhanna, et al. Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
Otherwise, the TLV-header format (T) flag is cleared. The setting of
the TLV-header Format (T) flag in the Proxy Binding Acknowledgement
indicates to the mobile access gateway that it MUST use the TLV-
header UDP encapsulation format for all packets tunneled to the local
mobility anchor for the entire duration the mobile node is attached
to the mobile access gateway. The TLV-header UDP tunneling format
SHOULD NOT change during a Binding Lifetime Extension Proxy Binding
Update (re-registration) from the same mobile access gateway.
Any Proxy Binding Update message triggered by a handoff (<a href="./rfc5213#section-5.3.4">Section</a>
<a href="./rfc5213#section-5.3.4">5.3.4 of [RFC5213]</a>) may renegotiate the tunneling format. Therefore,
in order to avoid interoperability issues, the local mobility anchor
MUST NOT set the TLV-header format (T) flag unless it was set in the
Proxy Binding Update received from the mobile access gateway.
The TLV-header format is as shown below in Figure 6.
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 | Res. | Next Header | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: TLV-Header Format
Type
This field is always 0 (zero) and distinguishes the TLV header
from the IPv4 and IPv6 headers.
Res.
These fields are Reserved and unused. They MUST be initialized to
zero by the sender and MUST be ignored by the receiver.
Next Header
An 8-bit unsigned integer that indicates the protocol number of
the payload header following this TLV header. It is set to the
protocol number as assigned by IANA in the "Assigned Internet
Protocol Numbers" registry. For example, if an IPv6 header
follows, it should be '41'; if a GRE header follows, it should be
'47'.
Length
A 16-bit unsigned integer indicating the length in octets of the
payload following this header, excluding the TLV header itself.
<span class="grey">Muhanna, et al. Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Mobile Access Gateway Operation</span>
When sending a Proxy Binding Update message over an IPv4 transport
network, the mobile access gateway follows the procedures specified
in [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>] for using IPv4-UDP encapsulation mode. However, when
using GRE header in conjunction with IPv4-UDP encapsulation mode is
required, the mobile access gateway MUST set the TLV-header format
(T) flag in the Proxy Binding Update and follow this specification
for GRE encapsulation negotiation. If the received Proxy Binding
Acknowledgement is successful and the TLV-header format (T) flag is
set and the GRE Key option included, the mobile access gateway MUST
update the mobile node's Binding Update List entry described in
<a href="#section-4.1">Section 4.1</a> by setting the UDP-based TLV-header format (T) flag. In
this case, the mobile access gateway MUST use the TLV-header UDP-
based encapsulation format as shown in Figure 5.
If the mobile access gateway receives a Proxy Binding Acknowledgement
with the status GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED in
response to a Proxy Binding Update with the GRE Key option and the
(T) flag set, the mobile access gateway MUST use GRE encapsulation
without UDP encapsulation. If the mobile access gateway is allowed
to use GRE encapsulation without UDP tunneling, the mobile access
gateway MUST update the mobile node's Binding Update List entry
described in <a href="#section-4.1">Section 4.1</a> by setting the GRE-encapsulation-enabled
flag and the uplink and downlink GRE key fields. In this case, the
mobile access gateway MUST set the UDP-based TLV-header format (T)
flag to FALSE. A Proxy Binding Acknowledgement message with the
status code GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED has the (T)
flag cleared. Alternatively, the mobile access gateway may resend
the Proxy Binding Update to negotiate different tunneling options,
e.g., using UDP-based tunneling without GRE encapsulation if possible
or de-register the mobile node mobility session.
<span class="h4"><a class="selflink" id="section-7.3.1" href="#section-7.3.1">7.3.1</a>. Sending and Receiving Data Packets</span>
When the mobile access gateway is located in an IPv6-enabled or IPv4-
enabled network, it may be required to use GRE encapsulation for
tunneling IPv6 or IPv4 data packets to the local mobility anchor. In
this case, and if the mobile access gateway has successfully
negotiated GRE encapsulation mode only or GRE encapsulation and GRE
keys as described in this specification, the mobile access gateway
encapsulates or decapsulates IPv6-or-IPv4 payload packets following
the rules described in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] and [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>] while ensuring that
the GRE header is present as shown in Figure 7.
<span class="grey">Muhanna, et al. Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
[IPv6 or IPv4 Header]
[GRE Header]
[Payload - IPv6 or IPv4 Header]
Upper Layer protocols
Figure 7: IPv6-or-IPv4 over IPv4 Using GRE Encapsulation
On the other hand, if the mobile access gateway is located in an
IPv4-only network where NAT has been detected on the path between the
mobile access gateway and the local mobility anchor and successfully
negotiated GRE encapsulation and the TLV-header format, the mobile
access gateway MUST use UDP TLV-header tunneling format when sending
an IPv6-or-IPv4 payload packet to the local mobility anchor according
to the format described in Figure 5. The source and the destination
of the IPv4 outer header are mobile node IPv4 Proxy Care-of Address,
IPv4-Proxy-CoA, and the IPv4 local mobility anchor address, IPv4-
LMAA, respectively. In addition, the source and the destination IP
addresses of the IPv6-or-IPv4 payload data packet are the mobile
node's IPv6-or-IPv4 home address, IPv6/IPv4-MN-HoA, and the IPv6-or-
IPv4 corresponding node's address, IPv6/IPv4-CN-Addr, respectively.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Local Mobility Anchor Operation</span>
When the local mobility anchor receives a Proxy Binding Update
encapsulated in UDP and containing the IPv4 Home Address Request
option ([<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]), it needs to follow all the steps in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] and
[<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]. In addition, if the TLV-header format (T) flag is set in
the Proxy Binding Update, the local mobility anchor needs to
determine whether it can accept the TLV-header UDP-based
encapsulation format. If it does, it SHOULD set the TLV-header
format (T) flag in the Proxy Binding Acknowledgement. Otherwise, the
local mobility anchor MUST NOT set the TLV-header format (T) flag in
the Proxy Binding Acknowledgement.
If the local mobility anchor (LMA) receives a Proxy Binding Update
with the GRE Key option and TLV-header format (T) flag set and, based
on a policy check, the LMA determines that GRE encapsulation is
required and the LMA supports TLV-header tunneling and the LMA sent a
successful Proxy Binding Acknowledgement with the TLV-header format
(T) flag set, the LMA MUST update the mobile node's Binding Cache
entry described in <a href="#section-5.1">Section 5.1</a> by setting the GRE-encapsulation-
enabled flag and update the uplink and downlink GRE key fields. In
addition, the LMA MUST set the UDP-based TLV-header format flag.
<span class="grey">Muhanna, et al. Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
If the LMA receives a Proxy Binding Update with the GRE Key option
and TLV-header format (T) flag set and, based on a policy check, the
LMA determines that GRE encapsulation is required BUT the LMA does
NOT support TLV-header tunneling and if the Proxy Binding Update has
been successfully processed, the LMA MUST send a successful Proxy
Binding Acknowledgement with the status code
GRE_TUNNELING_BUT_TLV_HEADER_NOT_SUPPORTED. This way, the LMA
indicates to the mobile access gateway that GRE encapsulation has
been successfully negotiated BUT TLV-header UDP-based tunneling
format is not supported. In this case, the LMA MUST update the
mobile node's BCE described in <a href="#section-5.1">Section 5.1</a> by setting the GRE
encapsulation enabled flag and update the uplink and downlink GRE key
fields. In this case, the LMA MUST set the UDP-based TLV-header
format flag to FALSE.
If the local mobility anchor and the mobile access gateway have
successfully negotiated the TLV-header UDP-based tunneling format and
GRE encapsulation for a specific mobility session, the local mobility
anchor processes data packets as described in the following
subsection.
<span class="h4"><a class="selflink" id="section-7.4.1" href="#section-7.4.1">7.4.1</a>. Sending and Receiving Data Packets</span>
The local mobility anchor may use GRE encapsulation for tunneling an
IPv6 or IPv4 data packet to the mobile access gateway. If the local
mobility anchor has successfully negotiated GRE encapsulation with
the mobile access gateway for a specific mobility session, the local
mobility anchor encapsulates and decapsulates IPv6-or-IPv4 payload
data packets following the rules described in [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>] and [<a href="./rfc5844" title=""IPv4 Support for Proxy Mobile IPv6"">RFC5844</a>]
while ensuring that the GRE header is present as shown in Figure 7.
In the case when TLV-tunneling format and GRE encapsulation for a
specific mobility session have been successfully negotiated between
the local mobility anchor and the mobile access gateway, the local
mobility anchor follows the TLV-header UDP-based tunneling format and
header order as shown in Figure 5 to encapsulate IPv4 or IPv6 payload
packets in IPv4 before sending the IPv4 packet to the mobile access
gateway. In this case, the source and the destination of the IPv4
outer header are IPv4-LMAA and IPv4-Proxy-CoA, respectively. In
addition, the source and the destination IP addresses of the IPv6-or-
IPv4 payload data packet are IPv6/IPv4-CN-Addr and IPv6/IPv4-MN-HoA,
respectively. On the other hand, the local mobility anchor ensures
the same TLV-header UDP-based tunneling format and header order when
it decapsulates received IPv4 packets from the mobile access gateway
for the same mobility session.
<span class="grey">Muhanna, et al. Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
This specification defines a new mobility option, the GRE Key option,
described in <a href="#section-6.1">Section 6.1</a>. This option is carried in the Mobility
Header. The type value for this option has been assigned from the
same numbering space as allocated for the other mobility options
defined in the Mobile IPv6 specification [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>].
This specification also defines three new Binding Acknowledgement
status codes as described in <a href="#section-6.4">Section 6.4</a> and IANA has allocated the
numeric values as specified in <a href="#section-6.4">Section 6.4</a> from the "Status Codes"
registry of the Mobility IPv6 Parameters.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
The GRE Key option, defined in this specification, when carried in
Proxy Binding Update and Proxy Binding Acknowledgement messages,
reveals the group affiliation of a mobile node identified by its
Network Access Identifier (NAI) or an IP address. It may help an
attacker in targeting flows belonging to a specific group. This
vulnerability can be prevented, by enabling confidentiality
protection on the Proxy Binding Update and Proxy Binding
Acknowledgement messages where the presence of the NAI and GRE Key
options establish a mobile node's relation to a specific group. This
vulnerability can also be avoided by enabling confidentiality
protection on all the tunneled data packets between the mobile access
gateway and the local mobility anchor, for hiding all the markings.
In Proxy Mobile IPv6 [<a href="./rfc5213" title=""Proxy Mobile IPv6"">RFC5213</a>], the use of IPsec [<a href="./rfc4301" title=""Security Architecture for the Internet Protocol"">RFC4301</a>] for
protecting a mobile node's data traffic is optional. Additionally,
Proxy Mobile IPv6 recommends the use of Encapsulating Security
Payload (ESP) [<a href="./rfc4303" title=""IP Encapsulating Security Payload (ESP)"">RFC4303</a>] in tunnel mode when using ESP for protecting
the mobile node's data traffic. However, when GRE encapsulation is
used, both IPsec tunnel mode and transport mode can be used to
protect the GRE header. The IPsec traffic selectors will contain the
protocol number for GRE, and there is currently no mechanism to use
the GRE key as a traffic selector.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
The authors would like to thank Alessio Casati, Barney Barnowski,
Mark Grayson, and Parviz Yegani for their input on the need for this
option. The authors would like to thank Charlie Perkins, Curtis
Provost, Irfan Ali, Jouni Korhonen, Julien Laganier, Kuntal
Chowdhury, Suresh Krishnan, and Vijay Devarapalli for their review
and comments.
<span class="grey">Muhanna, et al. Standards Track [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC1918">RFC1918</a>] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
<a href="https://www.rfc-editor.org/bcp/bcp5">BCP 5</a>, <a href="./rfc1918">RFC 1918</a>, February 1996.
[<a id="ref-RFC2003">RFC2003</a>] Perkins, C., "IP Encapsulation within IP", <a href="./rfc2003">RFC 2003</a>,
October 1996.
[<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-RFC2473">RFC2473</a>] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", <a href="./rfc2473">RFC 2473</a>, December 1998.
[<a id="ref-RFC2784">RFC2784</a>] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", <a href="./rfc2784">RFC 2784</a>,
March 2000.
[<a id="ref-RFC2890">RFC2890</a>] Dommety, G., "Key and Sequence Number Extensions to GRE",
<a href="./rfc2890">RFC 2890</a>, September 2000.
[<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-RFC5213">RFC5213</a>] Gundavelli, S., 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-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-RFC4301">RFC4301</a>] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.
[<a id="ref-RFC4303">RFC4303</a>] Kent, S., "IP Encapsulating Security Payload (ESP)",
<a href="./rfc4303">RFC 4303</a>, December 2005.
[<a id="ref-RFC5648">RFC5648</a>] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
and K. Nagami, "Multiple Care-of Addresses Registration",
<a href="./rfc5648">RFC 5648</a>, October 2009.
<span class="grey">Muhanna, et al. Standards Track [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc5845">RFC 5845</a> GRE Key Option for Proxy MIPv6 June 2010</span>
Authors' Addresses
Ahmad Muhanna
Ericsson, Inc.
2201 Lakeside Blvd.
Richardson, TX 75082
USA
EMail: ahmad.muhanna@ericsson.com
Mohamed Khalil
Ericsson, Inc.
6300 Legacy Dr.
Plano, TX 75024
USA
EMail: Mohamed.khalil@ericsson.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: sgundave@cisco.com
Kent Leung
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: kleung@cisco.com
Muhanna, et al. Standards Track [Page 23]
</pre>
|
