RFC1624 日本語訳

Network Working Group                             A. Rijsinghani, Editor
Request for Comments: 1624                 Digital Equipment Corporation
Updates: 1141                                                   May 1994
Category: Informational

ワーキンググループA.Rijsinghani、コメントを求めるエディタ要求をネットワークでつないでください: 1624のDECアップデート: 1141 1994年5月のカテゴリ: 情報

                  Computation of the Internet Checksum
                         via Incremental Update

Incremental Updateを通したインターネットChecksumの計算

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This memo describes an updated technique for incremental computation
   of the standard Internet checksum.  It updates the method described
   in RFC 1141.

このメモは標準のインターネットチェックサムの増加の計算のためのアップデートされたテクニックについて説明します。 それはRFC1141で説明された方法をアップデートします。

Table of Contents

目次

   1. Introduction ..........................................  1
   2. Notation and Equations ................................  2
   3. Discussion ............................................  2
   4. Examples ..............................................  3
   5. Checksum verification by end systems ..................  4
   6. Historical Note .......................................  4
   7. Acknowledgments .......................................  5
   8. Security Considerations ...............................  5
   9. Conclusions ...........................................  5
   10. Author's Address .....................................  5
   11. References ...........................................  6

1. 序論… 1 2. 記法と方程式… 2 3. 議論… 2 4. 例… 3 5. エンドシステムによるチェックサム検証… 4 6. 歴史的な注意… 4 7. 承認… 5 8. セキュリティ問題… 5 9. 結論… 5 10. 作者のアドレス… 5 11. 参照… 6

1.  Introduction

1. 序論

   Incremental checksum update is useful in speeding up several
   types of operations routinely performed on IP packets, such as
   TTL update, IP fragmentation, and source route update.

増加のチェックサムアップデートはきまりきってIPパケットに実行されたいくつかのタイプの操作を早くする際に役に立ちます、TTLアップデートや、IP断片化や、送信元経路アップデートなどのように。

   RFC 1071, on pages 4 and 5, describes a procedure to
   incrementally update the standard Internet checksum.  The
   relevant discussion, though comprehensive, was not complete.
   Therefore, RFC 1141 was published to replace this description
   on Incremental Update.  In particular, RFC 1141 provides a
   more detailed exposure to the procedure described in RFC 1071.
   However, it computes a result for certain cases that differs

4と5ページでは、RFC1071は、標準のインターネットチェックサムを増加してアップデートするために手順について説明します。 包括的ですが、関連議論は完全ではありませんでした。 したがって、RFC1141は、Incremental Updateでこの記述を取り替えるために発行されました。 特に、RFC1141はRFC1071で説明された手順への、より詳細な露出を供給します。 しかしながら、それはあるケースのための異なる結果を計算します。

Rijsinghani                                                     [Page 1]

RFC 1624             Incremental Internet Checksum              May 1994

インターネットチェックサム1994年5月の増加のRijsinghani[1ページ]RFC1624

   from the one obtained from scratch (one's complement of one's
   complement sum of the original fields).

最初から得られたもの(元の分野の1の補数合計の1の補数)から。

   For the sake of completeness, this memo briefly highlights key
   points from RFCs 1071 and 1141.  Based on these discussions,
   an updated procedure to incrementally compute the standard
   Internet checksum is developed and presented.

完全を期すために、このメモはRFCs1071と1141年から要点を簡潔に強調します。 これらの議論に基づいて、標準のインターネットチェックサムを増加して計算するアップデートされた手順は、開発されて、提示されます。

2.  Notation and Equations

2. 記法と方程式

   Given the following notation:

以下の記法を与えます:

          HC  - old checksum in header
          C   - one's complement sum of old header
          HC' - new checksum in header
          C'  - one's complement sum of new header
          m   - old value of a 16-bit field
          m'  - new value of a 16-bit field

'HC--ヘッダーCの古いチェックサム--新しいヘッダーmの古いヘッダーHC'--ヘッダーC'の新しいチェックサム--1の補数合計の1の補数合計--16ビットの古い価値はmをさばきます'--、16ビットの分野の新しい値

          RFC 1071 states that C' is:

