RFC3146 日本語訳
3146 Transmission of IPv6 Packets over IEEE 1394 Networks. K.Fujisawa, A. Onoe. October 2001. (Format: TXT=16569 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Fujisawa
Request for Comments: 3146 A. Onoe
Category: Standards Track Sony Corporation
October 2001
コメントを求めるワーキンググループK.藤沢の要求をネットワークでつないでください: 3146年のA.尾上カテゴリ: 標準化過程ソニー2001年10月
Transmission of IPv6 Packets over IEEE 1394 Networks
IEEE1394ネットワークの上のIPv6パケットのトランスミッション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks.
このドキュメントはIPv6パケットのトランスミッションとIPv6のリンクローカルのアドレスと状態がない自動構成されたアドレスをIEEE1394ネットワークに形成するメソッドのためにフレーム形式について説明します。
1. INTRODUCTION
1. 序論
IEEE Std 1394-1995 (and its amendment) is a standard for a High Performance Serial Bus. IETF IP1394 Working Group has standardized the method to carry IPv4 datagrams and ARP packets over IEEE1394 subnetwork [IP1394].
IEEE Std1394-1995(そして、修正)はHighパフォーマンスSerial Busの規格です。 IETF IP1394作業部会はIEEE1394サブネットワーク[IP1394]の上までIPv4データグラムとARPパケットを運ぶメソッドを標準化しました。
This document describes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network.
このドキュメントはIPv6[IPV6]パケットのトランスミッションとIPv6のリンクローカルのアドレスと状態がない自動構成されたアドレスをIEEE1394ネットワークに形成するメソッドのためにフレーム形式について説明します。 また、メッセージがIEEE1394ネットワークで送られるとき、それはオプションがNeighborディスカバリー[DISC]で使用したSource/目標Address Link-層の内容について説明します。
2. SPECIFICATION TERMINOLOGY
2. 仕様用語
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 RFC 2119.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Fujisawa & Onoe Standards Track [Page 1] RFC 3146 IPv6 Packets over IEEE 1394 Networks October 2001
藤沢と尾上規格は2001年10月にIEEE1394ネットワークの上でRFC3146IPv6パケットの跡をつけます[1ページ]。
3. IPv6-CAPABLE NODES
3. IPv6できるノード
An IPv6-capable node MUST fulfill the following minimum requirements:
IPv6できるノードは以下の必要最小限を実現させなければなりません:
- it MUST implement configuration ROM in the general format
specified by ISO/IEC 13213:1994 and MUST implement the bus
information block specified by IEEE Std 1394a-2000 [1394a] and a
unit directory specified by this document;
- それがISO/IECによって指定された一般形式で構成ROMを実装しなければならない、13213:1994、IEEE Std 1394a-2000[1394a]でバス情報ブロックが指定した道具とこのドキュメントによって指定されたユニットディレクトリはそうしなければなりません。
- the max_rec field in its bus information block MUST be at least 8;
this indicates an ability to accept block write requests and
asynchronous stream packets with data payload of 512 octets. The
same ability MUST also apply to read requests; that is, the node
MUST be able to transmit a block response packet with a data
payload of 512 octets;
- バス情報ブロックの最大_rec分野は少なくとも8であるに違いありません。 これは、ブロックを受け入れる能力が512の八重奏のデータペイロードで要求と非同期なストリームパケットを書くのを示します。 また、同じ能力は、要求を読むのに申し込まなければなりません。 すなわち、ノードは512の八重奏のデータペイロードでブロック応答パケットを伝えることができなければなりません。
- it MUST be isochronous resource manager capable, as specified by
IEEE Std 1394a-2000;
- それはIEEE Std 1394a-2000による指定されるとしてできる同一時間の資源管理プログラムであるに違いありません。
- it MUST support both reception and transmission of asynchronous
streams as specified by IEEE Std 1394a-2000.
- それはレセプションとIEEE Std 1394a-2000による指定されるとしての非同期なストリームの送信の両方をサポートしなければなりません。
4. LINK ENCAPSULATION AND FRAGMENTATION
4. リンクカプセル化と断片化
The encapsulation and fragmentation mechanism MUST be the same as "4. LINK ENCAPSULATION AND FRAGMENTATION" of [IP1394].
カプセル化と断片化メカニズムは「4」と同じであるに違いありません。 [IP1394]の「リンクカプセル化と断片化。」
Note: Since there is an ether_type field to discriminate protocols
and MCAP (multicast channel allocation protocol) is used for both
IPv4 and IPv6, the version field in GASP (global asynchronous
stream packet) header of IPv6 datagrams is the same value (one) as
[IP1394].
以下に注意してください。 プロトコルを差別するためにエーテル_タイプ分野があって、MCAP(マルチキャストチャンネル配分プロトコル)がIPv4とIPv6の両方に使用されるので、IPv6データグラムのGASP(グローバルな非同期なストリームパケット)ヘッダーのバージョン分野は[IP1394]と同じ値(1)です。
The ether_type value for IPv6 is 0x86dd.
IPv6のためのエーテル_タイプ値は0x86ddです。
The default MTU size for IPv6 packets on an IEEE1394 network is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on an IEEE1394 interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but MUST be otherwise ignored. The mechanism to extend MTU size between particular two nodes is for further study.
IEEE1394ネットワークのIPv6パケットのためのデフォルトMTUサイズは1500の八重奏です。 このサイズは、より小さいMTUを指定するMTUオプションを含むRouter Advertisement[DISC]、またはそれぞれのノードの手動の構成によって減少させられるかもしれません。 受け取って、IEEE1394インタフェースでMTUを指定するMTUオプションがRouter Advertisementであるなら1500年より大きくなるか、手動で構成された値より大きくて、そのMTUオプションをシステム管理に登録されるかもしれませんが、別の方法で無視しなければなりません。 さらなる研究には特定の2つのノードの間のMTUサイズを広げるメカニズムがあります。
Fujisawa & Onoe Standards Track [Page 2] RFC 3146 IPv6 Packets over IEEE 1394 Networks October 2001
藤沢と尾上規格は2001年10月にIEEE1394ネットワークの上でRFC3146IPv6パケットの跡をつけます[2ページ]。
5. CONFIGURATION ROM
5. 構成ROM
Configuration ROM for IPv6-capable nodes MUST contain a unit directory in the format specified by [IP1394] except following rules.
IPv6できるノードのための構成ROMは規則に従うのを除いて、[IP1394]によって指定された形式にユニットディレクトリを含まなければなりません。
- The value for Unit_SW_Version is 0x000002.
- Unit_SW_バージョンのための値は0×000002です。
- The textual descriptor for the Unit_SW_Version MUST be "IPv6".
- Unit_SW_バージョンのための原文の記述子は"IPv6""であるに違いありません。
Note: A dual-stack (IPv4 and IPv6) node will have two unit
directories for IPv4 and IPv6 respectively.
以下に注意してください。 デュアルスタック(IPv4とIPv6)ノードには、それぞれIPv4とIPv6のための2つのディレクトリがあるでしょう。
6. STATELESS AUTOCONFIGURATION
6. 状態がない自動構成
The Interface Identifier [AARCH] for an IEEE1394 interface is formed from the interface's built-in EUI-64 identifier by complementing the "Universal/Local" (U/L) bit, which is the next-to-lowest order bit of the first octet of the EUI-64 identifier. Complementing this bit will generally change a 0 value to a 1, since an interface's built-in EUI-64 identifier is expected to be from a universally administered address space and hence have a globally unique value. A universally administered EUI-64 identifier is signified by a 0 in the U/L bit position, while a globally unique IPv6 Interface Identifier is signified by a 1 in the corresponding position. For further discussion on this point, see [AARCH].
IEEE1394インタフェースへのInterface Identifier[AARCH]は、インタフェースの内蔵のEUI-64識別子から「普遍的であるか地方(U/L)」のビットの補足となることによって、形成されます。(ビットはEUI-64識別子の最初の八重奏のオーダー最も低いことへの次ビットです)。 このビットの補足となると、一般に、0値は1に変化するでしょう、インタフェースの内蔵のEUI-64識別子が一般に管理されたアドレス空間から来ていて、したがって、グローバルにユニークな値を持っていると予想されるので。 一般に管理されたEUI-64識別子はU/Lビット位置の0時までに意味されています、グローバルにユニークなIPv6 Interface Identifierが対応する位置の1時までに意味されていますが。 このポイントのさらなる議論に関しては、[AARCH]を見てください。
An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an IEEE1394 interface MUST have a length of 64 bits.
IEEE1394インタフェースの状態がない自動構成[ACONF]に使用されるIPv6アドレス接頭語は64ビットの長さを持たなければなりません。
7. LINK-LOCAL ADDRESSES
7. リンクローカルのアドレス
The IPv6 link-local address [AARCH] for an IEEE1394 interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
IEEE1394インタフェースへのIPv6リンクローカルアドレス[AARCH]はInterface Identifierを追加することによって、形成されます、上で定義されるように、接頭語FE80に:、:/64.
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
10ビット54ビット64ビット+----------+-----------------------+----------------------------+ |1111111010| (ゼロ) | インタフェース識別子| +----------+-----------------------+----------------------------+
8. ADDRESS MAPPING FOR UNICAST
8. ユニキャストのためのアドレス・マッピング
The procedure for mapping IPv6 unicast addresses into IEEE1394 link- layer addresses uses the Neighbor Discovery [DISC]. Since 1394 link address (node_ID) will not be constant across a 1394 bridge, we have chosen not to put it in the Link-layer Address option. The recipient of the Neighbor Discovery SHOULD use the source_ID (obtained from either the asynchronous packet header or the GASP header) in
IEEE1394へのマッピングIPv6ユニキャストアドレスが層のアドレスをリンクするので、手順はNeighborディスカバリー[DISC]を使用します。 1394年のリンクアドレス(ノード_ID)が1394年のブリッジの向こう側に一定にならないので、私たちは、Link-層のAddressオプションにそれを入れないのを選びました。 SHOULDがソース_ID(非同期なパケットのヘッダーかGASPヘッダーのどちらかから、得る)を使用するNeighborディスカバリーの受取人
Fujisawa & Onoe Standards Track [Page 3] RFC 3146 IPv6 Packets over IEEE 1394 Networks October 2001
藤沢と尾上規格は2001年10月にIEEE1394ネットワークの上でRFC3146IPv6パケットの跡をつけます[3ページ]。
conjunction with the content of the Source link-layer address. An implementation MAY use some other methods to obtain a node_ID of the sender utilizing a mapping table between node_unique_ID (EUI-64 identifier) and node_ID. The mechanism to make such mapping table is out of scope of this document.
Sourceリンクレイヤアドレスの中身がある接続詞。 実装はノードの_のユニークな_ID(EUI-64識別子)とノード_IDの間にマッピングテーブルを利用している送付者のノード_IDを得るある他のメソッドを使用するかもしれません。 このドキュメントの範囲の外にそのようなマッピングテーブルを作るメカニズムがあります。
The recipient of an Neighbor Discovery packet MUST ignore it unless the most significant ten bits of the source_ID are equal to either 0x3FF or the most significant ten bits of the recipient's NODE_IDS register.
ソース_IDの最も重要な10ビットが0x3FFか受取人の最も重要な10ビットのNODE_IDSレジスタのどちらかと等しくない場合、Neighborディスカバリーパケットの受取人はそれを無視しなければなりません。
The Source/Target Link-layer Address option has the following form when the link layer is IEEE1394.
リンクレイヤがIEEE1394であるときに、Source/目標Link-層のAddressオプションには、以下のフォームがあります。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 3 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| node_unique_ID (EUI-64 identifier) |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | max_rec | spd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast_FIFO |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ=3| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | ノードの_のユニークな_ID(EUI-64識別子)| +--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 最大_rec| spd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ユニキャスト_先入れ先出し法| +--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 for Source Link-layer address.
2 for Target Link-layer address.
Length 3 (in units of 8 octets).
Source Link-層のアドレスのために1をタイプしてください。 2 Target Link-層のアドレスのために。 長さ3(8つの八重奏のユニットの)。
node_unique_ID This field contains the node unique ID of the
node and MUST be equal to that specified in the
node's configuration ROM.
Thisがさばくノードの_のユニークな_IDは、ノードのノード固有のIDを含んでいて、ノードの構成ROMで指定されたそれと等しいに違いありません。
max_rec This field MUST be equal to the value of max_rec
in the node's configuration ROM.
rec Thisがさばく最大_はノードの構成ROMの最大_recの値と等しいに違いありません。
spd This field MUST be set to the lesser of the node's
link speed and PHY speed. The link speed is the
maximum speed at which the link may send or
receive packets; the PHY speed is the maximum
speed at which the PHY may send, receive or repeat
packets. The encoding used for spd is specified in
the Table 2 of [IP1394].
ノードのリンク速度とPHY速度について、より少なくspd This分野を設定しなければなりません。 リンク速度はリンクがパケットを送るか、または受けるかもしれない最高回転数です。 PHY速度はPHYがパケットを送るか、受けるか、または繰り返すかもしれない最高回転数です。 spdに使用されるコード化は[IP1394]のTable2で指定されます。
Fujisawa & Onoe Standards Track [Page 4] RFC 3146 IPv6 Packets over IEEE 1394 Networks October 2001
藤沢と尾上規格は2001年10月にIEEE1394ネットワークの上でRFC3146IPv6パケットの跡をつけます[4ページ]。
unicast_FIFO This field MUST specify the 48-bit offset of the
node's FIFO available for the receipt of IPv6
datagrams. The offset of a node's unicast FIFO
MUST NOT change, except as the result of a power
reset.
ユニキャスト_先入れ先出し法This分野はノードのIPv6データグラムの領収書に利用可能な先入れ先出し法の48ビットのオフセットを指定しなければなりません。ノードのユニキャスト先入れ先出し法のオフセットは変化してはいけません、パワーリセットの結果を除いて。
reserved This field MUST be set to all zeros by the sender
and ignored by the receiver.
予約されたThis分野を送付者によるすべてのゼロに設定されて、受信機で無視しなければなりません。
Note that node_ID may change when 1394 bus-reset occurs. The mapping cache held in the node SHOULD be cleared on 1394 bus-reset.
ノード_IDが、1394年のバスリセットがいつ起こるかを変えるかもしれないことに注意してください。 写像しているキャッシュはノードSHOULDで成立しました。1394年のバスリセットときに、クリアされます。
According to [1394], the maximum data payload and the transmission speed SHOULD be determined based on the sender's capability, the recipient's capability, and the PHYs of all intervening nodes.
[1394]に従って、最大のデータペイロードと伝送速度はノードをすべての介入の送付者の能力、受取人の能力、およびPHYsに基礎づけましたSHOULDが決心している。
9. IPv6 MULTICAST
9. IPv6マルチキャスト
By default, all best-effort IPv6 multicast MUST use asynchronous stream packets whose channel number is equal to the channel field from the BROADCAST_CHANNEL register. In particular, datagrams addressed to all-nodes multicast addresses, all-routers multicast addresses, and solicited-node multicast addresses [AARCH] MUST use the default channel specified by the BROADCAST_CHANNEL register.
デフォルトで、すべてのベストエフォート型IPv6マルチキャストがBROADCAST_CHANNELレジスタから論理機番がチャンネル分野と等しい非同期なストリームパケットを使用しなければなりません。 特に、オールノードマルチキャストアドレス、オールルータマルチキャストアドレス、および請求されたノードマルチキャストアドレス[AARCH]に扱われたデータグラムはBROADCAST_CHANNELレジスタによって指定されたデフォルトチャンネルを使用しなければなりません。
Best-effort IPv6 multicast for other multicast group addresses may utilize a different channel number if such a channel number is allocated and advertised prior to use, by the multicast channel allocation protocol (MCAP), as described in [IP1394].
そのような論理機番が使用の前に割り当てられて、広告に掲載されるなら、他のマルチキャストグループアドレスのためのベストエフォート型IPv6マルチキャストは異なった論理機番を利用するかもしれません、マルチキャストチャンネル配分プロトコル(MCAP)で、[IP1394]で説明されるように。
When a node wishes to receive multicast data addressed to other than all-nodes multicast addresses, all-routers multicast addresses, and solicited-node multicast addresses, it MUST confirm if the channel mapping between a multicast group address and a channel number exists using MCAP, as described in "9.3 Multicast Receive" in [IP1394].
ノードは願っています。いつ、マルチキャストグループアドレスと論理機番の間のチャンネルマッピングがMCAPを使用することで存在しているならオールノードマルチキャストアドレス、それが確認しなければならないオールルータマルチキャストアドレス、および請求されたノードマルチキャストアドレスを除いて、[IP1394]で「9.3マルチキャストは受信するところ」で説明されるようにデータが扱ったマルチキャストを受けるために。
The implementation of MCAP is optional for send-only nodes. A node MAY transmit multicast data addressed to any multicast addresses into the default broadcast channel regardless of the existing allocation of the channel. If a node wishes to transmit multicast data on other than the default channel, it MUST first confirm by MCAP whether or not a channel number for the group address has been already allocated. The implementors are encouraged to use this protocol when transmitting high-rate multicast streams.
MCAPの実装が任意である、発信、-単に、ノード。 ノードはチャンネルの既存の配分にかかわらずどんなマルチキャストアドレスにも扱われたマルチキャストデータをデフォルト放送チャンネルに送るかもしれません。 ノードがデフォルトチャンネルを除いて、オンなマルチキャストデータを送りたいなら、それは、最初に、MCAPでグループアドレスのための論理機番が既に割り当てられたかどうか確認しなければなりません。 高い率マルチキャストストリームを伝えるとき、作成者がこのプロトコルを使用するよう奨励されます。
The MCAP 'type' value for IPv6 group address descriptor is 2.
IPv6グループアドレス記述子のためのMCAP'タイプ'価値は2です。
Fujisawa & Onoe Standards Track [Page 5] RFC 3146 IPv6 Packets over IEEE 1394 Networks October 2001
藤沢と尾上規格は2001年10月にIEEE1394ネットワークの上でRFC3146IPv6パケットの跡をつけます[5ページ]。
10. IANA CONSIDERATIONS
10. IANA問題
IANA has assigned a value of 0x000002 for "Unit_SW_Version for IPv6 over IEEE1394" out of the "CSR Protocol Identifiers" name space, as described in section 5. The details of the "CSR Protocol Identifiers" namespace is described in "10. IANA CONSIDERATIONS" of [IP1394].
IANAは「IEEE1394の上のIPv6のためのユニット_SW_バージョン」のためにスペースという「CSRプロトコル識別子」名から0×000002の値を割り当てました、セクション5で説明されるように。 「CSRプロトコル識別子」名前空間の詳細は「10」で説明されます。 [IP1394]の「IANA問題。」
Section 9.1 of [IP1394] defines MCAP group address descriptors, which include an 8-bit type name space. This document requests that IANA maintain a name space to manage MCAP group address descriptors. The initial assignments for that table are:
[IP1394]のセクション9.1はMCAPグループアドレス記述子を定義します。(記述子は8ビットのタイプ名前スペースを含んでいます)。 このドキュメントは、IANAがMCAPグループアドレス記述子を管理するために名前スペースを維持するよう要求します。 そのテーブルのための初期の課題は以下の通りです。
Value Usage
0 reserved
1 IPv4 Multicast Address
2 IPv6 Multicast Address
255 reserved
値のUsage0はIPv6 Multicast Address255が予約した1IPv4 Multicast Address2を予約しました。
Additional values from the range 3-254 can be assigned through Standards Action [RFC 2434].
Standards Action[RFC2434]を通して範囲3-254からの加算値を割り当てることができます。
11. Security Considerations
11. セキュリティ問題
IPv6 over IEEE1394 does not introduce any additional security considerations over [IP1394]. The security concerns described in "11. SECURITY CONSIDERATIONS" in [IP1394] apply here as well.
IEEE1394の上のIPv6は[IP1394]の上にどんな追加担保問題も紹介しません。 「11」で説明された安全上の配慮。 また、[IP1394]の「SECURITY CONSIDERATIONS」はここに適用します。
12. Acknowledgment
12. 承認
The authors would like to acknowledge the authors of [IP1394] and [ETHER] since some part of this document has been derived from them.
作者は、彼らからこのドキュメントの何らかの部分を得たので、[IP1394]と[ETHER]の作者を承認したがっています。
13. References
13. 参照
[1394] IEEE Std 1394-1995, Standard for a High Performance Serial
Bus
高性能シリーズバスにおける、標準の[1394]IEEE Std1394-1995
[1394a] IEEE Std 1394a-2000, Standard for a High Performance Serial
Bus - Amendment 1
高性能シリーズバスにおける、標準の[1394a]IEEE Std 1394a-2000--、修正1
[IP1394] Johansson, P., "IPv4 over IEEE 1394", RFC 2734, December
1999.
[IP1394]ヨハンソン、1999年12月のP.、「IEEE1394の上のIPv4」RFC2734。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
Fujisawa & Onoe Standards Track [Page 6] RFC 3146 IPv6 Packets over IEEE 1394 Networks October 2001
藤沢と尾上規格は2001年10月にIEEE1394ネットワークの上でRFC3146IPv6パケットの跡をつけます[6ページ]。
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373 December 1998.
[AARCH] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、2373年のRFC1998年12月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[ACONF] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[ディスク]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[エーテル] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
14. Authors' Addresses
14. 作者のアドレス
Kenji Fujisawa Network & Software Technology Center, Sony Corporation 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001, JAPAN
Kenji藤沢ネットワークとソフトウェア技術センター、Kitashinagawa、ソニー6-7-35品川区、東京141-0001、日本
Phone: +81-3-5795-8507 Fax: +81-3-5795-8977 EMail: fujisawa@sm.sony.co.jp
以下に電話をしてください。 +81-3-5795-8507 Fax: +81-3-5795-8977 メールしてください: fujisawa@sm.sony.co.jp
Atsushi Onoe Internet Systems Laboratory, Internet Laboratories, Sony Corporation 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001, JAPAN
篤尾上インターネットシステム研究所、インターネット研究所、Kitashinagawa、ソニー6-7-35品川区、東京141-0001、日本
Phone: +81-3-5448-4620 Fax: +81-3-5448-4622 EMail: onoe@sm.sony.co.jp
以下に電話をしてください。 +81-3-5448-4620 Fax: +81-3-5448-4622 メールしてください: onoe@sm.sony.co.jp
Fujisawa & Onoe Standards Track [Page 7] RFC 3146 IPv6 Packets over IEEE 1394 Networks October 2001
藤沢と尾上規格は2001年10月にIEEE1394ネットワークの上でRFC3146IPv6パケットの跡をつけます[7ページ]。
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Fujisawa & Onoe Standards Track [Page 8]
藤沢と尾上標準化過程[8ページ]
一覧
スポンサーリンク
