1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Network Working Group G. Bajko
Request for Comments: 5678 Nokia
Category: Standards Track S. Das
Telcordia Technologies Inc.
December 2009
<span class="h1">Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for</span>
<span class="h1">IEEE 802.21 Mobility Services (MoS) Discovery</span>
Abstract
This document defines new Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) options that contain a list of IP addresses and a list of
domain names that can be mapped to servers providing IEEE 802.21 type
of Mobility Service (MoS) (see <a href="./rfc5677">RFC 5677</a>). These Mobility Services
are used to assist a mobile node (MN) in handover preparation
(network discovery) and handover decision (network selection). The
services addressed in this document are the Media Independent
Handover Services defined in IEEE 802.21.
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
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
<span class="grey">Bajko & Das Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. MoS IPv4 Address Option for DHCPv4 ..............................<a href="#page-3">3</a>
<a href="#section-3">3</a>. MoS Domain Name List Option for DHCPv4 ..........................<a href="#page-5">5</a>
<a href="#section-4">4</a>. MoS IPv6 Address Option for DHCPv6 ..............................<a href="#page-7">7</a>
<a href="#section-5">5</a>. MoS Domain Name List Option for DHCPv6 ..........................<a href="#page-9">9</a>
<a href="#section-6">6</a>. Option Usage ...................................................<a href="#page-10">10</a>
<a href="#section-6.1">6.1</a>. Usage of MoS Options for DHCPv4 ...........................<a href="#page-10">10</a>
<a href="#section-6.2">6.2</a>. Usage of MoS Options for DHCPv6 ...........................<a href="#page-11">11</a>
<a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-9">9</a>. Acknowledgements ...............................................<a href="#page-13">13</a>
<a href="#section-10">10</a>. References ....................................................<a href="#page-13">13</a>
<a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-13">13</a>
<a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-14">14</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
IEEE 802.21 [<a href="#ref-IEEE802.21" title=""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services"">IEEE802.21</a>] defines three distinct service types to
facilitate link layer handovers across heterogeneous technologies:
a) Information Services (IS)
IS provides a unified framework to the higher-layer entities
across the heterogeneous network environment to facilitate
discovery and selection of multiple types of networks existing
within a geographical area. The objective is to help the higher-
layer mobility protocols acquire a global view of heterogeneous
networks and perform seamless handover across these networks.
b) Event Services (ES)
Events may indicate changes in state and transmission behavior of
the physical, data link, and logical link layers, or predict state
changes of these layers. The Event Service may also be used to
indicate management actions or command status on the part of the
network or some management entity.
c) Command Services (CS)
The command service enables higher layers to control the physical,
data link, and logical link layers. The higher layers may control
the reconfiguration or selection of an appropriate link through a
set of handover commands.
<span class="grey">Bajko & Das Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
In IEEE terminology, these services are called Media Independent
Handover (MIH) services. While these services may be co-located, the
different pattern and type of information they provide do not
necessitate the co-location.
A mobile node (MN) may make use of any of these MIH service types
separately or any combination of them [<a href="./rfc5677" title=""IEEE 802.21 Mobility Services Framework Design (MSFD)"">RFC5677</a>]. In practice, a
Mobility Server may not necessarily host all three of these MIH
services together; thus, there is a need to discover the MIH service
types separately.
This document defines new DHCPv4 and DHCPv6 options and sub-options
called the MoS IP Address and Domain Name List Options, which allow
the MN to locate a Mobility Server that hosts the desired service
type (i.e., IS, ES, or CS) as defined in [<a href="#ref-IEEE802.21" title=""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services"">IEEE802.21</a>]. Apart from
manual configuration, this is one of the possible solutions for
locating a server providing Mobility Services.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</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>. Terminology</span>
Mobility Services: a set of services provided by the network to
mobile nodes to facilitate handover preparation and handover
decision. In this document, Mobility Services refer to the services
defined in IEEE 802.21 specifications [<a href="#ref-IEEE802.21" title=""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services"">IEEE802.21</a>]
Mobility Server: a network node providing Mobility Services.
MIH: Media Independent Handover, as defined in [<a href="#ref-IEEE802.21" title=""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services"">IEEE802.21</a>].
MIH Service: IS, ES, or CS type of service, as defined in
[<a href="#ref-IEEE802.21" title=""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services"">IEEE802.21</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. MoS IPv4 Address Option for DHCPv4</span>
This section describes the MoS IPv4 Address Option for DHCPv4.
Whether the MN receives a MoS address from the local or home network
will depend on the actual network deployment [<a href="./rfc5677" title=""IEEE 802.21 Mobility Services Framework Design (MSFD)"">RFC5677</a>]. The MoS IPv4
Address Option begins with an option code followed by a length and
sub-options. The value of the length octet does not include itself
or the option code. The option layout is depicted below:
<span class="grey">Bajko & Das Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv4_Address-MoS (139) - 1 byte
Length
An 8-bit field indicating the length of the option excluding
the 'Option Code' and the 'Length' fields
Sub-options
A series of DHCPv4 sub-options
When the total length of a MoS IPv4 Address Option exceeds 254
octets, the procedure outlined in [<a href="./rfc3396" title=""Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)"">RFC3396</a>] MUST be employed to split
the option into multiple, smaller options.
A sub-option begins with a sub-option code followed by a length and
one or more IPv4 addresses. The sub-option layout is depicted below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt Code | Length | IP Address . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Bajko & Das Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
The sub-option codes are summarized below.
+--------------+---------------+
| Sub-opt | Service |
| Code | Name |
+==============+===============+
| 1 | IS |
+--------------+---------------+
| 2 | CS |
+--------------+---------------+
| 3 | ES |
+--------------+---------------+
If the length is followed by a list of IPv4 addresses indicating
appropriate MIH servers available to the MN for a requested option,
servers MUST be listed in order of preference and the client should
process them in decreasing order of preference. In the case that
there is no MIH server available, the length is set to 0; otherwise,
it is a multiple of 4.
The sub-option has the following format:
Code Len IPv4 Address 1 IPv4 Address 2
+-----+---+---+----+----+----+----+----+---
|1..3 | n |a1 | a2 |a3 | a4 | a1 | ...
+-----+---+---+----+----+----+-----+----+--
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. MoS Domain Name List Option for DHCPv4</span>
This section describes the MoS Domain Name List Option for DHCPv4.
The general format of this option is depicted below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Bajko & Das Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
Option Code
OPTION-IPv4_FQDN-MoS (140) - 1 byte
Length
An 8-bit field indicating the length of the option excluding
the 'Option Code' and the 'Length' fields
Sub-options
A series of DHCPv4 sub-options.
When the total length of a MoS Domain Name List Option exceeds 254
octets, the procedure outlined in [<a href="./rfc3396" title=""Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)"">RFC3396</a>] MUST be employed to split
the option into multiple, smaller options.
A sub-option begins with a sub-option code followed by a length and
one or more Fully Qualified Domain Names (FQDNs). The sub-option
layout is depicted below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt Code | Length | FQDN(s) . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option codes are summarized below.
+--------------+---------------+
| Sub-opt | Service |
| Code | Name |
+==============+===============+
| 1 | IS |
+--------------+---------------+
| 2 | CS |
+--------------+---------------+
| 3 | ES |
+--------------+---------------+
Thus, the sub-option for this encoding has the following format:
Code Len DNS name of Mobility Server
+-----+----+----+-----+-----+-----+-----+--
|1..3 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+----+----+-----+-----+-----+-----+--
<span class="grey">Bajko & Das Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
The sub-option begins with a sub-option code followed by a length and
a sequence of labels that are encoded according to <a href="./rfc3315#section-8">Section 8 of
[RFC3315]</a>.
The sub-option MAY contain multiple domain names, but these should
refer to the NAPTR records of different providers, rather than
different A records within the same provider. That is, the use of
multiple domain names is not meant to replace NAPTR and SRV records,
but rather to allow a single DHCP server to indicate MIH servers
operated by multiple providers.
The client MUST try the records in the order listed, applying the
mechanism described in [<a href="./rfc5679" title=""Locating IEEE 802.21 Mobility Services Using DNS"">RFC5679</a>] for each. The client only resolves
the subsequent domain names if attempts to contact the first one
failed or yielded no common transport protocols between the MN and
the server.
As an example, consider the case where the server wants to offer two
MIH IS servers, "example.com" and "example.net". These would be
encoded as follows:
+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|1..3 |26 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. MoS IPv6 Address Option for DHCPv6</span>
This section describes the MoS IPv6 Address Option for DHCPv6.
Whether the MN receives a MoS address from the local or home network
will depend on the actual network deployment [<a href="./rfc5677" title=""IEEE 802.21 Mobility Services Framework Design (MSFD)"">RFC5677</a>]. The MoS
Discovery Option begins with an option code followed by a length and
sub-options. The value of the length octet does not include itself
or the option code. The option layout is depicted below:
<span class="grey">Bajko & Das Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv6_Address-MoS (54) - 2 bytes
Length
A 16-bit field indicating the length of the option excluding
the 'Option Code' and the 'Length' fields.
Sub-options
A series of DHCPv6 sub-options
The sub-options follow the same format (except the Sub-opt Code and
Length value) as described in <a href="#section-2">Section 2</a>. The value of the Sub-opt
Code and Length is 2 octets, and the Length does not include itself
or the Sub-opt Code field. The sub-option layout is depicted below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Bajko & Das Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
The sub-option codes are summarized below.
+----------------+---------------+
| Sub-opt Code | Service Name |
+================+===============+
| 1 | IS |
+----------------+---------------+
| 2 | CS |
+----------------+---------------+
| 3 | ES |
+----------------+---------------+
If the length is followed by a list of IPv6 addresses indicating
appropriate MIH servers available to the MN for a requested option,
servers MUST be listed in order of preference and the client should
process them in decreasing order of preference. In the case where
there is no MIH server available, the length is set to 0; otherwise,
it is a multiple of 16.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. MoS Domain Name List Option for DHCPv6</span>
This section describes the MoS Domain List Option for DHCPv6. The
general format of this option is depicted below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
OPTION-IPv6_FQDN-MoS (55) - 2 bytes
Length
A 16-bit field indicating the length of the option excluding
the 'Option Code' and the 'Length' fields
<span class="grey">Bajko & Das Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
Sub-options
A series of DHCPv6 sub-options
The sub-options follow the same format (except the Sub-opt Code and
Length value) as described in <a href="#section-3">Section 3</a>. The value of the Sub-opt
Code and Length is 2 octets, and the Length does not include itself
or the Sub-opt Code field. The sub-option layout is depicted below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FQDN(s) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option codes are summarized below.
+----------------+---------------+
| Sub-opt Code | Service Name |
+================+===============+
| 1 | IS |
+----------------+---------------+
| 2 | CS |
+----------------+---------------+
| 3 | ES |
+----------------+---------------+
The semantics and content of the DHCPv6 encoding of this option are
exactly the same as the encoding described in <a href="#section-3">Section 3</a>, except the
Option Code and Length value.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Option Usage</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Usage of MoS Options for DHCPv4</span>
The requesting and sending of the proposed DHCPv4 options follow the
rules for DHCP options in [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>].
<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>. Mobile Node Behavior</span>
The mobile node may perform a MoS discovery either during initial
association with a network or when the mobility service is required.
It may also try to perform the MoS discovery when it lacks the
network information for MoS or needs to change the MoS for some
reasons, for instance, to recover from the single point of failure of
the existing MoS.
<span class="grey">Bajko & Das Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
In order to discover the IP address or FQDN of a MoS, the mobile node
(DHCP client) MUST include either a MoS IPv4 Address Option or a MoS
Domain Name List Option in the Parameter Request List (PRL) in the
respective DHCP messages as defined in [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>].
The client MAY include a MoS IPv4 Address Option or a MoS Domain Name
List Option that includes one or more sub-option(s) with the Sub-opt
Code or Codes that represent the service(s) the mobile node is
interested in. However, a client SHOULD be prepared to accept a
response from a server that includes other sub-option(s) or does not
include the requested sub-option(s).
<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>. DHCP Server Behavior</span>
When the DHCP server receives either a MoS IPv4 Address Option or a
MoS Domain Name List Option in the PRL, the DHCP server MUST include
the option in its response message as defined in [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>].
A server MAY use the sub-options in the received MoS IPv4 Address
Option or MoS Domain Name List Option from the client's message to
restrict its response to the client requested sub-options. In the
case when the server cannot find any Mobility Server satisfying a
requested sub-option, the server SHOULD return the MoS Option with
that sub-option and the length of the sub-option set to 0.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Usage of MoS Options for DHCPv6</span>
The requesting and sending of the proposed DHCPv6 options follow the
rules for DHCP options in [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>].
<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>. Mobile Node Behavior</span>
The mobile node may perform the MoS discovery either during initial
association with a network or when the mobility service is required.
It may also try to perform the MoS discovery when it lacks the
network information for MoS or needs to change the MoS for some
reasons, for instance, to recover from the single point of failure of
the existing MoS.
In order to discover the IP address or FQDN of a MoS, the mobile node
(DHCP client) MUST include either a MoS IPv6 Address Option or a MoS
Domain Name List Option in the Option Request Option (ORO) in the
respective DHCP messages as defined in [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>].
The client MAY include a MoS IPv6 Address Option or a MoS Domain Name
List Option that includes one or more sub-option(s) with the Sub-opt
Code or Codes that represent the service(s) the mobile node is
<span class="grey">Bajko & Das Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
interested in. However, a client SHOULD be prepared to accept a
response from a server that includes other sub-option(s) or does not
include the requested sub-option(s).
<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>. DHCP Server Behavior</span>
When the DHCP server receives either a MoS IPv6 Address Option or a
MoS Domain Name List Option in the ORO, the DHCP server MUST include
the option in its response message as defined in [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>].
A server MAY use the sub-options in the received MoS IPv6 Address
Option or MoS Domain Name List Option from the client's message to
restrict its response to the client-requested sub-options. In the
case when the server cannot find any Mobility Server satisfying a
requested sub-option, the server SHOULD return the MoS Option with
that sub-option and the length of the sub-option set to 0.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
The security considerations in [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>] apply. If an adversary
manages to modify the response from a DHCP server or insert its own
response, an MN could be led to contact a rogue Mobility Server,
possibly one that then would provide wrong information, event or
command for handover.
It is recommended to use either DHCP authentication option described
in [<a href="./rfc3118" title=""Authentication for DHCP Messages"">RFC3118</a>] where available. This will also protect the denial-of-
service attacks to DHCP servers. [<a href="./rfc3118" title=""Authentication for DHCP Messages"">RFC3118</a>] provides mechanisms for
both entity authentication and message authentication.
In deployments where DHCP authentication is not available, lower-
layer security services may be sufficient to protect DHCP messages.
Regarding domain name resolution, it is recommended to consider the
usage of DNSSEC [<a href="./rfc4033" title=""DNS Security Introduction and Requirements"">RFC4033</a>] and the aspects of DNSSEC Operational
Practices [<a href="./rfc4641" title=""DNSSEC Operational Practices"">RFC4641</a>]. Security considerations described in [<a href="./rfc5679" title=""Locating IEEE 802.21 Mobility Services Using DNS"">RFC5679</a>]
also apply.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
This document defines two new DHCPv4 options as described in Sections
2 and 3.
MoS IPv4 Address Option for DHCPv4 (OPTION-IPv4_Address-MoS) 139
MoS Domain Name List option for DHCPv4 (OPTION-IPv4_FQDN-MoS) 140
<span class="grey">Bajko & Das Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
This document creates a new registry for the Sub-Option fields in the
MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 Service
Type" (<a href="#section-2">Section 2</a> and 3).
IS 1
CS 2
ES 3
The values '0' and '255' are reserved. Values '1' through '3' are
allocated as above, and the rest are available for allocation. New
values can be allocated via Standards Action as defined in [<a href="./rfc5226" title="">RFC5226</a>].
This document also defines two DHCPv6 options as described in
Sections <a href="#section-4">4</a> and <a href="#section-5">5</a>.
MoS IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-MoS) 54
MoS Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-MoS) 55
This document creates a new registry for the sub-option field in the
MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 IPv6
Service Type" (Sections <a href="#section-4">4</a> and <a href="#section-5">5</a>).
IS 1
CS 2
ES 3
The values '0' and '65535' are reserved. Values '1' through '3' are
allocated as above, and the rest are available for allocation. New
values can be allocated via Standards Action as defined in [<a href="./rfc5226" title="">RFC5226</a>].
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
The authors would like to acknowledge the following individuals for
their valuable comments: Alfred Hoenes, Bernie Volz, David W.
Hankins, Jari Arkko, Telemaco Melia, Ralph Droms, Ted Lemon, Vijay
Devarapalli, and Yoshihiro Ohba.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.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-RFC2131">RFC2131</a>] Droms, R., "Dynamic Host Configuration Protocol", <a href="./rfc2131">RFC</a>
<a href="./rfc2131">2131</a>, March 1997.
<span class="grey">Bajko & Das Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5678">RFC 5678</a> Mobility Services for DCHP Options December 2009</span>
[<a id="ref-RFC3118">RFC3118</a>] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for
DHCP Messages", <a href="./rfc3118">RFC 3118</a>, June 2001.
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, July 2003.
[<a id="ref-RFC3396">RFC3396</a>] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", <a href="./rfc3396">RFC 3396</a>,
November 2002.
[<a id="ref-RFC4033">RFC4033</a>] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", <a href="./rfc4033">RFC</a>
<a href="./rfc4033">4033</a>, March 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.
[<a id="ref-RFC5677">RFC5677</a>] Melia, T., Ed., Bajko, G., Das, S., Golmie, N., and JC.
Zuniga, "IEEE 802.21 Mobility Services Framework Design
(MSFD)", <a href="./rfc5677">RFC 5677</a>, December 2009.
[<a id="ref-RFC5679">RFC5679</a>] Bajko, G., "Locating IEEE 802.21 Mobility Services Using
DNS", <a href="./rfc5679">RFC 5679</a>, December 2009.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-RFC4641">RFC4641</a>] Kolkman, O. and R. Gieben, "DNSSEC Operational
Practices", <a href="./rfc4641">RFC 4641</a>, September 2006.
[<a id="ref-IEEE802.21">IEEE802.21</a>] "IEEE Standard for Local and Metropolitan Area Networks
- Part 21: Media Independent Handover Services", IEEE
LAN/MAN Std 802.21-2008, January 2009,
<a href="http://www.ieee802.org/21/private/Published%20Spec/802.21-2008.pdf">http://www.ieee802.org/21/private/Published%20Spec/</a>
<a href="http://www.ieee802.org/21/private/Published%20Spec/802.21-2008.pdf">802.21-2008.pdf</a> (access to the document requires
membership).
Authors' Addresses
Gabor Bajko
Nokia
EMail: gabor.bajko@nokia.com
Subir Das
Telcordia Technologies Inc.
EMail: subir@research.telcordia.com
Bajko & Das Standards Track [Page 14]
</pre>
|