'RFC1071は、C'は以下の通りであると述べます。

          C' = C + (-m) + m'    --    [Eqn. 1]
             = C + (m' - m)

'C'はC+(-m)+mと等しいです'--[Eqn。 1] = C+'、(m、'、--、m)

   As RFC 1141 points out, the equation above is not useful for direct
   use in incremental updates since C and C' do not refer to the actual
   checksum stored in the header.  In addition, it is pointed out that
   RFC 1071 did not specify that all arithmetic must be performed using
   one's complement arithmetic.

'RFC1141が指摘するように、CとC'がヘッダーに格納された実際のチェックサムについて言及しないので、上の方程式はアップデート増加におけるダイレクト使用の役に立ちません。 さらに、RFC1071が、1の補数演算を使用することですべての演算を実行しなければならないと指定しなかったと指摘されます。

   Finally, complementing the above equation to get the actual checksum,
   RFC 1141 presents the following:

最終的に、実際のチェックサムを得る上の方程式の補足となって、RFC1141は以下を提示します:

          HC' = ~(C + (-m) + m')
              = HC + (m - m')
              = HC + m + ~m'    --    [Eqn. 2]

'HC'が~、と等しい、(C+(-m)+m、'、)、=HC+、(m--、m、'、)、=HC+m+~m、'、--[Eqn。 2]

3.  Discussion

3. 議論

   Although this equation appears to work, there are boundary conditions
   under which it produces a result which differs from the one obtained
   by checksum computation from scratch.  This is due to the way zero is
   handled in one's complement arithmetic.

この方程式は働くように見えますが、それが最初からチェックサム計算で得られたものと異なっている結果を生む境界状態があります。 これはゼロが1の補数演算で扱われる方法のためです。

   In one's complement, there are two representations of zero: the all
   zero and the all one bit values, often referred to as +0 and -0.
   One's complement addition of non-zero inputs can produce -0 as a
   result, but never +0.  Since there is guaranteed to be at least one

1の補数には、ゼロの2つの表現があります: すべてのゼロとしばしば+0と-0と呼ばれた1ビットの値 非ゼロ入力の1の補数添加はしかし、その結果、-0、決してどんな+0も生産できません。 以来、少なくとも1になるように保証されます。

Rijsinghani                                                     [Page 2]

RFC 1624             Incremental Internet Checksum              May 1994

インターネットチェックサム1994年5月の増加のRijsinghani[2ページ]RFC1624

   non-zero field in the IP header, and the checksum field in the
   protocol header is the complement of the sum, the checksum field can
   never contain ~(+0), which is -0 (0xFFFF).  It can, however, contain
   ~(-0), which is +0 (0x0000).

プロトコルヘッダーのIPヘッダー、およびチェックサムにおける非ゼロ磁場の分野が合計の補数である、チェックサム分野は~+0()を決して含むことができません。(それは、-0(0xFFFF)です)。 しかしながら、それは~(-0)、を含むことができます。(それは、+0(0×0000)です)。

   RFC 1141 yields an updated header checksum of -0 when it should be
   +0.  This is because it assumed that one's complement has a
   distributive property, which does not hold when the result is 0 (see
   derivation of [Eqn. 2]).

それが+0であるべきであるときに、RFC1141は-0のアップデートされたヘッダーチェックサムをもたらします。 これはそれが、1の補数には結果が0であるときに持ちこたえない分配的な特性があると仮定したからです(派生を見ます。[Eqn。 2]).

   The problem is avoided by not assuming this property.  The correct
   equation is given below:

問題は、この特性を仮定しないことによって、避けられます。 正しい方程式を以下に与えます:

          HC' = ~(C + (-m) + m')    --    [Eqn. 3]
              = ~(~HC + ~m + m')

'HC'が~、と等しい、(C+(-m)+m、'、)、--[Eqn。 3] = ~'、(~HC+~m+m、'、)

4.  Examples

4. 例

   Consider an IP packet header in which a 16-bit field m = 0x5555
   changes to m' = 0x3285.  Also, the one's complement sum of all other
   header octets is 0xCD7A.

'16ビットの分野m=0×5555が'=0x3285をmに変えるIPパケットのヘッダーを考えてください。 また、他のすべてのヘッダー八重奏の1の補数合計は0xCD7Aです。

   Then the header checksum would be:

そして、ヘッダーチェックサムは以下の通りでしょう。

          HC = ~(0xCD7A + 0x5555)
             = ~0x22D0
             =  0xDD2F

HC=~(0xCD7A+0×5555)=~0x22D0は0xDD2Fと等しいです。

   The new checksum via recomputation is:

再計算を通した新しいチェックサムは以下の通りです。

          HC' = ~(0xCD7A + 0x3285)
              = ~0xFFFF
              =  0x0000

'HC'は~(0xCD7A+0×3285)=~0xFFFF=0x0000と等しいです。

   Using [Eqn. 2], as specified in RFC 1141, the new checksum is
   computed as:

使用[Eqn。 2], RFC1141で指定されるように、新しいチェックサムは以下として計算されます。

          HC' = HC + m + ~m'
              =  0xDD2F + 0x5555 + ~0x3285
              =  0xFFFF

'0xDD2F+0×5555+~HC'=HC+m+~m'=0×3285は0xFFFFと等しいです。

   which does not match that computed from scratch, and moreover can
   never obtain for an IP header.

最初から計算して、そのうえ決して計算できなかったマッチはIPヘッダーとしてどれを得ませんか?

Rijsinghani                                                     [Page 3]

RFC 1624             Incremental Internet Checksum              May 1994

インターネットチェックサム1994年5月の増加のRijsinghani[3ページ]RFC1624

   Applying [Eqn. 3] to the example above, we get the correct result:

適用します。[Eqn。 3] 例に、私たちは正しい結果を上に、到着させます:

          HC' = ~(C + (-m) + m')
              = ~(0x22D0 + ~0x5555 + 0x3285)
              = ~0xFFFF
              =  0x0000

'HC'が~、と等しい、(C+(-m)+m、'、)、= ~(0x22D0+~0×5555+0x3285)は~0xFFFF=0x0000と等しいです。

5.  Checksum verification by end systems

5. エンドシステムによるチェックサム検証

   If an end system verifies the checksum by including the checksum
   field itself in the one's complement sum and then comparing the
   result against -0, as recommended by RFC 1071, it does not matter if
   an intermediate system generated a -0 instead of +0 due to the RFC
   1141 property described here.  In the example above:

エンドシステムが1の補数合計でチェックサム分野自体を含めて、次に、-0に対して結果をたとえることによってチェックサムについて確かめるなら、RFC1071によって推薦されるように、中間システムが+0の代わりにここで説明されたRFC1141の特性による-0を発生させたかどうかは重要ではありません。 上記の例で:

          0xCD7A + 0x3285 + 0xFFFF = 0xFFFF
          0xCD7A + 0x3285 + 0x0000 = 0xFFFF

0xCD7A+0×3285+0xFFFF=0xFFFF 0xCD7A+0×3285+0×0000=0xFFFF

   However, implementations exist which verify the checksum by computing
   it and comparing against the header checksum field.

しかしながら、ヘッダーチェックサム分野に対してそれを計算して、比較することによってチェックサムについて確かめる実現が存在しています。

   It is recommended that intermediate systems compute incremental
   checksum using the method described in this document, and end systems
   verify checksum as per the method described in RFC 1071.

中間システムが本書では説明された方法を使用することで増加のチェックサムを計算して、エンドシステムがRFC1071で説明された方法に従ってチェックサムについて確かめるのは、お勧めです。

   The method in [Eqn. 3] is slightly more expensive than the one in RFC
   1141.  If this is a concern, the two additional instructions can be
   eliminated by subtracting complements with borrow [see Sec. 7].  This
   would result in the following equation:

中の方法[Eqn。 3] RFC1141のものよりわずかに高価です。 これが関心であるなら、補数を引き算することによって2つの追加指示を排除できる、借用[Secを見てください。 7]. これは以下の方程式をもたらすでしょう:

          HC' = HC - ~m - m'    --    [Eqn. 4]

'HCは'HC--~m--mと等しいです'--[Eqn。 4]

          In the example shown above,

上の例で

          HC' = HC - ~m - m'
              =  0xDD2F - ~0x5555 - 0x3285
              =  0x0000

'HC'=HC--~m--m'=0xDD2F--~0×5555--0×3285=0×0000

6.  Historical Note

6. 歴史的な注意

   A historical aside: the fact that standard one's complement
   arithmetic produces negative zero results is one of its main
   drawbacks; it makes for difficulty in interpretation.  In the CDC
   6000 series computers [4], this problem was avoided by using
   subtraction as the primitive in one's complement arithmetic (i.e.,
   addition is subtraction of the complement).

歴史的な余談: 演算が生産するその標準の1の補数に、負のゼロが結果として生じるという事実は主な欠点の1つです。 それは解釈における困難になります。 6000台のCDCシリーズコンピュータ[4]では、この問題は、1の補数演算の原始として引き算を使用することによって、避けられました(すなわち、添加は補数の引き算です)。

Rijsinghani                                                     [Page 4]

RFC 1624             Incremental Internet Checksum              May 1994

インターネットチェックサム1994年5月の増加のRijsinghani[4ページ]RFC1624

7.  Acknowledgments

7. 承認

   The contribution of the following individuals to the work that led to
   this document is acknowledged:

このドキュメントにつながった仕事への以下の個人の貢献は承諾されます:

          Manu Kaycee - Ascom Timeplex, Incorporated
          Paul Koning - Digital Equipment Corporation
          Tracy Mallory - 3Com Corporation
          Krishna Narayanaswamy - Digital Equipment Corporation
          Atul Pandya - Digital Equipment Corporation

マヌーKaycee--法人組織のポール・コウニング--DECトレーシーMallory--Ascom Timeplex、3Com社のクリシュナNarayanaswamy--DEC Atul Pandya--DEC

   The failure condition was uncovered as a result of IP testing on a
   product which implemented the RFC 1141 algorithm.  It was analyzed,
   and the updated algorithm devised.  This algorithm was also verified
   using simulation.  It was also shown that the failure condition
   disappears if the checksum verification is done as per RFC 1071.

失敗状態は1141年のRFCアルゴリズムを実行した製品の上にテストされるIPの結果、暴露されました。 それは、分析されていて工夫されたアップデートされたアルゴリズムでした。 また、このアルゴリズムは、シミュレーションを使用することで確かめられました。 また、RFC1071に従ってチェックサム検証をするなら失敗状態が見えなくなるのが示されました。

8.  Security Considerations

8. セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

9.  Conclusions

9. 結論

   It is recommended that either [Eqn. 3] or [Eqn. 4] be the
   implementation technique used for incremental update of the standard
   Internet checksum.

それはお勧めそんなにのどちらかです。[Eqn。 3] または[Eqn。 4] 標準のインターネットチェックサムのアップデート増加に使用される実現のテクニックになってください。

10.  Author's Address

10. 作者のアドレス

   Anil Rijsinghani
   Digital Equipment Corporation
   550 King St
   Littleton, MA 01460

コマツナギRijsinghani DEC550Stリトルトン王、MA01460

   Phone: (508) 486-6786
   EMail: anil@levers.enet.dec.com

以下に電話をしてください。 (508) 486-6786 メールしてください: anil@levers.enet.dec.com

Rijsinghani                                                     [Page 5]

RFC 1624             Incremental Internet Checksum              May 1994

インターネットチェックサム1994年5月の増加のRijsinghani[5ページ]RFC1624

11.  References

11. 参照

   [1] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
       Specification", STD 5, RFC 791, DARPA, September 1981.

[1] ポステル、J.、「インターネットは議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」STD5、RFC791、DARPA、1981年9月。

   [2] Braden, R., Borman, D., and C. Partridge, "Computing the Internet
       Checksum", RFC 1071, ISI, Cray Research, BBN Laboratories,
       September 1988.

[2] ブレーデン、R.、ボーマン、D.、およびC.ヤマウズラ、「インターネットチェックサムを計算します」、RFC1071、ISI、クレイリサーチ、BBN研究所(1988年9月)。

   [3] Mallory, T., and A. Kullberg, "Incremental Updating of the
       Internet Checksum", RFC 1141, BBN Communications, January 1990.

[3] マロリー・ワイス症候群、T.とA.Kullberg、「インターネットチェックサムの増加のアップデート」RFC1141、BBNコミュニケーション、1990年1月。

   [4] Thornton, J., "Design of a Computer -- the Control
       Data 6600", Scott, Foresman and Company, 1970.

[4] ソーントン、J.、「コントロールデータ6600インチとスコットとForesmanと会社、コンピュータの設計--1970

Rijsinghani                                                     [Page 6]

Rijsinghani[6ページ]