[要約] 要約：RFC 7216は、IPアドレスと逆DNSを使用して、位置情報サーバ（LIS）を検出するための方法を提案しています。 目的：このRFCの目的は、ユーザの位置情報を特定するために、IPアドレスと逆DNSを使用する方法を標準化することです。
Internet Engineering Task Force (IETF) M. Thomson
Request for Comments: 7216 Mozilla
Category: Standards Track R. Bellis
ISSN: 2070-1721 Nominet UK
April 2014
Location Information Server (LIS) Discovery Using IP Addresses and Reverse DNS
IPアドレスと逆引きDNSを使用した位置情報サーバー（LIS）の検出
Abstract
概要
The residential gateway is a device that has become an integral part of home networking equipment. Discovering a Location Information Server (LIS) is a necessary part of acquiring location information for location-based services. However, discovering a LIS when a residential gateway is present poses a configuration challenge, requiring a method that is able to work around the obstacle presented by the gateway.
住宅用ゲートウェイは、ホームネットワーキング機器の不可欠な部分となっているデバイスです。位置情報サーバー（LIS）の検出は、位置情報サービスの位置情報を取得するために必要な部分です。ただし、レジデンシャルゲートウェイが存在するときにLISを検出すると、構成の課題が発生し、ゲートウェイが提示する障害を回避できる方法が必要になります。
This document describes a solution to this problem. The solution provides alternative domain names as input to the LIS discovery process based on the network addresses assigned to a Device.
このドキュメントでは、この問題の解決策について説明します。このソリューションは、デバイスに割り当てられたネットワークアドレスに基づいて、LIS検出プロセスへの入力として代替ドメイン名を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7216.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7216で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Residential Gateway . . . . . . . . . . . . . . . . . . . 6
3.2. Security Features of Residential Gateways . . . . . . . . 7
4. IP-based DNS Solution . . . . . . . . . . . . . . . . . . . . 7
4.1. Identification of IP Addresses . . . . . . . . . . . . . 8
4.2. Domain Name Selection . . . . . . . . . . . . . . . . . . 9
4.3. Shortened DNS Names . . . . . . . . . . . . . . . . . . . 9
4.4. When To Use the Reverse DNS Method . . . . . . . . . . . 10
4.5. Private Address Spaces . . . . . . . . . . . . . . . . . 10
4.6. Necessary Assumptions and Restrictions . . . . . . . . . 11
4.7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . 12
4.8. Deployment Considerations . . . . . . . . . . . . . . . . 12
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16
A Location Information Server (LIS) is a service provided by an access network. The LIS uses knowledge of the access network topology and other information to generate location information for Devices. Devices within an access network are able to acquire location information from a LIS.
位置情報サーバー（LIS）は、アクセスネットワークによって提供されるサービスです。 LISは、アクセスネットワークトポロジおよびその他の情報を使用して、デバイスの位置情報を生成します。アクセスネットワーク内のデバイスは、LISから位置情報を取得できます。
The relationship between a Device and an access network might be transient. Configuration of the correct LIS at the Device ensures that accurate location information is available. Without location information, some network services are not available.
デバイスとアクセスネットワークの関係は一時的なものである可能性があります。デバイスでの正しいLISの構成により、正確な位置情報が利用可能になります。位置情報がないと、一部のネットワークサービスは利用できません。
The configuration of a LIS IP address on a Device requires some automated process. This is particularly relevant when one considers that Devices might move between different access networks served by different LISs. LIS Discovery [RFC5986] describes a method that employs the Dynamic Host Configuration Protocol (DHCPv4 [RFC2131], DHCPv6 [RFC3315]) as input to U-NAPTR [RFC4848] discovery.
デバイスのLIS IPアドレスの構成には、いくつかの自動化プロセスが必要です。これは、デバイスがさまざまなLISによって処理されるさまざまなアクセスネットワーク間を移動する可能性があることを考えると、特に関連があります。 LIS検出[RFC5986]は、U-NAPTR [RFC4848]検出への入力として動的ホスト構成プロトコル（DHCPv4 [RFC2131]、DHCPv6 [RFC3315]）を使用する方法を説明しています。
A residential gateway, or home router, provides a range of networking functions for Devices within the network it serves. Unfortunately, in most cases these functions effectively prevent the successful use of DHCP for LIS discovery.
レジデンシャルゲートウェイまたはホームルーターは、サービスを提供するネットワーク内のデバイスにさまざまなネットワーク機能を提供します。残念ながら、ほとんどの場合、これらの機能は、LIS検出のためのDHCPの正常な使用を効果的に妨げます。
One drawback with DHCP is that universal deployment of a new option takes a considerable amount of time. Often, networking equipment needs to be updated in order to support the new option. Of particular concern are the millions of residential gateway devices used to provide Internet access to homes and businesses. While [RFC5986] describes functions that can be provided by residential gateways to support LIS discovery, gateways built before the publication of this specification are not expected (and are likely not able) to provide these functions.
DHCPの欠点の1つは、新しいオプションのユニバーサル展開にかなりの時間がかかることです。多くの場合、新しいオプションをサポートするには、ネットワーク機器を更新する必要があります。特に懸念されるのは、家や企業へのインターネットアクセスを提供するために使用される数百万の住宅用ゲートウェイデバイスです。 [RFC5986]はLISディスカバリーをサポートするためにレジデンシャルゲートウェイによって提供できる機能について説明していますが、この仕様の公開前に構築されたゲートウェイは、これらの機能を提供することは期待されていません（また、できない可能性があります）。
This document explores the problem of configuring Devices with a LIS address when a residential gateway is interposed between the Device and access network. Section 3 defines the problem, and Section 4 describes a method for determining a domain name that can be used for discovery of the LIS.
このドキュメントでは、住宅用ゲートウェイがデバイスとアクセスネットワークの間に挿入されている場合に、LISアドレスを使用してデバイスを構成する際の問題について説明します。セクション3では問題を定義し、セクション4ではLISの検出に使用できるドメイン名を決定する方法について説明します。
In some cases, the solution described in this document is based on a UNilateral Self-Address Fixing (UNSAF) [RFC3424] method. For those cases, this solution is considered transitional until such time as the recommendations for residential gateways in [RFC5986] are more widely deployed. Considerations relating to UNSAF applications are described in Section 7.
場合によっては、このドキュメントで説明するソリューションは、UNilateral Self-Address Fixing（UNSAF）[RFC3424]メソッドに基づいています。これらのケースでは、このソリューションは[RFC5986]の住宅用ゲートウェイの推奨がより広く展開されるまでの過渡的なものと見なされます。 UNSAFアプリケーションに関する考慮事項については、セクション7で説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses terminology established in [RFC6280] and [RFC5012]. The terms "Device" and "LIS" are capitalized throughout when they are used to identify the roles defined in [RFC6280].
このドキュメントでは、[RFC6280]と[RFC5012]で確立された用語を使用します。 [デバイス]と[LIS]という用語は、[RFC6280]で定義されている役割を識別するために使用される場合、全体を通して大文字になります。
Figure 1 shows a simplified network topology for fixed wire-line Internet access. This arrangement is typical when wired Internet access is provided. The diagram shows two network segments: the access network provided by an Internet service provider (ISP), and the residential network served by the residential gateway.
図1は、固定有線インターネットアクセスの簡略化されたネットワークトポロジを示しています。この配置は、有線インターネットアクセスが提供されている場合に一般的です。この図は、2つのネットワークセグメントを示しています。インターネットサービスプロバイダー（ISP）が提供するアクセスネットワークと、住宅用ゲートウェイが提供する住宅用ネットワークです。
There are a number of variations on this arrangement, as documented in Section 3.1 of [RFC5687]. In each of these variations, the goal of LIS discovery is to identify the LIS in the access network.
[RFC5687]のセクション3.1に記載されているように、この配置にはさまざまなバリエーションがあります。これらのバリエーションのそれぞれにおいて、LISディスカバリの目的は、アクセスネットワーク内のLISを識別することです。
________
(/ \)
(( Internet ))
(\________/)
|
|
.- - -|- - - - - - - - - - - -.
( | )
( +--------+ +-------+ )
Access ( | Access |. . . .| LIS | )
Network ( | Node | | | )
(ISP) ( +--------+ +-------+ )
( \ \ )
`- - - -\- - - - - - - -\- - -'
\ \
\ |
.- - - - -\- - - - - - - + -.
( \ | )
( +-------------+ : )
( | Residential | | )
Residential ( | Gateway | : )
Network ( +-------------+ | )
( / \ / )
( / \ / )
( +--------+ +--------+ )
( | Device | | Device | )
( +--------+ +--------+ )
( )
`- - - - - - - - - - - - - -'
Figure 1: Simplified Network Topology
図1：簡素化されたネットワークトポロジ
A particularly important characteristic of this arrangement is the relatively small geographical area served by the residential gateway. Given a small enough area, it is reasonable to delegate the responsibility for providing Devices within the residential network with location information to the ISP. The ISP is able to provide location information that identifies the residence, which should be adequate for a wide range of purposes.
この配置の特に重要な特徴は、住宅用ゲートウェイがサービスを提供する比較的狭い地理的領域です。十分に小さいエリアを考えると、住宅用ネットワーク内のデバイスに位置情報を提供する責任をISPに委任することは妥当です。 ISPは、住居を特定する位置情報を提供できます。これは、幅広い目的に適しています。
A residential network that covers a larger geographical area might require a dedicated LIS, a case that is outside the scope of this document.
より広い地理的領域をカバーする住宅用ネットワークでは、専用のLISが必要になる場合がありますが、このケースはこのドキュメントの範囲外です。
The goal of LIS discovery is to identify a LIS that is able to provide the Device with accurate location information. In the network topology described, this means identifying the LIS in the access network. The residential gateway is a major obstacle in achieving this goal.
LIS検出の目的は、デバイスに正確な位置情報を提供できるLISを識別することです。説明されているネットワークトポロジでは、これはアクセスネットワークのLISを識別することを意味します。住宅用ゲートウェイは、この目標を達成する上での主要な障害です。
A residential gateway can encompass several different functions including: modem, Ethernet switch, wireless access point, router, network address translation (NAT), DHCP server, DNS relay, and firewall. Of the common functions provided, the NAT function of a residential gateway has the greatest impact on LIS discovery.
住宅用ゲートウェイには、モデム、イーサネットスイッチ、ワイヤレスアクセスポイント、ルーター、ネットワークアドレス変換（NAT）、DHCPサーバー、DNSリレー、ファイアウォールなど、いくつかの異なる機能を含めることができます。提供される一般的な機能のうち、レジデンシャルゲートウェイのNAT機能がLIS検出に最大の影響を与えます。
An ISP is typically parsimonious about their IP address allocations; each customer is allocated a limited number of IP addresses. Therefore, NAT is an extremely common function of gateways. NAT enables the use of multiple Devices within the residential network. However, NAT also means that Devices within the residence are not configured by the ISP directly.
ISPは、通常、IPアドレスの割り当てについて節約的です。各顧客には、限られた数のIPアドレスが割り当てられます。したがって、NATはゲートウェイの非常に一般的な機能です。 NATは、住宅用ネットワーク内で複数のデバイスの使用を可能にします。ただし、NATは、住宅内のデバイスがISPによって直接設定されないことも意味します。
When it comes to discovering a LIS, the fact that Devices are not configured by the ISP causes a significant problem. Configuration is the ideal method of conveying the information necessary for discovery. Devices attached to residential gateways are usually given a generic configuration that includes no information about the ISP network. For instance, DNS configuration typically points to a DNS relay on the gateway device. This approach ensures that the local network served by the gateway is able to operate without a connection to the ISP, but it also means that Devices are effectively ignorant of the ISP network.
LISの検出に関しては、デバイスがISPによって構成されていないという事実が重大な問題を引き起こしています。構成は、発見に必要な情報を伝達する理想的な方法です。通常、住宅用ゲートウェイに接続されたデバイスには、ISPネットワークに関する情報を含まない一般的な構成が与えられます。たとえば、DNS構成は通常、ゲートウェイデバイス上のDNSリレーをポイントします。このアプローチにより、ゲートウェイによって提供されるローカルネットワークがISPへの接続なしで動作できることが保証されますが、デバイスがISPネットワークを事実上知らないことも意味します。
[RFC5986] describes several methods that can be applied by a residential gateway to assist Devices in acquiring location information. For instance, the residential gateway could forward LIS address information to hosts within the network it serves. Unfortunately, such an active involvement in the discovery process only works for new residential gateway devices that implement those recommendations.
[RFC5986]は、デバイスが位置情報を取得するのを支援するためにレジデンシャルゲートウェイによって適用できるいくつかの方法を説明しています。たとえば、レジデンシャルゲートウェイは、サービスを提供するネットワーク内のホストにLISアドレス情報を転送できます。残念ながら、このような発見プロセスへの積極的な関与は、これらの推奨事項を実装する新しい住宅用ゲートウェイデバイスでのみ機能します。
Where residential gateways already exist, direct involvement of the gateway in LIS discovery requires that the residential gateway be updated or replaced. The cost of replacement is difficult to justify to the owner of the gateway, especially when it is considered that the gateway still fills its primary function: Internet access. Furthermore, updating the software in such devices is not feasible in many cases. Even if software updates were made available, many residential gateways cannot be updated remotely, inevitably leading to some proportion that is not updated.
住宅用ゲートウェイが既に存在する場合、LIS検出にゲートウェイを直接関与させるには、住宅用ゲートウェイを更新または交換する必要があります。特にゲートウェイが依然としてその主要な機能であるインターネットアクセスを満たしていると考えられる場合、交換のコストをゲートウェイの所有者に正当化することは困難です。さらに、そのようなデバイスでソフトウェアを更新することは、多くの場合実行可能ではありません。ソフトウェアの更新が利用可能になったとしても、多くのレジデンシャルゲートウェイをリモートで更新することはできず、必然的に更新されない割合が生じます。
This document therefore describes a method that can be used by Devices to discover their LIS without any assistance from the network.
したがって、このドキュメントでは、ネットワークからの支援なしにデバイスがLISを検出するために使用できる方法について説明します。
A network firewall function is often provided by residential gateways as a security measure. Security features like intrusion detection systems help protect users from attacks. Amongst these protections is a port filter that prevents both inbound and outbound traffic on certain TCP and UDP ports. Therefore, any solution needs to consider the likelihood of traffic being blocked.
多くの場合、ネットワークファイアウォール機能は、セキュリティ対策としてレジデンシャルゲートウェイによって提供されます。侵入検知システムなどのセキュリティ機能は、攻撃からユーザーを保護するのに役立ちます。これらの保護の中には、特定のTCPおよびUDPポートでの受信トラフィックと送信トラフィックの両方を防止するポートフィルターがあります。したがって、どのようなソリューションでも、トラフィックがブロックされる可能性を考慮する必要があります。
LIS discovery [RFC5986] uses a DNS-based Dynamic Delegation Discovery Service (DDDS) system as the basis of discovery. Input to this process is a domain name. Use of DHCP for acquiring the domain name is specified, but alternative methods of acquisition are permitted.
LIS発見[RFC5986]は、発見の基礎としてDNSベースの動的委任発見サービス（DDDS）システムを使用します。このプロセスへの入力はドメイン名です。ドメイン名を取得するためのDHCPの使用が指定されていますが、別の取得方法が許可されています。
This document specifies a means for a Device to discover several alternative domain names that can be used as input to the DDDS process. These domain names are based on the IP address of the Device. Specifically, the domain names are a portion of the reverse DNS trees -- either the ".in-addr.arpa." or ".ip6.arpa." tree.
このドキュメントでは、DDDSプロセスへの入力として使用できるいくつかの代替ドメイン名をデバイスが検出するための手段を指定します。これらのドメイン名は、デバイスのIPアドレスに基づいています。具体的には、ドメイン名は逆DNSツリーの一部です。「。in-addr.arpa」のいずれかです。または「.ip6.arpa」木。
The goal of this process is to make a small number of DDDS queries in order to find a LIS. After LIS discovery using the DHCP-based process in [RFC5986] has failed, a Device can:
このプロセスの目的は、LISを見つけるために少数のDDDSクエリを作成することです。 [RFC5986]のDHCPベースのプロセスを使用したLIS検出が失敗した後、デバイスは次のことができます。
1. Collect a set of IP addresses that refer to the Device (Section 4.1).
1. デバイスを参照するIPアドレスのセットを収集します（セクション4.1）。
2. Convert each IP address into DNS names in the "in-addr.arpa." or "ip6.arpa." tree (Section 4.2).
2. 「in-addr.arpa」で各IPアドレスをDNS名に変換します。または「ip6.arpa」。ツリー（セクション4.2）。
3. Perform the DDDS process for LIS discovery on those DNS names ([RFC5986]).
3. それらのDNS名でLIS検出のDDDSプロセスを実行します（[RFC5986]）。
4. Shorten the DNS names by some number of labels and repeat the DDDS process (Section 4.3).
4. ラベルの数だけDNS名を短くして、DDDSプロセスを繰り返します（セクション4.3）。
A Device might be reachable at one of a number of IP addresses. In the process described, a Device first identifies each IP address from which it is potentially reachable. From each of these addresses, the Device then selects up to three domain names for use in discovery. These domain names are then used as input to the DDDS process.
デバイスは、多数のIPアドレスの1つで到達可能である可能性があります。説明されているプロセスでは、デバイスはまず、到達可能な各IPアドレスを識別します。次に、デバイスはこれらの各アドレスから、検出に使用する最大3つのドメイン名を選択します。これらのドメイン名は、DDDSプロセスへの入力として使用されます。
A Device identifies a set of potential IP addresses that currently result in packets being routed to it. These are ordered by proximity, with those addresses that are used in adjacent network segments being favored over those used in public or remote networks. The first addresses in the set are those that are assigned to local network interfaces.
デバイスは、現在パケットがルーティングされる原因となる可能性のあるIPアドレスのセットを識別します。これらは近接度順に並べられ、隣接ネットワークセグメントで使用されるアドレスは、パブリックネットワークまたはリモートネットワークで使用されるアドレスよりも優先されます。セットの最初のアドレスは、ローカルネットワークインターフェイスに割り当てられているアドレスです。
A Device can use the Session Traversal Utilities for NAT (STUN) [RFC5389] mechanism to determine its public, reflexive transport address. The host uses the "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" parameter that is returned in the response.
デバイスは、NAT用セッショントラバーサルユーティリティ（STUN）[RFC5389]メカニズムを使用して、そのパブリックな再帰トランスポートアドレスを決定できます。ホストは、「Binding Request」メッセージと、応答で返される結果の「XOR-MAPPED-ADDRESS」パラメーターを使用します。
Alternative methods for determining other IP addresses MAY be used by the Device. If enabled, the Port Control Protocol (PCP) [RFC6887], Universal Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1], and NAT Port Mapping Protocol (NAT-PMP) [RFC6886] are each able to provide the external address of a residential gateway device. These, as well as proprietary methods for determining other addresses, might be available. Because there is no assurance that these methods will be supported by any access network, these methods are not mandated. Note also that in some cases, methods that rely on the view of the network from the residential gateway device could reveal an address in a private address range (see Section 4.6).
他のIPアドレスを決定する別の方法がデバイスによって使用される場合があります。有効になっている場合、ポート制御プロトコル（PCP）[RFC6887]、ユニバーサルプラグアンドプレイ（UPnP）[UPnP-IGD-WANIPConnection1]、およびNATポートマッピングプロトコル（NAT-PMP）[RFC6886]は、それぞれ外部アドレスを提供できます住宅用ゲートウェイデバイスの。これら、および他のアドレスを決定するための独自の方法が利用できる場合があります。これらの方法がアクセスネットワークでサポートされる保証はないため、これらの方法は必須ではありません。場合によっては、レジデンシャルゲートウェイデバイスからのネットワークのビューに依存するメソッドがプライベートアドレス範囲のアドレスを明らかにする可能性があることにも注意してください（セクション4.6を参照）。
In many instances, the IP address produced might be from a private address range. For instance, the address on a local network interface could be from a private range allocated by the residential gateway. In other cases, methods that rely on the view of the network (UPnP, NAT-PMP) from the residential gateway device could reveal an address in a private address range if the access network also uses NAT. For a private IP address, the derived domain name is only usable where the employed DNS server contains data for the corresponding private IP address range.
多くの場合、生成されるIPアドレスはプライベートアドレス範囲からのものである可能性があります。たとえば、ローカルネットワークインターフェイスのアドレスは、住宅用ゲートウェイによって割り当てられたプライベート範囲からのものである可能性があります。他の場合では、住宅用ゲートウェイデバイスからのネットワーク（UPnP、NAT-PMP）のビューに依存するメソッドは、アクセスネットワークもNATを使用している場合、プライベートアドレス範囲のアドレスを明らかにする可能性があります。プライベートIPアドレスの場合、派生ドメイン名は、使用されているDNSサーバーに対応するプライベートIPアドレス範囲のデータが含まれている場合にのみ使用できます。
The domain name selected for each resulting IP address is the name that would be used for a reverse DNS lookup. The domain name derived from an IP version 4 address is in the ".in-addr.arpa." tree and follows the construction rules in Section 3.5 of [RFC1035]. The domain name derived from an IP version 6 address is in the ".ip6.arpa." tree and follows the construction rules in Section 2.5 of [RFC3596].
結果のIPアドレスごとに選択されたドメイン名は、逆DNSルックアップに使用される名前です。 IPバージョン4アドレスから派生したドメイン名は、「。in-addr.arpa」にあります。ツリーを作成し、[RFC1035]のセクション3.5の構築ルールに従います。 IPバージョン6アドレスから派生したドメイン名は、「。ip6.arpa」にあります。ツリーを作成し、[RFC3596]のセクション2.5の構築ルールに従います。
Additional domain names are added to allow for a single DNS record to cover a larger set of addresses. If the search on the domain derived from the full IP address does not produce a NAPTR record with the desired service tag (e.g., "LIS:HELD"), a similar search is repeated based on a shorter domain name, using a part of the IP address:
単一のDNSレコードでより大きなアドレスのセットをカバーできるように、追加のドメイン名が追加されます。完全なIPアドレスから取得されたドメインの検索で、目的のサービスタグ（たとえば、「LIS：HELD」）を含むNAPTRレコードが生成されない場合、類似の検索が、 IPアドレス：
o For IP version 4, the resulting domain name SHOULD be shortened successively by one and two labels, and the query repeated. This corresponds to a search on a /24 or /16 network prefix. This allows for fewer DNS records in the case where a single access network covering an entire /24 or /16 network is served by the same LIS.
o IPバージョン4の場合、結果のドメイン名は1つおよび2つのラベルによって連続的に短縮され、クエリが繰り返される必要があります（SHOULD）。これは、/ 24または/ 16ネットワークプレフィックスの検索に対応します。これにより、/ 24または/ 16ネットワーク全体をカバーする単一のアクセスネットワークが同じLISによって処理される場合に、DNSレコードを少なくすることができます。
o For IP version 6, the resulting domain SHOULD be shortened successively by 16, 18, 20, and 24 labels, and the query repeated. This corresponds to a search on a /64, /56, /48, or /32 network prefix.
o IPバージョン6の場合、結果のドメインは、16、18、20、および24のラベルによって連続的に短縮され、クエリが繰り返される必要があります。これは、/ 64、/ 56、/ 48、または/ 32ネットワークプレフィックスの検索に対応します。
This set of labels is intended to provide network operators with a degree of flexibility in where LIS discovery records can be placed without significantly increasing the number of DNS names that are searched. This does not attach any other significance to these specific zone cuts or create a classful addressing hierarchy based on the reverse DNS tree.
このラベルのセットは、検索されるDNS名の数を大幅に増やすことなくLIS検出レコードを配置できる柔軟性をネットワークオペレーターに提供することを目的としています。これは、これらの特定のゾーンカットに他の重要性を付加したり、逆引きDNSツリーに基づいてクラスフルアドレッシング階層を作成したりしません。
For example, the IPv4 address "192.0.2.75" could result in queries to:
たとえば、IPv4アドレス「192.0.2.75」は、次のクエリになります。
o 75.2.0.192.in-addr.arpa.
o ７５。２。０。１９２。いんーあっｄｒ。あｒぱ。
o 2.0.192.in-addr.arpa.
o ２。０。１９２。いんーあっｄｒ。あｒぱ。
o 0.192.in-addr.arpa.
o ０。１９２。いんーあっｄｒ。あｒぱ。
Similarly, the IPv6 address "2001:DB8::28e4:3a93:4429:dfb5" could result in queries to:
同様に、IPv6アドレス「2001：DB8 :: 28e4：3a93：4429：dfb5」は、次のクエリになります。
o 5.b.f.d.9.2.4.4.3.9.a.3.4.e.8.2.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2 .ip6.arpa.
o 5.b.f.d.9.2.4.4.3.9.a.3.4.e.8.2.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2 .ip6.arpa。
o 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o ０。０。０。０。０。０。０。０。８。ｂ。ｄ。０。１。０。０。２。いｐ６。あｒぱ。
o 0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o ０。０。０。０。０。０。８。ｂ。ｄ。０。１。０。０。２。いｐ６。あｒぱ。
o 0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
o ０。０。０。０。８。ｂ。ｄ。０。１。０。０。２。いｐ６。あｒぱ。
o 8.b.d.0.1.0.0.2.ip6.arpa.
o ８。ｂ。ｄ。０。１。０。０。２。いｐ６。あｒぱ。
The limited number of labels by which each name is shortened is intended to limit the number of DNS queries performed by Devices. If no LIS is discovered by this method, the result will be that no more than five U-NAPTR resolutions are invoked for each IP address.
各名前が短縮されるラベルの数は、デバイスが実行するDNSクエリの数を制限することを目的としています。この方法でLISが検出されない場合、各IPアドレスに対して呼び出されるU-NAPTR解決は5つ以下になります。
The DHCP method described in [RFC5986] MUST be attempted on all local network interfaces before attempting this method. This method is employed either because DHCP is unavailable, when the DHCP server does not provide a value for the access network domain name option, or because a request to the resulting LIS results in a HELD "notLocatable" error or equivalent.
[RFC5986]で説明されているDHCPメソッドは、このメソッドを試行する前に、すべてのローカルネットワークインターフェイスで試行する必要があります。この方法が採用されているのは、DHCPが利用できない、DHCPサーバーがアクセスネットワークドメイン名オプションの値を提供しない、または結果のLISへのリクエストによりHELD "notLocatable"エラーまたは同等のエラーが発生するためです。
Addresses from a private-use address space can be used as input to this method. In many cases, this applies to addresses defined in [RFC1918], though other address ranges could have limited reachability where this advice also applies. This is only possible if a DNS server with a view of the same address space is used. Public DNS servers cannot provide useful records for private addresses.
このメソッドへの入力として、私用アドレススペースのアドレスを使用できます。多くの場合、これは[RFC1918]で定義されたアドレスに適用されますが、このアドバイスが適用される場合、他のアドレス範囲は到達可能性が制限される可能性があります。これは、同じアドレス空間のビューを持つDNSサーバーが使用されている場合にのみ可能です。パブリックDNSサーバーは、プライベートアドレスの有用なレコードを提供できません。
Using an address from a private space in discovery can provide a more specific answer if the DNS server has records for that space. Figure 2 shows a network configuration where addresses from an ISP network could better indicate the correct LIS. Records in DNS B can be provided for the 10.0.0.0/8 range, potentially dividing that range so that a more local LIS can be selected.
DNSサーバーにそのスペースのレコードがある場合、ディスカバリーでプライベートスペースのアドレスを使用すると、より具体的な回答が得られます。図2は、ISPネットワークからのアドレスが正しいLISをより適切に示すことができるネットワーク構成を示しています。 DNS Bのレコードは10.0.0.0/8の範囲に提供でき、その範囲を分割して、よりローカルなLISを選択できるようにすることができます。
_____ ________
( DNS ).....(/ \) Public
(__A__) (( Internet )) Address
(\________/) Space
|
[NAT]
_____ _____|_____
( DNS )....(/ \) Private
(__B__) (( ISP Network )) Address Space
(\___________/) (e.g., 10.0.0.0/8)
|
[Gateway]
____|____
(/ \) Private
(( Residence )) Address Space
(\_________/) (e.g., 192.168.0.0/16)
Figure 2: Address Space Example
図2：アドレス空間の例
The goal of automatic DNS configuration is usually to select a local DNS, which suits configurations like the one shown. However, use of public DNS or STUN servers means that a public IP address is likely to be found. For STUN in particular, selecting a public server minimizes the need for reconfiguration when a Device moves. Adding records for the public address space used by an access network ensures that the discovery process succeeds when a public address is used.
自動DNS構成の目的は通常、ローカルDNSを選択することです。これは、示されているような構成に適しています。ただし、パブリックDNSまたはSTUNサーバーを使用すると、パブリックIPアドレスが見つかる可能性が高くなります。特にSTUNの場合、パブリックサーバーを選択すると、デバイスの移動時に再構成する必要が最小限になります。アクセスネットワークで使用されるパブリックアドレススペースのレコードを追加すると、パブリックアドレスが使用されている場合に検出プロセスが確実に成功します。
When used by a Device for LIS discovery, this is an UNSAF application and is subject to the limitations described in Section 7.
LISディスカバリー用のデバイスで使用される場合、これはUNSAFアプリケーションであり、セクション7で説明されている制限の対象となります。
It is not necessary that the IP address used is unique to the Device, only that the address can be somehow related to the Device or the access network that serves the Device. This allows a degree of flexibility in determining this value, although security considerations (Section 6) might require that the address be verified to limit the chance of falsification.
使用するIPアドレスがデバイスに固有である必要はありません。アドレスがデバイスまたはデバイスにサービスを提供するアクセスネットワークに何らかの形で関連している可能性があることだけが必要です。これにより、この値を決定する際にある程度の柔軟性が得られますが、セキュリティ上の考慮事項（セクション6）では、アドレスを検証して改ざんの可能性を制限する必要がある場合があります。
This solution assumes that the public, reflexive transport address used by a Device is in some way controlled by the access network provider or some other related party. This implies that the corresponding ".in-addr.arpa." or ".ip6.arpa." record can be updated by that entity to include a useful value for the LIS address.
このソリューションは、デバイスによって使用されるパブリックな再帰トランスポートアドレスが、何らかの方法でアクセスネットワークプロバイダーまたは他の関連するパーティによって制御されることを前提としています。これは、対応する「.in-addr.arpa。」または「.ip6.arpa」そのエンティティによってレコードを更新して、LISアドレスの有用な値を含めることができます。
Successful use of private addresses relies on a DNS server that has records for the address space that is used. Using a public IP address increases the likelihood of this. This document relies on STUN to provide the Device with a public, reflexive transport address. Configuration of a STUN server is necessary to ensure that this is successful.
プライベートアドレスの正常な使用は、使用されるアドレススペースのレコードを持つDNSサーバーに依存しています。パブリックIPアドレスを使用すると、この可能性が高くなります。このドキュメントでは、STUNを使用して、デバイスにパブリックな再帰トランスポートアドレスを提供しています。これを確実に成功させるには、STUNサーバーの構成が必要です。
In cases where a virtual private network (VPN) or other tunnel is used, the entity providing a public IP address might not be able to provide the Device with location information. It is assumed that this entity is able to identify this problem and indicate this to the Device (using the "notLocatable" HELD error or similar). This problem is described in more detail in [RFC5985].
仮想プライベートネットワーク（VPN）または他のトンネルが使用される場合、パブリックIPアドレスを提供するエンティティは、デバイスに位置情報を提供できない場合があります。このエンティティはこの問題を識別し、これをデバイスに示すことができると想定されています（「notLocatable」HELDエラーなどを使用）。この問題は、[RFC5985]でより詳細に説明されています。
An access network provider SHOULD provide NAPTR records for each public IP address that is used for Devices within the access network.
アクセスネットワークプロバイダーは、アクセスネットワーク内のデバイスに使用される各パブリックIPアドレスのNAPTRレコードを提供する必要があります（SHOULD）。
Any DNS server internal to a NAT SHOULD also include records for the private address range. These records might only be provided to clients making requests from the private address range. Doing so allows clients within the private address range to discover a LIS based on their IP address prior to any address translation. In geographically distributed networks that use a private address range, this enables the use of a different LIS for different locations, based on the IP address range used at each location. Use of a public, translated IP address for the network can still work, but it might result in a suboptimal LIS selection.
NAT内部のDNSサーバーには、プライベートアドレス範囲のレコードも含める必要があります（SHOULD）。これらのレコードは、プライベートアドレス範囲からリクエストを行うクライアントにのみ提供される場合があります。これにより、プライベートアドレス範囲内のクライアントは、アドレス変換の前に、IPアドレスに基づいてLISを検出できます。プライベートアドレス範囲を使用する地理的に分散したネットワークでは、これにより、各場所で使用されるIPアドレス範囲に基づいて、場所ごとに異なるLISを使用できます。ネットワークに変換されたパブリックIPアドレスを使用しても機能しますが、LISの選択が最適ではなくなる可能性があります。
A network that operates network address translation SHOULD provide NAPTR records that reference a LIS endpoint with a public address. This requires the reservation of an IP address and port for the LIS. To ensure requests toward the LIS from within the private address space do not traverse the NAT and have source addresses mapped by the NAT, networks can provide a direct route to the LIS. Clients that perform discovery based on public DNS or STUN servers are thereby easier to trace based on source address information.
ネットワークアドレス変換を操作するネットワークは、LISエンドポイントをパブリックアドレスで参照するNAPTRレコードを提供する必要があります（SHOULD）。これには、LISのIPアドレスとポートの予約が必要です。プライベートアドレススペース内からLISへの要求がNATを通過せず、NATによって送信元アドレスがマップされるようにするために、ネットワークはLISへの直接ルートを提供できます。これにより、パブリックDNSまたはSTUNサーバーに基づいて検出を実行するクライアントは、送信元アドレス情報に基づいてトレースしやすくなります。
NAPTR records can be provided for individual IP addresses. To limit the proliferation of identical records, a single record can be placed at higher nodes of the tree (corresponding to /24 and /16 for IPv4; /64, /56, /48, and /32 for IPv6). A record at a higher point in the tree (those with a shorter prefix) applies to all addresses lower in the tree (those with a longer prefix); records at the lower point override those at higher points, thus allowing for exceptions to be specified.
NAPTRレコードは、個々のIPアドレスに対して提供できます。同一のレコードの増加を制限するために、単一のレコードをツリーの上位ノードに配置できます（IPv4の場合は/ 24および/ 16、IPv6の場合は/ 64、/ 56、/ 48、および/ 32に対応）。ツリーの上位のポイント（短い接頭辞を持つレコード）は、ツリーの下位（長い接頭辞を持つアドレス）のすべてのアドレスに適用されます。低いポイントのレコードは高いポイントのレコードをオーバーライドするため、例外を指定できます。
As with all uses of geolocation information, it is very important that measures be taken to ensure that location information is not provided to unauthorized parties. The mechanism defined in this document is focused on the case where a device is learning its own location so that it can provide that location information to applications. We assume that the device learning its own location is not a privacy risk. There are then two remaining privacy risks: the use of geolocation by applications, and the abuse of the location configuration protocol.
地理位置情報のすべての使用と同様に、位置情報が不正な関係者に提供されないようにするための対策を講じることは非常に重要です。このドキュメントで定義されているメカニズムは、デバイスが位置情報をアプリケーションに提供できるように、デバイスが自身の位置を学習している場合に焦点を当てています。私たちは、デバイスが自身の位置を学習することはプライバシーリスクではないと想定しています。次に、2つのプライバシーリスクが残ります。アプリケーションによるジオロケーションの使用と、ロケーション構成プロトコルの乱用です。
The privacy considerations around the use of geolocation by applications vary considerably by application context. A framework for location privacy in applications is provided in [RFC6280].
アプリケーションによる地理位置情報の使用に関するプライバシーの考慮事項は、アプリケーションのコンテキストによってかなり異なります。アプリケーションの位置プライバシーのフレームワークは、[RFC6280]で提供されています。
The mechanism specified in this document allows a device to discover its local LIS, from which it then acquires its location using a Location Configuration Protocol (LCP) [RFC5687]. If an unauthorized third party can spoof the LCP to obtain a target's location information, then the mechanism in this document could allow them to discover the proper server to attack for a given IP address. Thus, it is important that a LIS meet the security requirements of the LCP it implements. For HELD, these requirements are laid out in Section 9 of [RFC5985].
このドキュメントで指定されているメカニズムにより、デバイスはローカルLISを検出し、そこからLocation Configuration Protocol（LCP）[RFC5687]を使用してその位置を取得できます。許可されていない第三者がLCPを偽装してターゲットの位置情報を取得できる場合、このドキュメントのメカニズムにより、特定のIPアドレスを攻撃する適切なサーバーを発見できる可能性があります。したがって、LISが実装するLCPのセキュリティ要件を満たすことが重要です。 HELDの場合、これらの要件は[RFC5985]のセクション9に示されています。
A Device that discovers a LIS using the methods in this document MUST NOT provide that LIS with additional information that might reveal its position, such as the location measurements described in [RFC7105], unless it has a secondary method for determining the authenticity of the LIS, such as a white list.
このドキュメントの方法を使用してLISを検出するデバイスは、LISの信頼性を判断するための二次的な方法がない限り、[RFC7105]で説明されている位置測定など、その位置を明らかにする可能性がある追加情報をLISに提供してはなりません、ホワイトリストなど。
The security considerations described in [RFC5986] apply to the discovery process as a whole. The primary security concern is with the potential for an attacker to impersonate a LIS.
[RFC5986]で説明されているセキュリティの考慮事項は、検出プロセス全体に適用されます。セキュリティの主な問題は、攻撃者がLISを偽装する可能性があることです。
The added ability for a third party to discover the identity of a LIS does not add any concerns, since the identity of a LIS is considered public information.
LISのIDは公開情報と見なされるため、第三者がLISのIDを検出する機能が追加されても問題はありません。
In addition to existing considerations, this document introduces further security considerations relating to the identification of the IP address. It is possible that an attacker could attempt to provide a falsified IP address in an attempt to subvert the rest of the process.
このドキュメントでは、既存の考慮事項に加えて、IPアドレスの識別に関するセキュリティの考慮事項をさらに紹介します。攻撃者がプロセスの残りを破壊しようとして、偽造されたIPアドレスを提供しようとする可能性があります。
[RFC5389] describes attacks where an attacker is able to ensure that a Device receives a falsified reflexive address. An on-path attacker might be able to ensure that a falsified address is provided to the Device. Even though STUN messages are protected by a STUN MESSAGE-INTEGRITY attribute, which is an HMAC that uses a shared secret, an on-path attacker can capture and modify packets, altering source and destination addresses to provide falsified addresses.
[RFC5389]は、攻撃者がデバイスが改ざんされた再帰アドレスを受信したことを確認できる攻撃について説明しています。パス上の攻撃者は、偽のアドレスがデバイスに提供されていることを確認できる可能性があります。 STUNメッセージは共有シークレットを使用するHMACであるSTUN MESSAGE-INTEGRITY属性で保護されていますが、パス上の攻撃者はパケットをキャプチャして変更し、送信元アドレスと宛先アドレスを変更して偽造アドレスを提供する可能性があります。
This attack could result in an effective means of denial of service, or a means to provide a deliberately misleading service. Notably, any LIS that is identified based on a falsified IP address could still be a valid LIS for the given IP address, just not one that is useful for providing the Device with location information. In this case, the LIS provides a HELD "notLocatable" error or an equivalent. If the falsified IP address is under the control of the attacker, it is possible that misleading (but verifiable) DNS records could indicate a malicious LIS that provides false location information.
この攻撃は、サービス拒否の効果的な手段、または意図的に誤解を招くサービスを提供する手段になる可能性があります。特に、改ざんされたIPアドレスに基づいて識別されるLISは、特定のIPアドレスに対して有効なLISである可能性があり、デバイスに位置情報を提供するのに役立つLISだけではありません。この場合、LISはHELD "notLocatable"エラーまたは同等のエラーを提供します。偽造されたIPアドレスが攻撃者の制御下にある場合、誤解を招く（ただし検証可能な）DNSレコードが、誤った位置情報を提供する悪意のあるLISを示している可能性があります。
In all cases of falsification, the best remedy is to perform some form of independent verification of the result. No specific mechanism is currently available to prevent attacks based on falsification of reflexive addresses; it is suggested that Devices attempt to independently verify that the reflexive transport address provided is accurate. An independent, trusted source of location information could aid in verification, even if the trusted source is unable to provide information with the same degree of accuracy as the discovered LIS.
改ざんのすべての場合において、最善の救済策は、結果の独立した検証を何らかの形で実行することです。現在、再帰アドレスの改ざんに基づく攻撃を防止するための特定のメカニズムはありません。デバイスは、提供された再帰トランスポートアドレスが正確であることを個別に検証しようとすることが推奨されます。信頼できる発信元が発見されたLISと同じ程度の精度で情報を提供できない場合でも、独立した信頼できる位置情報の発信元は検証に役立ちます。
Use of private address space effectively prevents use of the usual set of trust anchors for DNSSEC. Only a DNS server that is able to see the same private address space can provide useful records. A Device that relies on DNS records in the private address space portion of the ".in-addr.arpa." or ".ip6.arpa." trees MUST either use an alternative trust anchor for these records or rely on other means of ensuring the veracity of the DNS records.
プライベートアドレススペースを使用すると、DNSSECの通常のトラストアンカーセットを使用できなくなります。同じプライベートアドレススペースを参照できるDNSサーバーのみが、有用なレコードを提供できます。 「.in-addr.arpa」のプライベートアドレススペース部分のDNSレコードに依存するデバイス。または「.ip6.arpa」ツリーは、これらのレコードに代替のトラストアンカーを使用するか、DNSレコードの信憑性を保証する他の手段に依存する必要があります。
DNS queries that are not blocked as [RFC6303] demands, or directed to servers outside the network, can cause the addresses that are in use within the network to be exposed outside of the network. For resolvers within the network, implementing [RFC6303] avoids this issue; otherwise, the problem cannot be avoided without blocking DNS queries to external servers.
[RFC6303]要求としてブロックされない、またはネットワーク外のサーバーに送信されるDNSクエリにより、ネットワーク内で使用中のアドレスがネットワーク外に公開される可能性があります。ネットワーク内のリゾルバの場合、[RFC6303]を実装するとこの問題を回避できます。そうしないと、外部サーバーへのDNSクエリをブロックしない限り、問題を回避できません。
The IAB has studied the problem of Unilateral Self-Address Fixing (UNSAF) [RFC3424], which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism, such as STUN.
IABは、ユニラテラルセルフアドレスフィクシング（UNSAF）[RFC3424]の問題を調査しました。これは、クライアントが協調プロトコルリフレクションメカニズムを介してNATの反対側にある別のレルムでアドレスを決定しようとする一般的なプロセスです。 STUNなど。
This section only applies to the use of this method of LIS discovery by Devices and does not apply to its use for third-party LIS discovery.
このセクションは、デバイスによるこのLIS検出方法の使用にのみ適用され、サードパーティのLIS検出での使用には適用されません。
The IAB requires that protocol specifications that define UNSAF mechanisms document a set of considerations.
IABは、UNSAFメカニズムを定義するプロトコル仕様が一連の考慮事項を文書化することを要求しています。
1. Precise definition of a specific, limited-scope problem that is to be solved with the UNSAF proposal.
1. UNSAF提案で解決される特定の限定スコープ問題の正確な定義。
Section 3 describes the limited scope of the problem addressed in this document.
セクション3では、このドキュメントで扱う問題の限定的な範囲について説明します。
2. Description of an exit strategy/transition plan.
2. 出口戦略/移行計画の説明。
[RFC5986] describes behavior that residential gateways require in order for this short-term solution to be rendered unnecessary. When implementations of the recommendations in LIS discovery are widely available, this UNSAF mechanism can be made obsolete.
[RFC5986]は、この短期的なソリューションを不要にするためにレジデンシャルゲートウェイが必要とする動作を説明しています。 LISディスカバリでの推奨事項の実装が広く利用できる場合、このUNSAFメカニズムは廃止することができます。
3. Discussion of specific issues that may render systems more "brittle".
3. システムをより「脆弱」にする可能性のある特定の問題についての議論。
A description of the necessary assumptions and limitations of this solution are included in Section 4.6.
このソリューションに必要な前提と制限の説明は、セクション4.6に含まれています。
Use of STUN for discovery of a reflexive transport address is inherently brittle in the presence of multiple NATs or address realms. In particular, brittleness is added by the requirement of using a DNS server that is able to view the address realm that contains the IP address in question. If address realms use overlapping addressing space, then there is a risk that the DNS server provides information that is not useful to the Device.
複数のNATまたはアドレスレルムが存在する場合、再帰トランスポートアドレスの検出にSTUNを使用することは本質的に脆弱です。特に、問題のIPアドレスを含むアドレスレルムを表示できるDNSサーバーを使用する必要があるため、脆弱性が追加されています。アドレスレルムが重複するアドレス空間を使用する場合、DNSサーバーがデバイスにとって有用でない情報を提供するリスクがあります。
4. Identify requirements for longer-term, sound technical solutions; contribute to the process of finding the right longer-term solution.
4. 長期的で健全な技術ソリューションの要件を特定します。適切な長期的な解決策を見つけるプロセスに貢献する。
A longer-term solution is already provided in [RFC5986]. However, that solution relies on widespread deployment. The UNSAF solution provided here is an interim solution that enables LIS access for Devices that are not able to benefit from deployment of the recommendations in [RFC5986].
より長期的な解決策はすでに[RFC5986]で提供されています。ただし、そのソリューションは広範囲にわたる展開に依存しています。ここで提供されるUNSAFソリューションは、[RFC5986]の推奨事項の展開から利益を得ることができないデバイスのLISアクセスを可能にする暫定的なソリューションです。
5. Discussion of the impact of the noted practical issues with existing deployed NATs and experience reports.
5. 既存の展開済みNATと経験報告で指摘された実際的な問題の影響についての議論。
The UNSAF mechanism depends on the experience in deployment of STUN [RFC5389]. On the whole, existing residential gateway devices are able to provide access to STUN and DNS service reliably, although regard should be given to the size of the DNS response (see [RFC5625]).
UNSAFメカニズムは、STUN [RFC5389]の導入経験に依存します。概して、既存の住宅用ゲートウェイデバイスは、DNS応答のサイズを考慮する必要がありますが（[RFC5625]を参照）、STUNおよびDNSサービスへのアクセスを確実に提供できます。
Richard Barnes provided the text in Section 5.
Richard Barnesがセクション5でテキストを提供しました。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V.、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、2003年10月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986] Thomson、M.およびJ. Winterbottom、「Discovering the Local Location Information Server（LIS）」、RFC 5986、2010年9月。
[RFC7105] Thomson, M. and J. Winterbottom, "Using Device-Provided Location-Related Measurements in Location Configuration Protocols", RFC 7105, January 2014.
[RFC7105] Thomson、M。、およびJ. Winterbottom、「Using Device-Provided Location-Related Measurements in Location Configuration Protocols」、RFC 7105、2014年1月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[RFC4848] Daigle、L。、「URIと動的委任発見サービス（DDDS）を使用したドメインベースのアプリケーションサービスロケーション」、RFC 4848、2007年4月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012] Schulzrinne、H。およびR. Marshall、「インターネットテクノロジーによる緊急コンテキスト解決の要件」、RFC 5012、2008年1月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687] Tschofenig、H。およびH. Schulzrinne、「GEOPRIV Layer 7 Location Configuration Protocol：Problem Statement and Requirements」、RFC 5687、2010年3月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, July 2011.
[RFC6303]アンドリュース、M。、「ローカルで提供されるDNSゾーン」、BCP 163、RFC 6303、2011年7月。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.
[RFC6887] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、2013年4月。
[UPnP-IGD-WANIPConnection1] UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0: WANIPConnection:1 Service Template Version 1.01 For UPnP Version 1.0", DCP 05-001, Nov. 2001, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>.
[UPnP-IGD-WANIPConnection1] UPnPフォーラム、「インターネットゲートウェイデバイス（IGD）標準化デバイスコントロールプロトコルV 1.0：WANIPConnection：1サービステンプレートバージョン1.01、UPnPバージョン1.0用」、DCP 05-001、2001年11月、<http：/ /upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v1-Service.pdf>。
[RFC6886] Cheshire, S. and M. Krochmal, "NAT Port Mapping Protocol (NAT-PMP)", RFC 6886, April 2013.
[RFC6886] Cheshire、S。およびM. Krochmal、「NATポートマッピングプロトコル（NAT-PMP）」、RFC 6886、2013年4月。
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, August 2009.
[RFC5625] Bellis、R。、「DNSプロキシ実装ガイドライン」、BCP 152、RFC 5625、2009年8月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP-Enabled Location Delivery（HELD）」、RFC 5985、2010年9月。
Authors' Addresses
著者のアドレス
Martin Thomson Mozilla Suite 300 650 Castro Street Mountain View, CA 94041 US
Martin Thomson Mozilla Suite 300 650 Castro Street Mountain View、CA 94041 US
EMail: martin.thomson@gmail.com
Ray Bellis Nominet UK Edmund Halley Road Oxford OX4 4DQ United Kingdom
レイベリスノミネットイギリスエドマンドハリーロードオックスフォードOX4 4DQイギリス
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/