RFC4339 日本語訳
4339 IPv6 Host Configuration of DNS Server Information Approaches. J.Jeong, Ed.. February 2006. (Format: TXT=60803 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Jeong, Ed. Request for Comments: 4339 ETRI/University of Minnesota Category: Informational February 2006
Network Working Group J. Jeong, Ed. Request for Comments: 4339 ETRI/University of Minnesota Category: Informational February 2006
IPv6 Host Configuration of DNS Server Information Approaches
IPv6 Host Configuration of DNS Server Information Approaches
Status of This Memo
Status of This Memo
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
IESG Note
IESG Note
This document describes three different approaches for the configuration of DNS name resolution server information in IPv6 hosts.
This document describes three different approaches for the configuration of DNS name resolution server information in IPv6 hosts.
There is not an IETF consensus on which approach is preferred. The analysis in this document was developed by the proponents for each approach and does not represent an IETF consensus.
There is not an IETF consensus on which approach is preferred. The analysis in this document was developed by the proponents for each approach and does not represent an IETF consensus.
The 'RA option' and 'Well-known anycast' approaches described in this document are not standardized. Consequently the analysis for these approaches might not be completely applicable to any specific proposal that might be proposed in the future.
The 'RA option' and 'Well-known anycast' approaches described in this document are not standardized. Consequently the analysis for these approaches might not be completely applicable to any specific proposal that might be proposed in the future.
Abstract
Abstract
This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution.
This document describes three approaches for IPv6 recursive DNS server address configuration. It details the operational attributes of three solutions: RA option, DHCPv6 option, and well-known anycast addresses for recursive DNS servers. Additionally, it suggests the deployment scenarios in four kinds of networks (ISP, enterprise, 3GPP, and unmanaged networks) considering multi-solution resolution.
Jeong Informational [Page 1] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 1] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Table of Contents
Table of Contents
1. Introduction ....................................................3 2. Terminology .....................................................3 3. IPv6 DNS Configuration Approaches ...............................3 3.1. RA Option ..................................................3 3.1.1. Advantages ..........................................4 3.1.2. Disadvantages .......................................5 3.1.3. Observations ........................................5 3.2. DHCPv6 Option ..............................................6 3.2.1. Advantages ..........................................7 3.2.2. Disadvantages .......................................8 3.2.3. Observations ........................................9 3.3. Well-known Anycast Addresses ...............................9 3.3.1. Advantages .........................................10 3.3.2. Disadvantages ......................................10 3.3.3. Observations .......................................10 4. Interworking among IPv6 DNS Configuration Approaches ...........11 5. Deployment Scenarios ...........................................12 5.1. ISP Network ...............................................12 5.1.1. RA Option Approach .................................13 5.1.2. DHCPv6 Option Approach .............................13 5.1.3. Well-known Anycast Addresses Approach ..............14 5.2. Enterprise Network ........................................14 5.3. 3GPP Network ..............................................15 5.3.1. Currently Available Mechanisms and Recommendations ....................................15 5.3.2. RA Extension .......................................16 5.3.3. Stateless DHCPv6 ...................................16 5.3.4. Well-known Addresses ...............................17 5.3.5. Recommendations ....................................18 5.4. Unmanaged Network .........................................18 5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18 5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP .....................................19 5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP ...................................19 5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19 6. Security Considerations ........................................19 6.1. RA Option .................................................20 6.2. DHCPv6 Option .............................................21 6.3. Well-known Anycast Addresses ..............................21 7. Contributors ...................................................21 8. Acknowledgements ...............................................23 9. References .....................................................23 9.1. Normative References ......................................23 9.2. Informative References ....................................23
1. Introduction ....................................................3 2. Terminology .....................................................3 3. IPv6 DNS Configuration Approaches ...............................3 3.1. RA Option ..................................................3 3.1.1. Advantages ..........................................4 3.1.2. Disadvantages .......................................5 3.1.3. Observations ........................................5 3.2. DHCPv6 Option ..............................................6 3.2.1. Advantages ..........................................7 3.2.2. Disadvantages .......................................8 3.2.3. Observations ........................................9 3.3. Well-known Anycast Addresses ...............................9 3.3.1. Advantages .........................................10 3.3.2. Disadvantages ......................................10 3.3.3. Observations .......................................10 4. Interworking among IPv6 DNS Configuration Approaches ...........11 5. Deployment Scenarios ...........................................12 5.1. ISP Network ...............................................12 5.1.1. RA Option Approach .................................13 5.1.2. DHCPv6 Option Approach .............................13 5.1.3. Well-known Anycast Addresses Approach ..............14 5.2. Enterprise Network ........................................14 5.3. 3GPP Network ..............................................15 5.3.1. Currently Available Mechanisms and Recommendations ....................................15 5.3.2. RA Extension .......................................16 5.3.3. Stateless DHCPv6 ...................................16 5.3.4. Well-known Addresses ...............................17 5.3.5. Recommendations ....................................18 5.4. Unmanaged Network .........................................18 5.4.1. Case A: Gateway Does Not Provide IPv6 at All .......18 5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP .....................................19 5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP ...................................19 5.4.4. Case D: A Gateway Connected to an IPv6-only ISP ....19 6. Security Considerations ........................................19 6.1. RA Option .................................................20 6.2. DHCPv6 Option .............................................21 6.3. Well-known Anycast Addresses ..............................21 7. Contributors ...................................................21 8. Acknowledgements ...............................................23 9. References .....................................................23 9.1. Normative References ......................................23 9.2. Informative References ....................................23
Jeong Informational [Page 2] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 2] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
1. Introduction
1. Introduction
Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address Autoconfiguration provide ways to configure either fixed or mobile nodes with one or more IPv6 addresses, default routes, and some other parameters [1][2]. To support the access to additional services in the Internet that are identified by a DNS name, such as a web server, the configuration of at least one recursive DNS server is also needed for DNS name resolution.
Neighbor Discovery (ND) for IP Version 6 and IPv6 Stateless Address Autoconfiguration provide ways to configure either fixed or mobile nodes with one or more IPv6 addresses, default routes, and some other parameters [1][2]. To support the access to additional services in the Internet that are identified by a DNS name, such as a web server, the configuration of at least one recursive DNS server is also needed for DNS name resolution.
This document describes three approaches of recursive DNS server address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6 option [3]-[5], and (c) well-known anycast addresses for recursive DNS servers [7]. Also, it suggests the applicable scenarios for four kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP network, and (d) unmanaged network.
This document describes three approaches of recursive DNS server address configuration for IPv6 host: (a) RA option [6], (b) DHCPv6 option [3]-[5], and (c) well-known anycast addresses for recursive DNS servers [7]. Also, it suggests the applicable scenarios for four kinds of networks: (a) ISP network, (b) enterprise network, (c) 3GPP network, and (d) unmanaged network.
This document is just an analysis of each possible approach, and it does not recommend a particular approach or combination of approaches. Some approaches may even not be adopted at all as a result of further discussion.
This document is just an analysis of each possible approach, and it does not recommend a particular approach or combination of approaches. Some approaches may even not be adopted at all as a result of further discussion.
Therefore, the objective of this document is to help the audience select the approaches suitable for IPv6 host configuration of recursive DNS servers.
Therefore, the objective of this document is to help the audience select the approaches suitable for IPv6 host configuration of recursive DNS servers.
2. Terminology
2. Terminology
This document uses the terminology described in [1]-[7]. In addition, a new term is defined below:
This document uses the terminology described in [1]-[7]. In addition, a new term is defined below:
o Recursive DNS Server (RDNSS): Server which provides a recursive DNS resolution service.
o Recursive DNS Server (RDNSS): Server which provides a recursive DNS resolution service.
3. IPv6 DNS Configuration Approaches
3. IPv6 DNS Configuration Approaches
In this section, the operational attributes of the three solutions are described in detail.
In this section, the operational attributes of the three solutions are described in detail.
3.1. RA Option
3.1. RA Option
The RA approach defines a new ND option, called the RDNSS option, that contains a recursive DNS server address [6]. Existing ND transport mechanisms (i.e., advertisements and solicitations) are used. This works in the same way that nodes learn about routers and prefixes. An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA message periodically sent by a router or solicited by a Router Solicitation (RS).
The RA approach defines a new ND option, called the RDNSS option, that contains a recursive DNS server address [6]. Existing ND transport mechanisms (i.e., advertisements and solicitations) are used. This works in the same way that nodes learn about routers and prefixes. An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA message periodically sent by a router or solicited by a Router Solicitation (RS).
Jeong Informational [Page 3] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 3] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
This approach needs RDNSS information to be configured in the routers doing the advertisements. The configuration of RDNSS addresses can be performed manually by an operator or in other ways, such as automatic configuration through a DHCPv6 client running on the router. An RA message with one RDNSS option can include as many RDNSS addresses as needed [6].
This approach needs RDNSS information to be configured in the routers doing the advertisements. The configuration of RDNSS addresses can be performed manually by an operator or in other ways, such as automatic configuration through a DHCPv6 client running on the router. An RA message with one RDNSS option can include as many RDNSS addresses as needed [6].
Through the ND protocol and RDNSS option, along with a prefix information option, an IPv6 host can perform network configuration of its IPv6 address and RDNSS simultaneously [1][2]. The RA option for RDNSS can be used on any network that supports the use of ND.
Through the ND protocol and RDNSS option, along with a prefix information option, an IPv6 host can perform network configuration of its IPv6 address and RDNSS simultaneously [1][2]. The RA option for RDNSS can be used on any network that supports the use of ND.
The RA approach is useful in some mobile environments where the addresses of the RDNSSes are changing because the RA option includes a lifetime field that allows client to use RDNSSes nearer to the client. This can be configured to a value that will require the client to time out the entry and switch over to another RDNSS address [6]. However, from the viewpoint of implementation, the lifetime field would seem to make matters a bit more complex. Instead of just writing to a DNS configuration file, such as resolv.conf for the list of RDNSS addresses, we have to have a daemon around (or a program that is called at the defined intervals) that keeps monitoring the lifetime of RDNSSes all the time.
The RA approach is useful in some mobile environments where the addresses of the RDNSSes are changing because the RA option includes a lifetime field that allows client to use RDNSSes nearer to the client. This can be configured to a value that will require the client to time out the entry and switch over to another RDNSS address [6]. However, from the viewpoint of implementation, the lifetime field would seem to make matters a bit more complex. Instead of just writing to a DNS configuration file, such as resolv.conf for the list of RDNSS addresses, we have to have a daemon around (or a program that is called at the defined intervals) that keeps monitoring the lifetime of RDNSSes all the time.
The preference value of RDNSS, included in the RDNSS option, allows IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this can be used for the load balancing of RDNSSes.
The preference value of RDNSS, included in the RDNSS option, allows IPv6 hosts to select primary RDNSS among several RDNSSes [6]; this can be used for the load balancing of RDNSSes.
3.1.1. Advantages
3.1.1. Advantages
The RA option for RDNSS has a number of advantages. These include:
The RA option for RDNSS has a number of advantages. These include:
1. The RA option is an extension of existing ND/Autoconfig mechanisms [1][2] and does not require a change in the base ND protocol.
1. The RA option is an extension of existing ND/Autoconfig mechanisms [1][2] and does not require a change in the base ND protocol.
2. This approach, like ND, works well on a variety of link types, including point-to-point links, point-to-multipoint, and multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1] states, however, that there may be some link types on which ND is not feasible; on such links, some other mechanisms will be needed for DNS configuration.
2. This approach, like ND, works well on a variety of link types, including point-to-point links, point-to-multipoint, and multipoint-to-multipoint (i.e., Ethernet LANs). RFC 2461 [1] states, however, that there may be some link types on which ND is not feasible; on such links, some other mechanisms will be needed for DNS configuration.
3. All the information a host needs to run the basic Internet applications (such as the email, web, ftp, etc.) can be obtained with the addition of this option to ND and address autoconfiguration. The use of a single mechanism is more reliable and easier to provide than when the RDNSS information is
3. All the information a host needs to run the basic Internet applications (such as the email, web, ftp, etc.) can be obtained with the addition of this option to ND and address autoconfiguration. The use of a single mechanism is more reliable and easier to provide than when the RDNSS information is
Jeong Informational [Page 4] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 4] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
learned via another protocol mechanism. Debugging problems when multiple protocol mechanisms are being used is harder and much more complex.
learned via another protocol mechanism. Debugging problems when multiple protocol mechanisms are being used is harder and much more complex.
4. This mechanism works over a broad range of scenarios and leverages IPv6 ND. This works well on links that are high performance (e.g., Ethernet LANs) and low performance (e.g., cellular networks). In the latter case, by combining the RDNSS information with the other information in the RA, the host can learn all the information needed to use most Internet applications, such as the web, in a single packet. This not only saves bandwidth, but also minimizes the delay needed to learn the RDNSS information.
4. This mechanism works over a broad range of scenarios and leverages IPv6 ND. This works well on links that are high performance (e.g., Ethernet LANs) and low performance (e.g., cellular networks). In the latter case, by combining the RDNSS information with the other information in the RA, the host can learn all the information needed to use most Internet applications, such as the web, in a single packet. This not only saves bandwidth, but also minimizes the delay needed to learn the RDNSS information.
5. The RA approach could be used as a model for similar types of configuration information. New RA options for other server addresses, such as NTP server address, that are common to all clients on a subnet would be easy to define.
5. The RA approach could be used as a model for similar types of configuration information. New RA options for other server addresses, such as NTP server address, that are common to all clients on a subnet would be easy to define.
3.1.2. Disadvantages
3.1.2. Disadvantages
1. ND is mostly implemented in the kernel of the operating system. Therefore, if ND supports the configuration of some additional services, such as DNS servers, ND should be extended in the kernel and complemented by a user-land process. DHCPv6, however, has more flexibility for the extension of service discovery because it is an application layer protocol.
1. ND is mostly implemented in the kernel of the operating system. Therefore, if ND supports the configuration of some additional services, such as DNS servers, ND should be extended in the kernel and complemented by a user-land process. DHCPv6, however, has more flexibility for the extension of service discovery because it is an application layer protocol.
2. The current ND framework should be modified to facilitate the synchronization between another ND cache for RDNSSes in the kernel space and the DNS configuration file in the user space. Because it is unacceptable to write and rewrite to the DNS configuration file (e.g., resolv.conf) from the kernel, another approach is needed. One simple approach to solve this is to have a daemon listening to what the kernel conveys, and to have the daemon do these steps, but such a daemon is not needed with the current ND framework.
2. The current ND framework should be modified to facilitate the synchronization between another ND cache for RDNSSes in the kernel space and the DNS configuration file in the user space. Because it is unacceptable to write and rewrite to the DNS configuration file (e.g., resolv.conf) from the kernel, another approach is needed. One simple approach to solve this is to have a daemon listening to what the kernel conveys, and to have the daemon do these steps, but such a daemon is not needed with the current ND framework.
3. It is necessary to configure RDNSS addresses at least at one router on every link where this information needs to be configured via the RA option.
3. It is necessary to configure RDNSS addresses at least at one router on every link where this information needs to be configured via the RA option.
3.1.3. Observations
3.1.3. Observations
The proposed RDNSS RA option, along with the IPv6 ND and Autoconfiguration, allows a host to obtain all of the information it needs to access basic Internet services like the web, email, ftp, etc. This is preferable in the environments where hosts use RAs to
The proposed RDNSS RA option, along with the IPv6 ND and Autoconfiguration, allows a host to obtain all of the information it needs to access basic Internet services like the web, email, ftp, etc. This is preferable in the environments where hosts use RAs to
Jeong Informational [Page 5] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 5] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
autoconfigure their addresses and all the hosts on the subnet share the same router and server addresses. If the configuration information can be obtained from a single mechanism, it is preferable because it does not add additional delay, and because it uses a minimum of bandwidth. Environments like this include homes, public cellular networks, and enterprise environments where no per host configuration is needed.
autoconfigure their addresses and all the hosts on the subnet share the same router and server addresses. If the configuration information can be obtained from a single mechanism, it is preferable because it does not add additional delay, and because it uses a minimum of bandwidth. Environments like this include homes, public cellular networks, and enterprise environments where no per host configuration is needed.
DHCPv6 is preferable where it is being used for address configuration and if there is a need for host specific configuration [3]-[5]. Environments like this are most likely to be the enterprise environments where the local administration chooses to have per host configuration control.
DHCPv6 is preferable where it is being used for address configuration and if there is a need for host specific configuration [3]-[5]. Environments like this are most likely to be the enterprise environments where the local administration chooses to have per host configuration control.
3.2. DHCPv6 Option
3.2. DHCPv6 Option
DHCPv6 [3] includes the "DNS Recursive Name Server" option, through which a host can obtain a list of IP addresses of recursive DNS servers [5]. The DNS Recursive Name Server option carries a list of IPv6 addresses of RDNSSes to which the host may send DNS queries. The DNS servers are listed in the order of preference for use by the DNS resolver on the host.
DHCPv6 [3] includes the "DNS Recursive Name Server" option, through which a host can obtain a list of IP addresses of recursive DNS servers [5]. The DNS Recursive Name Server option carries a list of IPv6 addresses of RDNSSes to which the host may send DNS queries. The DNS servers are listed in the order of preference for use by the DNS resolver on the host.
The DNS Recursive Name Server option can be carried in any DHCPv6 Reply message, in response to either a Request or an Information request message. Thus, the DNS Recursive Name Server option can be used either when DHCPv6 is used for address assignment, or when DHCPv6 is used only for other configuration information as stateless DHCPv6 [4].
The DNS Recursive Name Server option can be carried in any DHCPv6 Reply message, in response to either a Request or an Information request message. Thus, the DNS Recursive Name Server option can be used either when DHCPv6 is used for address assignment, or when DHCPv6 is used only for other configuration information as stateless DHCPv6 [4].
Stateless DHCPv6 can be deployed either by using DHCPv6 servers running on general-purpose computers, or on router hardware. Several router vendors currently implement stateless DHCPv6 servers. Deploying stateless DHCPv6 in routers has the advantage that no special hardware is required, and it should work well for networks where DHCPv6 is needed for very straightforward configuration of network devices.
Stateless DHCPv6 can be deployed either by using DHCPv6 servers running on general-purpose computers, or on router hardware. Several router vendors currently implement stateless DHCPv6 servers. Deploying stateless DHCPv6 in routers has the advantage that no special hardware is required, and it should work well for networks where DHCPv6 is needed for very straightforward configuration of network devices.
However, routers can also act as DHCPv6 relay agents. In this case, the DHCPv6 server need not be on the router; it can be on a general purpose computer. This has the potential to give the operator of the DHCPv6 server more flexibility in how the DHCPv6 server responds to individual clients that can easily be given different configuration information based on their identity, or for any other reason. Nothing precludes adding this flexibility to a router, but generally, in current practice, DHCP servers running on general-purpose hosts tend to have more configuration options than those that are embedded in routers.
However, routers can also act as DHCPv6 relay agents. In this case, the DHCPv6 server need not be on the router; it can be on a general purpose computer. This has the potential to give the operator of the DHCPv6 server more flexibility in how the DHCPv6 server responds to individual clients that can easily be given different configuration information based on their identity, or for any other reason. Nothing precludes adding this flexibility to a router, but generally, in current practice, DHCP servers running on general-purpose hosts tend to have more configuration options than those that are embedded in routers.
Jeong Informational [Page 6] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 6] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 clients that use a stateful configuration assignment. To do this, the DHCPv6 server sends a Reconfigure message to the client. The client validates the Reconfigure message, and then contacts the DHCPv6 server to obtain updated configuration information. By using this mechanism, it is currently possible to propagate new configuration information to DHCPv6 clients as this information changes.
DHCPv6 currently provides a mechanism for reconfiguring DHCPv6 clients that use a stateful configuration assignment. To do this, the DHCPv6 server sends a Reconfigure message to the client. The client validates the Reconfigure message, and then contacts the DHCPv6 server to obtain updated configuration information. By using this mechanism, it is currently possible to propagate new configuration information to DHCPv6 clients as this information changes.
The DHC Working Group has standardized an additional mechanism through which configuration information, including the list of RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns a lifetime to configuration information obtained through DHCPv6. At the expiration of the lifetime, the host contacts the DHCPv6 server to obtain updated configuration information, including the list of RDNSSes. This lifetime gives the network administrator another mechanism to configure hosts with new RDNSSes by controlling the time at which the host refreshes the list.
The DHC Working Group has standardized an additional mechanism through which configuration information, including the list of RDNSSes, can be updated. The lifetime option for DHCPv6 [8] assigns a lifetime to configuration information obtained through DHCPv6. At the expiration of the lifetime, the host contacts the DHCPv6 server to obtain updated configuration information, including the list of RDNSSes. This lifetime gives the network administrator another mechanism to configure hosts with new RDNSSes by controlling the time at which the host refreshes the list.
The DHC Working Group has also discussed the possibility of defining an extension to DHCPv6 that would allow the use of multicast to provide configuration information to multiple hosts with a single DHCPv6 message. Because of the lack of deployment experience, the WG has deferred consideration of multicast DHCPv6 configuration at this time. Experience with DHCPv4 has not identified a requirement for multicast message delivery, even in large service provider networks with tens of thousands of hosts that may initiate a DHCPv4 message exchange simultaneously.
The DHC Working Group has also discussed the possibility of defining an extension to DHCPv6 that would allow the use of multicast to provide configuration information to multiple hosts with a single DHCPv6 message. Because of the lack of deployment experience, the WG has deferred consideration of multicast DHCPv6 configuration at this time. Experience with DHCPv4 has not identified a requirement for multicast message delivery, even in large service provider networks with tens of thousands of hosts that may initiate a DHCPv4 message exchange simultaneously.
3.2.1. Advantages
3.2.1. Advantages
The DHCPv6 option for RDNSS has a number of advantages. These include:
The DHCPv6 option for RDNSS has a number of advantages. These include:
1. DHCPv6 currently provides a general mechanism for conveying network configuration information to clients. Configuring DHCPv6 servers in this way allows the network administrator to configure RDNSSes, the addresses of other network services, and location- specific information, such as time zones.
1. DHCPv6 currently provides a general mechanism for conveying network configuration information to clients. Configuring DHCPv6 servers in this way allows the network administrator to configure RDNSSes, the addresses of other network services, and location- specific information, such as time zones.
2. As a consequence, when the network administrator goes to configure DHCPv6, all the configuration information can be managed through a single service, typically with a single user interface and a single configuration database.
2. As a consequence, when the network administrator goes to configure DHCPv6, all the configuration information can be managed through a single service, typically with a single user interface and a single configuration database.
Jeong Informational [Page 7] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 7] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
3. DHCPv6 allows for the configuration of a host with information specific to that host, so that hosts on the same link can be configured with different RDNSSes and with other configuration information.
3. DHCPv6 allows for the configuration of a host with information specific to that host, so that hosts on the same link can be configured with different RDNSSes and with other configuration information.
4. A mechanism exists for extending DHCPv6 to support the transmission of additional configuration that has not yet been anticipated.
4. A mechanism exists for extending DHCPv6 to support the transmission of additional configuration that has not yet been anticipated.
5. Hosts that require other configuration information, such as the addresses of SIP servers and NTP servers, are likely to need DHCPv6 for other configuration information.
5. Hosts that require other configuration information, such as the addresses of SIP servers and NTP servers, are likely to need DHCPv6 for other configuration information.
6. The specification for configuration of RDNSSes through DHCPv6 is available as an RFC. No new protocol extensions (such as new options) are necessary.
6. The specification for configuration of RDNSSes through DHCPv6 is available as an RFC. No new protocol extensions (such as new options) are necessary.
7. Interoperability among independent implementations has been demonstrated.
7. Interoperability among independent implementations has been demonstrated.
3.2.2. Disadvantages
3.2.2. Disadvantages
The DHCPv6 option for RDNSS has a few disadvantages. These include:
The DHCPv6 option for RDNSS has a few disadvantages. These include:
1. Update currently requires a message from server (however, see [8]).
1. Update currently requires a message from server (however, see [8]).
2. Because DNS information is not contained in RA messages, the host must receive two messages from the router and must transmit at least one message to the router. On networks where bandwidth is at a premium, this is a disadvantage, although on most networks it is not a practical concern.
2. Because DNS information is not contained in RA messages, the host must receive two messages from the router and must transmit at least one message to the router. On networks where bandwidth is at a premium, this is a disadvantage, although on most networks it is not a practical concern.
3. There is an increased latency for initial configuration. In addition to waiting for an RA message, the client must now exchange packets with a DHCPv6 server. Even if it is locally installed on a router, this will slightly extend the time required to configure the client. For clients that are moving rapidly from one network to another, this will be a disadvantage.
3. There is an increased latency for initial configuration. In addition to waiting for an RA message, the client must now exchange packets with a DHCPv6 server. Even if it is locally installed on a router, this will slightly extend the time required to configure the client. For clients that are moving rapidly from one network to another, this will be a disadvantage.
Jeong Informational [Page 8] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 8] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
3.2.3. Observations
3.2.3. Observations
In the general case, on general-purpose networks, stateless DHCPv6 provides significant advantages and no significant disadvantages. Even in the case where bandwidth is at a premium and low latency is desired, if hosts require other configuration information in addition to a list of RDNSSes or if hosts must be configured selectively, those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive name server option will be advantageous.
In the general case, on general-purpose networks, stateless DHCPv6 provides significant advantages and no significant disadvantages. Even in the case where bandwidth is at a premium and low latency is desired, if hosts require other configuration information in addition to a list of RDNSSes or if hosts must be configured selectively, those hosts will use DHCPv6 and the use of the DHCPv6 DNS recursive name server option will be advantageous.
However, we are aware of some applications where it would be preferable to put the RDNSS information into an RA packet; for example, in a mobile phone network, where bandwidth is at a premium and extremely low latency is desired. The DNS configuration based on RA should be standardized so as to allow these special applications to be handled using DNS information in the RA packet.
However, we are aware of some applications where it would be preferable to put the RDNSS information into an RA packet; for example, in a mobile phone network, where bandwidth is at a premium and extremely low latency is desired. The DNS configuration based on RA should be standardized so as to allow these special applications to be handled using DNS information in the RA packet.
3.3. Well-known Anycast Addresses
3.3. Well-known Anycast Addresses
Anycast uses the same routing system as unicast [9]. However, administrative entities are local ones. The local entities may accept unicast routes (including default routes) to anycast servers from adjacent entities. The administrative entities should not advertise their peer routes to their internal anycast servers, if they want to prohibit external access from some peers to the servers. If some advertisement is inevitable (such as the case with default routes), the packets to the servers should be blocked at the boundary of the entities. Thus, for this anycast, not only unicast routing but also unicast ND protocols can be used as is.
Anycast uses the same routing system as unicast [9]. However, administrative entities are local ones. The local entities may accept unicast routes (including default routes) to anycast servers from adjacent entities. The administrative entities should not advertise their peer routes to their internal anycast servers, if they want to prohibit external access from some peers to the servers. If some advertisement is inevitable (such as the case with default routes), the packets to the servers should be blocked at the boundary of the entities. Thus, for this anycast, not only unicast routing but also unicast ND protocols can be used as is.
First of all, the well-known anycast addresses approach is much different from that discussed by the IPv6 Working Group in the past [7]. Note that "anycast" in this memo is simpler than that of RFC 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to have multiple servers on a single link sharing an anycast address. That is, on a link, an anycast address is assumed to be unique. DNS clients today already have redundancy by having multiple well-known anycast addresses configured as RDNSS addresses. There is no point in having multiple RDNSSes sharing an anycast address on a single link.
First of all, the well-known anycast addresses approach is much different from that discussed by the IPv6 Working Group in the past [7]. Note that "anycast" in this memo is simpler than that of RFC 1546 [9] and RFC 3513 [10], where it is assumed to be prohibited to have multiple servers on a single link sharing an anycast address. That is, on a link, an anycast address is assumed to be unique. DNS clients today already have redundancy by having multiple well-known anycast addresses configured as RDNSS addresses. There is no point in having multiple RDNSSes sharing an anycast address on a single link.
The approach with well-known anycast addresses is to set multiple well-known anycast addresses in clients' resolver configuration files from the beginning as, say, factory default. Thus, there is no transport mechanism and no packet format [7].
The approach with well-known anycast addresses is to set multiple well-known anycast addresses in clients' resolver configuration files from the beginning as, say, factory default. Thus, there is no transport mechanism and no packet format [7].
An anycast address is an address shared by multiple servers (in this case, the servers are RDNSSes). A request from a client to the
An anycast address is an address shared by multiple servers (in this case, the servers are RDNSSes). A request from a client to the
Jeong Informational [Page 9] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
Jeong Informational [Page 9] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
anycast address is routed to a server selected by the routing system. However, it is a bad idea to mandate "site" boundary on anycast addresses, because most users do not have their own servers and want to access their ISPs across their site boundaries. Larger sites may also depend on their ISPs or may have their own RDNSSes within "site" boundaries.
anycast address is routed to a server selected by the routing system. However, it is a bad idea to mandate "site" boundary on anycast addresses, because most users do not have their own servers and want to access their ISPs across their site boundaries. Larger sites may also depend on their ISPs or may have their own RDNSSes within "site" boundaries.
3.3.1. Advantages
3.3.1. Advantages
The basic advantage of the well-known addresses approach is that it uses no transport mechanism. Thus, the following apply:
The basic advantage of the well-known addresses approach is that it uses no transport mechanism. Thus, the following apply:
1. There is no delay to get the response and no further delay by packet losses.
1. There is no delay to get the response and no further delay by packet losses.
2. The approach can be combined with any other configuration mechanisms, such as the RA-based approach and DHCP-based approach, as well as the factory default configuration.
2. The approach can be combined with any other configuration mechanisms, such as the RA-based approach and DHCP-based approach, as well as the factory default configuration.
3. The approach works over any environment where DNS works.
3. The approach works over any environment where DNS works.
Another advantage is that this approach only needs configuration of the DNS servers as a router (or configuration of a proxy router). Considering that DNS servers do need configuration, the amount of overall configuration effort is proportional to the number of DNS servers and it scales linearly. Note that, in the simplest case, where a subscriber to an ISP does not have a DNS server, the subscriber naturally accesses DNS servers of the ISP, even though the subscriber and the ISP do nothing and there is no protocol to exchange DNS server information between the subscriber and the ISP.
Another advantage is that this approach only needs configuration of the DNS servers as a router (or configuration of a proxy router). Considering that DNS servers do need configuration, the amount of overall configuration effort is proportional to the number of DNS servers and it scales linearly. Note that, in the simplest case, where a subscriber to an ISP does not have a DNS server, the subscriber naturally accesses DNS servers of the ISP, even though the subscriber and the ISP do nothing and there is no protocol to exchange DNS server information between the subscriber and the ISP.
3.3.2. Disadvantages
3.3.2. Disadvantages
The well-known anycast addresses approach requires that DNS servers (or routers near to them as a proxy) act as routers to advertise their anycast addresses to the routing system, which requires some configuration (see the last paragraph of the previous section on the scalability of the effort). In addition, routers at the boundary of the "site" might need the configuration of route filters to prevent providing DNS services for parties outside the "site" and the possibility of denial of service attacks on the internal DNS infrastructure.
The well-known anycast addresses approach requires that DNS servers (or routers near to them as a proxy) act as routers to advertise their anycast addresses to the routing system, which requires some configuration (see the last paragraph of the previous section on the scalability of the effort). In addition, routers at the boundary of the "site" might need the configuration of route filters to prevent providing DNS services for parties outside the "site" and the possibility of denial of service attacks on the internal DNS infrastructure.
3.3.3. Observations
3.3.3. Observations
If other approaches are used in addition, the well-known anycast addresses should also be set in RA or DHCP configuration files to reduce the configuration effort of users.
また、他のアプローチがさらに、使用されるなら、RAかDHCP構成ファイルによく知られるanycastアドレスがユーザの構成取り組みを減少させるように設定されるべきです。
Jeong Informational [Page 10] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[10ページ]のRFC4339IPv6ホスト構成
The redundancy by multiple RDNSSes is better provided by multiple servers with different anycast addresses than by multiple servers sharing the same anycast address, because the former approach allows stale servers to generate routes to their anycast addresses. Thus, in a routing domain (or domains sharing DNS servers), there will be only one server with an anycast address unless the domain is so large that load distribution is necessary.
複数のサーバで同じanycastアドレスを共有する複数のサーバと異なったanycastアドレスに複数のRDNSSesによる冗長を提供するほうがよいです、聞き古したサーバが前のアプローチでそれらのanycastアドレスにルートを生成することができるので。 したがって、経路ドメイン(または、DNSサーバを共有するドメイン)には、ドメインが非常に大きいので負荷分配は必要でない場合、anycastアドレスがある1つのサーバしかないでしょう。
Small ISPs will operate one RDNSS at each anycast address that is shared by all the subscribers. Large ISPs may operate multiple RDNSSes at each anycast address to distribute and reduce load, where the boundary between RDNSSes may be fixed (redundancy is still provided by multiple addresses) or change dynamically. DNS packets with the well-known anycast addresses are not expected (though not prohibited) to cross ISP boundaries, as ISPs are expected to be able to take care of themselves.
小さいISPはすべての加入者によって共有されるそれぞれのanycastアドレスの1RDNSSを操作するでしょう。 大きいISPは負荷を分配して、減少させるためにそれぞれのanycastアドレスの複数のRDNSSesを操作するかもしれません、RDNSSesの間の境界が修理されているか(複数のアドレスはまだ冗長を提供しています)、またはダイナミックに変化するかもしれないところで。 よく知られるanycastアドレスがあるDNSパケットがISP境界に交差しないと予想されます(禁止されていませんが)、ISPが体を大事にすることができると予想されるとき。
Because "anycast" in this memo is simpler than that of RFC 1546 [9] and RFC 3513 [10], where it is assumed to be administratively prohibited to have multiple servers on a single link sharing an anycast address, anycast in this memo should be implemented as UNICAST of RFC 2461 [1] and RFC 3513 [10]. As a result, ND-related instability disappears. Thus, in the well-known anycast addresses approach, anycast can and should use the anycast address as a source unicast (according to RFC 3513 [10]) address of packets of UDP and TCP responses. With TCP, if a route flips and packets to an anycast address are routed to a new server, it is expected that the flip is detected by ICMP or sequence number inconsistency, and that the TCP connection is reset and retried.
このメモによる"anycast"がそれがanycastアドレスを共有しながら単一のリンクの上に複数のサーバを持つために行政上禁止されていると思われるRFC1546[9]とRFC3513[10]のものより簡単であるので、このメモによるanycastはRFC2461[1]とRFC3513[10]のUNICASTとして実装されるべきです。 その結果、ノースダコタ関連の不安定性は見えなくなります。 その結果、anycastはよく知られるanycastアドレスアプローチでは、使用できて、ソースユニキャストとしてanycastアドレスを使用するはずです。(UDPとTCP応答のパケットのRFC3513[10])アドレスによると。 ルートが宙返りして、anycastアドレスへのパケットが新しいサーバに発送されるなら、TCPと共に、TCP接続が宙返りがICMPか一連番号矛盾で検出されて、リセットされて、再試行されると予想されます。
4. Interworking among IPv6 DNS Configuration Approaches
4. IPv6 DNSの中で構成アプローチを織り込みます。
Three approaches can work together for IPv6 host configuration of RDNSS. This section shows a consideration on how these approaches can interwork.
3つのアプローチがRDNSSのIPv6ホスト構成に一緒に効き目があることができます。 これらのアプローチがどう織り込むことができるかに関してこのセクションは考慮を示しています。
For ordering between RA and DHCP approaches, the O (Other stateful configuration) flag in the RA message can be used [6][28]. If no RDNSS option is included, an IPv6 host may perform DNS configuration through DHCPv6 [3]-[5] regardless of whether the O flag is set or not.
RAとDHCPアプローチの間で注文するために、RAメッセージのO(他のstateful構成)旗は中古の[6][28]であることができる。 どんなRDNSSオプションも含まれていないなら、IPv6ホストはDHCPv6[3]を通してDNS構成を実行するかもしれません--O旗が設定されるかどうかにかかわらず[5]。
The well-known anycast addresses approach fully interworks with the other approaches. That is, the other approaches can remove the configuration effort on servers by using the well-known addresses as the default configuration. Moreover, the clients preconfigured with the well-known anycast addresses can be further configured to use other approaches to override the well-known addresses, if the
アプローチが他のアプローチで完全に織り込むよく知られるanycastアドレス。 すなわち、他のアプローチは、サーバでデフォルト設定としてよく知られるアドレスを使用することによって、構成取り組みを取り除くことができます。 そのうえ、よく知られるアドレスをくつがえすのに他のアプローチを使用するためにさらによく知られるanycastアドレスであらかじめ設定されたクライアントは構成できます。
Jeong Informational [Page 11] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[11ページ]のRFC4339IPv6ホスト構成
configuration information from other approaches is available. Otherwise, all the clients need to have the well-known anycast addresses preconfigured. In order to use the anycast approach along with two other approaches, there are three choices as follows:
他のアプローチからの設定情報は利用可能です。 さもなければ、すべてのクライアントが、よく知られるanycastアドレスをあらかじめ設定させる必要があります。 他の2つのアプローチに伴うanycastアプローチを使用するために、以下の3つの選択があります:
1. The first choice is that well-known addresses are used as last resort, when an IPv6 host cannot get RDNSS information through RA and DHCP. The well-known anycast addresses have to be preconfigured in all of IPv6 hosts' resolver configuration files.
1. 最初の選択はよく知られるアドレスが切り札として使用されるということです、IPv6ホストがRAとDHCPにRDNSS情報を通すことができないなら。 よく知られるanycastアドレスはIPv6ホストのレゾルバ構成ファイルのすべてであらかじめ設定されなければなりません。
2. The second is that an IPv6 host can configure well-known addresses as the most preferable in its configuration file even though either an RA option or DHCP option is available.
2. 2番目はRAオプションかDHCPオプションのどちらかが利用可能ですが、IPv6ホストが構成ファイルで最も望ましいとしてよく知られるアドレスを構成できるということです。
3. The last is that the well-known anycast addresses can be set in RA or DHCP configuration to reduce the configuration effort of users. According to either the RA or DHCP mechanism, the well- known addresses can be obtained by an IPv6 host. Because this approach is the most convenient for users, the last option is recommended.
3. 最終はRAかDHCP構成でよく知られるanycastアドレスがユーザの構成取り組みを減少させるように設定できるということです。 RAかDHCPメカニズムによると、IPv6ホストはよく知られているアドレスを得ることができます。 ユーザはこのアプローチが最も都合がよいので、最後のオプションはお勧めです。
Note: This section does not necessarily mean that this document suggests adopting all of these three approaches and making them interwork in the way described here. In fact, as a result of further discussion some approaches may not even be adopted at all.
以下に注意してください。 このセクションは、必ずこのドキュメントが、3つのアプローチとそれらを作るとここに述べられた方法で織り込まれるこれらをすべて、採用するのを示すことを意味するというわけではありません。 事実上、さらなる議論の結果、いくつかのアプローチは全くも取られないかもしれません。
5. Deployment Scenarios
5. 展開シナリオ
Regarding the DNS configuration on the IPv6 host, several mechanisms are being considered by the DNSOP Working Group, such as RA option, DHCPv6 option, and well-known preconfigured anycast addresses as of today, and this document is a final result from the long thread. In this section, we suggest four applicable scenarios of three approaches for IPv6 DNS configuration.
IPv6ホストでのDNS構成に関して、数個のメカニズムがDNSOP作業部会によって考えられています、今日現在RAオプションや、DHCPv6オプションや、よく知られるあらかじめ設定されたanycastアドレスなどのように、そして、このドキュメントは長いスレッドからの最終的な結果です。 このセクションで、私たちはIPv6 DNS構成のための3つのアプローチの4つの適切なシナリオを勧めます。
Note: In the applicable scenarios, authors do not implicitly push any specific approaches into the restricted environments. No enforcement is in each scenario, and all mentioned scenarios are probable. The main objective of this work is to provide a useful guideline for IPv6 DNS configuration.
以下に注意してください。 適切なシナリオでは、作者はそれとなく少しの特定のアプローチも制限された環境に押し込みません。 実施が全く各シナリオにありませんでした、そして、すべてがシナリオがありえそうであると言及しました。 この仕事の主な目標はIPv6 DNS構成のための役に立つガイドラインを提供することです。
5.1. ISP Network
5.1. ISPネットワーク
A characteristic of an ISP network is that multiple Customer Premises Equipment (CPE) devices are connected to IPv6 PE (Provider Edge) routers and that each PE connects multiple CPE devices to the backbone network infrastructure [11]. The CPEs may be hosts or routers.
ISPネットワークの特性は複数のCustomer Premises Equipment(CPE)デバイスがIPv6 PE(プロバイダーEdge)ルータに接続されて、各PEが複数のCPEデバイスをバックボーンネットワークインフラ[11]に接続するということです。 CPEsはホストかルータであるかもしれません。
Jeong Informational [Page 12] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[12ページ]のRFC4339IPv6ホスト構成
If the CPE is a router, there is a customer network that is connected to the ISP backbone through the CPE. Typically, each customer network gets a different IPv6 prefix from an IPv6 PE router, but the same RDNSS configuration will be distributed.
CPEがルータであるなら、CPEを通してISPバックボーンに接続される顧客ネットワークがあります。 通常、それぞれの顧客ネットワークはIPv6 PEルータと異なったIPv6接頭語を得ますが、同じRDNSS構成は分配されるでしょう。
This section discusses how the different approaches to distributing DNS information are compared in an ISP network.
このセクションはDNS情報を分配することへの異なるアプローチがISPネットワークでどう比較されるかを論じます。
5.1.1. RA Option Approach
5.1.1. RAオプションアプローチ
When the CPE is a host, the RA option for RDNSS can be used to allow the CPE to get RDNSS information and /64 prefix information for stateless address autoconfiguration at the same time when the host is attached to a new subnet [6]. Because an IPv6 host must receive at least one RA message for stateless address autoconfiguration and router configuration, the host could receive RDNSS configuration information in the RA without the overhead of an additional message exchange.
CPEがホストであるときに、CPEがホストが新しいサブネット[6]に付けられるのと同時代に状態がないアドレス自動構成のために情報をRDNSSに得て、接頭語情報を/64に得るのを許容するのにRDNSSのためのRAオプションを使用できます。 IPv6ホストが状態がないアドレス自動構成とルータ構成への少なくとも1つのRAメッセージを受け取らなければならないので、ホストは追加交換処理のオーバーヘッドなしでRAのRDNSS設定情報を受け取ることができました。
When the CPE is a router, the CPE may accept the RDNSS information from the RA on the interface connected to the ISP and copy that information into the RAs advertised in the customer network.
CPEがルータであるときに、CPEはISPに関連づけられたインタフェースのRAからRDNSS情報を受け入れて、顧客ネットワークの広告に掲載されたRAsにその情報をコピーするかもしれません。
This approach is more valuable in the mobile host scenario, in which the host must receive at least an RA message for detecting a new network, than in other scenarios generally, although the administrator should configure RDNSS information on the routers. Secure ND [12] can provide extended security when RA messages are used.
モバイルホストシナリオでは、このアプローチは、より貴重です、管理者がルータのRDNSS情報を構成するべきですが。(一般に、そこでは、ホストが少なくとも他のシナリオより新しいネットワークを検出することへのRAメッセージを受け取らなければなりません)。 RAメッセージが使用されているとき、安全なノースダコタ[12]は拡張セキュリティを提供できます。
5.1.2. DHCPv6 Option Approach
5.1.2. DHCPv6オプションアプローチ
DHCPv6 can be used for RDNSS configuration through the use of the DNS option, and can provide other configuration information in the same message with RDNSS configuration [3]-[5]. The DHCPv6 DNS option is already in place for DHCPv6, as RFC 3646 [5] and DHCPv6-lite or stateless DHCP [4] is not nearly as complex as a full DHCPv6 implementation. DHCP is a client-server model protocol, so ISPs can handle user identification on its network intentionally; also, authenticated DHCP [13] can be used for secure message exchange.
DHCPv6はRDNSS構成にDNSオプションの使用で使用できて、同じメッセージの他の設定情報にRDNSS構成[3]を提供できます--[5]。 DHCPv6 DNSオプションはDHCPv6のために既に適所にあります、RFC3646[5]とDHCPv6-liteか状態がないDHCP[4]が完全なDHCPv6実装と決して同じくらい複雑でないように。 DHCPがクライアント・サーバモデルプロトコルであるので、ISPは故意にネットワークでユーザ登録名を扱うことができます。 また、安全な交換処理に認証されたDHCP[13]を使用できます。
The expected model for deployment of IPv6 service by ISPs is to assign a prefix to each customer, which will be used by the customer gateway to assign a /64 prefix to each network in the customer's network. Prefix delegation with DHCP (DHCPv6 PD) has already been adopted by ISPs for automating the assignment of the customer prefix to the customer gateway [15]. DNS configuration can be carried in the same DHCPv6 message exchange used for DHCPv6 to provide that
ISPによるIPv6サービスの展開のための予想されたモデルは各顧客に接頭語を割り当てることになっています。(その顧客は、顧客ゲートウェイによって使用されて、)顧客のネットワークにおける各ネットワークへの64接頭語を/に割り当てるでしょう。 DHCP(DHCPv6 PD)がある接頭語委譲は、顧客ゲートウェイ[15]に顧客接頭語の課題を自動化するためにISPによって既に採用されました。 DHCPv6がそれを提供するのに使用される同じDHCPv6交換処理でDNS構成を運ぶことができます。
Jeong Informational [Page 13] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[13ページ]のRFC4339IPv6ホスト構成
information efficiently, along with any other configuration information needed by the customer gateway or customer network. This service model can be useful to Home or SOHO subscribers. The Home or SOHO gateway, which is a customer gateway for ISP, can then pass that RDNSS configuration information to the hosts in the customer network through DHCP.
いかなる他の構成と共にも、効率的に、情報が顧客ゲートウェイか顧客でネットワークを必要としたという情報。 このサービスモデルはホームかソーホー加入者の役に立つ場合があります。 そして、ホームかソーホーゲートウェイ(ISPのための顧客ゲートウェイである)がDHCPを通してそのRDNSS設定情報を顧客ネットワークのホストに渡すことができます。
5.1.3. Well-known Anycast Addresses Approach
5.1.3. よく知られるAnycastはアプローチを扱います。
The well-known anycast addresses approach is also a feasible and simple mechanism for ISP [7]. The use of well-known anycast addresses avoids some of the security risks in rogue messages sent through an external protocol such as RA or DHCPv6. The configuration of hosts for the use of well-known anycast addresses requires no protocol or manual configuration, but the configuration of routing for the anycast addresses requires intervention on the part of the network administrator. Also, the number of special addresses would be equal to the number of RDNSSes that could be made available to subscribers.
また、アドレスがアプローチするよく知られるanycastはISP[7]のための可能で簡単なメカニズムです。 よく知られるanycastアドレスの使用はRAかDHCPv6などの外部のプロトコルを通して送られた凶暴なメッセージにおけるセキュリティ危険のいくつかを避けます。 よく知られるanycastアドレスの使用のためのホストの構成はどんなプロトコルも手動の構成も必要としませんが、anycastアドレスのためのルーティングの構成はネットワーク管理者側の介入を必要とします。 また、特別なアドレスの数も加入者にとって利用可能にすることができたRDNSSesの数と等しいでしょう。
5.2. Enterprise Network
5.2. 企業網
An enterprise network is defined as a network that has multiple internal links, one or more router connections to one or more providers, and is actively managed by a network operations entity [14]. An enterprise network can get network prefixes from an ISP by either manual configuration or prefix delegation [15]. In most cases, because an enterprise network manages its own DNS domains, it operates its own DNS servers for the domains. These DNS servers within enterprise networks process recursive DNS name resolution requests from IPv6 hosts as RDNSSes. The RDNSS configuration in the enterprise network can be performed as it is in Section 4, in which three approaches can be used together as follows:
企業網は、複数の内部のリンクを持っているネットワーク、1つ以上のプロバイダーとの1つ以上のルータ接続と定義されて、ネットワーク操作実体[14]によって活発に経営されます。 企業網は手動の構成か接頭語委譲[15]のどちらかでISPからネットワーク接頭語を得ることができます。 多くの場合、企業網がそれ自身のDNSドメインを管理するので、それはそれ自身のDNSサーバをドメインに操作します。 企業網の中のこれらのDNSサーバはRDNSSesとしてIPv6ホストから再帰的なDNS名前解決要求を処理します。 それが以下の通り3つのアプローチを一緒に使用できるセクション4にあって、企業網におけるRDNSS構成を実行できます:
1. An IPv6 host can decide which approach is or may be used in its subnet with the O flag in RA message [6][28]. As the first choice in Section 4, well-known anycast addresses can be used as a last resort when RDNSS information cannot be obtained through either an RA option or a DHCP option. This case needs IPv6 hosts to preconfigure the well-known anycast addresses in their DNS configuration files.
1. IPv6ホストは、アプローチがどれであるかを決めることができるか、またはサブネットにRAメッセージ[6][28]のO旗で使用されるかもしれません。 最後の手段としてRAオプションかDHCPオプションのどちらかでRDNSS情報を得ることができないとき、セクション4における最初の選択として、よく知られるanycastアドレスを使用できます。 本件は、IPv6ホストが、よく知られるanycastが彼らのDNSで構成ファイルを扱うのをあらかじめ設定する必要があります。
2. When the enterprise prefers the well-known anycast approach to others, IPv6 hosts should preconfigure the well-known anycast addresses as it is in the first choice.
2. 企業がよく知られるanycastアプローチを好むとき、それが最初の選択中であって、他のものに、IPv6ホストはよく知られるanycastアドレスをあらかじめ設定するべきです。
3. The last choice, a more convenient and transparent way, does not need IPv6 hosts to preconfigure the well-known anycast addresses
3. IPv6ホストは最後の選択(より便利で見え透いた方法)はよく知られるanycastアドレスをあらかじめ設定する必要はありません。
Jeong Informational [Page 14] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[14ページ]のRFC4339IPv6ホスト構成
because the addresses are delivered to IPv6 hosts via either the RA option or DHCPv6 option as if they were unicast addresses. This way is most recommended for the sake of the user's convenience.
アドレスがまるで彼らがユニキャストアドレスであるかのようにRAオプションかDHCPv6オプションでIPv6ホストに提供されるので。 この道はユーザの便宜のために最もお勧めです。
5.3. 3GPP Network
5.3. 3GPPネットワーク
The IPv6 DNS configuration is a missing part of IPv6 autoconfiguration and an important part of the basic IPv6 functionality in the 3GPP User Equipment (UE). The higher-level description of the 3GPP architecture can be found in [16], and transition to IPv6 in 3GPP networks is analyzed in [17] and [18].
IPv6 DNS構成は、3GPP User Equipment(UE)のIPv6自動構成の紛失した部品と基本のIPv6の機能性の重要な部分です。 [16]で3GPPアーキテクチャの、よりハイレベルの記述を見つけることができます、そして、3GPPネットワークにおけるIPv6への変遷は[17]と[18]で分析されます。
In the 3GPP architecture, there is a dedicated link between the UE and the GGSN called the Packet Data Protocol (PDP) Context. This link is created through the PDP Context activation procedure [19]. There is a separate PDP context type for IPv4 and IPv6 traffic. If a 3GPP UE user is communicating by using IPv6 (i.e., by having an active IPv6 PDP context), it cannot be assumed that the user simultaneously has an active IPv4 PDP context, and DNS queries could be done using IPv4. A 3GPP UE can thus be an IPv6 node, and somehow it needs to discover the address of the RDNSS. Before IP-based services (e.g., web browsing or e-mail) can be used, the IPv6 (and IPv4) RDNSS addresses need to be discovered in the 3GPP UE.
3GPPアーキテクチャには、Packet Dataプロトコル(PDP)文脈と呼ばれるUEとGGSNとの専用リンクがあります。 このリンクはPDP Context起動手順[19]で作成されます。 IPv4とIPv6トラフィックのための別々のPDP文脈タイプがあります。 3GPP UEユーザがIPv6(すなわち、アクティブなIPv6 PDP文脈を持っているのによる)を使用することによって交信する予定であるなら、ユーザにはアクティブなIPv4 PDP文脈が同時にあると思うことができないで、DNS質問はIPv4を使用し終わることができました。 その結果、3GPP UEはIPv6ノードであるかもしれません、そして、どうにか、それはRDNSSのアドレスを発見する必要があります。 IPベースのサービス(例えば、ウェブ閲覧かメール)を利用できる前に、IPv6(そして、IPv4)RDNSSアドレスは、3GPP UEで発見される必要があります。
Section 5.3.1 briefly summarizes currently available mechanisms in 3GPP networks and recommendations. 5.3.2 analyzes the Router Advertisement-based solution, 5.3.3 analyzes the Stateless DHCPv6 mechanism, and 5.3.4 analyzes the well-known addresses approach. Section 5.3.5 summarizes the recommendations.
セクション5.3 .1 簡潔に、3GPPネットワークにおける現在利用可能なメカニズムと推薦をまとめます。 5.3.2、Router Advertisementベースのソリューションを分析する、5.3、.3、Stateless DHCPv6メカニズムを分析する、5.3に、.4はよく知られるアドレスアプローチを分析します。 セクション5.3 .5 推薦をまとめます。
5.3.1. Currently Available Mechanisms and Recommendations
5.3.1. 現在利用可能なメカニズムと推薦
3GPP has defined a mechanism in which RDNSS addresses can be received in the PDP context activation (a control plane mechanism). That is called the Protocol Configuration Options Information Element (PCO- IE) mechanism [20]. The RDNSS addresses can also be received over the air (using text messages) or typed in manually in the UE. Note that the two last mechanisms are not very well scalable. The UE user most probably does not want to type IPv6 RDNSS addresses manually in the user's UE. The use of well-known addresses is briefly discussed in section 5.3.4.
3GPPはPDP文脈起動(制御飛行機メカニズム)でRDNSSアドレスを受け取ることができるメカニズムを定義しました。 それはプロトコルConfiguration Options情報Element(PCO- IE)メカニズム[20]と呼ばれます。 また、RDNSSアドレスを空気(テキスト・メッセージを使用する)の上に受け取るか、またはUEで手動でタイプできます。 最後の2つのメカニズムが非常によくスケーラブルでないことに注意してください。 UEユーザは最もたぶん手動でユーザのUEにIPv6 RDNSSアドレスをタイプしたがっていません。 セクション5.3.4で簡潔によく知られるアドレスの使用について議論します。
It is seen that the mechanisms above most probably are not sufficient for the 3GPP environment. IPv6 is intended to operate in a zero- configuration manner, no matter what the underlying network infrastructure is. Typically, the RDNSS address is needed to make an IPv6 node operational, and the DNS configuration should be as simple
大部分上のメカニズムがたぶん3GPP環境で十分でないことがわかっています。 基本的なネットワークインフラが何であってもIPv6が無構成方法で作動することを意図します。 RDNSSアドレスがIPv6ノードを操作上にするのに通常、必要です、そして、DNS構成は同じくらい簡単であるべきです。
Jeong Informational [Page 15] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[15ページ]のRFC4339IPv6ホスト構成
as the address autoconfiguration mechanism. Note that there will be additional IP interfaces in some near-future 3GPP UEs; e.g., 3GPP- specific DNS configuration mechanisms (such as PCO-IE [20]) do not work for those IP interfaces. In other words, a good IPv6 DNS configuration mechanism should also work in a multi-access network environment.
アドレス自動構成メカニズムとして。 追加IPインタフェースがいくつかの近い将来3GPP UEsにあることに注意してください。 例えば、3GPPの特定のDNS構成メカニズム、(PCO-IE[20])がそれらのIPで働いていないとき、そのようなものは連結します。 言い換えれば、また、良いIPv6 DNS構成メカニズムはマルチアクセスネットワーク環境で動作するはずです。
From a 3GPP point of view, the best IPv6 DNS configuration solution is feasible for a very large number of IPv6-capable UEs (even hundreds of millions in one operator's network), is automatic, and thus requires no user action. It is suggested that a lightweight, stateless mechanism be standardized for use in all network environments. The solution could then be used for 3GPP, 3GPP2, and other access network technologies. Thus, not only is a light, stateless IPv6 DNS configuration mechanism needed in 3GPP networks, but also 3GPP networks and UEs would certainly benefit from the new mechanism.
3GPP観点から、最も良いIPv6 DNS構成ソリューションは、多くのIPv6できるUEs(1人のオペレータのネットワークにおける何億さえ)に可能であり、自動であり、その結果、ユーザ動作を全く必要としません。 軽量の、そして、状態がないメカニズムがすべてのネットワーク環境における使用のために標準化されることが提案されます。 そして、3GPP、3GPP2、および他のアクセスネットワーク技術にソリューションを使用できました。 したがって、唯一でないのが、光ですが、状態がないIPv6 DNS構成メカニズムは3GPPでネットワークを必要としましたが、確かに、3GPPネットワークとUEsは新しいメカニズムのまた利益を得るでしょう。
5.3.2. RA Extension
5.3.2. RA拡張子
Router Advertisement extension [6] is a lightweight IPv6 DNS configuration mechanism that requires minor changes in the 3GPP UE IPv6 stack and Gateway GPRS Support Node (GGSN, the default router in the 3GPP architecture) IPv6 stack. This solution can be specified in the IETF (no action is needed in the 3GPP) and taken in use in 3GPP UEs and GGSNs.
ルータAdvertisement拡張子[6]は3GPP UE IPv6スタックとゲートウェイGPRS Support Node(GGSN、3GPPアーキテクチャのデフォルトルータ)IPv6スタックでマイナーチェンジを必要とする軽量のIPv6 DNS構成メカニズムです。 IETF(動作は全く3GPPで必要でない)で指定して、3GPP UEsとGGSNsで使用で取って、このソリューションはそうすることができます。
In this solution, an IPv6-capable UE configures DNS information via an RA message sent by its default router (GGSN); i.e., the RDNSS option for a recursive DNS server is included in the RA message. This solution is easily scalable for a very large number of UEs. The operator can configure the RDNSS addresses in the GGSN as a part of normal GGSN configuration. The IPv6 RDNSS address is received in the Router Advertisement, and an extra Round Trip Time (RTT) for asking RDNSS addresses can be avoided.
このソリューションでは、IPv6できるUEはデフォルトルータ(GGSN)によって送られたRAメッセージでDNS情報を構成します。 再帰的なDNSサーバのためのすなわち、RDNSSオプションはRAメッセージに含まれています。 多くのUEsには、このソリューションは容易にスケーラブルです。 オペレータはGGSNの正常なGGSN構成の一部としてのRDNSSアドレスを構成できます。 Router AdvertisementにIPv6 RDNSSアドレスを受け取ります、そして、アドレスをRDNSSに尋ねるための付加的なRound Trip Time(RTT)を避けることができます。
When one considers the cons, this mechanism still requires standardization effort in the IETF, and the end nodes and routers need to support this mechanism. The equipment software update should, however, be pretty straightforward, and new IPv6 equipment could support RA extension already from the beginning.
人がまやかしを考えるとき、このメカニズムはIETFでまだ標準化取り組みを必要としています、そして、エンドノードとルータはこのメカニズムをサポートする必要があります。 しかしながら、設備ソフトウェアアップデートはかなり簡単であるべきです、そして、新しいIPv6設備は既に始めからRAが拡大であるとサポートするかもしれません。
5.3.3. Stateless DHCPv6
5.3.3. 状態がないDHCPv6
A DHCPv6-based solution needs the implementation of Stateless DHCP [4] and DHCPv6 DNS options [5] in the UE, and a DHCPv6 server in the operator's network. A possible configuration is such that the GGSN works as a DHCP relay.
DHCPv6ベースのソリューションはオペレータのネットワークでStateless DHCP[4]の実装とUE、およびDHCPv6サーバにおけるDHCPv6 DNSオプション[5]を必要とします。 可能な構成がそのようなものであるので、GGSNはDHCPリレーとして働いています。
Jeong Informational [Page 16] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[16ページ]のRFC4339IPv6ホスト構成
The pros of a stateless DHCPv6-based solution are:
状態がないDHCPv6ベースのソリューションに関するプロは以下の通りです。
1. Stateless DHCPv6 is a standardized mechanism.
1. 状態がないDHCPv6は標準化されたメカニズムです。
2. DHCPv6 can be used for receiving configuration information other than RDNSS addresses; e.g., SIP server addresses.
2. RDNSSアドレス以外の設定情報を受け取るのにDHCPv6を使用できます。 例えば、SIPサーバアドレス。
3. DHCPv6 works in different network environments.
3. DHCPv6は異なったネットワーク環境で働いています。
4. When DHCPv6 service is deployed through a single, centralized server, the RDNSS configuration information can be updated by the network administrator at a single source.
4. DHCPv6サービスが単一の、そして、集結されたサーバを通して配布されるとき、単独のソースのネットワーク管理者はRDNSS設定情報をアップデートできます。
Some issues with DHCPv6 in 3GPP networks are listed below:
3GPPネットワークにおけるDHCPv6のいくつかの問題が以下に記載されています:
1. DHCPv6 requires an additional server in the network unless the (Stateless) DHCPv6 functionality is integrated into an existing router. This means that there might be one additional server to be maintained.
1. (状態がない)のDHCPv6の機能性が既存のルータと統合されない場合、DHCPv6はネットワークで追加サーバを必要とします。 これは、維持される1つの追加サーバがあるかもしれないことを意味します。
2. DHCPv6 is not necessarily needed for 3GPP UE IPv6 addressing (3GPP Stateless Address Autoconfiguration is typically used) and is not automatically implemented in 3GPP IPv6 UEs.
2. DHCPv6は必ず3GPP UE IPv6アドレシング(3GPP Stateless Address Autoconfigurationは通常使用される)に必要であるというわけではなく、3GPP IPv6 UEsで自動的に実装されません。
3. Scalability and reliability of DHCPv6 in very large 3GPP networks (with tens or hundreds of millions of UEs) may be an issue; at least the redundancy needs to be taken care of. However, if the DHCPv6 service is integrated into the network elements, such as a router operating system, scalability and reliability is comparable with other DNS configuration approaches.
3. 非常に大きい3GPPネットワーク(10か何億UEsと)における、DHCPv6のスケーラビリティと信頼性は問題であるかもしれません。 少なくとも冗長は、世話をされる必要があります。 しかしながら、DHCPv6サービスがルータオペレーティングシステムなどのネットワーク要素と統合されるなら、スケーラビリティと信頼性は他のDNS構成アプローチに匹敵しています。
4. It is sub-optimal to utilize the radio resources in 3GPP networks for DHCPv6 messages if there is a simpler alternative is available.
4. 3GPPネットワークであれば、より簡単な代替手段が利用可能であるというDHCPv6メッセージにラジオリソースを利用するのはサブ最適です。
* The use of stateless DHCPv6 adds one round-trip delay to the case in which the UE can start transmitting data right after the Router Advertisement.
* 状態がないDHCPv6の使用はUEがRouter Advertisement直後データを送り始めることができる場合に1つの往復の遅れを加えます。
5. If the DNS information (suddenly) changes, Stateless DHCPv6 cannot automatically update the UE; see [21].
5. DNS情報が(突然)変化するなら、Stateless DHCPv6は自動的にUEをアップデートできません。 [21]を見てください。
5.3.4. Well-known Addresses
5.3.4. よく知られるアドレス
Using well-known addresses is also a feasible and light mechanism for 3GPP UEs. Those well-known addresses can be preconfigured in the UE software and the operator can make the corresponding configuration on the network side. Thus, this is a very easy mechanism for the UE,
また、よく知られるアドレスを使用するのは、3GPP UEsのための可能で軽いメカニズムです。 UEソフトウェアでそれらのよく知られるアドレスをあらかじめ設定できます、そして、オペレータはネットワーク側で対応する構成を作ることができます。 したがって、これはUEのための非常に簡単なメカニズムです。
Jeong Informational [Page 17] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[17ページ]のRFC4339IPv6ホスト構成
but it requires some configuration work in the network. When using well-known addresses, UE forwards queries to any of the preconfigured addresses. In the current proposal [7], IPv6 anycast addresses are suggested.
しかし、それはネットワークにおけるいくらかの構成仕事を必要とします。 よく知られるアドレスを使用するとき、UEはあらかじめ設定されたアドレスのいずれにも質問を送ります。 現在の提案[7]では、IPv6 anycastアドレスは示されます。
Note: An IPv6 DNS configuration proposal, based on the use of well- known site-local addresses, was developed by the IPv6 Working Group; it was seen as a feasible mechanism for 3GPP UEs, although no IETF consensus was reached on this proposal. In the end, the deprecation of IPv6 site-local addresses made it impossible to standardize a mechanism that uses site-local addresses as well-known addresses. However, as of this writing, this mechanism is implemented in some operating systems and 3GPP UEs as a last resort of IPv6 DNS configuration.
以下に注意してください。 よく知られているサイトローカルのアドレスの使用に基づくIPv6 DNS構成提案はIPv6作業部会によって開発されました。 IETFコンセンサスに全くこの提案のときに達しませんでしたが、それは3GPP UEsに、可能なメカニズムと考えられました。 結局、IPv6のサイトローカルのアドレスの不賛成で、よく知られるアドレスとしてサイトローカルのアドレスを使用するメカニズムを標準化するのは不可能になりました。 しかしながら、この書くこと現在、このメカニズムはIPv6 DNS構成の切り札としていくつかのオペレーティングシステムと3GPP UEsで実装されます。
5.3.5. Recommendations
5.3.5. 推薦
It is suggested that a lightweight, stateless DNS configuration mechanism be specified as soon as possible. From a 3GPP UE and network point of view, the Router Advertisement-based mechanism looks most promising. The sooner a light, stateless mechanism is specified, the sooner we can stop using well-known site-local addresses for IPv6 DNS configuration.
軽量の、そして、状態がないDNS構成メカニズムができるだけ早く指定されることが提案されます。 3GPP UEとネットワーク観点から、Router Advertisementベースのメカニズムは最も有望に見えます。 軽くて、状態がないメカニズムが、より早く指定されれば指定するほど、私たちは、IPv6 DNS構成によく知られるサイトローカルのアドレスを使用するのをより早く止めることができます。
5.4. Unmanaged Network
5.4. ネットワークをUnmanagedしました。
There are four deployment scenarios of interest in unmanaged networks [22]:
非管理されたネットワーク[22]には興味深い4つの展開シナリオがあります:
1. A gateway that does not provide IPv6 at all,
1. 全くIPv6を提供しないゲートウェイ
2. A dual-stack gateway connected to a dual-stack ISP,
2. デュアルスタックゲートウェイはデュアルスタックISPに接続しました。
3. A dual-stack gateway connected to an IPv4-only ISP, and
3. そしてデュアルスタックゲートウェイがIPv4だけISPに接続した。
4. A gateway connected to an IPv6-only ISP.
4. ゲートウェイはIPv6だけISPに接続しました。
5.4.1. Case A: Gateway Does Not Provide IPv6 at All
5.4.1. ケースA: ゲートウェイは全くIPv6を提供しません。
In this case, the gateway does not provide IPv6; the ISP may or may not provide IPv6. Automatic or Configured tunnels are the recommended transition mechanisms for this scenario.
この場合、ゲートウェイはIPv6を提供しません。 ISPはIPv6を提供するかもしれません。 自動であるかConfiguredトンネルはこのシナリオのためのお勧めの変遷メカニズムです。
The case where dual-stack hosts behind an NAT need access to an IPv6 RDNSS cannot be entirely ruled out. The DNS configuration mechanism has to work over the tunnel, and the underlying tunneling mechanism could implement NAT traversal. The tunnel server assumes the role of a relay (for both DHCP and well-known anycast addresses approaches).
NATの後ろのデュアルスタックホストがIPv6 RDNSSへのアクセスを必要とするケースを完全に除外できません。 DNS構成メカニズムはトンネルの上で動作しなければなりません、そして、基本的なトンネリングメカニズムはNATが縦断であると実装するかもしれません。 トンネルサーバはリレー(両方のDHCPとよく知られるanycastアドレスアプローチのための)の役割を引き受けます。
Jeong Informational [Page 18] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[18ページ]のRFC4339IPv6ホスト構成
The RA-based mechanism is relatively straightforward in its operation, assuming the tunnel server is also the IPv6 router emitting RAs. The well-known anycast addresses approach also seems simple in operation across the tunnel, but the deployment model using well-known anycast addresses in a tunneled environment is unclear or not well understood.
また、トンネルサーバがRAsを放つIPv6ルータであると仮定して、RAベースのメカニズムは稼働中であり比較的簡単です。 また、アドレスがアプローチするよく知られるanycastはトンネルの向こう側に稼働中であり簡単に見えますが、トンネルを堀られた環境でよく知られるanycastアドレスを使用している展開モデルは、不明瞭であるかよく理解されていません。
5.4.2. Case B: A Dual-stack Gateway Connected to a Dual-stack ISP
5.4.2. ケースB: デュアルスタックISPに接続されたデュアルスタックゲートウェイ
This is similar to a typical IPv4 home user scenario, where DNS configuration parameters are obtained using DHCP. The exception is that Stateless DHCPv6 is used, as opposed to the IPv4 scenario, where the DHCP server is stateful (it maintains the state for clients).
これは典型的なIPv4家庭でのユーザシナリオと同様です。そこでは、DNS設定パラメータが、DHCPを使用することで得られます。 例外はStateless DHCPv6がIPv4シナリオと対照的にDHCPサーバがstatefulである(それはクライアントのために状態を維持します)ところで使用されるということです。
5.4.3. Case C: A Dual-stack Gateway Connected to an IPv4-only ISP
5.4.3. ケースC: IPv4だけISPに接続されたデュアルスタックゲートウェイ
This is similar to Case B. If a gateway provides IPv6 connectivity by managing tunnels, then it is also supposed to provide access to an RDNSS. Like this, the tunnel for IPv6 connectivity originates from the dual-stack gateway instead of from the host.
これがゲートウェイがトンネルを管理することによってIPv6の接続性を供給するCase B.Ifと同様である、そして、また、それはRDNSSへのアクセスを提供するべきです。 このように、IPv6の接続性のためのトンネルはホストの代わりにデュアルスタックゲートウェイから発します。
5.4.4. Case D: A Gateway Connected to an IPv6-only ISP
5.4.4. ケースD: IPv6だけISPに接続されたゲートウェイ
This is similar to Case B.
これはCase Bと同様です。
6. Security Considerations
6. セキュリティ問題
As security requirements depend solely on applications and differ from application to application, there can be no generic requirement defined at the IP or application layer for DNS.
セキュリティ要件が唯一アプリケーションによって、アプリケーションからアプリケーションまで異なるので、DNSのためにIPか応用層で定義されたジェネリック要件が全くあるはずがありません。
However, note that cryptographic security requires configured secret information and that full autoconfiguration and cryptographic security are mutually exclusive. People insisting on secure, full autoconfiguration will get false security, false autoconfiguration, or both.
しかしながら、暗号のセキュリティが構成された秘密の情報を必要として、その完全な自動構成と暗号のセキュリティが互いに排他的であることに注意してください。 安全で、完全な自動構成を主張する人々が誤ったセキュリティ、誤った自動構成、または両方を得るでしょう。
In some deployment scenarios [17], where cryptographic security is required for applications, the secret information for the cryptographic security is preconfigured, through which application- specific configuration data, including those for DNS, can be securely configured. Note that if applications requiring cryptographic security depend on DNS, the applications also require cryptographic security to DNS. Therefore, the full autoconfiguration of DNS is not acceptable.
いくつかの展開シナリオ[17]では、暗号のセキュリティのための秘密の情報(しっかりとDNSのためのものを含むアプリケーションの特定のコンフィギュレーション・データは構成できる)はあらかじめ設定されます。そこでは、暗号のセキュリティがアプリケーションに必要です。 また、暗号のセキュリティを必要とするアプリケーションがDNSによるなら、アプリケーションが暗号のセキュリティをDNSに必要とすることに注意してください。 したがって、DNSの完全な自動構成は許容していません。
However, with full autoconfiguration, weaker but still reasonable security is being widely accepted and will continue to be acceptable.
しかしながら、完全な自動構成で、より弱い、しかし、まだ手頃なセキュリティは、広く受け入れられていて、ずっと許容できるでしょう。
Jeong Informational [Page 19] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[19ページ]のRFC4339IPv6ホスト構成
That is, with full autoconfiguration, which means there is no cryptographic security for the autoconfiguration, it is already assumed that the local environment is secure enough that the information from the local autoconfiguration server has acceptable security even without cryptographic security. Thus, the communication between the local DNS client and local DNS server has acceptable security.
すなわち、完全な自動構成で、地方の環境がローカルの自動構成サーバからの情報には許容できるセキュリティが暗号のセキュリティがなくてもあるほど安全であると既に思われます。(それは、自動構成のためのどんな暗号のセキュリティもないことを意味します)。 したがって、地元のDNSクライアントとローカルのDNSサーバとのコミュニケーションには、許容できるセキュリティがあります。
In autoconfiguring recursive servers, DNSSEC may be overkill, because DNSSEC [23]-[25] needs the configuration and reconfiguration of clients at root key roll-over [26][27]. Even if additional keys for secure key roll-over are added at the initial configuration, they are as vulnerable as the original keys to some forms of attack, such as social hacking. Another problem of using DNSSEC and autoconfiguration together is that DNSSEC requires secure time, which means secure communication with autoconfigured time servers, which requires configured secret information. Therefore, in order that the autoconfiguration may be secure, configured secret information is required.
再帰的なサーバを自動構成することにおいて、DNSSECが過剰殺傷であるかもしれない、DNSSEC[23]--[25]はルートキーロールオーバー[26][27]でクライアントの構成と再構成を必要とします。 安全な主要なロールオーバーのための追加キーが初期の構成で加えられても、それらはいくつかの形式の攻撃のオリジナルのキーと同じくらい被害を受け易いです、社会的なハッキングなどのように。 DNSSECと自動構成を一緒に使用するという別の問題はDNSSECが安全な時間を必要とするということです。(時間は自動構成された時間サーバとの安全なコミュニケーションを意味します)。(それは、構成された秘密の情報を必要とします)。 したがって、自動構成が安全であることができなるように、構成された秘密の情報が必要です。
If DNSSEC [23]-[25] is used and the signatures are verified on the client host, the misconfiguration of a DNS server may simply be denial of service. Also, if local routing environment is not reliable, clients may be directed to a false resolver with the same IP address as the true one.
DNSSECであるなら、[23]--[25]は使用されています、そして、署名はクライアントホストの上で確かめられます、そして、DNSサーバのmisconfigurationは単にサービスの否定であるかもしれません。 また、地方のルーティング環境が信頼できないなら、クライアントは本当の方と同じIPアドレスで偽のレゾルバに向けられるかもしれません。
6.1. RA Option
6.1. RAオプション
The security of RA option for RDNSS is the same as the ND protocol security [1][6]. The RA option does not add any new vulnerability.
RDNSSのためのRAオプションのセキュリティはノースダコタプロトコルセキュリティ[1][6]と同じです。 RAオプションはどんな新しい脆弱性も加えません。
Note that the vulnerability of ND is not worse and is a subset of the attacks that any node attached to a LAN can do independently of ND. A malicious node on a LAN can promiscuously receive packets for any router's MAC address and send packets with the router's MAC address as the source MAC address in the L2 header. As a result, the L2 switches send packets addressed to the router to the malicious node. Also, this attack can send redirects that tell the hosts to send their traffic somewhere else. The malicious node can send unsolicited RA or NA replies, answer RS or NS requests, etc. All of this can be done independently of implementing ND. Therefore, the RA option for RDNSS does not add to the vulnerability.
ノースダコタの脆弱性が、より悪くなく、どんなノードもLANに付けた攻撃の部分集合であるというメモは独自にノースダコタができます。 LANの悪意があるノードは、どんなルータのMACアドレスのためにも乱雑にパケットを受けて、ソースMACアドレスとしてL2ヘッダーでルータのMACアドレスがあるパケットを送ることができます。 その結果、L2スイッチはルータに扱われたパケットを悪意があるノードに送ります。 また、攻撃が送ることができるこれはそれを向け直します。彼らのトラフィックを他のどこかに送るようにホストに言ってください。 悪意があるノードは求められていないRA、NA回答、答えRSまたはNSに要求などを送ることができます。 ノースダコタを実装することの如何にかかわらずこのすべてをできます。 したがって、RDNSSのためのRAオプションは脆弱性に加えません。
Security issues regarding the ND protocol were discussed by the IETF SEND (Securing Neighbor Discovery) Working Group, and RFC 3971 for the ND security has been published [12].
ノースダコタプロトコルに関する安全保障問題はIETF SEND(Neighborがディスカバリーであると機密保護する)作業部会によって議論されました、そして、ノースダコタセキュリティのためのRFC3971は発行されました。[12]。
Jeong Informational [Page 20] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[20ページ]のRFC4339IPv6ホスト構成
6.2. DHCPv6 Option
6.2. DHCPv6オプション
The DNS Recursive Name Server option may be used by an intruder DHCP server to cause DHCP clients to send DNS queries to an intruder DNS recursive name server [5]. The results of these misdirected DNS queries may be used to spoof DNS names.
DNS Recursive Name Serverオプションは侵入者DHCPサーバによって使用されて、DHCPクライアントが侵入者のDNSの再帰的なネームサーバ[5]への質問をDNSに送ることを引き起こすかもしれません。 これらの的外れのDNS質問の結果は、DNSが名前であると偽造するのに使用されるかもしれません。
To avoid attacks through the DNS Recursive Name Server option, the DHCP client SHOULD require DHCP authentication (see "Authentication of DHCP messages" in RFC 3315 [3][13]) before installing a list of DNS recursive name servers obtained through authenticated DHCP.
DNS Recursive Name Serverオプション、DHCPを通した攻撃を避けるために、クライアントSHOULDはDHCP認証を必要とします。(DNSの再帰的なネームサーバのリストをインストールする前のRFC3315[3][13])の「DHCPメッセージの認証」が認証されたDHCPを通して得られるのを見てください。
6.3. Well-known Anycast Addresses
6.3. よく知られるAnycastアドレス
The well-known anycast addresses approach is not a protocol, thus there is no need to secure the protocol itself.
よく知られるanycastはプロトコルでなく、その結果、あるアプローチにプロトコル自体を保証する必要性を全く扱いません。
However, denial of service attacks on the DNS resolver system might be easier to achieve as the anycast addresses used are by definition well known.
しかしながら、使用されるanycastアドレスが定義上よく知られているようにDNSレゾルバシステムにおけるサービス不能攻撃は達成するのが、より簡単であるかもしれません。
7. Contributors
7. 貢献者
Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Ave. Boxboro, MA 01719 US
ラルフDromsシスコシステムズInc.1414マサチューセッツAve。 Boxboro、MA01719米国
Phone: +1 978 936 1674 EMail: rdroms@cisco.com
以下に電話をしてください。 +1 1674年の978 936メール: rdroms@cisco.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
ロバートM.Hindenノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625 2004 EMail: bob.hinden@nokia.com
以下に電話をしてください。 +1 2004年の650 625メール: bob.hinden@nokia.com
Jeong Informational [Page 21] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[21ページ]のRFC4339IPv6ホスト構成
Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 US
テッドレモンNominum Inc.950憲章通りカリフォルニア94043レッドウッドシティー(米国)
EMail: Ted.Lemon@nominum.com
メール: Ted.Lemon@nominum.com
Masataka Ohta Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku Tokyo 152-8552 Japan
Masataka太田東京工業大学2-12-1、大岡山、目黒区日本東京152-8552
Phone: +81 3 5734 3299 Fax: +81 3 5734 3299 EMail: mohta@necom830.hpcl.titech.ac.jp
以下に電話をしてください。 +81 3 5734 3299、Fax: +81 3 5734 3299はメールされます: mohta@necom830.hpcl.titech.ac.jp
Soohong Daniel Park Mobile Platform Laboratory, SAMSUNG Electronics 416 Maetan-3dong, Yeongtong-Gu Suwon, Gyeonggi-Do 443-742 Korea
モバイルプラットホーム研究所、三星エレクトロニクス416Maetan-3dong、Yeongtong-Gu水原がGyeonggi443-742 韓国をするSoohongダニエルPark
Phone: +82 31 200 4508 EMail: soohong.park@samsung.com
以下に電話をしてください。 +82 31 200 4508はメールされます: soohong.park@samsung.com
Suresh Satapati Cisco Systems, Inc. San Jose, CA 95134 US
Suresh SatapatiシスコシステムズInc.カリフォルニア95134サンノゼ(米国)
EMail: satapati@cisco.com
メール: satapati@cisco.com
Juha Wiljakka Nokia Visiokatu 3 FIN-33720, TAMPERE Finland
ユハWiljakkaノキアVisiokatu3フィン-33720、タンペレフィンランド
Phone: +358 7180 48372 EMail: juha.wiljakka@nokia.com
以下に電話をしてください。 +358 7180 48372はメールされます: juha.wiljakka@nokia.com
Jeong Informational [Page 22] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[22ページ]のRFC4339IPv6ホスト構成
8. Acknowledgements
8. 承認
This document has greatly benefited from inputs by David Meyer, Rob Austein, Tatuya Jinmei, Pekka Savola, Tim Chown, Luc Beloeil, Christian Huitema, Thomas Narten, Pascal Thubert, and Greg Daley. Also, Tony Bonanno proofread this document. The authors appreciate their contribution.
このドキュメントは大いにデヴィッド・マイヤー、ロブAustein、Tatuya Jinmei、ペッカSavola、ティムChown、リュックBeloeil、クリスチャンのHuitema、トーマスNarten、パスカルThubert、およびグレッグ・デイリーによる入力の利益を得ました。 また、トニーBonannoはこのドキュメントを校正します。 作者は彼らの貢献に感謝します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[1]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[2] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[3] Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[4]Droms、R.「(DHCP)がIPv6"、RFC3736年のために修理する状態がないダイナミックなホスト構成プロトコル、2004年4月」。
[5] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[5]Droms、R.、「IPv6(DHCPv6)のためのDynamic Host Configuration ProtocolのためのDNS Configurationオプション」、RFC3646、2003年12月。
9.2. Informative References
9.2. 有益な参照
[6] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Option for DNS Configuration", Work in Progress, September 2005.
「DNS構成のためのIPv6ルータ通知オプション」という[6]Jeong、J.、公園、S.、Beloeil、L.、およびS.Madanapalliは進行中(2005年9月)で働いています。
[7] Ohta, M., "Preconfigured DNS Server Addresses", Work in Progress, February 2004.
[7] 太田、M.が進歩、2004年2月に働くのを「DNSサーバアドレスはあらかじめ設定しました」。
[8] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
[8] Venaas、S.、Chown、T.、およびB.フォルツ、「情報はIPv6(DHCPv6)のためにダイナミックなホスト構成プロトコルのための時間オプションをリフレッシュします」、RFC4242、2005年11月。
[9] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[9] ヤマウズラとC.とメンデス、T.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、1993年11月。
[10] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[10]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
Jeong Informational [Page 23] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[23ページ]のRFC4339IPv6ホスト構成
[11] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. Savola, "Scenarios and Analysis for Introducing IPv6 into ISP Networks", RFC 4029, March 2005.
[11]リンド、M.、Ksinant、V.、公園、S.、Baudot、A.、およびP.Savola、「ISPネットワークにIPv6を取り入れるためのシナリオと分析」(RFC4029)は2005を行進させます。
[12] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[12]ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[13] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[13]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。
[14] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057, June 2005.
[14] バウンド、J.、「IPv6企業網シナリオ」、RFC4057、2005年6月。
[15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[15]TroanとO.とR.Droms、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」
[16] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[16] ワッサーマン、M.、「第三世代パートナーシッププロジェクト(3GPP)規格におけるIPv6のための推薦」、RFC3314、2002年9月。
[17] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003.
[17]Soininen、J.、「3GPPネットワークのための変遷シナリオ」、RFC3574、2003年8月。
[18] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[18]Wiljakka、J.、「第三世代パートナーシッププロジェクト(3GPP)ネットワークにおけるIPv6変遷の分析」、RFC4215、2005年10月。
[19] 3GPP TS 23.060 V5.4.0, "General Packet Radio Service (GPRS); Service description; Stage 2 (Release 5)", December 2002.
[19] 3GPP t23.060V5.4.0、「汎用パケット無線システム(GPRS)」。 記述を修理してください。 2002年12月の「ステージ2(リリース5)。」
[20] 3GPP TS 24.008 V5.8.0, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 (Release 5)", June 2003.
[20] 3GPP TS24.008V5.8.0、「移動無線インタフェースLayer3仕様」。 コアネットワーク・プロトコル。 2003年6月の「ステージ3(リリース5)。」
[21] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[21] Chown(T.、Venaas、S.、およびA.Vijayabhaskar、「IPv6(DHCPv6)のために状態がないダイナミックなホスト構成プロトコルのための要件に番号を付け替える」RFC4076)は2005がそうするかもしれません。
[22] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004.
[22]Huitema、C.、Austein、R.、Satapati、S.、およびR.バンder Pol、「UnmanagedはIPv6変遷シナリオをネットワークでつなぐ」RFC3750(2004年4月)。
[23] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[23]はArendsします、R.、Austein、R.、ラーソン、M.、マッシー、D.、S.ローズと、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
[24] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[24] Arends、R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.が上昇したと「リソースはDNSセキュリティ拡張子のために記録します」、RFC4034、2005年3月。
Jeong Informational [Page 24] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[24ページ]のRFC4339IPv6ホスト構成
[25] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[25] Arends(R.、Austein、R.、ラーソン、M.、マッシー、D.、およびS.ローズ)は「DNSセキュリティ拡張子のための変更について議定書の中で述べます」、RFC4035、2005年3月。
[26] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", Work in Progress, October 2005.
[26] 「DNSSECの操作上の習慣」というKolkman、O.、およびR.Giebenは進歩、2005年10月に働いています。
[27] Guette, G. and O. Courtay, "Requirements for Automated Key Rollover in DNSSEC", Work in Progress, January 2005.
[27] 「DNSSECの自動化された主要なロールオーバーのための要件」というGuette、G.、およびO.Courtayは進歩、2005年1月に働いています。
[28] Park, S., Madanapalli, S., and T. Jinmei, "Considerations on M and O Flags of IPv6 Router Advertisement", Work in Progress, March 2005.
「IPv6ルータ通知のMとO旗の上の問題」という[28]公園、S.、Madanapalli、S.、およびT.Jinmeiは進行中(2005年3月)で働いています。
Author's Address
作者のアドレス
Jaehoon Paul Jeong (editor) ETRI/Department of Computer Science and Engineering University of Minnesota 117 Pleasant Street SE Minneapolis, MN 55455 US
JaehoonポールJeong(エディタ)ETRI/コンピュータサイエンス学部と工学ミネソタ大学117の快い通りSE MN55455ミネアポリス(米国)
Phone: +1 651 587 7774 Fax: +1 612 625 2002 EMail: jjeong@cs.umn.edu URI: http://www.cs.umn.edu/~jjeong/
以下に電話をしてください。 +1 651 587、7774Fax: +1 2002年の612 625メール: jjeong@cs.umn.edu ユリ: http://www.cs.umn.edu/~jjeong/
Jeong Informational [Page 25] RFC 4339 IPv6 Host Configuration of DNS Server February 2006
DNSサーバ2006年2月のJeongの情報[25ページ]のRFC4339IPv6ホスト構成
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Jeong Informational [Page 26]
Jeong情報です。[26ページ]
一覧
スポンサーリンク