[要約] RFC 6281は、AppleのBack to My Mac（BTMM）サービスについての理解と目的を説明しています。このRFCの目的は、BTMMサービスの機能と動作を詳細に説明し、ユーザーがサービスを効果的に利用できるようにすることです。
Internet Engineering Task Force (IETF) S. Cheshire
Request for Comments: 6281 Apple Inc.
Category: Informational Z. Zhu
ISSN: 2070-1721 UCLA
R. Wakikawa
Toyota ITC
L. Zhang
UCLA
June 2011
Understanding Apple's Back to My Mac (BTMM) Service
AppleのBack to My Mac（BTMM）サービスを理解する
Abstract
概要
This document describes the implementation of Apple Inc.'s Back to My Mac (BTMM) service. BTMM provides network connectivity between devices so that a user can perform file sharing and screen sharing among multiple computers at home, at work, or on the road. The implementation of BTMM addresses the issues of single sign-on authentication, secure data communication, service discovery, and end-to-end connectivity in the face of Network Address Translators (NATs) and mobility of devices.
このドキュメントでは、Apple Inc.のBack to My Mac（BTMM）サービスの実装について説明しています。BTMMは、デバイス間のネットワーク接続を提供し、ユーザーが自宅、職場、または路上で複数のコンピューター間でファイル共有と画面共有を実行できるようにします。BTMMの実装は、ネットワークアドレス翻訳者（NAT）とデバイスのモビリティに直面したシングルサインオン認証、安全なデータ通信、サービスの発見、エンドツーエンドの接続の問題に対処します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc6281.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6281で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. An Overview of Back to My Mac . . . . . . . . . . . . . . . . 3
3. Encoding Host Information in DNS Resource Records . . . . . . 5
4. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Introduction to NAT-PMP . . . . . . . . . . . . . . . . . 6
4.2. Requesting/Removing a Port Mapping . . . . . . . . . . . . 7
4.3. Obtaining NAT Box's Public IP Address . . . . . . . . . . 7
4.4. Unsupported Scenarios . . . . . . . . . . . . . . . . . . 8
5. Handling IP Address or Port Changes . . . . . . . . . . . . . 8
5.1. Updating Local Interfaces and Tunnels . . . . . . . . . . 8
5.2. Dynamically Updating Reachability Information . . . . . . 8
5.3. Getting Up-to-Date DNS Resource Records without Polling . 9
6. IPv6 ULA as Host ID . . . . . . . . . . . . . . . . . . . . . 11
6.1. The Need for a Host Identifier . . . . . . . . . . . . . . 11
6.2. What to Use as Host Identifiers . . . . . . . . . . . . . 11
6.3. IPv6 ULA Configuration . . . . . . . . . . . . . . . . . . 11
7. Securing Communication . . . . . . . . . . . . . . . . . . . . 12
7.1. Authentication for Connecting to Remote Host . . . . . . . 12
7.2. Authentication for DNS Exchanges . . . . . . . . . . . . . 12
7.3. IPsec for Secure End-to-End Data Communication . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative Reference . . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
Apple Inc.'s Back to My Mac (BTMM) service was first shipped with MAC OS X 10.5 release in October 2007; since then, it has been widely used. BTMM provides an integrated solution to host mobility support, NAT traversal, and secure end-to-end data delivery through a combination of several existing protocols and software tools instead of designing new protocols. Note that we generally refer to Network Address Port Translation (NAPT) as NAT in this document. This document describes the implementation of BTMM and describes how BTMM works in MAC OS X version 10.5.x; BTMM continues to evolve over time.
Apple Inc.のBack to My Mac（BTMM）サービスは、2007年10月にMac OS X 10.5リリースで最初に出荷されました。それ以来、広く使用されています。BTMMは、新しいプロトコルを設計する代わりに、いくつかの既存のプロトコルとソフトウェアツールの組み合わせを介して、ホストモビリティサポート、NATトラバーサル、および安全なエンドツーエンドのデータ配信を統合したソリューションを提供します。通常、このドキュメントのネットワークアドレスポート翻訳（NAPT）をNATと呼びます。このドキュメントでは、BTMMの実装について説明し、Mac OS Xバージョン10.5.xでBTMMがどのように機能するかについて説明します。BTMMは時間の経過とともに進化し続けています。
BTMM provides secure transport connections among a set of devices that may be located over a dynamic and heterogeneous network environment. Independent from whether a user is traveling and accessing the Internet via airport WiFi or staying at home behind a NAT, BTMM allows the user to connect to any Mac hosts with a click, after which the user can share files with remote computers or control the remote host through screen sharing. When a user changes locations and thus also changes the IP address of his computer (e.g., roaming around with a laptop and receiving dynamically allocated IP address), BTMM provides a means for the roaming host to update its reachability information to keep it reachable by the user's other Mac devices. BTMM maintains end-to-end transport connections in the face of host IP address changes through the use of unique host identifiers. It also provides a means to reach devices behind a NAT.
BTMMは、動的で不均一なネットワーク環境上に配置される可能性のある一連のデバイス間の安全な輸送接続を提供します。ユーザーが空港WiFi経由でインターネットにアクセスしているか、NATの後ろに家にいるかどうかから独立して、BTMMを使用すると、ユーザーはクリックしてMacホストに接続できます。スクリーン共有を介してホスト。ユーザーが場所を変更してコンピューターのIPアドレスを変更すると（たとえば、ラップトップで歩き回って動的に割り当てられたIPアドレスを受信します）、BTMMはローミングホストが到達可能な情報を更新して、到達可能な情報を更新する手段を提供します。ユーザーの他のMacデバイス。BTMMは、一意のホスト識別子を使用して、ホストIPアドレスの変更に直面してエンドツーエンドのトランスポート接続を維持します。また、NATの背後にあるデバイスに到達する手段も提供します。
BTMM achieves the above functions mainly by integrating a set of existing protocols and software tools. It uses DNS-based Service Discovery [DNS-SD] to announce host reachability information, dynamic DNS update [RFC2136] to refresh the DNS resource records (RRs) when a host detects network changes, and DNS Long-Lived Queries (LLQs) [DNS-LLQ] to notify hosts immediately when the answers to their earlier DNS queries have changed. BTMM uses the IPv6 Unique Local Address (ULA) [RFC4193] as the host identifier and employs the NAT Port Mapping Protocol (PMP) [NAT-PMP] to assist NAT traversal. It uses Kerberos [RFC4120] for end-to-end authentication and uses IPsec [RFC4301] to secure data communications between two end hosts.
BTMMは、主に一連の既存のプロトコルとソフトウェアツールを統合することにより、上記の機能を達成します。DNSベースのサービスディスカバリー[DNS-SD]を使用して、ホストの到達可能性情報、動的DNSアップデート[RFC2136]を発表して、ホストがネットワークの変更を検出したときにDNSリソースレコード（RRS）を更新し、DNSの長寿命（LLQS）[LLQS）[DNS-llq]以前のDNSクエリへの回答が変更されたときにすぐにホストに通知するため。BTMMは、IPv6一意のローカルアドレス（ULA）[RFC4193]をホスト識別子として使用し、NATポートマッピングプロトコル（PMP）[NAT-PMP]を使用してNATトラバーサルを支援します。エンドツーエンド認証にKerberos [RFC4120]を使用し、IPSEC [RFC4301]を使用して、2つのエンドホスト間でデータ通信を保護します。
To keep an established TCP connection running while either of the two end hosts may change its IP address requires that the connection use unique and stable identifiers that do not change with the addresses, and that a mapping service exists between these stable identifiers and dynamically changing IP addresses. BTMM uses DNS to provide this mapping service. Figure 1 provides a sketch of the basic components in the BTMM implementation.
確立されたTCP接続を実行し続けるには、2つのエンドホストのいずれかがIPアドレスを変更する可能性がある間、接続を使用する必要があります。アドレス。BTMMはDNSを使用してこのマッピングサービスを提供します。図1に、BTMM実装の基本コンポーネントのスケッチを示します。
DDNS update +--------+ DDNS update
+--------------->| |<-------+
| | DNS | |
| LLQ | | LLQ |
| +---------->| |<----+ |
| | | | | |
| | +--------+ | |
| | | | +----------+
| V +---+--+----+ | |
+-+-------+ | +-------| |
|Endhost N| Tunnel | NAT +------>|Endhost M |
| |<=====================================>| |
+---------+ | | | |
+-----------+ +----------+
Figure 1
図1
Apple Inc. operates a DNS domain called members.me.com and provides DNS name resolution services for all the subdomains underneath. Every BTMM user is assigned a DNS subdomain under members.me.com, e.g., alice.members.me.com. The user then assigns a DNS name for each of her computers, e.g., myMacPro.alice.members.me.com. The reachability information of each of the user's hosts is encoded in DNS resource records and published in the DNS. For example, if the host myMacPro.alice.members.me.com has a public IPv4 address P, P represents the reachability information to the host. On the other hand, if the host is behind a NAT, its reachability information is composed of the public IP address of the NAT box and the port number opened on the NAT to reach the internal host. In this case, both the public IP address of the NAT box and the port number are encoded into DNS using DNS SRV records [RFC2782], as we explain in the next section. When a user logs in from a host M, M starts updating the DNS server about its reachability information. If the user has multiple hosts, M also sets up LLQs with the DNS server for her other hosts, so that the DNS server can push any reachability changes of these other hosts to M immediately.
Apple Inc.は、Members.me.comと呼ばれるDNSドメインを運用し、下のすべてのサブドメインにDNS名解像度サービスを提供しています。すべてのBTMMユーザーには、member.me.comの下でDNSサブドメインが割り当てられます。次に、ユーザーは各コンピューターにDNS名を割り当てます。たとえば、mymacpro.alice.members.me.com。各ユーザーのホストの到達可能性情報は、DNSリソースレコードにエンコードされ、DNSで公開されています。たとえば、ホストmymacpro.alice.members.me.comがパブリックIPv4アドレスPを持っている場合、Pはホストの到達可能性情報を表します。一方、ホストがNATの背後にある場合、その到達可能性情報はNATボックスのパブリックIPアドレスで構成され、内部ホストに到達するためにNATにポート番号が開いています。この場合、次のセクションで説明するように、NATボックスのパブリックIPアドレスとポート番号の両方がDNS SRVレコード[RFC2782]を使用してDNSにエンコードされます。ユーザーがホストMからログインすると、Mはその到達可能性情報についてDNSサーバーの更新を開始します。ユーザーが複数のホストを持っている場合、Mは他のホストのDNSサーバーでLLQSを設定するため、DNSサーバーはこれらの他のホストの到達可能性の変更をすぐにMにプッシュできます。
To obtain a unique identifier for each host, BTMM automatically generates an IPv6 ULA for each host as its identifier at machine boot time. This design choice allows BTMM to reuse all the existing code of applications and protocols that already support IPv6. To ensure end-to-end data security, BTMM leverages the existing IPsec to protect the communications and Kerberos to perform end-to-end authentication.
各ホストの一意の識別子を取得するために、BTMMは、マシンブート時間に識別子として各ホストのIPv6 ULAを自動的に生成します。この設計の選択により、BTMMは既存のすべてのアプリケーションコードとすでにIPv6をサポートするプロトコルを再利用できます。エンドツーエンドのデータセキュリティを確保するために、BTMMは既存のIPSECを活用して通信を保護し、Kerberosはエンドツーエンド認証を実行します。
BTMM provides an IPv6 socket interface to user applications. It then wraps the IPv6 packets with IPsec Encapsulating Security Payload (ESP) [RFC4303] and encapsulates the packets in a UDP/IP tunnel, as illustrated in Figure 2. Note that this is the case even when both ends have public IPv4 addresses.
BTMMは、ユーザーアプリケーションにIPv6ソケットインターフェイスを提供します。次に、IPv6パケットをIPSECをセキュリティペイロード（ESP）[RFC4303]にカプセル化し、図2に示すように、UDP/IPトンネルのパケットをカプセル化します。
+-------------+------------+------------+---------------+
| IPv4 Header | UDP Header | IPsec ESP | IPv6 Packet |
+-------------+------------+------------+---------------+
Figure 2
図2
The following sections describe each of the basic components in BTMM. Since this document is intended to be an informal description of the BTMM implementation, it does not include all the details (e.g., packet format, error code, etc) of each component.
次のセクションでは、BTMMの基本コンポーネントのそれぞれについて説明します。このドキュメントはBTMM実装の非公式の説明であることを目的としているため、各コンポーネントのすべての詳細（パケット形式、エラーコードなど）はすべて含まれていません。
For each host, BTMM encodes into DNS both the host identifier and its current location information. BTMM stores the host identifier (IPv6 ULA) in a DNS AAAA RR and uses a DNS SRV RR [RFC2782] to represent the host's current location information. For hosts behind a NAT box, the use of a DNS SRV RR allows BTMM to store both the public IP address of the NAT box and also the port opened for the host.
各ホストについて、BTMMはホスト識別子とその現在の位置情報の両方のDNSにエンコードします。BTMMは、ホスト識別子（IPv6 ULA）をDNS AAAA RRに保存し、DNS SRV RR [RFC2782]を使用してホストの現在の位置情報を表します。NATボックスの背後にあるホストの場合、DNS SRV RRの使用により、BTMMはNATボックスのパブリックIPアドレスとホスト用に開くポートの両方を保存できます。
The SRV RR consists of eight fields: _Service._Proto.Name, Time to Live (TTL), Class, Type, Priority, Weight, Port, and Target. BTMM uses SRV RRs in the following way.
SRV RRは、_Service._Proto.Name、Live（TTL）、クラス、タイプ、優先度、重量、ポート、およびターゲットの8つのフィールドで構成されています。BTMMは、次の方法でSRV RRSを使用します。
Service is the symbolic name of the desired service. In the BTMM case, the service is named "autotunnel", which means that the information contained in the SRV RR is used by BTMM to automatically set up a tunnel between two end hosts.
サービスは、目的のサービスの象徴的な名前です。BTMMの場合、サービスの名前は「AutoTunnel」と名付けられています。つまり、SRV RRに含まれる情報は、BTMMが2つのエンドホスト間にトンネルを自動的にセットアップするために使用されます。
Proto is the symbolic name of the desired protocol. In this document, the protocol is "_udp". BTMM uses "_udp" to tunnel packets between the two ends to achieve NAT traversal.
Protoは、目的のプロトコルの象徴的な名前です。このドキュメントでは、プロトコルは「_udp」です。BTMMは「_udp」を使用して、2つの端の間のトンネルパケットを使用して、NATトラバーサルを実現します。
Name is the domain this RR refers to. When a user subscribes to BTMM service with the username "alice", a domain name "alice.members.me.com" is assigned to her. The user assigns a name, such as "myMacPro", to each host that is appended to the assigned domain name. Hence, the first part of the SRV record would look like this: "_autotunnel._udp.myMacPro.alice.members.me.com".
名前は、このRRが指すドメインです。ユーザーがユーザー名「Alice」を使用してBTMMサービスを購読すると、ドメイン名「Alice.members.me.com」が彼女に割り当てられます。ユーザーは、割り当てられたドメイン名に追加された各ホストに「mymacpro」などの名前を割り当てます。したがって、SRVレコードの最初の部分は次のようになります。
Priority and Weight are set to zero, since there is only one instance that provides autotunnel service for each name in BTMM.
優先度と重量はゼロに設定されています。これは、BTMMの各名前にAutoTunnelサービスを提供するインスタンスが1つしかないためです。
Port is the port opened on the target host of the service. In BTMM, most likely it is the external port a NAT opened for the host behind it. Knowing the port number is the basic requirement for NAT traversal via UDP encapsulation. If the host is not behind a NAT, the port opened on the host for autotunnel service is placed here.
ポートは、サービスのターゲットホストに開かれたポートです。BTMMでは、おそらくそれはその背後にあるホストのために開かれたNAT A NATが外部ポートである可能性があります。ポート番号を知ることは、UDPカプセル化を介したNATトラバーサルの基本要件です。ホストがNATの後ろにいない場合、AutoTunnelサービスのホストに開かれたポートがここに配置されます。
Target is the canonical hostname of the host that provides the service. In BTMM, it refers to a name constructed by appending the user's domain name to an autotunnel label, which identifies the host and is not generally user-visible. The autotunnel label is created by concatenating "AutoTunnel" with the IEEE EUI-64 identifier [EUI64] of the primary network interface. Hence, an example for the Target field would look like this: AutoTunnel-00-22-69-FF-FE-8E-34- 2A.alice.members.me.com. After obtaining the SRV RR, the remote host can query the A RR for the Target and get the external tunnel address for the BTMM client during the NAT Traversal.
ターゲットは、サービスを提供するホストの正規ホスト名です。BTMMでは、ユーザーのドメイン名をAutoTunnelラベルに追加することで作成された名前を指します。これは、ホストを識別し、一般にユーザー可視ではありません。AutoTunnelラベルは、プライマリネットワークインターフェイスのIEEE EUI-64識別子[EUI64]と「オートトゥンネル」を連結することにより作成されます。したがって、ターゲットフィールドの例は次のようになります：autotunnel-00-22-69-ff-fe-8e-34-2a.alice.members.me.com。SRV RRを取得した後、リモートホストはターゲットのA RRを照会し、NATトラバーサル中にBTMMクライアントの外部トンネルアドレスを取得できます。
BTMM's NAT traversal function requires NAT router devices to support NAT-PMP or the Universal Plug and Play (UPnP) Internet Gateway Device (IGD). NAT-PMP is the alternative introduced by Apple Inc. to the more common IGD Standardized Device Control Protocol [IGD] as published in the UPnP Forum. Both NAT-PMP and IGD require the NAT devices to be able to open a port for inbound traffic to some host behind it and to inform the host about its public IP address. The differences between IGD and NAT-PMP can be found in [NAT-PMP]. This section focuses on NAT-PMP.
BTMMのNATトラバーサル関数では、NAT-PMPまたはユニバーサルプラグアンドプレイ（UPNP）インターネットゲートウェイデバイス（IGD）をサポートするためにNATルーターデバイスが必要です。NAT-PMPは、UPNPフォーラムで公開されているように、より一般的なIGD標準化されたデバイス制御プロトコル[IGD]にApple Inc.によって導入された代替案です。NAT-PMPとIGDはどちらも、NATデバイスがその背後にあるホストへのインバウンドトラフィック用のポートを開き、ホストにパブリックIPアドレスについて通知できるように要求しています。IGDとNAT-PMPの違いは、[NAT-PMP]に記載されています。このセクションでは、NAT-PMPに焦点を当てています。
NAT-PMP is a protocol that is designed specifically to handle the NAT traversal without manual configuration. When a host determines that its primary IPv4 address is in one of the private IP address ranges defined in "Address Allocation for Private Internets" [RFC1918], it invokes NAT-PMP to communicate with the NAT gateway to request the creation of inbound mappings on demand. Having created a NAT mapping to allow inbound traffic, the client host then publishes its NAT box's public IP address and external port number in a DNS server.
NAT-PMPは、手動構成なしでNATトラバーサルを処理するために特別に設計されたプロトコルです。ホストが「プライベートインターネットのアドレス割り当て」[RFC1918]で定義されているプライベートIPアドレス範囲の1つにあるとホストが判断すると、NAT-PMPを呼び出してNATゲートウェイと通信して、インバウンドマッピングの作成を要求します要求する。インバウンドトラフィックを可能にするNATマッピングを作成した後、クライアントホストはDNSサーバーでNATボックスのパブリックIPアドレスと外部ポート番号を公開します。
A host sends its Port Mapping Protocol request to the default gateway, which means that by default, this protocol is designed for small home networks where the host's default gateway is the NAT router. If the host finds that NAT-PMP or UPnP IGD is not available on its network, it would proceed under the assumption that the network is a public network.
ホストは、ポートマッピングプロトコル要求をデフォルトゲートウェイに送信します。つまり、デフォルトでは、このプロトコルは、ホストのデフォルトゲートウェイがNATルーターである小さなホームネットワーク用に設計されています。ホストがNAT-PMPまたはUPNP IGDがそのネットワークで利用できないことを発見した場合、ネットワークがパブリックネットワークであるという仮定の下で進行します。
To request a port mapping, the client host sends its request packet via UDP to port 5351 of its configured gateway address and waits 250 ms for a response [NAT-PMP]. If no response is received after 250 ms, the host repeats the process with exponential back-off.
ポートマッピングをリクエストするために、クライアントホストは、構成されたゲートウェイアドレスのポート5351にUDPを介してリクエストパケットを送信し、応答[NAT-PMP]を250ミリ秒待ちます。250ミリ秒後に応答がない場合、ホストは指数関数的なバックオフでプロセスを繰り返します。
While requesting the port mapping, the host can specify the desired external port (e.g., the port that is identical to the internal port opened on the host), but the NAT device is not obliged to allocate the desired one. If such a port is not available, the NAT device responds with another port. The primary reason for allowing the host to request a specific port is to help recovery from a NAT device crash by allowing the host to request the same port number used before the crash. This simple mechanism allows the end hosts (instead of the NAT box) to keep the mapping states, which turns hard state in the network into soft state, and enables automatic recovery whenever possible.
ポートマッピングを要求している間、ホストは目的の外部ポート（ホストに開いた内部ポートと同一のポートなど）を指定できますが、NATデバイスは目的のデバイスを割り当てる義務はありません。そのようなポートが利用できない場合、NATデバイスは別のポートで応答します。ホストが特定のポートを要求できるようにする主な理由は、ホストがクラッシュ前に使用されるのと同じポート番号を要求できるようにすることにより、NATデバイスのクラッシュからの回復を支援することです。この単純なメカニズムにより、（NATボックスの代わりに）エンドホストがマッピング状態を維持することができます。これにより、ネットワーク内のハードステートがソフト状態になり、可能な限り自動回復が可能になります。
The default port-mapping lifetime is 3600 seconds. The host tries to renew the mapping every 1800 seconds. The renewal message sent by the client host, whether for the purpose of extending the lease or recreating mappings after the NAT device reboots, is the same as the message requesting a port mapping.
デフォルトのポートマッピングライフタイムは3600秒です。ホストは、1800秒ごとにマッピングを更新しようとします。クライアントホストが送信した更新メッセージは、NATデバイスの再起動後にリースを延長するか、マッピングを再作成する目的であろうと、ポートマッピングを要求するメッセージと同じです。
A mapping may be removed in a variety of ways. If a client host fails to renew a mapping, the mapping is automatically deleted when its lifetime expires. If the client host's DHCP address lease expires, the NAT device also automatically deletes the mapping. A client host can also send an explicit packet to request the deletion of a mapping that is no longer needed.
マッピングは、さまざまな方法で削除される場合があります。クライアントホストがマッピングの更新に失敗した場合、マッピングは寿命が切れると自動的に削除されます。クライアントホストのDHCPアドレスリースが期限切れになった場合、NATデバイスは自動的にマッピングを削除します。クライアントホストは、明示的なパケットを送信して、不要なマッピングの削除を要求することもできます。
To determine the public IP address of the NAT, the client host also sends the query packet to port 5351 of the configured gateway address. The NAT device responds with a packet containing the public IP address of NAT.
NATのパブリックIPアドレスを決定するために、クライアントホストは、構成されたゲートウェイアドレスのポート5351にクエリパケットを送信します。NATデバイスは、NATのパブリックIPアドレスを含むパケットで応答します。
In case the public IP address of the NAT changes, the NAT gateway sends a gratuitous response to the link-local multicast address 224.0.0.1, port 5350 to notify the clients about the new IP address, and the host can then update its DNS SRV record to reflect its new reachability as we describe in the next section.
NATのパブリックIPアドレスが変更された場合、NATゲートウェイはリンクローカルマルチキャストアドレス224.0.0.1、ポート5350に無償の応答を送信して、クライアントに新しいIPアドレスについて通知し、ホストはDNS SRVを更新できます。次のセクションで説明しているように、その新しい到達可能性を反映する記録を記録します。
There are a number of situations where NAT-PMP (and consequently BTMM) does not work.
NAT-PMP（およびその結果、BTMM）が機能しない状況がいくつかあります。
Some people's primary IP address assigned by their ISPs may itself be a NAT address. In addition, some people may have a public IP address, but may put their hosts (perhaps unknowingly) behind multiple nested NAT boxes. NAT traversal cannot be achieved with NAT-PMP in such situations.
ISPによって割り当てられた一部の人々の主要なIPアドレス自体がNATアドレスである可能性があります。さらに、一部の人々はパブリックIPアドレスを持っているかもしれませんが、複数のネストされたNATボックスの後ろにホストを（おそらく無意識に）置くことがあります。このような状況では、NATトラバーサルはNAT-PMPでは達成できません。
In some cases, a site may run multiple subnets in the private network behind a NAT gateway. Such subnetting breaks the assumption of NAT-PMP protocol because a host's default router is not necessarily the device performing NAT.
場合によっては、サイトがNATゲートウェイの背後にあるプライベートネットワークで複数のサブネットを実行する場合があります。このようなサブネットは、ホストのデフォルトルーターが必ずしもNATを実行するデバイスではないため、NAT-PMPプロトコルの仮定を破ります。
This section describes how BTMM handles IP address or port number changes, so that the hosts of the same user can find each other and keep ongoing TCP connections even after the changes happen at one or both ends.
このセクションでは、BTMMがIPアドレスまたはポート番号の変更を処理する方法について説明します。これにより、同じユーザーのホストがお互いを見つけて、一方または両方の端で変更が発生した後でもTCP接続を維持できます。
After a BTMM client receives the notification about the network changes, it updates the list of active interfaces. Then, the client sends requests to the NAT device (if it is behind a NAT) in order to create a port mapping and obtain the new public IP address.
BTMMクライアントがネットワークの変更に関する通知を受け取った後、アクティブなインターフェイスのリストを更新します。次に、クライアントは、ポートマッピングを作成して新しいパブリックIPアドレスを取得するために、NATデバイス（NATの背後にある場合）にリクエストを送信します。
Next, the BTMM client makes changes to the local autotunnel interface, i.e., configures the IPv6 interface for the inner address of the tunnel. If there are established tunnels, it scans to find those whose local inner/outer addresses have been changed since the tunnel was set up, and then puts in the current addresses.
次に、BTMMクライアントは、ローカルAutoTunnelインターフェイスを変更します。つまり、トンネルの内側アドレスのIPv6インターフェイスを構成します。確立されたトンネルがある場合、トンネルがセットアップされてからローカルの内側/外側のアドレスが変更されたものを見つけるためにスキャンしてから、現在のアドレスに入れます。
With all these done, the BTMM client publishes the changes to DNS.
これらすべてが完了すると、BTMMクライアントはDNSの変更を公開します。
The mobile nature of BTMM clients implies that dynamic DNS updates are required if the location information of hosts are to be published via DNS.
BTMMクライアントのモバイル性は、ホストの位置情報をDNSを介して公開する場合、動的DNSの更新が必要であることを意味します。
However, a mobile host may have dynamically updated an RR but the updated value has not been propagated to the authoritative DNS server, leaving stale RRs in the server. Hence, Dynamic DNS Update Leases (DDULs) [DDUL] are employed by BTMM to minimize the chances of stale RRs. Note that DDUL controls the lifetime of dynamically updated RRs at the authoritative DNS servers, while the RRs' TTL values control the cache lifetime at caching resolvers.
ただし、モバイルホストはRRを動的に更新した可能性がありますが、更新された値は権威あるDNSサーバーに伝播されておらず、サーバーに古いRRを残しています。したがって、DNSアップデートリース（DDUL）[DDUL]はBTMMによって採用され、古いRRSの可能性を最小限に抑えます。DDULは、権威あるDNSサーバーで動的に更新されたRRSの寿命を制御し、RRSのTTL値はキャッシュリゾルバーでキャッシュ寿命を制御することに注意してください。
In case of network changes, the RRs of a host are updated immediately after local interfaces are properly configured, and after the port mapping and the public IP address of the NAT are obtained. Usually there are 4 types of RRs involved: a AAAA RR for updating the new host identifier of the host (possibly the same as the old one); an SRV RR for updating the autotunnel service information, which includes the new external port; an A RR for updating the new public IP address; and a TXT RR for describing the autotunnel device information. The name for the SRV RR is discussed in Section 3, and the names for the A, AAAA, and TXT RRs are specified in the Target field of the SRV RR. The host then constructs and sends an SRV query for the dynamic DNS server to which it should send updates. Following our example for alice, it queries the SRV RR for _dns-update-tls._udp.alice.members.me.com. Then, the updates are sent to the dynamic DNS server returned in the Target field of query response.
ネットワークの変更の場合、ローカルインターフェイスが適切に構成された直後にホストのRRが更新され、ポートマッピングとNATのパブリックIPアドレスが取得された後に更新されます。通常、関係する4種類のRRがあります。ホストの新しいホスト識別子を更新するためのAAAA RR（おそらく古いものと同じ）。新しい外部ポートを含むAutoTunnelサービス情報を更新するためのSRV RR。新しいパブリックIPアドレスを更新するためのRR。オートトゥンネルデバイス情報を説明するためのTXT RR。SRV RRの名前はセクション3で説明されており、A、AAAA、およびTXT RRの名前はSRV RRのターゲットフィールドで指定されています。その後、ホストは、更新を送信する動的DNSサーバーのSRVクエリを構築して送信します。Aliceの例に従って、_DNS-Update-tls._udp.alice.members.me.comのSRV RRを照会します。次に、更新は、クエリ応答のターゲットフィールドで返される動的DNSサーバーに送信されます。
In addition, periodic refreshes are also required by the DDUL even in the absence of any network changes. The update requests contain a signed 32-bit integer indicating the lease life in seconds. To reduce network and server load, a minimum lease of 30 minutes is required. On the other hand, to avoid stale information, a lease longer than 2 hours is not allowed in BTMM. The typical length is 90 minutes. The client host refreshes the RRs before the lease expires to prevent them from being deleted by the server.
さらに、ネットワークの変更がない場合でも、DDULによって定期的な更新も必要です。更新リクエストには、数秒でリース寿命を示す署名された32ビット整数が含まれています。ネットワークとサーバーの負荷を削減するには、30分の最小リースが必要です。一方、古い情報を避けるために、BTMMでは2時間以上長いリースが許可されていません。典型的な長さは90分です。クライアントホストは、リースが期限切れになる前にRRSを再リッシュして、サーバーによって削除されないようにします。
In dynamic environments, changes to DNS information can often be frequent. However, since a DNS query only retrieves the RR value available at that instance in time, one must continue to query DNS to learn the latest changes. This solution presents the dilemma of choosing a low polling rate that leaves the client with stale information or choosing a high polling rate that would have an adverse impact on the network and server.
動的環境では、DNS情報の変更が頻繁に発生する可能性があります。ただし、DNSクエリはそのインスタンスで使用可能なRR値のみを取得するため、最新の変更を学ぶためにDNSを照会し続ける必要があります。このソリューションは、クライアントに古い情報を残すか、ネットワークとサーバーに悪影響を与える高いポーリング率を選択する低いポーリング率を選択するというジレンマを提示します。
To let the hosts that care about particular DNS RRs learn the changes quickly and efficiently, BTMM uses DNS Long-Lived Queries (LLQs) [DNS-LLQ] to let the DNS server notify the client host once any changes are made to the concerned DNS data.
特定のDNS RRSを気にするホストに変更を迅速かつ効率的に学習させるために、BTMMはDNS Long-Livedクエリ（LLQS）[DNS-LLQ]を使用して、DNSサーバーに関係DNSに変更が加えられたらクライアントホストに通知できるようにします。データ。
To obtain the LLQ server information, the client issues an SRV query. So alice's host issues a query for _dns-llq-tls._udp.alice.members.me.com and obtains the server that provides LLQ service. LLQs are initiated by a client and are completed via a four-way handshake: Initial Request, Challenge, Challenge Response, and ACK + Answers. During the Challenge phase, the DNS server provides a unique identifier for the request, and the client is required to echo this identifier in the Challenge Response phase. This handshake provides resilience to packet loss, demonstrates client reachability, and reduces denial-of-service attack opportunities.
LLQサーバー情報を取得するには、クライアントがSRVクエリを発行します。したがって、Aliceのホストは、_DNS-llq-tls._udp.alice.members.me.comのクエリを発行し、LLQサービスを提供するサーバーを取得します。LLQはクライアントによって開始され、4方向の握手、初期リクエスト、チャレンジ、チャレンジ応答、ACK回答によって完了します。チャレンジフェーズ中、DNSサーバーは要求に一意の識別子を提供し、クライアントはチャレンジ応答フェーズでこの識別子をエコーする必要があります。この握手は、パケットの損失に回復力を提供し、クライアントの到達可能性を示し、サービス拒否攻撃の機会を減らします。
LLQ lease is negotiated during the handshake. In BTMM, the minimum lease is 15 minutes, and the maximum lease is 2 hours. Leases are refreshed before they expire.
LLQリースは握手中に交渉されます。BTMMでは、最小リースは15分で、最大リースは2時間です。リースは期限切れになる前に更新されます。
When a change ("event") occurs to a name server's domain, the server checks if the new or deleted RRs answer any LLQs. If so, the RRs are sent to the LLQ issuers in the form of a gratuitous DNS response. The client acknowledges the reception of the notification; otherwise, the server resends the response. If a total of 3 transmissions (with exponential backoff) fail, the client is considered unreachable, and the LLQ is deleted.
Name Serverのドメインに対して変更（「イベント」）が発生すると、サーバーは新規または削除されたRRSがLLQに応答するかどうかを確認します。その場合、RRSは無償のDNS応答の形でLLQ発行者に送信されます。クライアントは、通知の受信を認めます。それ以外の場合、サーバーは応答を再送信します。合計3つの送信（指数バックオフを使用）が失敗すると、クライアントは到達不能と見なされ、LLQは削除されます。
A BTMM client then updates its tunnels according to the query answers. The callback function for automatically updating tunnels is depicted Figure 3.
BTMMクライアントは、クエリの回答に従ってトンネルを更新します。トンネルを自動的に更新するためのコールバック関数を図3に示します。
1: Push Updated AAAA RR +------------+
<----------------------------------- | |
2: Query for autotunnel SRV RR | |
+--------+ -----------------------------------> | |
| | 3: Reply Updated SRV RR | DNS server |
| client | <----------------------------------- | |
| | 4: Query for Target in SRV RR | |
+--------+ -----------------------------------> | |
5: Reply Updated A RR of Target | |
<----------------------------------- | |
+------------+
In Step 1: Client learns the inner IP address of the tunnel. In Step 3: Client learns the port opened for UDP NAT traversal. In Step 5: Client learns the public IP address of the remote NAT, i.e., the outer IP address of the tunnel.
ステップ1で：クライアントはトンネルの内部IPアドレスを学習します。ステップ3で：クライアントは、UDP NAT Traversalのポートが開かれたポートを学習します。ステップ5で：クライアントは、リモートNATのパブリックIPアドレス、つまりトンネルの外側IPアドレスを学習します。
Figure 3
図3
BTMM needs to assign a topology-independent identifier to each client host for the following reasons. First, two end hosts may wish to have the established TCP connections survive network changes. Second, sometimes one needs a constant identifier to be associated with a key so that the Security Association can survive the location changes.
BTMMは、以下の理由により、各クライアントホストにトポロジに依存しない識別子を割り当てる必要があります。まず、2つのエンドホストが、確立されたTCP接続がネットワークの変更に耐えることを望む場合があります。第二に、セキュリティ協会が場所の変化を乗り切ることができるように、キーに関連付けられる一定の識別子が必要な場合があります。
The above needs for a host identifier impose very little constraint on the properties of the identifier. In particular, one notes that this identifier does not need to be a permanent one as long as its lifetime is no shorter than the lifetime of any TCP connection or any Security Association that runs on the host.
ホスト識別子の上記のニーズは、識別子のプロパティにほとんど制約を課しません。特に、この識別子は、その寿命がTCP接続またはホストで実行されるセキュリティ協会の寿命よりも短くない限り、永続的なものである必要はないことに注意してください。
Much effort has been put into the development of host identifiers. Possible candidates for host identifiers include DNS name and Host Identity Tag (HIT) in the Host Identity Protocol (HIP) [RFC4423]. However, because the current protocol stack used IP as identifiers in TCP, other transport protocols, and some applications, if one does not wish to rewrite all the transport protocol and application code, then DNS is ruled out as infeasible because DNS names have variable lengths.
ホスト識別子の開発に多くの努力が払われています。ホスト識別子の可能な候補には、ホストIDプロトコル（HIP）[RFC4423]のDNS名とホストIDタグ（HIT）が含まれます。ただし、現在のプロトコルスタックはIPをTCP、他の輸送プロトコル、および一部のアプリケーションの識別子として使用したため、すべての輸送プロトコルとアプリケーションコードの書き換えを希望しない場合、DNS名の長さが異なるため、DNSは実行不可能として除外されます。。
For HIP, although publickey-based HIT has the same length as an IPv6 address, we still lack a secure way to retrieve the public keys. Under this condition, using HIT would not bring us much benefit.
HIPの場合、PublicKeyベースのヒットはIPv6アドレスと同じ長さですが、パブリックキーを取得する安全な方法がまだありません。この条件下では、ヒットを使用しても多くの利益が得られません。
BTMM chooses to use IPv6 ULA as the host identifier so that all the existing IPv6 code can be used directly. Since the identifier does not need to stay constant over machine shutdown or crashes, each host creates an IPv6 ULA at boot time. Furthermore, since a host does not leak this ULA to the network, it would not cause any problem to the routing system.
BTMMは、すべての既存のIPv6コードを直接使用できるように、IPv6 ULAをホスト識別子として使用することを選択します。識別子はマシンのシャットダウンやクラッシュで一定のままでいる必要がないため、各ホストはブート時にIPv6 ULAを作成します。さらに、ホストはこのULAをネットワークに漏らしないため、ルーティングシステムに問題を引き起こすことはありません。
In BTMM, IPv6 ULA is advertised to be used in the autotunnel service of the host. Thus, the IPv6 address needs to be configured before BTMM starts its service.
BTMMでは、IPv6 ULAがホストのオートトゥンネルサービスで使用されるように宣伝されています。したがって、BTMMがサービスを開始する前にIPv6アドレスを構成する必要があります。
When the machine boots up, the IPv6 address for autotunnel service is initialized as zeros, and the autotunnel interface is marked as inactive. During the process when BTMM updates the interfaces list (which is performed every time the network changes), BTMM would randomly generate an IPv6 ULA according to [RFC4193] if the IPv6 address is found uninitialized. The first octet of the ULA is set to be "0xFD", and the following 7 octets are randomly selected from 0~255. Finally, the EUI-64 identifier fills up the remaining 8 octets. Since there are 56 random bits plus a theoretically unique EUI-64 identifier, it is unlikely for an IPv6 ULA collision between any two hosts of the same subscriber to occur.
マシンが起動すると、AutoTunnelサービスのIPv6アドレスがZerosとして初期化され、AutoTunnelインターフェイスは非アクティブとしてマークされます。BTMMがインターフェイスリスト（ネットワークが変更されるたびに実行される）を更新するプロセス中に、BTMMはIPv6アドレスが非Initializezizedであることが判明した場合、[RFC4193]に従ってIPv6 ULAをランダムに生成します。ULAの最初のオクテットは「0xFD」に設定されており、次の7つのオクテットは0〜255からランダムに選択されています。最後に、EUI-64識別子は残りの8オクテットを埋めます。56のランダムビットと理論的に一意のEUI-64識別子があるため、同じサブスクライバーの任意の2つのホスト間のIPv6 ULA衝突が発生する可能性は低いです。
This locally generated ULA remains unchanged when the machine is on, despite its location changes. Hence, the user can fully enjoy the benefits brought by topology-independent host identifiers. After the machine is turned off, this particular ULA is no longer kept.
このローカルで生成されたULAは、その場所の変更にもかかわらず、マシンがオンになっている場合は変更されません。したがって、ユーザーは、トポロジに依存しないホスト識別子によってもたらされる利点を完全に享受できます。マシンがオフになった後、この特定のULAはもはや保持されません。
BTMM users often have to fetch their personal data via a network they don't trust (or they do not know whether or not it's trustworthy). Hence, it is important for BTMM to have an effective means to secure the communications.
BTMMユーザーは、信頼していないネットワークを介して個人データを取得する必要があることがよくあります（または、信頼できるかどうかはわかりません）。したがって、BTMMが通信を保護するための効果的な手段を持つことが重要です。
Kerberos is a "single sign on" technology and has been supported in Apple's products since MAC OS X 10.5. Each Mac OS X client maintains a local Key Distribution Center (KDC) for the use of Bonjour and peer-to-peer security.
Kerberosは「シングルサインオン」テクノロジーであり、Mac OS X 10.5以来Appleの製品でサポートされています。各Mac OS Xクライアントは、BonjourとPeer-to-Peerのセキュリティを使用するためにローカルキー配布センター（KDC）を維持しています。
When the user first signs in to MobileMe on a host, it automatically receives a digital certificate and private key for "Back to My Mac Encryption Certificate" from KDC. When the user connects to another system using BTMM, authentication is performed using the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) protocol [RFC4556] with that certificate. After that, the user is granted a "ticket" that permits it to continue to use the services on the remote host without re-authenticating until the ticket expires (a ticket usually has a 10-hour lifetime).
ユーザーが最初にホストでMobileMeにサインインすると、KDCから「Mac暗号化証明書に戻る」ためのデジタル証明書と秘密鍵を自動的に受信します。ユーザーがBTMMを使用して別のシステムに接続すると、その証明書を使用して、Kerberos（Pkinit）プロトコル[RFC4556]の初期認証のために公開キー暗号化を使用して認証が実行されます。その後、ユーザーには、チケットの有効期限が切れるまで再認識せずにリモートホストのサービスを引き続き使用できるようにする「チケット」が付与されます（通常、チケットは10時間の寿命があります）。
BTMM uses Transaction SIGnature (TSIG) to authenticate the user when dynamic DNS update is performed [RFC2845]. Also, to protect the subscriber's privacy, LLQ is required to contain TSIG. This authentication mechanism is based on the shared secret key, which in BTMM's case is derived from the subscriber's MobileMe account password.
BTMMは、動的DNSアップデートが実行されたときにトランザクション署名（TSIG）を使用してユーザーを認証します[RFC2845]。また、サブスクライバーのプライバシーを保護するために、LLQはTSIGを含める必要があります。この認証メカニズムは、BTMMの場合、サブスクライバーのMobileMeアカウントパスワードから派生した共有シークレットキーに基づいています。
Every time a DNS request/response is going to be issued, a TSIG RR is dynamically computed with the HMAC-MD5 [RFC2104] message digest algorithm (and the TSIG RR will be discarded once its has been used). Inside the TSIG RR, the name of the shared secret key in the domain name syntax is included, so the receiver knows which key to use (this is especially useful if the receiver is the DNS server). This TSIG RR is appended to the additional data section before the message is sent out. The receiver of the message verifies the TSIG RR and proceeds only if the TSIG is valid.
DNSリクエスト/応答が発行されるたびに、TSIG RRはHMAC-MD5 [RFC2104]メッセージダイジェストアルゴリズムで動的に計算されます（および使用されるとTSIG RRは破棄されます）。TSIG RRの内部では、ドメイン名の構文の共有シークレットキーの名前が含まれているため、受信者はどのキーを使用するかを知っています（これは、受信者がDNSサーバーである場合に特に役立ちます）。このTSIG RRは、メッセージが送信される前に追加のデータセクションに追加されます。メッセージの受信者はTSIG RRを検証し、TSIGが有効である場合にのみ進行します。
Besides, the DNS messages are also protected by TLS [RFC5246] to prevent eavesdropping.
また、DNSメッセージは、盗聴を防ぐためにTLS [RFC5246]によって保護されています。
Before the Security Association can be established between two end hosts, the Internet Key Exchange (IKE) [RFC5996] process needs to be accomplished.
セキュリティ協会を2つのエンドホスト間で確立する前に、インターネットキーエクスチェンジ（IKE）[RFC5996]プロセスを達成する必要があります。
BTMM calls Racoon [Racoon], the IKE daemon, to do the key exchange, after which the key is put into the Security Association Database (SAD). The exchange mode is set to be aggressive so that it will not take too long, and it uses a pre-shared key to do the user authentication. The subscriber's Fully Qualified Domain Name (FQDN) is used as both identifier and pre-shared key during the IKE process.
BTMMは、Ike DaemonのRacoon [Racoon]を呼び出してキーエクスチェンジを行います。その後、キーがセキュリティ協会データベース（SAD）に入れられます。Exchangeモードは、攻撃的に設定されているため、時間がかかりすぎないように設定されており、事前に共有キーを使用してユーザー認証を行います。サブスクライバーの完全資格のドメイン名（FQDN）は、IKEプロセス中に識別子と事前共有キーの両方として使用されます。
When it comes time to set up Security Associations between two BTMM clients, we have two choices: put the other host's IPv4 address in the destination address field or put it in the IPv6 address of the remote end.
2つのBTMMクライアント間でセキュリティ関連を設定するときが来たら、2つの選択肢があります。他のホストのIPv4アドレスを宛先アドレスフィールドに配置するか、リモートエンドのIPv6アドレスに配置します。
If the IPv4 address (which is the public address of a NAT) is chosen to associate with a Security Association, that means we set up a Security Association between one end host and the NAT of the other host. The IPv6 packet would then be wrapped by the UDP header and then get encrypted by ESP. After the encrypted packet arrives at the NAT, the NAT device decrypts the packet and sends it to the destination according to the port mapping. Although this approach seems viable, there are 3 drawbacks:
IPv4アドレス（NATの公開アドレス）がセキュリティ協会に関連するように選択されている場合、つまり、一方のエンドホストと他のホストのNATの間にセキュリティ協会を設定します。IPv6パケットはUDPヘッダーによってラップされ、ESPによって暗号化されます。暗号化されたパケットがNATに到着した後、NATデバイスはパケットを復号化し、ポートマッピングに従って宛先に送信します。このアプローチは実行可能と思われますが、3つの欠点があります。
o First, the encryption is not really end-to-end, i.e., only the path between one end host and the NAT device of the other end is protected. The rest of the path, from the NAT device to the other BTMM client, is unprotected and vulnerable to attacks. If the NAT device is not trustworthy, the communication is at high risk. Even if the NAT device is trustworthy (e.g., the user owns the NAT), it is not uncommon for the NAT to communicate with the host through a broadcast channel, which provides opportunities for an eavesdropper to sniff the sensitive data (consider the unlocked "free" WiFi access near your neighborhood).
o まず、暗号化は実際にはエンドツーエンドではありません。つまり、一方の端ホストともう一方の端のNATデバイスの間のパスのみが保護されます。NATデバイスから他のBTMMクライアントまでのパスの残りの部分は、保護されておらず、攻撃に対して脆弱です。NATデバイスが信頼できない場合、通信はリスクが高くなります。NATデバイスが信頼できる場合でも（ユーザーがNATを所有している場合）、NATが放送チャネルを介してホストと通信することは珍しくありません。これにより、盗聴者が機密データを嗅ぐ機会が提供されます（ロック解除されたものを検討してください」あなたの近所の近くのwifiアクセス無料）。
o Second, quite a few BTMM clients are on the move very often. Every time they change their attachment points to the Internet, they will get different IPv4 addresses. As a result, the previously established Security Associations become obsoleted, and the two end hosts need to re-establish them again. This is a waste of time and resources.
o 第二に、かなりの数のBTMMクライアントが非常に頻繁に移動しています。彼らがインターネットに添付ポイントを変更するたびに、彼らは異なるIPv4アドレスを取得します。その結果、以前に確立されたセキュリティ協会は廃止され、2つのエンドホストは再びそれらを再確立する必要があります。これは時間とリソースの無駄です。
o Third, this approach assumes that the NAT device is able and willing to do the IPsec ESP for the host behind it, which is not always the case.
o 第三に、このアプローチは、NATデバイスがその背後にあるホストのためにIPSEC ESPを喜んで実行できることを前提としています。
Consequently, BTMM decides to put the IPv6 ULA into the destination field of IPsec Security Associations. In this way, the end-to-end path between the hosts is fully protected, and the Security Associations survive the network changes since the IPv6 ULA remains the same even if the BTMM client changes its location. Furthermore, the encryption is transparent to the NAT device, which means the NAT device is not required to interfere with the IPsec protection.
その結果、BTMMはIPv6 ULAをIPSECセキュリティ協会の宛先フィールドに入れることにしました。このようにして、ホスト間のエンドツーエンドのパスは完全に保護されており、BTMMクライアントがその場所を変更してもIPv6 ULAは同じままであるため、セキュリティ関連はネットワークが変化します。さらに、暗号化はNATデバイスに対して透明です。つまり、NATデバイスはIPSEC保護を妨害する必要はありません。
The BTMM implementation utilizes existing security protocols to address the end-to-end security considerations. It uses Kerberos [RFC4120] for end-to-end authentication and uses IPsec [RFC4301] to secure data communications between two end hosts.
BTMM実装は、既存のセキュリティプロトコルを利用して、エンドツーエンドのセキュリティに関する考慮事項に対処します。エンドツーエンド認証にKerberos [RFC4120]を使用し、IPSEC [RFC4301]を使用して、2つのエンドホスト間でデータ通信を保護します。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「ドメイン名システムの動的更新（DNSアップデート）」、RFC 2136、1997年4月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[RFC2845] Vixie、P.、Gudmundsson、O.、Eastlake、D。、およびB. Wellington、「DNSのシークレットキートランザクション認証」、RFC 2845、2000年5月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、2005年7月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556] Zhu、L。およびB. Tung、「Kerberos（Pkinit）の初期認証のための公開キー暗号」、RFC 4556、2006年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン2（IKEV2）」、RFC 5996、2010年9月。
[DDUL] Sekar, K., "Dynamic DNS Update Leases", Work in Progress, August 2006.
[DDUL] Sekar、K。、「ダイナミックDNSアップデートリース」、2006年8月、進行中の作業。
[DNS-LLQ] Sekar, K., "DNS Long-Lived Queries", Work in Progess, August 2006.
[DNS-llq] Sekar、K。、「DNS Long-Livedクエリ」、2006年8月、進行中の作業。
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, February 2011.
[DNS-SD] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリー」、Work in Progress、2011年2月。
[EUI64] "Guidelines for 64-bit Global Identifier (EUI-64)", <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[EUI64]「64ビットグローバル識別子（EUI-64）のガイドライン」、<http://standards.ieee.org/regauth/oui/tutorials/ eui64.html>。
[IGD] "Internet Gateway Device (IGD) Standard Device Control Protocol", <http://www.upnp.org>.
[IGD]「インターネットゲートウェイデバイス（IGD）標準デバイス制御プロトコル」、<http://www.upnp.org>。
[NAT-PMP] Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, April 2008.
[NAT-PMP] Cheshire、S。、「Nat Port Mapping Protocol（Nat-PMP）」、2008年4月の作業。
[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、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「ホストアイデンティティプロトコル（HIP）アーキテクチャ」、RFC 4423、2006年5月。
[Racoon] "Racoon", <http://ipsec-tools.sourceforge.net>.
[Racoon] "Racoon"、<http://ipsec-tools.sourceforge.net>。
Authors' Addresses
著者のアドレス
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Phone: +1 408 974 3207 EMail: cheshire@apple.com
Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA電話：1 408 974 3207メール：cheshire@apple.com
Zhenkai Zhu UCLA 4805 Boelter Hall, UCLA Los Angeles, CA 90095 USA Phone: +1 310 993 7128 EMail: zhenkai@cs.ucla.edu
Zhenkai Zhu UCLA 4805 Boelter Hall、UCLA Los Angeles、CA 90095 USA電話：1 310 993 7128メール：Zhenkai@cs.ucla.edu
Ryuji Wakikawa Toyota ITC 465 Bernardo Avenue Mountain View, CA 94043 USA EMail: ryuji.wakikawa@gmail.com
Ryuji Wakikawa Toyota ITC 465 Bernardo Avenue Mountain View、CA 94043 USAメール：ryuji.wakikawa@gmail.com
Lixia Zhang UCLA 3713 Boelter Hall, UCLA Los Angeles, CA 90095 USA Phone: +1 310 825 2695 EMail: lixia@cs.ucla.edu
Lixia Zhang UCLA 3713 Boelter Hall、UCLA Los Angeles、CA 90095 USA電話：1 310 825 2695メール：lixia@cs.ucla.edu