RFC894 日本語訳
0894 A Standard for the Transmission of IP Datagrams over EthernetNetworks. C. Hornig. April 1 1984. (Format: TXT=5697 bytes) (Also STD0041) (Status: STANDARD)
RFC一覧
英語原文
Network Working Group Charles Hornig
Request for Comments: 894 Symbolics Cambridge Research Center
April 1984
A Standard for the Transmission of IP Datagrams over Ethernet Networks
Ether ネットワーク上での IP データグラム伝送に関する標準
Status of this Memo
このメモの位置づけ
This RFC specifies a standard method of encapsulating Internet
Protocol (IP) [1] datagrams on an Ethernet [2]. This RFC specifies a
standard protocol for the ARPA-Internet community.
この RFC は、Ethernet [2] 上で Internet Protocol (IP) [1] データグラ
ムカプセル化の標準方法を明細に述べる。この RFC は、ARPA-Internet
community のための標準プロトコルを明細に述べる。
-----------------------------------------------------------------------
Introduction
序論
This memo applies to the Ethernet (10-megabit/second, 48-bit
addresses). The procedure for transmission of IP datagrams on the
Experimental Ethernet (3-megabit/second, 8-bit addresses) is
described in [3].
このメモは、Ethernet (10 メガビット/秒, 48-bit アドレス) への適用で
ある。Experimental Ethernet (3 メガビット/秒, 8-bit アドレス) 上での
IP データグラム伝送の手続きは、[3] で記述される。
-----------------------------------------------------------------------
Frame Format
フレーム形式
IP datagrams are transmitted in standard Ethernet frames. The type
field of the Ethernet frame must contain the value hexadecimal 0800.
The data field contains the IP header followed immediately by the IP
data.
IP データグラムは、標準 Ethernet フレームで伝送される。その Ethernet
フレームのタイプフィールドは、16 進数値で 0800 を含まなければならな
い。データフィールドは、IP ヘッダと、それに直ちに続く IP データを含
む。
The minimum length of the data field of a packet sent over an
Ethernet is 46 octets. If necessary, the data field should be padded
(with octets of zero) to meet the Ethernet minimum frame size. This
padding is not part of the IP packet and is not included in the total
length field of the IP header.
Ethernet 上で送信されるパケットのデータフィールド最小長は、46 octets
である。もし必要なら、データは、Ethernet 最小フレームサイズを満たす
ために (zero 値の octets で) パッドされるべきである。このパディング
は、IP パケットの一部分ではなく、IP ヘッダの全長フィールドには含まれ
ない。
The minimum length of the data field of a packet sent over an
Ethernet is 1500 octets, thus the maximum length of an IP datagram
sent over an Ethernet is 1500 octets. Implementations are encouraged
to support full-length packets. Gateway implementations MUST be
prepared to accept full-length packets and fragment them if
necessary. If a system cannot receive full-length packets, it should
take steps to discourage others from sending them, such as using the
TCP Maximum Segment Size option [4].
Ethernet 上で送信されるパケットのデータフィールド最大長は、1500
octets である。したがって Ethernet 上で送信される IP データグラム最
大長は、1500 octets である。実装は、最大長パケットのサポートが奨励さ
れる。ゲートウェイ実装は、最大長パケットを受理し、もし必要ならそれら
パケットの分割をするよう用意されなければならない (MUST)。もしシステ
ムが最大長パケットを受信できないなら、システムは、TCP Maximum
Segment Size オプション [4] を使用するようにして、他へとそれら最大長
パケットの送信中止ステップを取るべきである。
Note: Datagrams on the Ethernet may be longer than the general
Internet default maximum packet size of 576 octets. Hosts connected
to an Ethernet should keep this in mind when sending datagrams to
hosts not on the same Ethernet. It may be appropriate to send
smaller datagrams to avoid unnecessary fragmentation at intermediate
gateways. Please see [4] for further information on this point.
注意: Ethernet 上のデータグラムは、一般的な Internet デフォルト最大
パケットサイズ 576 octets より大きいだろう。Ethernet に接続されたホ
ストは、同じ Ethernet に接続されていないホストへ送信する時、上で述べ
たことを心に留めておくべきである。中間ゲートウェイでの不必要な分割を
避けるため、小さなデータグラムを送信することは、適切であるかもしれな
い。この点のさらに進んだ情報について、[4] を参照してもらいたい。
-----------------------------------------------------------------------
Address Mappings
アドレスマッピング
The mapping of 32-bit Internet addresses to 48-bit Ethernet addresses
can be done several ways. A static table could be used, or a dynamic
discovery procedure could be used.
32-bit Internet アドレスの 48-bit Ethernet アドレスへのマッピングは
いくつかの方法でおこなわれることができる。静的テーブルが使用されるか
動的探索手続きが使用されることができる。
Static Table
静的テーブル
Each host could be provided with a table of all other hosts on the
local network with both their Ethernet and Internet addresses.
それぞれのホストは、ローカルネットワーク上のすべてのホストに関す
るそれら Ethernet と Internet アドレス両方のテーブルを持って提供
されることができる。
Dynamic Discovery
動的探索
Mappings between 32-bit Internet addresses and 48-bit Ethernet
addresses could be accomplished through the Address Resolution
Protocol (ARP) [5]. Internet addresses are assigned arbitrarily
on some Internet network. Each host's implementation must know
its own Internet address and respond to Ethernet Address
Resolution packets appropriately. It should also use ARP to
translate Internet addresses to Ethernet addresses when needed.
32-bit Internet アドレスと 48-bit Ethernet アドレス間のマッピング
は、Address Resolution Protocol (ARP) [5] により成し遂げられるこ
とができる。Internet アドレスは、いくつかの Internet ネットワーク
上で任意に割り当てられる。それぞれのホスト実装は、その自分自身の
Internet アドレスを知っていなければならなく、適切な方法で
Ethernet Addresss Resolution パケットに応答しなければならない。こ
れは、必要な時 Internet アドレスを Ethernet アドレスに変換するた
め、ARP も使用するべきである。
Broadcast Address
ブロードキャストアドレス
The broadcast Internet address (the address on that network with a
host part of all binary ones) should be mapped to the broadcast
Ethernet address (of all binary ones, FF-FF-FF-FF-FF-FF hex).
ブロードキャスト Internet アドレス (ホスト部分すべて 1 をもつ、そ
のネットワーク上のアドレス) は、ブロードキャスト Ethernet アドレ
ス (すべて 1, 16 進で FF-FF-FF-FF-FF-FF) にマップされる。
The use of the ARP dynamic discovery procedure is strongly
recommended.
ARP 動的探索手続きの使用は、強く奨励される。
-----------------------------------------------------------------------
Trailer Formats
トレイラ形式
Some versions of Unix 4.2bsd use a different encapsulation method in
order to get better network performance with the VAX virtual memory
architecture. Consenting systems on the same Ethernet may use this
format between themselves.
Unix 4.2bsd のいくつかのバージョンは、VAX 仮想メモリアーキテクチャで
よりよいネットワークパフォーマンスを得るため、異なるカプセル化方法を
使用する。同じ Ethernet 上の (この方法に) 同意しているシステムは、そ
れらシステム間で、この形式を使用するかもしれない。
No host is required to implement it, and no datagrams in this format
should be sent to any host unless the sender has positive knowledge
that the recipient will be able to interpret them. Details of the
trailer encapsulation may be found in [6].
ホストは、これを実装する必要がない。そして受信側はこのデータグラムを
解釈できるという明確な知識を、もし送信側が持っていなければ、この形式
のデータグラムは、どんなホストにも送信されるべきでない。トレイラカプ
セル化の詳細は、[6] で見つけられる。
(Note: At the present time Unix 4.2bsd will either always use
trailers or never use them (per interface), depending on a boot-time
option. This is expected to be changed in the future. Unix 4.2bsd
also uses a non-standard Internet broadcast address with a host part
of all zeroes, this may also be changed in the future.)
(注意: 現在 Unix 4.2bsd は、ブート時のオプションに依存して、いつもト
レイラを使用するか、(インターフェイスごとに) それらを決して使用しな
いかのどちらかである。これは、将来変更されることが期待される。Unix
4.2bsd は、ホスト部分すべて 0 の標準でない Internet ブロードキャスト
アドレスも使用する。同様にこれも、将来変更されるだろう。)
-----------------------------------------------------------------------
Byte Order
バイトオーダ
As described in Appendix B of the Internet Protocol
specification [1], the IP datagram is transmitted over the Ethernet
as a series of 8-bit bytes.
Internet Protocol 仕様書 [1] の Appendix (付録) B で記述されるように
IP データグラムは、8-bit の bytes の連続として Ethernet 上で伝送され
る。
-----------------------------------------------------------------------
References
参考文献
[1] Postel, J., "Internet Protocol", RFC-791, USC/Information
Sciences Institute, September 1981.
[2] "The Ethernet - A Local Area Network", Version 1.0, Digital
Equipment Corporation, Intel Corporation, Xerox Corporation,
September 1980.
[3] Postel, J., "A Standard for the Transmission of IP Datagrams
over Experimental Ethernet Networks", RFC-895, USC/Information
Sciences Institute, April 1984.
[4] Postel, J., "The TCP Maximum Segment Size Option and Related
Topics", RFC-879, USC/Information Sciences Institute, November 1983.
[5] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826,
Symbolics Cambridge Research Center, November 1982.
[6] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893,
University of California at Berkeley, April 1984.
-----------------------------------------------------------------------
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (1984). 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.
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.
一覧
スポンサーリンク
