RFC5214 日本語訳
5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP). F.Templin, T. Gleeson, D. Thaler. March 2008. (Format: TXT=30126 bytes) (Obsoletes RFC4214) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group F. Templin
Request for Comments: 5214 Boeing Phantom Works
Obsoletes: 4214 T. Gleeson
Category: Informational Cisco Systems K.K.
D. Thaler
Microsoft Corporation
March 2008
コメントを求めるワーキンググループF.テンプリンの要求をネットワークでつないでください: 5214個のボーイングの幻影の作品が以下を時代遅れにします。 4214年のT.グリーソンカテゴリ: 2008年の情報のシスコシステムズのK.K.D.ターレルマイクロソフト社行進
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
イントラサイトの自動トンネルアドレシングプロトコル(ISATAP)
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
IESG Note
IESG注意
The IESG thinks that this work is related to IETF work done in WG softwires, but this does not prevent publishing.
IESGは、この仕事がWG softwiresで行われたIETF仕事に関連すると思いますが、これは、発行するのを防ぎません。
Abstract
要約
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) model.
Intra-サイトAutomatic Tunnel Addressingプロトコル(ISATAP)はデュアルスタック(IPv6/IPv4)ノードをIPv4ネットワークの上に接続します。 ISATAPはIPv6のためにIPv4ネットワークをリンクレイヤであるとみなして、Non-放送Multiple Access(NBMA)モデルと同様の自動トンネリング抽象化をサポートします。
Templin, et al. Informational [Page 1] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[1ページ]情報のRFC5214ISATAP行進
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements ....................................................3
3. Terminology .....................................................3
4. Domain of Applicability .........................................4
5. Node Requirements ...............................................4
6. Addressing Requirements .........................................4
6.1. ISATAP Interface Identifiers ...............................4
6.2. ISATAP Interface Address Configuration .....................5
6.3. Multicast/Anycast ..........................................5
7. Automatic Tunneling .............................................5
7.1. Encapsulation ..............................................5
7.2. Handling ICMPv4 Errors .....................................5
7.3. Decapsulation ..............................................6
7.4. Link-Local Addresses .......................................6
7.5. Neighbor Discovery over Tunnels ............................6
8. Neighbor Discovery for ISATAP Interfaces ........................6
8.1. Conceptual Model of a Host .................................7
8.2. Router and Prefix Discovery - Router Specification .........7
8.3. Router and Prefix Discovery - Host Specification ...........7
8.3.1. Host Variables ......................................7
8.3.2. Potential Router List Initialization ................7
8.3.3. Processing Received Router Advertisements ...........8
8.3.4. Sending Router Solicitations ........................8
8.4. Neighbor Unreachability Detection ..........................9
9. Site Administration Considerations ..............................9
10. Security Considerations ........................................9
11. IANA Considerations ...........................................10
12. Acknowledgments ...............................................10
13. References ....................................................11
13.1. Normative References .....................................11
13.2. Informative References ...................................12
Appendix A. Modified EUI-64 Addresses in the IANA Ethernet
Address Block ...........................................13
1. 序論…2 2. 要件…3 3. 用語…3 4. 適用性のドメイン…4 5. ノード要件…4 6. 要件を扱います…4 6.1. ISATAPは識別子を連結します…4 6.2. ISATAPはアドレス構成を連結します…5 6.3. マルチキャスト/Anycast…5 7. 自動トンネリング…5 7.1. カプセル化…5 7.2. 取り扱いICMPv4誤り…5 7.3. 被膜剥離術…6 7.4. リンクローカルのアドレス…6 7.5. Tunnelsの上の隣人発見…6 8. ISATAPのための隣人発見は連結します…6 8.1. ホストの概念モデル…7 8.2. ルータと接頭語発見--ルータ仕様…7 8.3. ルータと接頭語発見--仕様をホスティングしてください…7 8.3.1. 変数をホスティングしてください…7 8.3.2. 潜在的ルータリスト初期設定…7 8.3.3. 処理はルータ通知を受け取りました…8 8.3.4. ルータ懇願を送ります…8 8.4. 隣人Unreachability検出…9 9. サイト政権問題…9 10. セキュリティ問題…9 11. IANA問題…10 12. 承認…10 13. 参照…11 13.1. 標準の参照…11 13.2. 有益な参照…12 付録のA.の変更されたEUI-64は、IANAでイーサネットがあて先ブロックであると扱います…13
1. Introduction
1. 序論
This document specifies a simple mechanism called the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) that connects dual-stack (IPv6/IPv4) nodes over IPv4 networks. Dual-stack nodes use ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP views the IPv4 network as a link layer for IPv6.
このドキュメントはデュアルスタック(IPv6/IPv4)ノードをIPv4ネットワークの上に接続するIntra-サイトAutomatic Tunnel Addressingプロトコル(ISATAP)と呼ばれる簡単なメカニズムを指定します。 デュアルスタックノードはIPv4で自動的にトンネルIPv6パケットにISATAPを使用します、すなわち、ISATAPがIPv6のためにIPv4ネットワークをリンクレイヤであるとみなします。
ISATAP enables automatic tunneling whether global or private IPv4 addresses are used, and it presents a Non-Broadcast Multiple Access (NBMA) abstraction similar to [RFC2491],[RFC2492],[RFC2529], and [RFC3056].
グローバルであるか個人的なIPv4アドレスが使用されているか否かに関係なく、ISATAPは自動トンネリングを可能にします、そして、それは[RFC2491]、[RFC2492]、[RFC2529]、および[RFC3056]と同様のNon-放送Multiple Access(NBMA)抽象化を提示します。
Templin, et al. Informational [Page 2] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[2ページ]情報のRFC5214ISATAP行進
The main objectives of this document are to: 1) describe the domain of applicability, 2) specify addressing requirements, 3) specify automatic tunneling using ISATAP, 4) specify the operation of IPv6 Neighbor Discovery over ISATAP interfaces, and 5) discuss Site Administration, Security, and IANA considerations.
このドキュメントの主な目標は以下のことのためのことです。 1) 2は)アドレシング要件を指定します、そして、3は)ISATAPを使用することで自動トンネリングを指定します、そして、4は)ISATAPインタフェースの上でIPv6 Neighborディスカバリーの操作を指定します、そして、適用領域について説明してください、そして、5は)Site政権、Security、およびIANA問題について議論します。
2. Requirements
2. 要件
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
キーワードが解釈しなければならない、本書では現れるとき、[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
This document also uses internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided in order to demonstrate protocol behavior. An implementation is not required to have them in the exact form described here, as long as its external behavior is consistent with that described in this document.
また、このドキュメントは、システム管理者が実装で変えることができなければならないプロトコルの振舞いと外部の変数について説明するのに内部の概念的な変数を使用します。 プロトコルの振舞いを示すために特定の変数名と、それらの値がどう変化するか、そして、彼らの設定影響がどう振舞いについて議定書の中で述べるかを提供します。 実装はここで説明された正確なフォームにそれらを持つのに必要ではありません、外部の振舞いが本書では説明されるそれと一致している限り。
3. Terminology
3. 用語
The terminology of [RFC2460] and [RFC4861] applies to this document. The following additional terms are defined:
[RFC2460]と[RFC4861]の用語はこのドキュメントに適用されます。 次の追加用語は定義されます:
ISATAP node/host/router:
A dual-stack (IPv6/IPv4) node/host/router that implements the
specifications in this document.
ISATAPノード/ホスト/ルータ: 本書では仕様を履行するデュアルスタック(IPv6/IPv4)ノード/ホスト/ルータ。
ISATAP interface:
An ISATAP node's Non-Broadcast Multi-Access (NBMA) IPv6 interface,
used for automatic tunneling of IPv6 packets in IPv4.
ISATAPは連結します: IPv4のIPv6パケットの自動トンネリングに使用されるISATAPノードのNon-放送Multi-アクセス(NBMA)IPv6インタフェース。
ISATAP interface identifier:
An IPv6 interface identifier with an embedded IPv4 address
constructed as specified in Section 6.1.
ISATAPは識別子を連結します: セクション6.1の埋め込まれたIPv4アドレスが指定されるとして構成されているIPv6インタフェース識別子。
ISATAP address:
An IPv6 unicast address that matches an on-link prefix on an
ISATAP interface of the node, and that includes an ISATAP
interface identifier.
ISATAPアドレス: ノードのISATAPインタフェースのリンクの上の接頭語を合わせて、ISATAPインタフェース識別子を含んでいるIPv6ユニキャストアドレス。
locator:
An IPv4 address-to-interface mapping; i.e., a node's IPv4 address
and its associated interface.
ロケータ: IPv4連結するアドレスマッピング。 すなわち、ノードのIPv4アドレスとその関連インタフェース。
Templin, et al. Informational [Page 3] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[3ページ]情報のRFC5214ISATAP行進
locator set:
A set of locators associated with an ISATAP interface. Each
locator in the set belongs to the same site.
ロケータはセットしました: 1セットのロケータはISATAPインタフェースと交際しました。 セットにおける各ロケータは同じサイトに属します。
4. Domain of Applicability
4. 適用領域
The domain of applicability for this technical specification is automatic tunneling of IPv6 packets in IPv4 for ISATAP nodes within sites that observe the security considerations found in this document, including host-to-router, router-to-host, and host-to-host automatic tunneling in certain enterprise networks and 3GPP/3GPP2 wireless operator networks. (Other scenarios with a sufficient trust basis ensured by the mechanisms specified in this document also fall within this domain of applicability.)
この技術仕様書のための適用領域は本書では見つけられたセキュリティ問題を観測するサイトの中のISATAPノードのためのIPv4のIPv6パケットの自動トンネリングです、ある企業網と3GPP/3GPP2無線通信士ネットワークにホストからルータ、ルータからホスト、およびホストからホストへの自動トンネリングを含んでいて。 (また、十分な信頼基礎が本書では指定されたメカニズムによって確実にされている他のシナリオはこの適用領域の中に下がります。)
Extensions to the above domain of applicability (e.g., by combining the mechanisms in this document with those in other technical specifications) are out of the scope of this document.
このドキュメントの範囲の外に適用性(例えば、本書では他の技術仕様書によるそれらにメカニズムを結合するのによる)の上のドメインへの拡大があります。
5. Node Requirements
5. ノード要件
ISATAP nodes observe the common functionality requirements for IPv6 nodes found in [RFC4294] and the requirements for dual IP layer operation found in Section 2 of [RFC4213]. They also implement the additional features specified in this document.
ISATAPノードは[RFC4294]で見つけられたIPv6ノードのための一般的な機能性要件と[RFC4213]のセクション2で見つけられた二元的なIP層の操作のための要件を観測します。 また、彼らは本書では指定された付加的な機能を実装します。
6. Addressing Requirements
6. 要件を扱います。
6.1. ISATAP Interface Identifiers
6.1. ISATAPインタフェース識別子
ISATAP interface identifiers are constructed in Modified EUI-64 format per Section 2.5.1 of [RFC4291] by concatenating the 24-bit IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 32-bit IPv4 address in network byte order as follows:
ISATAPインタフェース識別子は.1セクション2.5[RFC4291]あたりのModified EUI-64形式で24ビットのIANA OUI(00-00-5E)、8ビットの16進値の0xFE、および以下のネットワークバイトオーダーにおける32ビットのIPv4アドレスを連結することによって、構成されます:
|0 1|1 3|3 6| |0 5|6 1|2 3| +----------------+----------------+--------------------------------+ |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm| +----------------+----------------+--------------------------------+
|0 1|1 3|3 6| |0 5|6 1|2 3| +----------------+----------------+--------------------------------+ |000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm| +----------------+----------------+--------------------------------+
When the IPv4 address is known to be globally unique, the "u" bit (universal/local) is set to 1; otherwise, the "u" bit is set to 0. "g" is the individual/group bit, and "m" represents the bits of the IPv4 address.
IPv4アドレスがグローバルに特有であることが知られているとき、「u」ビット(普遍的であるか地方の)は1に設定されます。 さもなければ、「u」ビットは0に設定されます。 「g」は個人/グループビットです、そして、「m」はIPv4アドレスのビットを表します。
Templin, et al. Informational [Page 4] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[4ページ]情報のRFC5214ISATAP行進
Per Section 2.5.1 of [RFC4291], ISATAP nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique.
セクションに従って、普遍的に設定された「u」ビットに変更されたEUI-64トークンで作成された識別子を連結する.1[RFC4291]、ISATAPノードが有効にしている必要はない2.5はユニークです。
6.2. ISATAP Interface Address Configuration
6.2. ISATAPインターフェース・アドレス構成
Each ISATAP interface configures a set of locators consisting of IPv4 address-to-interface mappings from a single site; i.e., an ISATAP interface's locator set MUST NOT span multiple sites.
それぞれのISATAPインタフェースはただ一つのサイトからのIPv4連結するアドレスマッピングから成る1セットのロケータを構成します。 すなわち、ISATAPインタフェースのロケータセットは複数のサイトにかかってはいけません。
When an IPv4 address is removed from an interface, the corresponding locator SHOULD be removed from its associated locator set(s). When a new IPv4 address is assigned to an interface, the corresponding locator MAY be added to the appropriate locator set(s).
インタフェース、対応ロケータSHOULDからIPv4アドレスを取り除きます。いつ、関連ロケータセットから、取り除くか。 新しいIPv4アドレスがインタフェースに割り当てられるとき、対応するロケータは適切なロケータセットに追加されるかもしれません。
ISATAP interfaces form ISATAP interface identifiers from IPv4 addresses in their locator set and use them to create link-local ISATAP addresses (Section 5.3 of [RFC4862]).
ISATAPインタフェースは、IPv4アドレスからそれらのロケータセットでISATAPインタフェース識別子を形成して、リンクローカルのISATAPアドレス([RFC4862]のセクション5.3)を作成するのにそれらを使用します。
6.3. Multicast/Anycast
6.3. マルチキャスト/Anycast
It is not possible to assume the general availability of wide-area IPv4 multicast, so (unlike 6over4 [RFC2529]) ISATAP must assume that its underlying IPv4 carrier network only has unicast capability. Support for IPv6 multicast over ISATAP interfaces is not described in this document.
広い領域IPv4マルチキャストに関する一般的な入手可能性を仮定するのが可能でない、したがって(6over4[RFC2529]と異なって)、ISATAPは基本的なIPv4キャリヤーネットワークにはユニキャスト能力があるだけであると仮定しなければなりません。 ISATAPインタフェースの上のIPv6マルチキャストのサポートは本書では説明されません。
Similarly, support for Reserved IPv6 Subnet Anycast Addresses is not described in this document.
同様に、Reserved IPv6 Subnet Anycast Addressesのサポートは本書では説明されません。
7. Automatic Tunneling
7. 自動トンネリング
ISATAP interfaces use the basic tunneling mechanisms specified in Section 3 of [RFC4213]. The following sub-sections describe additional specifications.
ISATAPインタフェースは[RFC4213]のセクション3で指定された基本的なトンネリングメカニズムを使用します。 以下の小区分は追加仕様を説明します。
7.1. Encapsulation
7.1. カプセル化
ISATAP addresses are mapped to a link-layer address by a static computation; i.e., the last four octets are treated as an IPv4 address.
ISATAPアドレスは静的な計算でリンクレイヤアドレスに写像されます。 すなわち、最後の4つの八重奏がIPv4アドレスとして扱われます。
7.2. Handling ICMPv4 Errors
7.2. 取り扱いICMPv4誤り
ISATAP interfaces SHOULD process Address Resolution Protocol (ARP) failures and persistent ICMPv4 errors as link-specific information indicating that a path to a neighbor may have failed (Section 7.3.3 of [RFC4861]).
隣人への経路が(.3セクション7.3[RFC4861])に失敗したかもしれないのを示しながら、ISATAPはリンク特有の情報としてSHOULDプロセスAddress Resolutionプロトコル(ARP)失敗と永続的なICMPv4誤りを連結します。
Templin, et al. Informational [Page 5] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[5ページ]情報のRFC5214ISATAP行進
7.3. Decapsulation
7.3. 被膜剥離術
The specification in Section 3.6 of [RFC4213] is used. Additionally, when an ISATAP node receives an IPv4 protocol 41 datagram that does not belong to a configured tunnel interface, it determines whether the packet's IPv4 destination address and arrival interface match a locator configured in an ISATAP interface's locator set.
[RFC4213]のセクション3.6の仕様は使用されています。 ISATAPノードが構成されたトンネルのインタフェースに属さないIPv4プロトコル41データグラムを受けるとき、さらに、それは、パケットのIPv4送付先アドレスと到着インタフェースがISATAPインタフェースのロケータセットで構成されたロケータに合っているかどうか決定します。
If an ISATAP interface that configures a matching locator is found, the decapsulator MUST verify that the packet's IPv4 source address is correct for the encapsulated IPv6 source address. The IPv4 source address is correct if:
合っているロケータを構成するISATAPインタフェースが見つけられるなら、decapsulatorは、カプセル化されたIPv6ソースアドレスに、パケットのIPv4ソースアドレスが正しいことを確かめなければなりません。 IPv4ソースアドレスが正しい、:
o the IPv6 source address is an ISATAP address that embeds the
IPv4 source address in its interface identifier, or
o またはIPv6ソースアドレスがIPv4ソースアドレスをインタフェース識別子に埋め込むISATAPアドレスである。
o the IPv4 source address is a member of the Potential Router
List (see Section 8.1).
o IPv4ソースアドレスはPotential Router Listのメンバー(セクション8.1を見る)です。
Packets for which the IPv4 source address is incorrect for this ISATAP interface are checked to determine whether they belong to another tunnel interface.
このISATAPインタフェースに、IPv4ソースアドレスが不正確であるパケットは、それらが別のトンネルのインタフェースに属すかどうか決定するためにチェックされます。
7.4. Link-Local Addresses
7.4. リンクローカルのアドレス
ISATAP interfaces use link-local addresses constructed as specified in Section 6 of this document.
ISATAPインタフェースはこのドキュメントのセクション6で指定されるように構成されたリンクローカルのアドレスを使用します。
7.5. Neighbor Discovery over Tunnels
7.5. Tunnelsの上の隣人発見
ISATAP interfaces use the specifications for neighbor discovery found in the following section of this document.
ISATAPインタフェースはこのドキュメントの以下のセクションで見つけられた隣人発見に仕様を使用します。
8. Neighbor Discovery for ISATAP Interfaces
8. ISATAPインタフェースのための隣人発見
ISATAP interfaces use the neighbor discovery mechanisms specified in [RFC4861]. The following sub-sections describe specifications that are also implemented.
ISATAPインタフェースは[RFC4861]で指定された隣人発見メカニズムを使用します。 以下の小区分はまた、履行される仕様を説明します。
Templin, et al. Informational [Page 6] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[6ページ]情報のRFC5214ISATAP行進
8.1. Conceptual Model of a Host
8.1. ホストの概念モデル
To the list of Conceptual Data Structures (Section 5.1 of [RFC4861]), ISATAP interfaces add the following:
Conceptual Data Structures([RFC4861]のセクション5.1)のリストに、ISATAPインタフェースは以下を追加します:
Potential Router List (PRL)
A set of entries about potential routers; used to support router
and prefix discovery. Each entry ("PRL(i)") has an associated
timer ("TIMER(i)"), and an IPv4 address ("V4ADDR(i)") that
represents a router's advertising ISATAP interface.
Router List(PRL)Aが設定する潜在的ルータに関するエントリーの可能性。 ルータと接頭語発見をサポートするのにおいて、使用されています。 各エントリー("PRL(i)")には、関連タイマ(「タイマ(i)」)、およびルータの広告ISATAPインタフェースを表すIPv4アドレス("V4ADDR(i)")があります。
8.2. Router and Prefix Discovery - Router Specification
8.2. ルータと接頭語発見--ルータ仕様
Advertising ISATAP interfaces send Solicited Router Advertisement messages as specified in Section 6.2.6 of [RFC4861] except that the messages are sent directly to the soliciting node; i.e., they might not be received by other nodes on the link.
直接請求ノードにメッセージを送るのを除いて、広告ISATAPインタフェースは.6セクション6.2[RFC4861]の指定されるとしてのメッセージをSolicited Router Advertisementに送ります。 すなわち、それらはリンクの上の他のノードによって受け取られないかもしれません。
8.3. Router and Prefix Discovery - Host Specification
8.3. ルータと接頭語発見--ホスト仕様
The Host Specification in Section 6.3 of [RFC4861] is used. The following sub-sections describe specifications added by ISATAP interfaces.
[RFC4861]のセクション6.3におけるHost Specificationは使用されています。 以下の小区分はISATAPインタフェースによって加えられた仕様を説明します。
8.3.1. Host Variables
8.3.1. ホスト変数
To the list of host variables (Section 6.3.2 of [RFC4861]), ISATAP interfaces add the following:
ホスト変数(.2セクション6.3[RFC4861])のリストに、ISATAPインタフェースは以下を追加します:
PrlRefreshInterval
Time in seconds between successive refreshments of the PRL after
initialization. The designated value of all ones (0xffffffff)
represents infinity.
初期化の後のPRLの連続した軽い飲食物の間の秒のPrlRefreshInterval Time。 すべてのもの(0xffffffff)の指定された値は無限を表します。
Default: 3600 seconds
デフォルト: 3600秒
MinRouterSolicitInterval
Minimum time in seconds between successive solicitations of the
same advertising ISATAP interface. The designated value of all
ones (0xffffffff) represents infinity.
同じ広告ISATAPの連続した懇願の間の秒のMinRouterSolicitInterval Minimum時に、連結してください。 すべてのもの(0xffffffff)の指定された値は無限を表します。
8.3.2. Potential Router List Initialization
8.3.2. 潜在的ルータリスト初期設定
ISATAP nodes initialize an ISATAP interface's PRL with IPv4 addresses acquired via manual configuration, a DNS Fully Qualified Domain Name (FQDN) [RFC1035], a DHCPv4 [RFC2131] vendor-specific option, or an unspecified alternate method. Domain names are acquired via manual
ISATAPノードは手動の構成でIPv4アドレスを習得しているISATAPインタフェースのPRL、DNS Fully Qualified Domain Name(FQDN)[RFC1035]、DHCPv4[RFC2131]のベンダー特有のオプション、または不特定の代替方法を初期化します。 マニュアルを通してドメイン名を取得します。
Templin, et al. Informational [Page 7] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[7ページ]情報のRFC5214ISATAP行進
configuration, receipt of a DHCPv4 Domain Name option [RFC2132], or an unspecified alternate method. FQDNs are resolved into IPv4 addresses through a static host file lookup, querying the DNS service, querying a site-specific name service, or with an unspecified alternate method.
構成、DHCPv4 Domain Nameオプション[RFC2132]の領収書、または不特定の代替方法。 DNSサービスについて質問して、サイト種名サービスについて質問する静的なホストファイルルックアップを通して、または、不特定の代替方法でFQDNsはIPv4アドレスに変えられます。
After initializing an ISATAP interface's PRL, the node sets a timer for the interface to PrlRefreshInterval seconds and re-initializes the interface's PRL as specified above when the timer expires. When an FQDN is used, and when it is resolved via a service that includes Times to Live (TTLs) with the IPv4 addresses returned (e.g., DNS 'A' resource records [RFC1035]), the timer SHOULD be set to the minimum of PrlRefreshInterval and the minimum TTL returned. (Zero-valued TTLs are interpreted to mean that the PRL is re-initialized before each Router Solicitation event; see Section 8.3.4.)
ISATAPインタフェースのPRLを初期化した後に、ノードは、PrlRefreshInterval秒までインタフェースにタイマを設定して、タイマが期限が切れる時の上の指定されるとしてのインタフェースのPRLを再初期化します。 FQDNがいつ、使用されているか、そして、PrlRefreshIntervalの最小限へのセットと最小限がTTLであったならいつIPv4アドレスを返しているLive(TTLs)(例えばリソースが記録するDNS[RFC1035])にタイムズを含んでいるサービス、タイマSHOULDを通して決心しているかは戻りました。 (無評価されたTTLsはPRLがそれぞれのRouter Solicitationイベントの前に再初期化されることを意味するために解釈されます; セクション8.3.4を見てください。)
8.3.3. Processing Received Router Advertisements
8.3.3. 処理はルータ通知を受け取りました。
To the list of checks for validating Router Advertisement messages (Section 6.1.2 of [RFC4861]), ISATAP interfaces add the following:
Router Advertisementメッセージ(.2セクション6.1[RFC4861])を有効にするためのチェックのリストに、ISATAPインタフェースは以下を追加します:
o IP Source Address is a link-local ISATAP address that embeds
V4ADDR(i) for some PRL(i).
o IP Source AddressはいくらかのPRL(i)のためにV4ADDR(i)を埋め込むリンクローカルのISATAPアドレスです。
Valid Router Advertisements received on an ISATAP interface are processed as specified in Section 6.3.4 of [RFC4861].
ISATAPインタフェースに受け取られた有効なRouter Advertisementsは.4セクション6.3[RFC4861]で指定されるように処理されます。
8.3.4. Sending Router Solicitations
8.3.4. 送付ルータ懇願
To the list of events after which Router Solicitation messages may be sent (Section 6.3.7 of [RFC4861]), ISATAP interfaces add the following:
Router Solicitationメッセージが送られるかもしれないイベント(.7セクション6.3[RFC4861])のリストに、ISATAPインタフェースは以下を追加します:
o TIMER(i) for some PRL(i) expires.
o いくらかのPRL(i)のためのTIMER(i)は期限が切れます。
Since unsolicited Router Advertisements may be incomplete and/or absent, ISATAP nodes MAY schedule periodic Router Solicitation events for certain PRL(i)s by setting the corresponding TIMER(i).
求められていないRouter Advertisementsが不完全である、そして/または、欠けるかもしれないので、ISATAPノードはあるPRL(i)sのために対応するTIMER(i)を設定することによって、周期的なRouter Solicitationイベントの計画をするかもしれません。
When periodic Router Solicitation events are scheduled, the node SHOULD set TIMER(i) so that the next event will refresh remaining lifetimes stored for PRL(i) before they expire, including the Router Lifetime, Valid Lifetimes received in Prefix Information Options, and Route Lifetimes received in Route Information Options [RFC4191]. TIMER(i) MUST be set to no less than MinRouterSolicitInterval seconds where MinRouterSolicitInterval is configurable for the node, or for a specific PRL(i), with a conservative default value (e.g., 2 minutes).
周期的なRouter Solicitationイベントが予定されているとき、ノードSHOULDは、次のイベントがValid Lifetimesが、Prefix情報Optionsで期限が切れます、Router Lifetimeを含んでいて受けて、Route LifetimesがRoute情報Options[RFC4191]で受信する前にPRL(i)のために保存された残っている生涯をリフレッシュするように、TIMER(i)を設定します。 TIMER(i)はノードに、MinRouterSolicitIntervalが構成可能であるところ、または特定のPRL(i)のために少なくともMinRouterSolicitInterval秒に用意ができなければなりません、保守的なデフォルト値(例えば、2分)で。
Templin, et al. Informational [Page 8] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[8ページ]情報のRFC5214ISATAP行進
When TIMER(i) expires, the node sends Router Solicitation messages as specified in Section 6.3.7 of [RFC4861] except that the messages are sent directly to PRL(i); i.e., they might not be received by other routers. While the node continues to require periodic Router Solicitation events for PRL(i), and while PRL(i) continues to act as a router, the node resets TIMER(i) after each expiration event as described above.
TIMER(i)が期限が切れると、直接PRL(i)にメッセージを送るのを除いて、ノードは.7セクション6.3[RFC4861]の指定されるとしてのメッセージをRouter Solicitationに送ります。 すなわち、それらは他のルータによって受け取られないかもしれません。 ノードはPRL(i)のためにずっと周期的なRouter Solicitationイベントを必要とします、そして、PRL(i)はルータとして機能し続けていますが、ノードはそれぞれの満了イベントの後に上で説明されるようにTIMER(i)をリセットします。
8.4. Neighbor Unreachability Detection
8.4. 隣人Unreachability検出
ISATAP hosts SHOULD perform Neighbor Unreachability Detection (Section 7.3 of [RFC4861]). ISATAP routers MAY perform Neighbor Unreachability Detection, but this might not scale in all environments.
ISATAPホストSHOULDはNeighbor Unreachability Detection([RFC4861]のセクション7.3)を実行します。 ISATAPルータはNeighbor Unreachability Detectionを実行するかもしれませんが、これはすべての環境を計量するかもしれないというわけではありません。
After address resolution, ISATAP hosts SHOULD perform an initial reachability confirmation by sending Neighbor Solicitation messages and receiving a Neighbor Advertisement message. ISATAP routers MAY perform this initial reachability confirmation, but this might not scale in all environments.
アドレス解決、ISATAPホストのときにSHOULDがメッセージをNeighbor Solicitationに送って、Neighbor Advertisementメッセージを受け取りながら初期の可到達性確認を実行する後。 ISATAPルータはこの初期の可到達性確認を実行するかもしれませんが、これはすべての環境を計量するかもしれないというわけではありません。
9. Site Administration Considerations
9. サイト政権問題
Site administrators maintain a Potential Router List (PRL) of IPv4 addresses representing advertising ISATAP interfaces of routers.
サイトの管理者はルータの広告ISATAPインタフェースを表すIPv4アドレスのPotential Router List(PRL)を維持します。
The PRL is commonly maintained as an FQDN for the ISATAP service in the site's name service (see Section 8.3.2). There are no mandatory rules for the selection of the FQDN, but site administrators are encouraged to use the convention "isatap.domainname" (e.g., isatap.example.com).
PRLはサイトの名前サービスにおけるISATAPサービスのためのFQDNとして一般的に維持されます(セクション8.3.2を見てください)。 FQDNの選択のための委任統治が全くありませんが、サイトの管理者がコンベンション"isatap.domainname"(例えば、isatap.example.com)を使用するよう奨励されます。
When the site's name service includes TTLs with the IPv4 addresses returned, site administrators SHOULD configure the TTLs with conservative values to minimize control traffic.
サイトの名前サービスがIPv4アドレスを返しているTTLsを含んでいると、サイトの管理者SHOULDは、コントロールトラフィックを最小にするために保守的な値でTTLsを構成します。
10. Security Considerations
10. セキュリティ問題
Implementers should be aware that, in addition to possible attacks against IPv6, security attacks against IPv4 must also be considered. Use of IP security at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons. For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant unless traffic analysis is felt to be a threat. If IPv6 is running authenticated, then authentication of IPv4 will add little. Conversely, IPv4 security will not protect IPv6 traffic once it leaves the ISATAP domain. Therefore, implementing IPv6 security is required even if IPv4 security is available.
Implementersはまた、IPv6に対する可能な攻撃に加えてIPv4に対するセキュリティー攻撃を考えなければならないのを意識しているべきです。 それにもかかわらず、IPv4とIPv6レベルの両方におけるIPセキュリティの使用は効率理由で避けられるべきです。 例えば、IPv6が暗号化されていた状態で稼働する予定であり、トラヒック分析が脅威であることは感じられない場合、IPv4の暗号化が余分でしょう。 IPv6が認証されていた状態で稼働する予定であると、IPv4の認証は少ししか加えないでしょう。 逆に、いったんISATAPドメインを出ると、IPv4セキュリティはIPv6トラフィックを保護しないでしょう。 したがって、IPv4セキュリティが利用可能であっても、IPv6がセキュリティであると実装するのが必要です。
Templin, et al. Informational [Page 9] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[9ページ]情報のRFC5214ISATAP行進
The threats associated with IPv6 Neighbor Discovery are described in [RFC3756].
IPv6 Neighborディスカバリーに関連している脅威は[RFC3756]で説明されます。
There is a possible spoofing attack in which spurious ip-protocol-41 packets are injected into an ISATAP link from outside. Since an ISATAP link spans an entire IPv4 site, restricting access to the link can be achieved by restricting access to the site; i.e., by having site border routers implement IPv4 ingress filtering and ip- protocol-41 filtering.
偽りのipプロトコル41パケットが外部からISATAPリンクに注がれる可能なスプーフィング攻撃があります。 ISATAPリンクが全体のIPv4サイトにかかっているので、アクセスをサイトに制限することによって、アクセスをリンクに制限するのを達成できます。 すなわち、サイト境界ルータを持っていることによって、IPv4がイングレスフィルタリングとipプロトコル-41フィルタリングであると実装してください。
Another possible spoofing attack involves spurious ip-protocol-41 packets injected from within an ISATAP link by a node pretending to be a router. The Potential Router List (PRL) provides a list of IPv4 addresses representing advertising ISATAP interfaces of routers that hosts use in filtering decisions. Site administrators should ensure that the PRL is kept up to date, and that the resolution mechanism (see Section 9) cannot be subverted.
別の可能なスプーフィング攻撃はルータであるふりをするノードによってISATAPリンクから注入された偽りのipプロトコル41パケットにかかわります。 Potential Router List(PRL)はホストが決定をフィルターにかける際に使用するルータの広告ISATAPインタフェースを表すIPv4アドレスのリストを提供します。 サイトの管理者は、PRLが時代について行かせて、解決メカニズム(セクション9を見る)を打倒できないのを保証するべきです。
The use of temporary addresses [RFC4941] and Cryptographically Generated Addresses [RFC3972] on ISATAP interfaces is outside the scope of this specification.
この仕様の範囲の外にISATAPインタフェースの仮の住所[RFC4941]とCryptographically Generated Addresses[RFC3972]の使用があります。
11. IANA Considerations
11. IANA問題
The IANA has specified the format for Modified EUI-64 address construction (Appendix A of [RFC4291]) in the IANA Ethernet Address Block. The text in the Appendix of this document has been offered as an example specification. The current version of the IANA registry for Ether Types can be accessed at:
IANAはIANAイーサネットAddress BlockでのModified EUI-64アドレス工事([RFC4291]の付録A)に形式を指定しました。 例の仕様としてこのドキュメントのAppendixのテキストを提供しました。 以下でEther TypesのためのIANA登録の最新版にアクセスできます。
http://www.iana.org/assignments/ethernet-numbers
http://www.iana.org/assignments/ethernet-numbers
12. Acknowledgments
12. 承認
The ideas in this document are not original, and the authors acknowledge the original architects. Portions of this work were sponsored through SRI International and Nokia and Boeing internal projects and government contracts. Government sponsors include Monica Farah Stapleton and Russell Langan (U.S. Army CECOM ASEO) and Dr. Allen Moshfegh (U.S. Office of Naval Research). SRI International sponsors include Dr. Mike Frankel, J. Peter Marcotullio, Lou Rodriguez, and Dr. Ambatipudi Sastry.
アイデアは本書ではオリジナルではありません、そして、作者はオリジナルの建築家を承認します。 この仕事の部分はSRIインターナショナル、ノキア、ボーイングの内部のプロジェクト、および政府契約を通して後援されました。 政府のスポンサーはモニカ・ファラーステイプルトン、ラッセル・ランガン(米軍CECOM ASEO)、およびアレンMoshfegh博士(米国海軍研究事務所)を入れます。 SRIインターナショナルのスポンサーはマイク博士のフランケル、J.ピーターMarcotullio、ルウ・ロドリゲス、およびAmbatipudi Sastry博士を入れます。
The following are acknowledged for providing peer review input: Jim Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader, Ole Troan, and Vlad Yasevich.
以下はピア・レビュー入力を提供するために承認されます: ジムBound、豊かなDraves、シンディ・ユング、Ambatipudi Sastry、アーロンシュレーダー、Ole Troan、およびヴラドYasevich。
Templin, et al. Informational [Page 10] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[10ページ]情報のRFC5214ISATAP行進
The following are acknowledged for their significant contributions: Marcelo Albuquerque, Brian Carpenter, Alain Durand, Hannu Flinck, Jason Goldschmidt, Christian Huitema, Nathan Lutchansky, Karen Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Markku Savela, Pekka Savola, Margaret Wasserman, Brian Zill, and members of the IETF IPv6 and V6OPS working groups. Mohit Talwar contributed to earlier versions of this document.
以下は彼らの重要な貢献のために承認されます: マルセロ・アルバカーキ、ブライアンCarpenter、アラン・ジュランド、ハンヌ・フリンク、ジェイソン・ゴールドシュミット、クリスチャンのHuitema、ネイザンLutchansky、カレン・ニールセン、モハンパルタサラティ、Chirayuパテル、Art Shelest、マルックSavela、ペッカSavola、マーガレット・ワッサーマン、ブライアンZill、IETF IPv6のメンバー、およびV6OPSワーキンググループ。 Mohit Talwarはこのドキュメントの以前のバージョンに貢献しました。
The authors acknowledge the work done by Brian Carpenter and Cyndi Jung in RFC 2529 that introduced the concept of intra-site automatic tunneling. This concept was later called: "Virtual Ethernet" and researched by Quang Nguyen under the guidance of Dr. Lixia Zhang.
作者はイントラサイトの自動トンネリングの概念を紹介したRFC2529でブライアンCarpenterとシンディ・ユングによって行われた仕事を承諾します。 この概念は後で呼ばれました: 「仮想のイーサネット」でLixiaチャン博士の指導の下にQuang Nguyenによって研究されています。
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2132] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] NordmarkとE.とR.ギリガン、「IPv6ホストとルータのための基本的な変遷メカニズム」、RFC4213、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] トムソンとS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」、RFC4862、2007年9月。
Templin, et al. Informational [Page 11] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[11ページ]情報のRFC5214ISATAP行進
13.2. Informative References
13.2. 有益な参照
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", RFC
2491, January 1999.
[RFC2491] アーミテージ、G.、Schulter、P.、Jork、M.、およびG.Harter、「Non-放送Multiple Access(NBMA)ネットワークの上のIPv6」、RFC2491(1999年1月)。
[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM
Networks", RFC 2492, January 1999.
1999年1月の[RFC2492]アーミテージとG.とSchulter、P.とM.Jork、「気圧ネットワークの上のIPv6」RFC2492。
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[RFC2529] 大工とB.とC.ユング、「明白なTunnelsのいないIPv4ドメインの上のIPv6のトランスミッション」、RFC2529、1999年3月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", RFC
3756, May 2004.
[RFC3756]Nikander、P.(エド)、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信用モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC3972]香気(T.)が「暗号で、アドレス(CGA)を作った」、RFC3972、3月2005日
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves、研究開発ターレル、「デフォルトルータ好みの、そして、より特定のルート」、RFC4191、2005年11月。
[RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4294] Loughney、J.、エド、「IPv6ノード要件」、RFC4294、4月2006日
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4941] Narten、T.、Draves、R.、およびS.クリシュナン、「IPv6"、RFC4941、2007年9月の国がないアドレス自動構成のためのプライバシー拡大。」
Templin, et al. Informational [Page 12] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[12ページ]情報のRFC5214ISATAP行進
Appendix A. Modified EUI-64 Addresses in the IANA Ethernet Address
Block
IANAイーサネットあて先ブロックの付録のA.の変更されたEUI-64アドレス
Modified EUI-64 addresses (Section 2.5.1 and Appendix A of [RFC4291]) in the IANA Ethernet Address Block are formed by concatenating the 24-bit IANA OUI (00-00-5E) with a 40-bit extension identifier and inverting the "u" bit; i.e., the "u" bit is set to one (1) to indicate universal scope and set to zero (0) to indicate local scope. Modified EUI-64 addresses have the following appearance in memory (bits transmitted right-to-left within octets, octets transmitted left-to-right):
IANAイーサネットAddress Blockの変更されたEUI-64アドレス([RFC4291]のセクション2.5.1とAppendix A)は40ビットの拡大識別子で24ビットのIANA OUI(00-00-5E)を連結して、「u」ビットを逆にすることによって、形成されます。 すなわち、「u」ビットは、1つ(1)に普遍的な範囲を示すように設定されて、地方の範囲を示すために(0)のゼロを合わせるように設定されます。 変更されたEUI-64アドレスには、メモリにおける以下の外観があります(ビットが八重奏の中で左への右を伝えて、八重奏は左から右を伝えました):
0 23 63 | OUI | extension identifier | 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
0 23 63 | OUI| 拡大識別子| 000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
When the first two octets of the extension identifier encode the hexadecimal value 0xFFFE, the remainder of the extension identifier encodes a 24-bit vendor-supplied id as follows:
拡大識別子の最初の2つの八重奏が16進価値の0xFFFEをコード化するとき、拡大識別子の残りは以下の24ビットの業者によって供給されたイドをコード化します:
0 23 39 63 | OUI | 0xFFFE | vendor-supplied id | 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx
0 23 39 63 | OUI| 0xFFFE| 業者によって供給されたイド| 000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx
When the first octet of the extension identifier encodes the hexadecimal value 0xFE, the remainder of the extension identifier encodes a 32-bit IPv4 address as follows:
拡大識別子の最初の八重奏が16進価値の0xFEをコード化するとき、拡大識別子の残りは以下の32ビットのIPv4アドレスをコード化します:
0 23 31 63 | OUI | 0xFE | IPv4 address | 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
0 23 31 63 | OUI| 0xFE| IPv4アドレス| 000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
Templin, et al. Informational [Page 13] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[13ページ]情報のRFC5214ISATAP行進
Authors' Addresses
作者のアドレス
Fred L. Templin Boeing Phantom Works P.O. Box 3707 MC 7L-49 Seattle, WA 98124 USA
フレッドL.テンプリンボーイング幻は7L-49シアトルのM.C.、私書箱3707ワシントン98124米国を扱います。
EMail: fred.l.templin@boeing.com
メール: fred.l.templin@boeing.com
Tim Gleeson Cisco Systems K.K. Shinjuku Mitsui Building 2-1-1 Nishishinjuku, Shinjuku-ku Tokyo 163-0409 Japan
ビル2-1-1Nishishinjuku、ティムグリーソンシスコシステムズK.K.新宿三井東京日本新宿区163-0409
EMail: tgleeson@cisco.com
メール: tgleeson@cisco.com
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 US
デーヴターレルマイクロソフト社1マイクロソフト道ワシントン98052-6399レッドモンド(米国)
Phone: +1 425 703 8835 EMail: dthaler@microsoft.com
以下に電話をしてください。 +1 8835年の425 703メール: dthaler@microsoft.com
Templin, et al. Informational [Page 14] RFC 5214 ISATAP March 2008
テンプリン、他 2008年の[14ページ]情報のRFC5214ISATAP行進
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78と http://www.rfc-editor.org/copyright.html に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Templin, et al. Informational [Page 15]
テンプリン、他 情報[15ページ]
一覧
スポンサーリンク
