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
|
<pre>Network Working Group G. Tsirtsis
Request for Comments: 5454 V. Park
Category: Standards Track Qualcomm
H. Soliman
Elevate Technologies
March 2009
<span class="h1">Dual-Stack Mobile IPv4</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This specification provides IPv6 extensions to the Mobile IPv4
protocol. The extensions allow a dual-stack node to use IPv4 and
IPv6 home addresses as well as to move between IPv4 and dual stack
network infrastructures.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Notation ......................................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Goals ......................................................<a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Non-Goals ..................................................<a href="#page-4">4</a>
<a href="#section-1.4">1.4</a>. Implicit and Explicit Modes ................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Extension Formats ...............................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. IPv6 Prefix Request Extension ..............................<a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. IPv6 Prefix Reply Extension ................................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. IPv6 Tunneling Mode Extension ..............................<a href="#page-7">7</a>
<a href="#section-3">3</a>. Mobile IP Registrations .........................................<a href="#page-8">8</a>
<a href="#section-3.1">3.1</a>. Registration Request .......................................<a href="#page-8">8</a>
<a href="#section-3.2">3.2</a>. Registration Reply .........................................<a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. Home Agent Considerations ..................................<a href="#page-9">9</a>
<a href="#section-3.3.1">3.3.1</a>. IPv6 Reachability ..................................<a href="#page-10">10</a>
<a href="#section-3.3.2">3.3.2</a>. Processing Intercepted IPv6 Packets ................<a href="#page-10">10</a>
<a href="#section-3.3.3">3.3.3</a>. IPv6 Multicast Membership Control ..................<a href="#page-12">12</a>
<a href="#section-3.4">3.4</a>. Foreign Agent Considerations ..............................<a href="#page-12">12</a>
<a href="#section-3.5">3.5</a>. Mobile Node Considerations ................................<a href="#page-12">12</a>
<a href="#section-3.6">3.6</a>. Tunneling Impacts .........................................<a href="#page-13">13</a>
<a href="#section-3.7">3.7</a>. IPv6 Prefixes .............................................<a href="#page-14">14</a>
<a href="#section-3.7.1">3.7.1</a>. Dynamic IPv6 Prefix Delegation .....................<a href="#page-14">14</a>
<a href="#section-3.8">3.8</a>. Deregistration of IPv6 Prefix .............................<a href="#page-15">15</a>
<a href="#section-3.9">3.9</a>. Registration with a Private CoA ...........................<a href="#page-15">15</a>
<a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-15">15</a>
<a href="#section-5">5</a>. IANA Considerations ............................................<a href="#page-16">16</a>
<a href="#section-6">6</a>. Acknowledgements ...............................................<a href="#page-16">16</a>
<a href="#section-7">7</a>. References .....................................................<a href="#page-16">16</a>
<a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-16">16</a>
<a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-17">17</a>
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Mobile IPv4 [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>] allows a mobile node with an IPv4 address to
maintain communications while moving in an IPv4 network.
Extensions defined in this document allow a node that has IPv4 and
IPv6 addresses [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] to maintain communications through any of
its addresses while moving in IPv4 or dual stack networks.
Essentially, this specification separates the Mobile IPv4 signaling
from the IP version of the traffic it tunnels. Mobile IPv4 with the
present extensions remains a signaling protocol that runs over IPv4,
and yet can set up both IPv4 and IPv6 tunnels over IPv4.
The aim is two-fold:
On one hand, Mobile IPv4 with the present extensions becomes a
useful transition mechanism, allowing automated but controlled
tunneling of IPv6 traffic over IPv4 tunnels. Dual-stack nodes in
dual-stack home networks can now roam to and from legacy IPv4
networks, while IPv4 mobile nodes and networks can migrate to IPv6
without changing mobility management, and without upgrading all
network nodes to IPv6 at once.
On the other hand, and more importantly, it allows dual-stack
mobile nodes and networks to utilize a single protocol for the
movement of both IPv4 and IPv6 stacks in the network topology.
Note that features like Mobile IPv6 [<a href="./rfc3775" title=""Mobility Support in IPv6"">RFC3775</a>] style route
optimization will not be possible with this solution as it still
relies on Mobile IPv4 signaling, which does not provide route
optimization.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Notation</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Goals</span>
a. The solution supports the registration of IPv6 home prefix(es) in
addition to regular IPv4 home address (HoA) registration.
b. The solution supports static and dynamic IPv6 prefix delegation.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Non-Goals</span>
a. The solution does not provide support for IPv6 care-of address
(CoA) registration.
<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>. Implicit and Explicit Modes</span>
As defined in Network Mobility (NEMO) [<a href="./rfc3963" title=""Network Mobility (NEMO) Basic Support Protocol"">RFC3963</a>], this specification
also supports two modes of operation; the implicit mode and the
explicit mode.
In the implicit mode, the mobile node does not include any IPv6
prefix request extensions in the registration request. The home
agent can use any mechanism (not defined in this document) to
determine the IPv6 prefix(es) owned by the mobile node and to set up
forwarding for these prefixes. In this mode of operation, all
traffic to and from the IPv6 prefixes MUST be encapsulated over the
IPv4 tunnel between the mobile node's IPv4 home address and the IPv4
address of the home agent, and as such, it is transparent to any
foreign agent in the path. This IPv4 tunnel is established by
mechanisms that are out of the scope of this document on both the
mobile node and home agent when operating in the implicit mode.
In the explicit mode, IPv6 bindings are signaled explicitly. The
mobile node includes one or more IPv6 prefix request extensions in
the registration request, while the home agent returns corresponding
IPv6 prefix reply extensions to accept/reject the IPv6 bindings.
Additionally, in the explicit mode, the mobile node (when co-located
mode of operation is used) can indicate whether IPv6 traffic should
be tunneled to the care-of address or the home address of the mobile
node.
The rest of this specification is primarily defining the explicit
mode.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Extension Formats</span>
The following extensions are defined according to this specification.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. IPv6 Prefix Request Extension</span>
A new skippable extension to the Mobile IPv4 registration request
message in accordance to the short extension format of [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>] is
defined here.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
This extension contains a Mobile IPv6 network prefix and its prefix
length.
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 | Subtype | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: IPv6 Prefix Request Extension
Type
152 (Dual-Stack Mobile IPv4 (DSMIPv4) Extension)
Length
18
Subtype
1 (IPv6 Prefix Request)
Prefix Length
A sixteen-byte field containing the Mobile IPv6 Network Prefix;
all insignificant (low-order) bits (beyond the Prefix Length) MUST
be set to 0 by the originator of the option and ignored by the
receiver.
Mobile IPv6 Network Prefix
A sixteen-byte field containing the Mobile IPv6 Network Prefix
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. IPv6 Prefix Reply Extension</span>
A new skippable extension to the Mobile IPv4 registration reply
message in accordance to the short extension format of [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>] is
defined here.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
This extension defines a Mobile IPv6 Network Prefix and its prefix
length, as well as a code.
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 | Subtype | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Reserved | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Mobile IPv6 Network Prefix +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: IPv6 Prefix Reply Extension
Type
152 (DSMIPv4 Extension)
Length
20
Subtype
2 (IPv6 Prefix Reply)
Code
A value indicating the result of the registration request with
respect to the IPv6 home prefix registration. See below for
currently defined Codes.
Prefix Length
Indicates the prefix length of the prefix included in the Mobile
IPv6 Network Prefix field. A value of 255 indicates that a link-
local address is included in the Mobile IPv6 Network Prefix field.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
Reserved
Set to 0 by the sender, ignored by the receiver
Mobile IPv6 Network Prefix
A sixteen-byte field containing the Mobile IPv6 Network Prefix;
all insignificant (low-order) bits (beyond the Prefix Length) MUST
be set to 0 by the originator of the option and ignored by the
receiver.
The following values are defined for use as a Code value in the above
extension:
0 registration accepted, IPv6 to be tunneled to HoA
1 registration accepted, IPv6 to be tunneled to CoA
8 registration rejected, reason unspecified
9 registration rejected, administratively prohibited
Note that a registration reply that does not include an IPv6 prefix
reply extension, when received in response to a registration request
carrying at least one instance of the IPv6 prefix request extension,
indicates that the home agent does not support IPv6 extensions and
thus has ignored such extensions in the registration request.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. IPv6 Tunneling Mode Extension</span>
A new skippable extension to the Mobile IPv4 registration request
message in accordance to the short extension format of [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>] is
defined here.
By including this extension in a registration request, the sender
indicates that IPv6 traffic can be tunneled to the mobile node's CoA.
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 | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IPv6 Tunneling Mode Extension
Type
152 (DSMIPv4 Extension)
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
Length
2
Subtype
3 (IPv6 Tunneling Mode)
Reserved
Set to 0 by the sender, ignored by the receiver
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Mobile IP Registrations</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Registration Request</span>
A mobile node MAY include in a registration request one or more IPv6
prefix request extensions defined in this specification.
A mobile node MAY also include exactly one IPv6 tunneling mode
extension when it uses the co-located care-of address mode of
[<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>].
When IPv6 prefix and/or IPv6 tunneling mode extensions are used by
the mobile IP client, they MUST be placed after the registration
request header and before the mobile -- home authentication extension
so they MUST be included in the computation of any authentication
extension.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Registration Reply</span>
The mechanism described in this specification depends on skippable
extensions. For that reason, a registration reply that does not
include an IPv6 prefix reply extension, in response to a registration
request including an IPv6 prefix request extension, indicates that
the home agent does not support IPv6 extensions and has ignored the
request.
If an IPv6 prefix reply extension is included in a registration
reply, then the extension indicates the success or failure of the
IPv6 prefix registration. The IPv6 prefix reply extension does not
affect, in any way, the code value in the registration reply header
but it is superseded by it. In other words, if the code field in the
registration reply header is set to a reject code, then all IPv6
prefix request extensions are also rejected. If the code field in
the registration reply header, however, is set to an accept code,
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
then an IPv6 prefix reply extension with a code field set to a reject
code only rejects the binding for the specific IPv6 prefix indicated
in the same extension.
Note that a rejecting IPv6 prefix reply extension has the same effect
as not including such an extension at all, in the sense that, in both
cases, the mobile node must act as if the corresponding IPv6 prefix
request extension included in the registration request was rejected.
Of course, the inclusion of the IPv6 prefix reply extension allows
the home agent to indicate why a given IPv6 prefix request extension
was rejected. A detailed description of how the mobile node handles
different IPv6 prefix reply extension code values and the absence of
IPv6 prefix reply extensions is given in <a href="#section-3.5">Section 3.5</a>.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Home Agent Considerations</span>
The dual-stack home agent defined in this specification is a Mobile
IPv4 home agent in that, it MUST operate as defined in MIPv4
[<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>]. In addition to that, the following mechanisms are defined
in this specification.
For each IPv6 prefix request extension included in a valid
registration request, a home agent that supports this specification
SHOULD include a corresponding IPv6 prefix reply extension in the
registration reply message. The home agent MUST NOT include more
than one IPv6 prefix reply extension for the same prefix. For each
accepted IPv6 prefix, the home agent MUST decide the tunneling mode
it is going to use and set the code field of the IPv6 prefix reply
extension to the appropriate value. The IPv6 prefix field of each of
the IPv6 prefix reply extensions included in the registration reply
MUST match the IPv6 prefix field of an IPv6 prefix request extension
included in the corresponding registration request message.
When the home agent sends a successful registration reply to the
mobile node, with the code field of a corresponding IPv6 prefix reply
extension set to one of the "registration accepted" values, the home
agent indicates that the IPv6 prefix is registered for the lifetime
granted for the binding. It also indicates the tunneling mode used
i.e., tunneling to home address or care-of address, based on the
value of the code field used in the IPv6 prefix reply extension.
Note that since only IPv6 prefixes (and not addresses) are supported
by this specification, there is no need for Duplicate Address
Detection. The home agent, however, MUST check that registered
prefixes are not overlapping so that all addresses under each
registered prefix belong to a single mobile node at any one time.
These prefixes MUST NOT appear as on-link to any other node (e.g.,
via Router Advertisements).
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. IPv6 Reachability</span>
For each registered IPv6 prefix, the home agent MUST advertise its
reachability as defined in NEMO <a href="./rfc3963#section-6.3">Section 6.3 of [RFC3963]</a>.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Processing Intercepted IPv6 Packets</span>
A dual-stack home agent that supports the IPv6 extensions defined in
this specification MUST keep track of the following IPv6 related
state for the mobile nodes it supports, in addition to the state
defined in [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>].
- Registered IPv6 prefix(es) and prefix length(s).
- Tunneling mode for IPv6 traffic:
- Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA.
- Tunnel to CoA and accept IPv6 tunneled from CoA.
When IPv6 traffic is encapsulated over the tunnel between the home
agent (HA) and the mobile node's care-of address, the tunneling
mechanism used should be the same as the mechanism negotiated by the
Mobile IP header as defined in MIPv4 [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>]. In that case, when
IPinIP encapsulation is negotiated, IPv6 is tunneled over IPv4
according to [<a href="./rfc4213" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">RFC4213</a>]. Generic Routing Encapsulation (GRE) also
allows tunneling of IPv6 packets by setting the Protocol Type
[<a href="./rfc2784" title=""Generic Routing Encapsulation (GRE)"">RFC2784</a>] field, to the appropriate payload type defined for IPv6 by
IANA. Minimal Encapsulation [<a href="./rfc2004" title=""Minimal Encapsulation within IP"">RFC2004</a>] cannot be used, since the
second (inner) IP header is IPv6, which is not supported by
[<a href="./rfc2004" title=""Minimal Encapsulation within IP"">RFC2004</a>].
When IPv6 traffic is encapsulated over the tunnel between the HA and
the mobile node's home address, IPv6 is always tunneled over IPv4
according to [<a href="./rfc4213" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">RFC4213</a>]. The resulting IPv4 packet is then delivered
just like any other IPv4 packet addressed to the IPv4 HoA (using the
tunneling for normal IPv4 traffic, possibly going via the foreign
agent (FA)).
Tunneling mode selection for IPv6 traffic depends on the following
parameters in a successful registration request:
1) A registration request is received with one or more IPv6 prefix
request extensions. An IPv6 tunneling mode extension is not
included.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
All IPv6 packets destined to the registered IPv6 prefix(es)
MUST be tunneled by the home agent to the registered IPv4 home
address of the mobile node. The home agent first encapsulates
the IPv6 packet, addressing it to the mobile node's IPv4 home
address, and then tunnels this encapsulated packet to the
foreign agent. This extra level of encapsulation is required
so that IPv6 routing remains transparent to a foreign agent
that does not support IPv6. When received by the foreign
agent, the unicast encapsulated packet is de-tunneled and
delivered to the mobile node in the same way as any other
packet. The mobile node must decapsulate the received IPv4
packet in order to recover the original IPv6 packet.
Additionally, the home agent MUST be prepared to accept
reverse-tunneled packets from the IPv4 home address of the
mobile node encapsulating IPv6 packets sent by that mobile
node.
2) A registration request is received with one or more IPv6 prefix
request extensions. An IPv6 tunneling mode extension is
included.
All IPv6 packets destined to the registered IPv6 prefix(es)
SHOULD be tunneled by the home agent to the registered care-of
address of the mobile node. Additionally, the home agent
SHOULD be prepared to accept reverse-tunneled packets from the
care-of address of the mobile node encapsulating IPv6 packets
sent by that mobile node. The home agent MAY ignore the
presence of the IPv6 tunneling mode extension and act as in
case (1) above.
The home agent MUST check that all inner IPv6 packets received from
the mobile node over a tunnel with the mobile node's home address or
the care-of address as the outer source address, include a source
address that falls under the registered IPv6 prefix(es) for that
mobile node. If the source address of the outer header of a tunneled
packet is not the registered IPv4 care-of address or the registered
IPv4 home addresses, the packet SHOULD be dropped. If the source
address of the inner header of an tunneled packet does not match any
of the registered prefixes, the packet SHOULD be dropped.
Multicast packets addressed to a group to which the mobile node has
successfully subscribed, MUST be tunneled to the mobile node.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
<span class="h4"><a class="selflink" id="section-3.3.3" href="#section-3.3.3">3.3.3</a>. IPv6 Multicast Membership Control</span>
IPv6 multicast membership control is provided as defined in MIPv6
<a href="./rfc3775#section-10.4.3">[RFC3775], Section 10.4.3</a>. The only clarification required for the
purpose of this specification is that all Multicast Listener
Discovery (MLD) [<a href="./rfc2710" title=""Multicast Listener Discovery (MLD) for IPv6"">RFC2710</a>] or MLDv2 [<a href="./rfc3810" title=""Multicast Listener Discovery Version 2 (MLDv2) for IPv6"">RFC3810</a>] messages between the
mobile node and the home agent MUST be tunneled over an IPv4 tunnel
between the mobile node's IPv4 home address and the home agent's IPv4
address, bypassing the foreign agent. Note that if tunneling to the
care-of address has been negotiated for other traffic, then the rest
of the traffic continues using this tunnel.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Foreign Agent Considerations</span>
This specification does not affect the operation of the foreign
agent.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Mobile Node Considerations</span>
A dual-stack mobile node that supports the extensions described in
this document MAY use these extensions to register its IPv6
prefix(es) while moving between access routers.
The mobile node MAY include one or more IPv6 prefix request
extension(s) in the registration request.
In this case, the mobile node MUST take the following action
depending on the extensions included in the registration reply it
receives in response to the registration request:
1) The registration reply does not include any IPv6 prefix reply
extensions.
The mobile node MUST assume that the home agent does not
support the extensions defined in this specification. The
mobile node SHOULD continue to operate according to MIPv4
[<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>].
2) The registration reply includes one or more IPv6 prefix reply
extensions.
The mobile node MUST match each IPv6 prefix reply extension
with one of the IPv6 prefix request extensions included
earlier in the corresponding registration request message.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
If a matching IPv6 prefix reply extension is not included for
one or more of corresponding IPv6 prefix request extensions
included in the registration request message, the mobile node
MUST assume that these IPv6 prefixes are rejected.
For each matching IPv6 prefix reply extension, the mobile node
MUST inspect the code field. If the field is set to a
rejection code, then the corresponding IPv6 prefix
registration has been rejected. If the code field is set to
an acceptance code, then the corresponding IPv6 prefix
registration has been accepted.
If the code field is set to "0", then the mobile node MUST be
prepared to send/receive IPv6 packets encapsulated in the
bidirectional tunnel between the home agent address and the
registered IPv4 home address of the mobile node.
If the code field is set to "1", then the mobile node MUST act
as follows:
- Assuming the co-located care-of address mode is used, the
mobile node MUST be prepared to send/receive IPv6 packets
over the bidirectional tunnel between the home agent
address and its co-located care-of address. Otherwise, the
mobile node SHOULD act as in the case where the code field
is set to "0".
The mobile node SHOULD include exactly one IPv6 tunneling mode
extension if it uses the co-located care-of address model and it
wants to request that IPv6 packets are tunneled to its co-located
care-of address. If the mobile node uses the co-located care-of
address model but it does not include the IPv6 tunneling mode
extension, the home agent will tunnel IPv6 traffic to the mobile
node's IPv4 home address. The mobile node MUST NOT include an IPv6
tunneling mode extension if it uses the foreign agent care-of address
mode of operation. Note that if the mobile node includes an IPv6
tunneling mode extension in this case, IPv6 packets could be tunneled
to the FA by the HA. The FA is then likely to drop them since it
will not have appropriate state to process them.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. Tunneling Impacts</span>
When IPv6 runs over an IPv4 tunnel, the IPv6 tunnel endpoints can
treat the IPv4 tunnel as a single hop link as defined in [<a href="./rfc4213" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">RFC4213</a>].
The two tunnel endpoints, e.g., mobile node and home agent, MUST
configure link-local IPv6 addresses as defined in <a href="#section-3.7">Section 3.7</a> of
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
[<a href="./rfc4213" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">RFC4213</a>], while they MUST also adhere to the neighbor discovery
requirements of the same specification, <a href="#section-3.8">Section 3.8</a>, and the hop
limit requirements of <a href="#section-3.3">Section 3.3</a>.
With respect to the Tunnel MTU, an implementation MUST support the
Static Tunnel MTU approach as defined in <a href="./rfc4213#section-3.2">Section 3.2 of [RFC4213]</a>.
Implementation and use of the Dynamic Tunnel MTU method defined in
the same section of [<a href="./rfc4213" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">RFC4213</a>] is OPTIONAL.
To accommodate traffic that uses Explicit Congestion Notification
(ECN), it is RECOMMENDED that the ECN and Diffserv Code Point (DSCP)
information is copied between the inner and outer header as defined
in [<a href="./rfc3168" title=""The Addition of Explicit Congestion Notification (ECN) to IP"">RFC3168</a>] and [<a href="./rfc2983" title=""Differentiated Services and Tunnels"">RFC2983</a>]. It is RECOMMENDED that the full-
functionality option defined in <a href="./rfc3168#section-9.1.1">Section 9.1.1 of [RFC3168]</a> be used to
deal with ECN.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. IPv6 Prefixes</span>
An implementation can use any number of mechanisms to allocate IPv6
prefixes to a mobile node. Once one or more IPv6 prefixes are
allocated, they can be registered using the extensions and mechanism
already described in this specification.
How a home agent decides to accept an IPv6 prefix for a given mobile
node is out of scope of this specification. Local configuration or
external authorization via an authorization system, e.g., Diameter
[<a href="./rfc3588" title=""Diameter Base Protocol"">RFC3588</a>], or other mechanisms may be used to make such
determination.
<span class="h4"><a class="selflink" id="section-3.7.1" href="#section-3.7.1">3.7.1</a>. Dynamic IPv6 Prefix Delegation</span>
A dual-stack mobile node MAY use prefix delegation as defined in
DHCPv6 Prefix Delegation [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>] to get access to IPv6 prefixes.
In that case, if the mobile node is not directly attached to its home
agent, the mobile node MUST first register its IPv4 home address as
per MIPv4 [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>]. When that is done, the mobile node can generate
a link-local IPv6 address as per <a href="./rfc4213#section-3.7">Section 3.7 of [RFC4213]</a>. The
mobile node then sends a registration request to its home agent,
including an IPv6 prefix request extension with the prefix length
field set to 255 and setting the Mobile IPv6 Network Prefix field to
the locally generated link-local address. If the registration reply
message includes an IPv6 prefix reply extension with the code field
set to a success code, the mobile node can use the tunnel to send and
receive IPv6 link-local packets. The mobile node can now send DHCPv6
messages according to [<a href="./rfc3633" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">RFC3633</a>]. All IPv6 messages at this stage
MUST be tunneled over the IPv4 tunnel between the mobile node's IPv4
home address and the home agent's IPv4 address.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
Once prefixes are delegated, and assuming explicit mode is used, the
mobile node SHOULD send a registration request with the appropriate
IPv6 prefix request extensions to the home agent to register the
delegated prefixes.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Deregistration of IPv6 Prefix</span>
The mobile IP registration lifetime included in the registration
request header is valid for all the bindings created by the
registration request, which may include bindings for IPv6 prefix(es).
A registration request with a zero lifetime can be used to remove all
bindings from the home agent.
A re-registration request with non-zero lifetime can be used to
deregister some of the registered IPv6 prefixes by not including
corresponding IPv6 prefix request extensions in the registration
request message.
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>. Registration with a Private CoA</span>
If the care-of address is a private address, then Mobile IP NAT
Traversal as [<a href="./rfc3519" title=""Mobile IP Traversal of Network Address Translation (NAT) Devices"">RFC3519</a>] MAY be used in combination with the extensions
described in this specification. In that case, to transport IPv6
packets, the next header field of the Mobile Tunnel Data message
header [<a href="./rfc3519" title=""Mobile IP Traversal of Network Address Translation (NAT) Devices"">RFC3519</a>] MUST be set to the value for IPv6. Note that in
that case, the encapsulation field of the UDP Tunnel Request
Extension defined in [<a href="./rfc3519" title=""Mobile IP Traversal of Network Address Translation (NAT) Devices"">RFC3519</a>] MUST be set to zero.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This specification operates in the security constraints and
requirements of [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>]. It extends the operations defined in
[<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>] for IPv4 home addresses to cover home IPv6 prefixes and
provides the same level of security for both IP address versions.
Home agents MUST perform appropriate checks for reverse-tunneled IPv6
packets similar to what is defined in [<a href="./rfc3024" title=""Reverse Tunneling for Mobile IP, revised"">RFC3024</a>] for IPv4 packets.
The check defined in [<a href="./rfc3024" title=""Reverse Tunneling for Mobile IP, revised"">RFC3024</a>] requires that the outer header's
source address is set to a registered care-of address for the mobile
node and as such the same check protects from attacks whether the
encapsulated (inner) header is IPv4 or IPv6.
In addition to that, the home agent MUST check that the source
address of the inner header is a registered IPv4 home address or IPv6
prefix for this mobile node. If that is not the case, the home agent
SHOULD silently discard the packet and log the event as a security
exception.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
Security devices should look for IPv6 packets encapsulated over IPv4
either directly to the mobile node's care-of address or via double
encapsulation first to the mobile node's IPv4 home address and then
to the mobile node's care-of address. Interactions with Mobile IPv4
and IPsec have been covered elsewhere, for instance in [<a href="./rfc5265" title=""Mobile IPv4 Traversal across IPsec-Based VPN Gateways"">RFC5265</a>] and
[<a href="./rfc5266" title=""Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)"">RFC5266</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
A new type number (152) for DSMIPv4 extensions has been registered
from the space of numbers for skippable mobility extensions (i.e.,
128-255), defined for Mobile IPv4 [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>]. This registry is
available from <a href="http://www.iana.org">http://www.iana.org</a> under "Extensions appearing in
Mobile IP control messages".
A new subtype space for the type number of this extension has been
created: "DSMIPv4 Extension subtypes". The subtype values 1, 2, and
3 are defined in this specification, while the rest of the subtypes
are reserved and available for allocation based on Expert Review.
Finally, a new space for the code field of the IPv6 prefix reply
extension has been created: "IPv6 Prefix Reply Extension Codes".
Values 0, 1, 8, and 9 are defined in this specification. Values 2-7
are reserved for accept codes, and values 10-255 are reserved for
reject codes.
Similar to the procedures specified for Mobile IPv4 [<a href="./rfc3344" title=""IP Mobility Support for IPv4"">RFC3344</a>] number
spaces, future allocations from the two number spaces require Expert
Review [<a href="./rfc5226" title="">RFC5226</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Acknowledgements</span>
Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller, and Pete McCann
for earlier work on this subject. Thanks also to Alex Petrescu for
various suggestions. Special thanks also to Sri Gundavelli and Kent
Leung for their thorough review and suggestions.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
[<a id="ref-RFC3024">RFC3024</a>] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", <a href="./rfc3024">RFC 3024</a>, January 2001.
[<a id="ref-RFC3344">RFC3344</a>] Perkins, C., "IP Mobility Support for IPv4", <a href="./rfc3344">RFC 3344</a>,
August 2002.
[<a id="ref-RFC3519">RFC3519</a>] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", <a href="./rfc3519">RFC 3519</a>,
April 2003.
[<a id="ref-RFC3633">RFC3633</a>] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", <a href="./rfc3633">RFC 3633</a>,
December 2003.
[<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-RFC3963">RFC3963</a>] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
<a href="./rfc3963">RFC 3963</a>, January 2005.
[<a id="ref-RFC4213">RFC4213</a>] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", <a href="./rfc4213">RFC 4213</a>, October 2005.
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc5226">RFC 5226</a>,
May 2008.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC2004">RFC2004</a>] Perkins, C., "Minimal Encapsulation within IP", <a href="./rfc2004">RFC 2004</a>,
October 1996.
[<a id="ref-RFC2710">RFC2710</a>] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", <a href="./rfc2710">RFC 2710</a>,
October 1999.
[<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-RFC2983">RFC2983</a>] Black, D., "Differentiated Services and Tunnels",
<a href="./rfc2983">RFC 2983</a>, October 2000.
[<a id="ref-RFC3168">RFC3168</a>] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
<a href="./rfc3168">RFC 3168</a>, September 2001.
<span class="grey">Tsirtsis, 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="./rfc5454">RFC 5454</a> Dual-Stack Mobile IPv4 March 2009</span>
[<a id="ref-RFC3588">RFC3588</a>] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", <a href="./rfc3588">RFC 3588</a>, September 2003.
[<a id="ref-RFC3810">RFC3810</a>] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", <a href="./rfc3810">RFC 3810</a>, June 2004.
[<a id="ref-RFC5265">RFC5265</a>] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
IPsec-Based VPN Gateways", <a href="./rfc5265">RFC 5265</a>, June 2008.
[<a id="ref-RFC5266">RFC5266</a>] Devarapalli, V. and P. Eronen, "Secure Connectivity and
Mobility Using Mobile IPv4 and IKEv2 Mobility and
Multihoming (MOBIKE)", <a href="https://www.rfc-editor.org/bcp/bcp136">BCP 136</a>, <a href="./rfc5266">RFC 5266</a>, June 2008.
Authors' Addresses
George Tsirtsis
Qualcomm
EMail: tsirtsis@googlemail.com
Vincent Park
Qualcomm
Phone: +908-947-7084
EMail: vpark@qualcomm.com
Hesham Soliman
Elevate Technologies
Phone: +614-111-410-445
EMail: hesham@elevatemobile.com
Tsirtsis, et al. Standards Track [Page 18]
</pre>
|
