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
|
<pre>Network Working Group G. Bajko
Request for Comments: 5679 Nokia
Category: Standards Track December 2009
<span class="h1">Locating IEEE 802.21 Mobility Services Using DNS</span>
Abstract
This document defines application service tags that allow service
location without relying on rigid domain naming conventions, and DNS
procedures for discovering servers that provide IEEE 802.21-defined
Mobility Services. Such Mobility Services are used to assist a
Mobile Node (MN) supporting IEEE 802.21, in handover preparation
(network discovery) and handover decision (network selection). The
services addressed by 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 Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5679">RFC 5679</a> Locating Mobility Services Using DNS 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>. Discovering a Mobility Server ...................................<a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Selecting a Mobility Service ...............................<a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Selecting the Transport Protocol ...........................<a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Determining the IP Address and Port ........................<a href="#page-6">6</a>
<a href="#section-3">3</a>. IANA Considerations .............................................<a href="#page-7">7</a>
<a href="#section-4">4</a>. Security Considerations .........................................<a href="#page-8">8</a>
<a href="#section-5">5</a>. Normative References ............................................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Informative References ..........................................<a href="#page-9">9</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) MIH Information Service (MIHIS)
IS provide 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, with the objective to help the higher-layer
mobility protocols to acquire a global view of the heterogeneous
networks and perform seamless handover across these networks.
b) MIH Event Service (MIHES)
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 Services may also be used to
indicate management actions or command status on the part of the
network or some management entity.
c) MIH Command Service (MIHCS)
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.
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.
<span class="grey">Bajko Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5679">RFC 5679</a> Locating Mobility Services Using DNS December 2009</span>
"Service Management" service messages, i.e., MIH registration, MIH
capability discovery and MIH event subscription messages, are
considered as MIHES and MIHCS when transporting MIH messages over L3
transport.
A Mobile Node (MN) may make use of any of these MIH service types
separately or any combination of them.
It is anticipated that a Mobility Server will 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 a number of application service tags that allow
service location without relying on rigid domain naming conventions.
<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: composed of a set of different services provided
by the network to mobile nodes to facilitate handover preparation and
handover decision, as described in [<a href="#ref-IEEE802.21" title=""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services"">IEEE802.21</a>] and [<a href="./rfc5164" title=""Mobility Services Transport: Problem Statement"">RFC5164</a>].
Mobility Server: a network node providing IEEE 802.21 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>].
Application service: is a generic term for some type of application,
independent of the protocol that may be used to offer it. Each
application service will be associated with an IANA-registered tag.
Application protocol: is used to implement the application service.
These are also associated with IANA-registered tags.
Home domain: the DNS suffix of the operator with which the Mobile
Node has a subscription service. The suffix is usually stored in the
Mobile Node as part of the subscription.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Discovering a Mobility Server</span>
The Dynamic Delegation Discovery System (DDDS) [<a href="./rfc3401" title=""Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS"">RFC3401</a>] is used to
implement lazy binding of strings to data, in order to support
dynamically configured delegation systems. The DDDS functions by
<span class="grey">Bajko Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5679">RFC 5679</a> Locating Mobility Services Using DNS December 2009</span>
mapping some unique string to data stored within a DDDS database by
iteratively applying string transformation rules until a terminal
condition is reached. When DDDS uses DNS as a distributed database
of rules, these rules are encoded using the Naming Authority Pointer
(NAPTR) Resource Record (RR). One of these rules is the First Well
Known Rule, which says where the process starts.
In current specifications, the First Well Known Rule in a DDDS
application [<a href="./rfc3403" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">RFC3403</a>] is assumed to be fixed, i.e., the domain in the
tree where the lookups are to be routed to, is known. This document
proposes the input to the First Well Known Rule to be dynamic, based
on the search path the resolver discovers or is configured with.
The search path of the resolver can either be pre-configured,
discovered using DHCP, or learned from a previous MIH Information
Services (IS) query [<a href="#ref-IEEE802.21" title=""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services"">IEEE802.21</a>] as described in [<a href="./rfc5677" title=""IEEE 802.21 Mobility Services Framework Design (MSFD)"">RFC5677</a>].
When the MN needs to discover Mobility Services in its home domain,
the input to the First Well Known Rule MUST be the MN's home domain,
which is assumed to be pre-configured in the MN.
When the MN needs to discover Mobility Services in a local (visited)
domain, it SHOULD use DHCP as described in [<a href="./rfc5678" title=""Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery"">RFC5678</a>] to discover the
IP address of the server hosting the desired service, and contact it
directly. In some instances, the discovery may result in a per
protocol/application list of domain names that are then used as
starting points for the subsequent NAPTR lookups. If neither the IP
address or domain name can be discovered with the above procedure,
the MN MAY request a domain search list, as described in [<a href="./rfc3397" title=""Dynamic Host Configuration Protocol (DHCP) Domain Search Option"">RFC3397</a>]
and [<a href="./rfc3646" title=""DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3646</a>], and use it as input to the DDDS application.
The MN may also have a list of cached domain names of Service
Providers, learned from a previous MIH Information Services (IS)
query [<a href="#ref-IEEE802.21" title=""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services"">IEEE802.21</a>]. If the cache entries have not expired, they can
be used as input to the DDDS application.
When the MN does not find valid domain names using the procedures
above, it MUST stop any attempt to discover MIH services.
The dynamic rule described above SHOULD NOT be used for discovering
services other than MIH services described in this document, unless
stated otherwise by a future specification.
The procedures defined here result in an IP address, port, and
transport protocol where the MN can contact the Mobility Server that
hosts the service the MN is looking for.
<span class="grey">Bajko Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5679">RFC 5679</a> Locating Mobility Services Using DNS December 2009</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Selecting a Mobility Service</span>
The MN should know the characteristics of the Mobility Services
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>], and based on that, it should be able to
select the service it wants to use to facilitate its handover. The
services it can choose from are:
- Information Services (MIHIS)
- Event Services (MIHES)
- Command Services (MIHCS)
The service identifiers for the services are "MIHIS", "MIHES", and
"MIHCS", respectively. The server supporting any of the above
services MUST support at least UDP and TCP as transport, as described
in [<a href="./rfc5677" title=""IEEE 802.21 Mobility Services Framework Design (MSFD)"">RFC5677</a>]. SCTP and other transport protocols MAY also be
supported.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Selecting the Transport Protocol</span>
After the desired service has been chosen, the client selects the
transport protocol it prefers to use. Note that transport selection
may impact the handover performance.
The services relevant for the task of transport protocol selection
are those with NAPTR service fields with values "ID+M2X", where ID is
the service identifier defined in the previous section, and X is a
letter that corresponds to a transport protocol supported by the
domain. This specification defines M2U for UDP, M2T for TCP and M2S
for SCTP. This document also establishes an IANA registry for
mappings of NAPTR service name to transport protocol.
These NAPTR [<a href="./rfc3403" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">RFC3403</a>] records provide a mapping from a domain to the
SRV [<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>] record for contacting a server with the specific
transport protocol in the NAPTR services field. The resource record
MUST contain an empty regular expression and a replacement value,
which indicates the domain name where the SRV record for that
particular transport protocol can be found. If the server supports
multiple transport protocols, there will be multiple NAPTR records,
each with a different service value. As per [<a href="./rfc3403" title=""Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database"">RFC3403</a>], the client
discards any records whose services fields are not applicable.
The MN MUST discard any service fields that identify a resolution
service whose value is not "M2X", for values of X that indicate
transport protocols supported by the client. The NAPTR processing as
described in <a href="./rfc3403">RFC 3403</a> will result in the discovery of the most
preferred transport protocol of the server that is supported by the
client, as well as an SRV record for the server.
<span class="grey">Bajko Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5679">RFC 5679</a> Locating Mobility Services Using DNS December 2009</span>
As an example, consider a client that wishes to find MIHIS service in
the example.com domain. The client performs a NAPTR query for that
domain, and the following NAPTR records are returned:
Order Pref Flags Service Regexp Replacement
IN NAPTR 50 50 "s" "MIHIS+M2T" "" _MIHIS._tcp.example.com
IN NAPTR 90 50 "s" "MIHIS+M2U" "" _MIHIS._udp.example.com
This indicates that the domain does have a server providing MIHIS
services over TCP and UDP, in that order of preference. Since the
client supports TCP and UDP, TCP will be used, targeted to a host
determined by an SRV lookup of _MIHIS._tcp.example.com. That lookup
would return:
;; Priority Weight Port Target
IN SRV 0 1 XXXX server1.example.com
IN SRV 0 2 XXXX server2.example.com
where XXXX represents the port number at which the service is
reachable.
If no NAPTR records are found, the client constructs SRV queries for
those transport protocols it supports, and does a query for each.
Queries are done using the service identifier "_MIHIS" for the MIH
Information Service, "_MIHES" for the MIH Event Service and "_MIHCS"
for the MIH Command Service. A particular transport is supported if
the query is successful. The client MAY use any transport protocol
it desires that is supported by the server.
Note that the regexp field in the NAPTR example above is empty. The
regexp field MUST NOT be used when discovering MIH services, as its
usage can be complex and error prone. Also, the discovery of the MIH
services does not require the flexibility provided by this field over
a static target present in the TARGET field.
If the client is already configured with the information about which
transport protocol is used for a mobility service in a particular
domain, it can directly perform an SRV query for that specific
transport using the service identifier of the Mobility Service. For
example, if the client knows that it should be using TCP for MIHIS
service, it can perform a SRV query directly for
_MIHIS._tcp.example.com.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Determining the IP Address and Port</span>
Once the server providing the desired service and the transport
protocol has been determined, the next step is to determine the IP
address and port.
<span class="grey">Bajko Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5679">RFC 5679</a> Locating Mobility Services Using DNS December 2009</span>
The response to the SRV DNS query contains the port number in the
Port field of the SRV RDATA.
According to the specification of SRV RRs in [<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>], the TARGET
field is a fully qualified domain name (FQDN) that MUST have one or
more address records; the FQDN must not be an alias, i.e., there MUST
NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query
already has reported a sufficient number of these address records in
the Additional Data section of the DNS response (as recommended by
[<a href="./rfc2782" title=""A DNS RR for specifying the location of services (DNS SRV)"">RFC2782</a>]), the MN needs to perform A and/or AAAA record lookup(s) of
the domain name, as appropriate. The result will be a list of IP
addresses, each of which can be contacted using the transport
protocol determined previously.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. IANA Considerations</span>
The usage of NAPTR records described here requires well-known values
for the service fields for each transport supported by Mobility
Services. The table of mappings from service field values to
transport protocols is to be maintained by IANA.
The registration in the RFC MUST include the following information:
Service Field: The service field being registered.
Protocol: The specific transport protocol associated with that
service field. This MUST include the name and acronym for the
protocol, along with reference to a document that describes the
transport protocol.
Name and Contact Information: The name, address, email address,
and telephone number for the person performing the registration.
The following values have been placed into the registry:
Service Fields Protocol
MIHIS+M2T TCP
MIHIS+M2U UDP
MIHIS+M2S SCTP
MIHES+M2T TCP
MIHES+M2U UDP
MIHES+M2S SCTP
MIHCS+M2T TCP
MIHCS+M2U UDP
MIHCS+M2S SCTP
New Service Fields are to be added via Standards Action as defined in
[<a href="./rfc5226" title="">RFC5226</a>].
<span class="grey">Bajko Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5679">RFC 5679</a> Locating Mobility Services Using DNS December 2009</span>
New entries to the table that specify additional transport protocols
for the existing Service Fields may similarly be registered by IANA
through Standards Action [<a href="./rfc5226" title="">RFC5226</a>].
IANA is also requested to register MIHIS, MIHES, MIHCS as service
names in the Protocol and Service Names registry.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
A list of known threats to services using DNS is documented in
[<a href="./rfc3833" title=""Threat Analysis of the Domain Name System (DNS)"">RFC3833</a>]. For most of those identified threats, the DNS Security
Extensions [<a href="./rfc4033" title=""DNS Security Introduction and Requirements"">RFC4033</a>] does provide protection. It is therefore
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>] when deploying IEEE 802.21
Mobility Services.
In deployments where DNSSEC usage is not feasible, measures should be
taken to protect against forged DNS responses and cache poisoning as
much as possible. Efforts in this direction are documented in
[<a href="./rfc5452" title=""Measures for Making DNS More Resilient against Forged Answers"">RFC5452</a>].
Where inputs to the procedure described in this document are fed via
DHCP, DHCP vulnerabilities can also cause issues. For instance, the
inability to authenticate DHCP discovery results may lead to the
mobility service results also being incorrect, even if the DNS
process was secured.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</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-RFC2782">RFC2782</a>] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", <a href="./rfc2782">RFC</a>
<a href="./rfc2782">2782</a>, February 2000.
[<a id="ref-RFC3397">RFC3397</a>] Aboba, B. and S. Cheshire, "Dynamic Host Configuration
Protocol (DHCP) Domain Search Option", <a href="./rfc3397">RFC 3397</a>,
November 2002.
[<a id="ref-RFC3403">RFC3403</a>] Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part Three: The Domain Name System (DNS)
Database", <a href="./rfc3403">RFC 3403</a>, October 2002.
[<a id="ref-RFC3646">RFC3646</a>] Droms, R., Ed., "DNS Configuration options for Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)", <a href="./rfc3646">RFC</a>
<a href="./rfc3646">3646</a>, December 2003.
<span class="grey">Bajko Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5679">RFC 5679</a> Locating Mobility Services Using DNS December 2009</span>
[<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-RFC5678">RFC5678</a>] Bajko, G. and S. Das, "Dynamic Host Configuration
Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21
Mobility Services (MoS) Discovery", <a href="./rfc5678">RFC 5678</a>, December
2009.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Informative References</span>
[<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).
[<a id="ref-RFC3401">RFC3401</a>] Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part One: The Comprehensive DDDS", <a href="./rfc3401">RFC 3401</a>,
October 2002.
[<a id="ref-RFC3833">RFC3833</a>] Atkins, D. and R. Austein, "Threat Analysis of the
Domain Name System (DNS)", <a href="./rfc3833">RFC 3833</a>, August 2004.
[<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-RFC5164">RFC5164</a>] Melia, T., Ed., "Mobility Services Transport: Problem
Statement", <a href="./rfc5164">RFC 5164</a>, March 2008.
[<a id="ref-RFC5452">RFC5452</a>] Hubert, A. and R. van Mook, "Measures for Making DNS
More Resilient against Forged Answers", <a href="./rfc5452">RFC 5452</a>,
January 2009.
Author's Address
Gabor Bajko
Nokia
EMail: gabor.bajko@nokia.com
Bajko Standards Track [Page 9]
</pre>
|
