Network Working Group G. Bajko
Request for Comments: 5679 Nokia
Category: Standards Track December 2009
Network Working Group G. Bajko
Request for Comments: 5679 Nokia
Category: Standards Track December 2009
Locating IEEE 802.21 Mobility Services Using DNS
使用DNS定位IEEE 802.21移动服务
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.
本文档定义了允许服务定位而不依赖严格的域命名约定的应用程序服务标签，以及用于发现提供IEEE 802.21定义的移动服务的服务器的DNS过程。此类移动服务用于协助支持IEEE 802.21的移动节点（MN）进行切换准备（网络发现）和切换决策（网络选择）。本文件所述服务为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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Discovering a Mobility Server ...................................3
2.1. Selecting a Mobility Service ...............................5
2.2. Selecting the Transport Protocol ...........................5
2.3. Determining the IP Address and Port ........................6
3. IANA Considerations .............................................7
4. Security Considerations .........................................8
5. Normative References ............................................8
6. Informative References ..........................................9
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. Discovering a Mobility Server ...................................3
2.1. Selecting a Mobility Service ...............................5
2.2. Selecting the Transport Protocol ...........................5
2.3. Determining the IP Address and Port ........................6
3. IANA Considerations .............................................7
4. Security Considerations .........................................8
5. Normative References ............................................8
6. Informative References ..........................................9
IEEE 802.21 [IEEE802.21] defines three distinct service types to facilitate link-layer handovers across heterogeneous technologies:
IEEE 802.21[IEEE802.21]定义了三种不同的服务类型，以促进跨异构技术的链路层切换：
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.
a) MIH信息服务（MIHIS）为异构网络环境中的高层实体提供统一的框架，以便于发现和选择地理区域内存在的多种类型的网络，目的是帮助高层移动协议获得异构网络的全局视图，并在这些网络之间执行无缝切换。
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.
b) MIH事件服务（MIHES）事件可指示物理、数据链路和逻辑链路层的状态和传输行为的变化，或预测这些层的状态变化。事件服务还可用于指示网络或某些管理实体的管理操作或命令状态。
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.
c) MIH命令服务（MIHCS）命令服务允许更高层控制物理、数据链路和逻辑链路层。更高层可以通过一组切换命令来控制适当链路的重新配置或选择。
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.
在IEEE术语中，这些服务称为媒体独立切换（MIH）服务。虽然这些服务可能位于同一地点，但它们提供的不同模式和类型的信息并不需要位于同一地点。
"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.
“服务管理”服务消息，即MIH注册、MIH能力发现和MIH事件订阅消息，在通过L3传输传输MIH消息时被视为MIHES和MIHCS。
A Mobile Node (MN) may make use of any of these MIH service types separately or any combination of them.
移动节点（MN）可以单独使用这些MIH服务类型中的任何一种或它们的任何组合。
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.
预计移动服务器不一定会同时承载所有这三种MIH服务，因此需要分别发现MIH服务类型。
This document defines a number of application service tags that allow service location without relying on rigid domain naming conventions.
本文档定义了许多应用程序服务标记，这些标记允许在不依赖严格的域命名约定的情况下进行服务定位。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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 [IEEE802.21] and [RFC5164].
移动性服务：由网络向移动节点提供的一组不同服务组成，以便于切换准备和切换决策，如[IEEE802.21]和[RFC5164]所述。
Mobility Server: a network node providing IEEE 802.21 Mobility Services.
移动服务器：提供IEEE 802.21移动服务的网络节点。
MIH: Media Independent Handover, as defined in [IEEE802.21].
MIH:IEEE802.21中定义的媒体独立切换。
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.
应用程序服务：是某种类型应用程序的通用术语，独立于可能用于提供服务的协议。每个应用程序服务都将与IANA注册的标记相关联。
Application protocol: is used to implement the application service. These are also associated with IANA-registered tags.
应用程序协议：用于实现应用程序服务。这些标签还与IANA注册的标签相关联。
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.
主域：移动节点拥有订阅服务的运营商的DNS后缀。后缀通常作为订阅的一部分存储在移动节点中。
The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by
动态委托发现系统（DDDS）[RFC3401]用于实现字符串到数据的延迟绑定，以支持动态配置的委托系统。DDDS的功能是
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.
通过迭代应用字符串转换规则，将某些唯一字符串映射到DDDS数据库中存储的数据，直到达到终端条件为止。当DDDS使用DNS作为分布式规则数据库时，这些规则使用命名机构指针（NAPTR）资源记录（RR）进行编码。其中一条规则是第一条众所周知的规则，它说明了流程从何处开始。
In current specifications, the First Well Known Rule in a DDDS application [RFC3403] 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.
在当前规范中，假设DDDS应用程序[RFC3403]中的第一条众所周知的规则是固定的，即查找路由到的树中的域是已知的。本文档根据解析器发现或配置的搜索路径，建议将第一个已知规则的输入设置为动态。
The search path of the resolver can either be pre-configured, discovered using DHCP, or learned from a previous MIH Information Services (IS) query [IEEE802.21] as described in [RFC5677].
解析程序的搜索路径可以预先配置、使用DHCP查找，或者从[RFC5677]中所述的先前MIH信息服务（IS）查询[IEEE802.21]中学习。
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.
当MN需要在其归属域中发现移动服务时，第一个已知规则的输入必须是MN的归属域，该归属域被假定为在MN中预配置的。
When the MN needs to discover Mobility Services in a local (visited) domain, it SHOULD use DHCP as described in [RFC5678] 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 [RFC3397] and [RFC3646], and use it as input to the DDDS application.
当MN需要在本地（访问）域中发现移动服务时，它应该使用[RFC5678]中描述的DHCP来发现托管所需服务的服务器的IP地址，并直接与它联系。在某些情况下，发现可能会产生每个协议/应用程序的域名列表，然后将其用作后续NAPTR查找的起点。如果IP地址或域名都无法通过上述过程找到，MN可以请求域搜索列表，如[RFC3397]和[RFC3646]中所述，并将其用作DDDS应用程序的输入。
The MN may also have a list of cached domain names of Service Providers, learned from a previous MIH Information Services (IS) query [IEEE802.21]. If the cache entries have not expired, they can be used as input to the DDDS application.
MN还可以具有从先前的MIH信息服务（IS）查询[IEEE802.21]中获知的服务提供商的缓存域名的列表。如果缓存项尚未过期，则可以将其用作DDDS应用程序的输入。
When the MN does not find valid domain names using the procedures above, it MUST stop any attempt to discover MIH services.
当MN使用上述过程找不到有效域名时，它必须停止发现MIH服务的任何尝试。
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.
除非未来规范另有规定，否则上述动态规则不应用于发现本文档中描述的MIH服务以外的服务。
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.
这里定义的过程产生一个IP地址、端口和传输协议，MN可以在其中联系承载MN正在寻找的服务的移动服务器。
The MN should know the characteristics of the Mobility Services defined in [IEEE802.21], 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)
MN应该知道[IEEE802.21]中定义的移动服务的特征，并且基于此，它应该能够选择它想要使用的服务以促进其切换。它可以选择的服务有：-信息服务（MIHIS）-事件服务（MIHES）-命令服务（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 [RFC5677]. SCTP and other transport protocols MAY also be supported.
服务的服务标识符分别是“MIHIS”、“MIHES”和“MIHCS”。支持上述任何服务的服务器必须至少支持UDP和TCP作为传输，如[RFC5677]所述。还可以支持SCTP和其他传输协议。
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.
与传输协议选择任务相关的服务是具有值为“ID+M2X”的NAPTR服务字段的服务，其中ID是上一节中定义的服务标识符，X是与域支持的传输协议相对应的字母。本规范定义了用于UDP的M2U、用于TCP的M2T和用于SCTP的M2S。本文档还为NAPTR服务名称到传输协议的映射建立了IANA注册表。
These NAPTR [RFC3403] records provide a mapping from a domain to the SRV [RFC2782] 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 [RFC3403], the client discards any records whose services fields are not applicable.
这些NAPTR[RFC3403]记录提供了从域到SRV[RFC2782]记录的映射，用于使用NAPTR服务字段中的特定传输协议联系服务器。资源记录必须包含一个空正则表达式和一个替换值，该替换值指示可以在其中找到特定传输协议的SRV记录的域名。如果服务器支持多个传输协议，则将有多个NAPTR记录，每个记录具有不同的服务值。根据[RFC3403]，客户将丢弃其服务字段不适用的任何记录。
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 RFC 3403 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.
MN必须放弃标识值不是“M2X”的解析服务的任何服务字段，即表示客户端支持的传输协议的X值。RFC 3403中所述的NAPTR处理将发现客户端支持的服务器的最首选传输协议，以及服务器的SRV记录。
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:
作为一个例子，考虑一个希望在IMPUL.COM域中找到MIHS服务的客户端。客户端对该域执行NAPTR查询，并返回以下NAPTR记录：
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
Order Pref在NAPTR 50 50“s”“MIHIS+M2T”“”中标记服务Regexp替换。在NAPTR 90 50“s”“MIHIS+M2U”“”中标记tcp.example.com。\u 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:
这表明该域确实有一个服务器，按照优先顺序通过TCP和UDP提供MIHIS服务。由于客户端支持TCP和UDP，因此将使用TCP，目标主机由_MIHIS._TCP.example.com的SRV查找确定。该查找将返回：
;; Priority Weight Port Target IN SRV 0 1 XXXX server1.example.com IN SRV 0 2 XXXX server2.example.com
;; SRV 0 1 XXXX server1.example.com中SRV 0 2 XXXX server2.example.com中的优先级权重端口目标
where XXXX represents the port number at which the service is reachable.
其中XXXX表示可访问服务的端口号。
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.
如果找不到NAPTR记录，客户端将为其支持的传输协议构造SRV查询，并对每个传输协议执行查询。使用MIH信息服务的服务标识符“\u MIHIS”，MIH事件服务的服务标识符“\u MIHES”，以及MIH命令服务的服务标识符“\u MIHCS”进行查询。如果查询成功，则支持特定传输。客户端可以使用服务器支持的任何传输协议。
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.
请注意，上面NAPTR示例中的regexp字段为空。在发现MIH服务时，不能使用regexp字段，因为它的使用可能很复杂且容易出错。此外，MIH服务的发现不需要该字段相对于目标字段中存在的静态目标提供的灵活性。
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.
如果客户机已经配置了关于哪个传输协议用于特定域中的移动服务的信息，那么它可以使用移动服务的服务标识符直接对该特定传输执行SRV查询。例如，如果客户机知道它应该将TCP用于MIHIS服务，它可以直接为_MIHIS._TCP.example.com执行SRV查询。
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.
一旦确定了提供所需服务和传输协议的服务器，下一步就是确定IP地址和端口。
The response to the SRV DNS query contains the port number in the Port field of the SRV RDATA.
对SRV DNS查询的响应包含SRV RDATA端口字段中的端口号。
According to the specification of SRV RRs in [RFC2782], 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 [RFC2782]), 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.
根据[RFC2782]中SRV RRs的规范，目标字段是必须有一个或多个地址记录的完全限定域名（FQDN）；FQDN不得为别名，即此名称处不得有CNAME或DNAME RR。除非SRV DNS查询已经在DNS响应的附加数据部分中报告了足够数量的这些地址记录（如[RFC2782]所建议），否则MN需要对域名执行和/或AAAA记录查找（视情况而定）。结果将是一个IP地址列表，可以使用先前确定的传输协议联系每个IP地址。
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.
这里描述的NAPTR记录的使用需要移动服务支持的每个传输的服务字段的已知值。IANA将维护从服务字段值到传输协议的映射表。
The registration in the RFC MUST include the following information:
RFC中的注册必须包括以下信息：
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
服务字段协议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 [RFC5226].
将通过[RFC5226]中定义的标准操作添加新的服务字段。
New entries to the table that specify additional transport protocols for the existing Service Fields may similarly be registered by IANA through Standards Action [RFC5226].
IANA同样可以通过标准行动[RFC5226]注册表中为现有服务字段指定附加传输协议的新条目。
IANA is also requested to register MIHIS, MIHES, MIHCS as service names in the Protocol and Service Names registry.
IANA还被要求在协议和服务名称注册表中将MIHIS、MIHES、MIHCS注册为服务名称。
A list of known threats to services using DNS is documented in [RFC3833]. For most of those identified threats, the DNS Security Extensions [RFC4033] does provide protection. It is therefore recommended to consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational Practices [RFC4641] when deploying IEEE 802.21 Mobility Services.
[RFC3833]中记录了使用DNS的已知服务威胁列表。对于大多数已识别的威胁，DNS安全扩展[RFC4033]确实提供了保护。因此，建议在部署IEEE 802.21移动性服务时考虑DNSSEC[RFC4033 ]和DNSSEC操作实践[RCF461]的方面。
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 [RFC5452].
在无法使用DNSSEC的部署中，应采取措施尽可能防止伪造DNS响应和缓存中毒。[RFC5452]中记录了这方面的工作。
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.
如果本文档中描述的过程的输入通过DHCP提供，DHCP漏洞也会导致问题。例如，无法验证DHCP发现结果可能会导致移动服务结果也不正确，即使DNS进程是安全的。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[RFC3397]Aboba，B.和S.Cheshire，“动态主机配置协议（DHCP）域搜索选项”，RFC 3397，2002年11月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403]Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC34032002年10月。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646]Droms，R.，Ed.“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 3646，2003年12月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5677] Melia, T., Ed., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, "IEEE 802.21 Mobility Services Framework Design (MSFD)", RFC 5677, December 2009.
[RFC5677]Melia，T.，Ed.，Bajko，G.，Das，S.，Golmie，N.，和JC。Zuniga，“IEEE 802.21移动服务框架设计（MSFD）”，RFC 5677，2009年12月。
[RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", RFC 5678, December 2009.
[RFC5678]Bajko，G.和S.Das，“IEEE 802.21移动服务（MoS）发现的动态主机配置协议（DHCPv4和DHCPv6）选项”，RFC 5678，2009年12月。
[IEEE802.21] "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std 802.21-2008, January 2009, http://www.ieee802.org/21/private/Published%20Spec/ 802.21-2008.pdf (access to the document requires membership).
[IEEE802.21]“局域网和城域网IEEE标准-第21部分：媒体独立切换服务”，IEEE LAN/MAN Std 802.21-2008，2009年1月，http://www.ieee802.org/21/private/Published%20Spec/ 802.21-2008.pdf（访问该文件需要会员资格）。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401]Mealling，M.“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
[RFC4641]Kolkman，O.和R.Gieben，“DNSSEC运营实践”，RFC 46412006年9月。
[RFC5164] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
[RFC5164]Melia，T.，编辑，“移动服务运输：问题陈述”，RFC 5164，2008年3月。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5452]Hubert，A.和R.van Mook，“使DNS对伪造答案更具弹性的措施”，RFC 5452，2009年1月。
Author's Address
作者地址
Gabor Bajko Nokia EMail: gabor.bajko@nokia.com
Gabor Bajko诺基亚电子邮件：Gabor。bajko@nokia.com