RFC2147 日本語訳
2147 TCP and UDP over IPv6 Jumbograms. D. Borman. May 1997. (Format: TXT=1883 bytes) (Obsoleted by RFC2675) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Borman Request for Comments: 2147 Berkeley Software Design, Inc. Updates: 1883 May 1997 Category: Standards Track
コメントを求めるワーキンググループD.ボーマン要求をネットワークでつないでください: 2147のバークレイ・ソフトウェア・デザインInc.アップデート: 1883 1997年5月のカテゴリ: 標準化過程
TCP and UDP over IPv6 Jumbograms
IPv6 Jumbogramsの上のTCPとUDP
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)の現行版を参照してください。 このメモの分配は無制限です。
1. Overview
1. 概要
IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option [Deering95]. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms.
IPv6はしばしばjumbogramsと呼ばれた65535バイト長よりホップごとのJumbo有効搭載量オプション[Deering95]の使用で大きいデータグラムを支えます。 UDPプロトコルには、それがjumbogramsを利用できるのを妨げる16ビットの長さの分野があります、そして、TCPには、長さの分野がありませんが、MSSオプションとUrgent分野の両方が16ビットによって抑制されます。 このドキュメントはTCPとUDPがIPv6 jumbogramsを利用するのを許容すると行うことができるいくつかの簡単な変更について説明します。
2. UDP Jumbograms
2. UDP Jumbograms
To allow UDP to make use of jumbograms, either the UDP length field needs to be extended, or it needs to be ignored. Since the size of the field can't be changed, a length of zero is used to indicate that it is to be ignored, and the length in the "pseudo-header" is to be used to determine the true length of the UDP header plus data. This works because UDP length field includes the UDP header, so the minimum valid value for this field is 8.
UDPがjumbograms、UDP長さの分野が広げられるために必要とするどちらか、またはそれを利用するのを許容するのが無視される必要があります。 分野のサイズを変えることができないので、ゼロの長さはそれが無視されることになっているのを示すのに使用されます、そして、「疑似ヘッダー」の長さはUDPヘッダーとデータの真の長さを測定するのに使用されることです。 UDP長さの分野がUDPヘッダーを含んでいるのでこれが働いているので、この分野への最小の有効値は8です。
When sending a UDP packet, if and only if the length of the UDP header plus data is greater than 65,535, set the length field in the UDP header to zero.
そして、UDPパケットを送るときUDPヘッダーとデータの長さが6万5535以上である場合にだけ、UDPヘッダーの長さの分野をゼロに設定してください。
Note 1: The length used in the "pseudo-header" for computing the UDP checksum is always the true length of the UDP header plus data, NOT zero [RFC-1883, Section 8.1].
注意1: いつもUDPチェックサムを計算するのに「疑似ヘッダー」で使用される長さはゼロ[RFC-1883、セクション8.1]ではなく、UDPヘッダーとデータの真の長さです。
Borman Standards Track [Page 1] RFC 2147 TCP and UDP over IPv6 Jumbograms May 1997
ボーマンStandardsは1997年5月にIPv6 Jumbogramsの上でRFC2147TCPとUDPを追跡します[1ページ]。
Note 2: An IPv6 packet that carries a UDP packet of length greater than 65,535 will necessarily carry a Jumbo Payload option in a Hop-by-Hop Options header [RFC1883, Section 4.3]). The length field in the Jumbo Payload option contains the length of the IP packet excluding the IPv6 header, that is, it contains the length of all extension headers present plus the UDP header plus the UDP data. The length field in the IPv6 header contains zero to indicate the presence of the Jumbo Payload option.
注意2: 6万5535以上の長さのUDPパケットを運ぶIPv6パケットは必ずホップHopのOptionsヘッダー[RFC1883、セクション4.3)でJumbo有効搭載量オプションを運ぶでしょう。 Jumbo有効搭載量オプションにおける長さの分野はIPv6ヘッダーを除いたIPパケットの長さを含んでいます、すなわち、それがヘッダーが提示するすべての拡大、UDPヘッダー、およびUDPデータの長さを含んでいます。 IPv6ヘッダーの長さの分野はJumbo有効搭載量オプションの存在を示すゼロを含んでいます。
If a UDP packet is received with a length field of zero, the length of the UDP packet is computed from the length field in the Jumbo Payload option minus the length of all extension headers present between the IPv6 header and the UDP header.
ゼロの長さの分野でUDPパケットを受け取るなら、IPv6ヘッダーとUDPヘッダーの間に出席しているすべての拡張ヘッダーの長さを引いてJumbo有効搭載量オプションにおける長さの分野からUDPパケットの長さを計算します。
3. TCP Jumbograms
3. TCP Jumbograms
Because there is no length field in the TCP header, there is nothing limiting the length of an individual TCP packet. However, the MSS value that is negotiated at the beginning of the connection limits the largest TCP packet that can be sent, and the Urgent Pointer cannot reference data beyond 65535 bytes.
長さの分野が全くTCPヘッダーにないので、何も個々のTCPパケットの長さを制限するものがありません。 しかしながら、接続の始めに交渉されるMSS値は送ることができる中で最も大きいTCPパケットを制限します、そして、Urgent Pointerは65535バイトを超えた参考資料を制限できません。
3.1 TCP MSS
3.1 TCP MSS
When determining what MSS value to send, if the MTU of the directly attached interface is greater than 65535, then set the MSS value to 65535.
どんなMSS値を送ったらよいかを決定するときには、直接付属しているインタフェースのMTUが65535以上であるならMSS値を65535に設定してください。
When an MSS value of 65535 is received, it is to be treated as infinity. MTU discovery code, starting with the MTU of the outgoing interface, will be used to determine the actual MSS.
65535のMSS値が受け取られているとき、それは無限として扱われることになっています。 外向的なインタフェースのMTUから始まって、MTU発見コードは、実際のMSSを決定するのに使用されるでしょう。
3.2 TCP Urgent Pointer
3.2 TCPの緊急の指針
The Urgent Pointer problem could be fixed by adding a TCP Urgent Pointer Option. However, since it is unlikely that applications using jumbograms will also use Urgent Pointers, a less intrusive change similar to the MSS change will suffice.
TCP Urgent Pointer Optionを加えることによって、Urgent Pointer問題を修正できるでしょう。 しかしながら、また、jumbogramsを使用するアプリケーションがUrgent Pointersを使用するのが、ありそうもないので、MSS変化と同様のそれほど押しつけがましくない変化は十分でしょう。
When a TCP packet is to be sent with an Urgent Pointer (i.e., the URG bit set), first calculate the offset from the Sequence Number to the Urgent Pointer. If the offset is less than 65535, fill in the Urgent field and continue with the normal TCP processing. If the offset is greater than 65535, and the offset is greater than or equal to the length of the TCP data, fill in the Urgent Pointer with 65535 and continue with the normal TCP processing. Otherwise, the TCP packet must be split into two pieces. The first piece contains data up to, but not including the data pointed to by the Urgent Pointer, and the
TCPパケットがUrgent Pointerと共に送られることになっているとき(すなわち、URGビットはセットしました)、最初に、Sequence NumberからUrgent Pointerまでのオフセットを計算してください。 オフセットが65535未満であるなら、Urgent分野に記入してください、そして、通常のTCP処理を続行してください。 オフセットが65535以上であり、オフセットがTCPデータの長さ以上であるなら、65535でUrgent Pointerに記入してください、そして、通常のTCP処理を続行してください。 さもなければ、TCPパケットを2つの断片に分けなければなりません。 そしてデータを含んでいますが、最初の断片がUrgent Pointerで示されたデータを含んでいない。
Borman Standards Track [Page 2] RFC 2147 TCP and UDP over IPv6 Jumbograms May 1997
ボーマンStandardsは1997年5月にIPv6 Jumbogramsの上でRFC2147TCPとUDPを追跡します[2ページ]。
Urgent field is set to 65535 to indicate that the Urgent Pointer is beyond the end of this packet. The second piece can then be sent with the Urgent field set normally.
65535に緊急の分野が、Urgent Pointerがこのパケットの端のときにあるのを示すように設定されます。 そして、通常、Urgent分野セットで2番目の断片を送ることができます。
Note: The first piece does not have to include all of the data up to the Urgent Pointer. It can be shorter, just as long as it ends within 65534 bytes of the Urgent Pointer, so that the offset to the Urgent Pointer in the second piece will be less than 65535 bytes.
以下に注意してください。 最初の断片はデータのすべてをUrgent Pointerまで含む必要はありません。 それは、より短い場合があります、まさしくUrgent Pointerの65534バイト以内で終わる限り、2番目の断片へのUrgent Pointerへのオフセットが65535バイト未満になるように。
For TCP input processing, when a TCP packet is received with the URG bit set and an Urgent field of 65535, the Urgent Pointer is calculated using an offset equal to the length of the TCP data, rather than the offset in the Urgent field.
URGビットがセットした状態でTCPパケットを受け取るときのTCP入力処理と65535のUrgent分野において、Urgent Pointerは、Urgent分野でオフセットよりむしろTCPデータの長さと等しいオフセットを使用することで計算されます。
It should also be noted that though the TCP window is only 16-bits, larger windows can be used through use of the TCP Window Scale option [Jacobson92].
また、TCPの窓が16ビットであるだけですが、TCP Window Scaleオプション[Jacobson92]の使用で、より大きい窓を使用できることに注意されるべきです。
4. Security Considerations
4. セキュリティ問題
There are no known security issues involved in these changes.
これらの変化にかかわる安全保障問題は知られていません。
5. References
5. 参照
[Jacobson92] Jacobson, V., R. Braden and D. Borman, "TCP Extensions for High Performance", RFC 1323, LBL, ISI and Cray Research, May 1992.
[Jacobson92] ジェーコブソン、V.、R.ブレーデン、およびD.ボーマン(「高性能のためのTCP拡張子」、RFC1323、LBL、ISI、およびクレイリサーチ)は、1992がそうするかもしれません。
[Deering95] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon Networks, December 1995.
[Deering95] デアリングとS.とR.Hindenと「インターネットプロトコル、バージョン6(IPv6)仕様」とRFC1883とゼロックスPARCとIpsilonネットワーク、1995年12月。
Author's Address
作者のアドレス
David A. Borman Berkeley Software Design, Inc. 4719 Weston Hills Drive Eagan, MN 55123 Phone: (612) 405-8194 Mailing List: ipng@sunroof.Eng.Sun.COM Email: dab@bsdi.com
デヴィッドA.ボーマンバークレイ・ソフトウェア・デザインInc.4719ウェストンHillsはイーガン、Mn55123電話を動かします: (612) 405-8194メーリングリスト: ipng@sunroof.Eng.Sun.COM メール: dab@bsdi.com
Borman Standards Track [Page 3]
ボーマン標準化過程[3ページ]
一覧
スポンサーリンク