[要約] RFC 9187は、ウィンドウベースのプロトコルでシーケンス番号を拡張するための方法を定義しています。この拡張により、データ転送の信頼性と効率が向上します。主に、高速または大容量のデータ転送が必要なネットワーク環境で利用されます。
Independent Submission J. Touch
Request for Comments: 9187 Independent Consultant
Category: Informational January 2022
ISSN: 2070-1721
Sequence Number Extension for Windowed Protocols
ウィンドウプロトコルのシーケンス番号拡張
Abstract
概要
Sliding window protocols use finite sequence numbers to determine segment placement and order. These sequence number spaces wrap around and are reused during the operation of such protocols. This document describes a way to extend the size of these sequence numbers at the endpoints to avoid the impact of that wrap and reuse without transmitting additional information in the packet header. The resulting extended sequence numbers can be used at the endpoints in encryption and authentication algorithms to ensure input bit patterns do not repeat over the lifetime of a connection.
スライディングウィンドウプロトコルは、セグメントの配置と順序を決定するために有限のシーケンス番号を使用します。これらのシーケンス番号のスペースは折り返し、そのようなプロトコルの動作中に再使用されます。このドキュメントでは、パケットヘッダーに追加情報を送信せずにそのラップの影響を避けるために、エンドポイントでこれらのシーケンス番号のサイズを拡張する方法について説明します。結果として得られた拡張シーケンス番号は、暗号化および認証アルゴリズムのエンドポイントで使用して、入力ビットパターンが接続の寿命を越えて繰り返さないようにします。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。それは情報提供のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディタは、この文書をその判断で公開することを選択し、実装または展開の値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9187.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9187で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction
2. Background
3. Related Discussion
4. Using SNE in Protocol Design
5. Example Code
6. Validation Suite
7. Security Considerations
8. IANA Considerations
9. Informative References
Acknowledgments
Author's Address
Protocols use sequence numbers to maintain ordering and, in sliding window systems, to control the amount of outstanding unacknowledged information. These sequence numbers are finite and thus commonly wrap around during long connections, reusing past values.
プロトコルは、順序付けを維持し、スライディングウィンドウシステムでは、未解決の未確認情報の量を制御するために順序付けされます。これらのシーケンス番号は有限であり、したがって一般的に長い接続中に折り返し、過去の値を再利用します。
It can be useful for protocols to keep track of this wrap around in a separate counter, such that the sequence number and counter together form an equivalent number space that need not wrap. This technique was introduced as "Sequence Number Extension" in the TCP Authentication Option (TCP-AO) [RFC5925]. The example provided there was intended to introduce the concept, but the pseudocode provided is not complete.
シーケンス番号とカウンタが折り返される必要がある同等の数のスペースを形成するように、プロトコルが別のカウンタでこのラップを追跡するのに役立ちます。この手法は、TCP認証オプション（TCP-AO）[RFC5925]の「シーケンス番号拡張」として導入されました。その例は概念を導入することを意図していましたが、提供される疑似コードは完全ではありません。
This document presents the formal requirements for Sequence Number Extension (SNE), a code example, and a check sequence that can be used to validate this and alternate implementations. Sequence numbers are used in a variety of protocols to support loss detection, reordering, flow control, and congestion control. Limitations in the size of a sequence number protocol field can limit the ways in which these capabilities can be supported.
このドキュメントは、シーケンス番号拡張（SNE）、コード例、およびこれと代替の実装を検証するために使用できるチェックシーケンスの正式な要件を示しています。シーケンス番号は、損失検出、並べ替え、フロー制御、および輻輳制御をサポートするためのさまざまなプロトコルで使用されています。シーケンス番号プロトコルフィールドのサイズの制限事項は、これらの機能をサポートできる方法を制限できます。
Under certain conditions, it is possible for both endpoints of a protocol to keep track of sequence number rollover and effectively extend the sequence number space without requiring modification of the sequence number field used within protocol messages. These conditions assume that the received sequence numbers never vary by more than half the size of the space of the field used in messages, i.e., they never hop forward or backward by more than half that space. This constraint is typical in sliding window protocols, such as TCP. However, although both ends can track rollover unambiguously, doing so can be surprisingly complex. This document provides examples and test cases to simplify that process.
特定の条件下では、プロトコルメッセージ内で使用されるシーケンス番号フィールドの変更を必要とせずに、プロトコルのエンドポイントがシーケンス番号ロールオーバーを追跡し、シーケンス番号スペースを効果的に拡張することが可能である。これらの条件は、受信したシーケンス番号がメッセージで使用されるフィールドの空間の半分以上のサイズによっては決して変化しないと仮定します。この制約は、TCPなどのスライディングウィンドウプロトコルの概要です。しかしながら、両端はロールオーバーを明確に追跡することができるが、そうすることは驚くほど複雑になる可能性がある。この文書はそのプロセスを単純化するための例とテストケースを提供します。
This document is intended for protocol designers who seek to use larger sequence numbers at the endpoints without needing to extend the sequence number field used in messages, such as for authentication protocols, e.g., TCP-AO [RFC5925]. Use of extended sequence numbers should be part of a protocol specification so that both endpoints can ensure they comply with the requirements needed to enable their use in both locations.
この文書は、認証プロトコルなどのメッセージで使用されるシーケンス番号フィールド、例えばTCP-AO [RFC5925]など、エンドポイントでより大きなシーケンス番号を使用しようとするプロトコル設計者を対象としています。拡張シーケンス番号の使用は、両方のエンドポイントが両方の場所での使用を可能にするのに必要な要件に準拠していることを保証できるように、プロトコル仕様の一部である必要があります。
The remainder of this document describes how SNE can be supported and provides the pseudocode to demonstrate how received messages can unambiguously determine the appropriate extension value, as long as the reordering is constrained. Section 2 provides background on the concept. Section 3 discusses currently known uses of SNE. Section 4 discusses how SNE is used in protocol design and how it differs from in-band use of sequence numbers. Section 5 provides a framework for testing SNE implementations, including example code for the SNE function, and Section 6 provides a sequence that can be used by that code for validation. Section 7 concludes with a discussion of security issues.
この文書の残りの部分は、並べ替えが制限されている限り、受信メッセージが適切な拡張値を明確に決定できるのかを示すために、SNEをサポートできる方法を説明します。セクション2は概念の背景を提供します。セクション3は、現在知られているSNEの使用を論じている。セクション4は、SNEがプロトコル設計でどのように使用されるか、およびシーケンス番号の帯域内使用との異なる方法について説明します。セクション5は、SNE関数のコード例を含むSNE実装をテストするためのフレームワークを提供し、セクション6は検証のためにそのコードによって使用され得るシーケンスを提供します。セクション7はセキュリティ問題の議論を締結しています。
Protocols use sequence numbers to maintain message order. The transmitter typically increments them either once per message or by the length of the message. The receiver uses them to reorder messages and detect gaps due to inferred loss.
プロトコルは、メッセージ順序を維持するためにシーケンス番号を使用します。送信機は通常、メッセージごとに1回またはメッセージの長さによってそれらをインクリメントする。受信機はそれらを使用してメッセージを並べ替え、推論された損失のためにギャップを検出します。
Sequence numbers are represented within those messages (e.g., in the headers) as values of a finite, unsigned number space. This space is typically represented in a fixed-length bit string, whose values range from 0..(2^N)-1, inclusive.
シーケンス番号は、有限の符号なし数スペースの値としてそれらのメッセージ（例えば、ヘッダー内）内に表されます。このスペースは通常、その値が0から範囲である固定長ビット文字列で表されます..（2 ^ n）-1では、
The use of finite representations has repercussions on the use of these values at both the transmitter and receiver. Without additional constraints, when the number space "wraps around", it would be impossible for the receiver to distinguish between the uses of the same value.
有限表現の使用は、送信機と受信機の両方でこれらの値を使用するための影響を受けています。追加の制約なしで、数スペースが「ラップしている」とき、受信機が同じ値の使用を区別することは不可能であろう。
As a consequence, additional constraints are required. Transmitters are typically required to limit reuse until they can assume that receivers would successfully differentiate the two uses of the same value. The receiver always interprets values it sees based on the assumption that successive values never differ by just under half the number space. A receiver cannot detect an error in that sequence, but it will incorrectly interpret numbers if reordering violates this constraint.
結果として、追加の制約が必要です。トランスミッタは通常、受信機が同じ値の2つの使用をうまく区別したと仮定するまでの再利用を制限するために必要です。受信者は、連続した値が数値空間の半分の下ではないという仮定に基づいて、それが見る値を常に解釈します。受信側はそのシーケンスのエラーを検出できませんが、並べ替えがこの制約に違反した場合、数値を誤って解釈します。
The constraint requires that "forward" values advance the values by less than half the sequence number space, ensuring that receivers never experience a series of values that violate that rule.
制約では、「順方向」の値がシーケンス番号スペースの半分以下で値を進め、受信側がそのルールに違反する一連の値を経験することを保証する必要があります。
We define a sequence space as follows:
次のようにシーケンススペースを定義します。
* An unsigned integer within the range of 0..(2^N)-1, i.e., for N bits.
* （2 ^ n）-1、すなわちnビットの範囲内の符号なし整数。
* An operation that increments values in that space by K, where K < 2^(N-1), i.e., less than half the range. This operation is used exclusively by the transmitter.
* K <2 ^（n-1）、すなわち範囲の半分未満であるKによってその空間内の値を増分する動作。この操作は、送信機によって排他的に使用されます。
* An operation that compares two values in that space to determine their order, e.g., where X < Y implies that X comes before Y.
* そのスペース内の2つの値を比較して、それらの順序を決定する操作、例えばx <yはxがYの前に来ることを意味する。
We assume that both sides begin with the same initial value, which can be anywhere in the space. That value is either assumed (e.g., 0) before the protocol begins or coordinated before other messages are exchanged (as with TCP Initial Sequence Numbers (ISNs) [RFC0793]). It is assumed that the receiver always receives values that are always within (2^N)-1, but the successive received values never jump forward or backward by more than 2^(N-1)-1, i.e., just under half the range.
両側が同じ初期値で始まると仮定します。これはスペース内のどこにでもあります。その値は、（TCP初期シーケンス番号（ISNS）[RFC0793]と同様に、プロトコルが交換される前にプロトコルが開始または調整される前に想定される（例えば0）。受信機は常に常に（2 ^ n）-1の内側にある値を受け取るが、連続した受信値は2 ^（N - 1）-1、すなわち半分の下で前後に進退することはない。範囲。
No other operations are supported. The transmitter is not permitted to "backup", such that values are always used in "increment" order. The receiver cannot experience loss or gaps larger than 2^(N-1)-1, which is typically enforced either by assumption or by explicit endpoint coordination.
他の操作はサポートされていません。送信機は「バックアップ」には許可されていないため、値が常に「増分」順序で使用されます。受信機は、2 ^（n-1）-1より大きい損失またはギャップを経験することはできません。これは通常、仮定または明示的なエンドポイント調整によって適用されます。
An SNE is a separate number space that can be combined with the sequence number to create a larger number space that need not wrap around during a connection.
SNEは、シーケンス番号と組み合わせることができる個別の数のスペースで、接続中に折り返される必要がないより大きな数のスペースを作成することができます。
On the transmit side, SNE is trivially accomplished by incrementing a local counter once each time the sequence number increment "wraps" around or by keeping a larger local sequence number whose least-significant part is the message sequence number and most-significant part can be considered the SNE. The transmitter typically does not need to maintain an SNE except when used in local computations, such as for Message Authentication Codes (MACs) in TCP-AO [RFC5925].
送信側では、SNEは、シーケンス番号の増分「ラップ」が周囲に1回、または最も重要な部分がメッセージシーケンス番号であり、最上位部分が最も大きくなることによって、ローカルカウンタをインクリメントすることによって機能的に達成される。SNEと見なされます。送信機は通常、TCP-AO [RFC5925]のメッセージ認証コード（MACS）など、ローカル計算で使用されている場合を除いてSNEを維持する必要はありません。
The goal of this document is to demonstrate that SNE can be accomplished on the receiver side without transmitting additional information in messages. It defines the stateful function compute_sne() as follows:
この文書の目的は、メッセージ内の追加情報を送信することなく、SNEを受信側で実行できることを示すことです。次のようにステートフル関数compute_sne（）を定義します。
SNE = compute_sne(seqno)
sne = compute_sne（seqno）
The compute_sne() function accepts the sequence number seen in a received message and computes the corresponding SNE. The function includes persistent local state that tracks the largest currently received SNE and seqno combination. The concatenation of SNE and seqno emulates the equivalent larger sequence number space that can avoid wrap around.
compute_sne（）関数は、受信したメッセージに見られるシーケンス番号を受け入れ、対応するSNEを計算します。この関数は、最大の現在受信されたSNEとSEQNOの組み合わせを追跡する永続的なローカル状態を含みます。SNEとSEQNOの連結は、折り返しの避けられない同等のシーケンス番号スペースをエミュレートします。
Note that the function defined here is capable of receiving any series of seqno values and computing their correct corresponding SNE, as long as the series never "jumps" more than half the number space "backward" from the largest value seen "forward".
ここで定義されている関数は、シリーズが「前方」の最大値から「後方」の半分を「ジャンプ」されない限り、任意の一連のSEQNO値を受信し、正しい対応するSNEを計算することができます。
The DNS uses sequence numbers to determine when a Start of Authority (SOA) serial number is more recent than a previous one, even considering sequence space wrap [RFC1034][RFC1035]. The use of wrapped sequence numbers for sliding windows in network protocols was first described as a sequence number space [IEN74].
DNSはシーケンス番号を使用して、シーケンススペースのラップ[RFC1034] [RFC1035]を考慮して、権限の開始（SOA）シリアル番号が前のものよりも最近の前回のものを決定します。ネットワークプロトコル内のスライドウィンドウのためのラップされたシーケンス番号を使用することは、まずシーケンス番号スペース[IEN74]として説明した。
A more recent discussion describes this as "serial number arithmetic" and defines a comparison operator it claimed was missing in IEN-74 [RFC1982]. That document defines two operations: addition (presumably shifting the window forward) and comparison (defining the order of two values). Addition is defined in that document as limited to values within the range of 0..windowsize/2-1. Comparison is defined in that document by a set of equations therein, but that document does not provide a way for a receiver to compute the correct equivalent SNE, especially including the potential for sequence number reordering, as is demonstrated in this document.
最近の説明ではこれを「シリアル番号算術」と説明し、IEN-74 [RFC1982]に欠落していると主張されている比較演算子を定義しています。その文書は2つの操作を定義します：追加（想定されているようにwindow forwardを転送する）と比較（2つの値の順序を定義します）。追加は、そのドキュメントで0..windowsize / 2-1の範囲内の値に限定されています。比較はその文書でその中の一連の式によって定義されていますが、この文書では、この文書で説明されているように、この文書は、特にシーケンス番号の並べ替えの可能性を含めて、正しい同等のSNEを計算する方法を提供しません。
As noted in the introduction, message sequence numbers enable reordering, loss detection, flow control, and congestion control. They are also used to differentiate otherwise potentially identical messages that might repeat as part of a sequence or stream.
序論に留意されたように、メッセージシーケンス番号は並べ替え、損失検出、フロー制御、および輻輳制御を可能にする。それらはまた、順序またはストリームの一部として繰り返される可能性があるという点では、潜在的に同じメッセージを区別するためにも使用されます。
The size of the sequence number field used within transferred messages defines the ability of a protocol to tolerate reordering and gaps, notably limited to half the space of that field. For example, a field of 8 bits can reorder and detect losses of smaller than 2^7, i.e., 127 messages. When used for these purposes -- reordering, loss detection, flow control, and congestion control -- the size of the field defines the limits of those capabilities.
転送されたメッセージ内で使用されるシーケンス番号フィールドのサイズは、並べ替えとギャップを許容するためのプロトコルの能力を定義し、特にそのフィールドの空間の半分に制限されます。たとえば、8ビットのフィールドは、2 ^ 7よりも小さい損失、すなわち127個のメッセージを並べ替えることができます。これらの目的のために使用されるとき - 並べ替え、損失検出、フロー制御、および輻輳制御 - フィールドのサイズはそれらの機能の制限を定義します。
Sequence numbers are also used to differentiate messages; when used this way, they can be problematic if they repeat for otherwise identical messages. Protocols using sequence numbers tolerate that repetition because they are aware of the rollover of these sequence number spaces at both endpoints. In some cases, it can be useful to track this rollover and use the rollover count as an extension to the sequence number, e.g., to differentiate authentication MACs. This SNE is never transmitted in messages; the existing rules of sequence numbers ensure both ends can keep track unambiguously -- both for new messages and reordered messages.
シーケンス番号はメッセージを区別するためにも使用されます。このように使用されるとき、それらはそれ以外の場合は同一のメッセージに対して繰り返されるならば、それらは問題となる可能性があります。シーケンス番号を使用したプロトコルは、両方のエンドポイントでこれらのシーケンス番号スペースのロールオーバーを認識しているため、その繰り返しを許容します。場合によっては、このロールオーバーを追跡し、ロールオーバーカウントをシーケンス番号の拡張として、例えば認証MACを区別するのに役立ちます。このSNEはメッセージで送信されません。シーケンス番号の既存の規則は、両端を確実に追跡できるようにします。
The constraints required to use SNE have already been presented as background in Section 2. The transmitter must never send messages out of sequence beyond half the range of the sequence number field used in messages. A receiver uses this assumption to interpret whether received numbers are part of pre-wrap sequences or post-wrap sequences. Note that a receiver cannot enforce or detect if the transmitter has violated these assumptions on its own; it relies on explicit coordination to ensure this property is maintained, such as the exchange of acknowledgements.
SNEを使用するのに必要な制約はすでにセクション2の背景として示されています。送信機は、メッセージで使用されるシーケンス番号フィールドの範囲の半分を超えて順番にメッセージを送信してはいけません。受信機はこの仮定を使用して、受信した数字がプリラップシーケンスの一部または折り返しシーケンスの一部であるかどうかを解釈します。送信機がこれらの仮定に違反したかどうかを受信者が強制または検出できないことに注意してください。承認の交換など、この財産が維持されていることを確認するための明示的な調整に依存しています。
SNEs are intended for use when it is helpful for both ends to unambiguously determine whether the sequence number in a message has wrapped and whether a received message is pre-wrap or post-wrap for each such wrap. This can be used by both endpoints to ensure all messages of arbitrarily long sequences can be differentiated, e.g., ensuring unique MACs.
SNESは、両端にとって、メッセージ内のシーケンス番号が折り返されているかどうか、および受信したメッセージがプリラップまたは折り返しのどちらであるかどうかを明確に決定するのに役立つ場合に使用することを意図しています。これは、両方のエンドポイントによって使用され、任意の長いシーケンスのすべてのメッセージを区別することができます。たとえば、ユニークなMacを確実にすることができます。
SNE does not extend the actual sequence space of a protocol or (thus) its tolerance to reordering or gaps. It also cannot improve its dynamic range for flow control or congestion control, although there are other somewhat related methods that can, such as window scaling [RFC7323] (which increases range at the expense of granularity).
SNEはプロトコルの実際のシーケンススペースを拡張しない、または（したがって）並べ替えまたはギャップに対する許容範囲。また、フロー制御や輻輳制御のダイナミックレンジを向上させることはできませんが、ウィンドウスケーリング[RFC7323]（粒度を犠牲にして範囲が長くなります）があります。
SNE is not needed if messages are already unique over the entirety of a transfer sequence, e.g., either because the sequence number field used in its messages never wrap around or because other fields provide that disambiguation, such as timestamps.
メッセージで使用されているシーケンス番号フィールドは、転送シーケンスの全体にわたって既に一意である場合はSNEは必要ありません。
The following C code is provided as a verified example of SNE from 16 to 32 bits. The code includes both the framework used for validation and the compute_sne() function, the latter of which can be used operationally.
次のCコードは、16から32ビットのSNEの検証例として提供されています。コードには、検証に使用されるフレームワークとcompute_sne（）関数の両方が含まれていますが、後者は動作上使用できます。
A correct test will indicate "OK" for each test. An incorrect test will indicate "ERROR" where applicable.
テストごとに正しいテストは「OK」を示します。該当する場合、誤ったテストは「エラー」を示します。
<CODE BEGINS> file "compute_sne.c"
#include <stdio.h>
#include <sys/param.h>
#define distance(x,y) (((x)<(y))?((y)-(x)):((x)-(y)))
#define SNEDEBUG 1
#define Snedebug 1
// This is the core code, stand-alone, to compute SNE from seqno
// >> replace this function with your own code to test alternates
unsigned long compute_sne(unsigned long seqno) {
// INPUT: 32-bit unsigned sequence number (low bits)
// OUTPUT: 32-bit unsigned SNE (high bits)
// variables used in this code example to compute SNE:
// SNEを計算するためにこのコード例で使用されている変数：
static unsigned long
RCV_SNE = 0; // high-watermark SNE
static int
RCV_SNE_FLAG = 1; // set during first half rollover
// (prevents re-rollover)
static unsigned long
RCV_PREV_SEQ = 0; // high-watermark SEQ
unsigned long
holdSNE; // temp copy of output
holdSNE = RCV_SNE; // use current SNE to start
if (distance(seqno,RCV_PREV_SEQ) < 0x80000000) {
// both in same SNE range?
if ((seqno >= 0x80000000) && (RCV_PREV_SEQ < 0x80000000)) {
// jumps fwd over N/2?
RCV_SNE_FLAG = 0; // reset wrap increment flag
}
RCV_PREV_SEQ = MAX(seqno,RCV_PREV_SEQ);
// move prev forward if needed
} else {
// both in diff SNE ranges
if (seqno < 0x80000000) {
// jumps forward over zero?
RCV_PREV_SEQ = seqno; // update prev
if (RCV_SNE_FLAG == 0) {
// first jump over zero? (wrap)
RCV_SNE_FLAG = 1;
// set flag so we increment once
RCV_SNE = RCV_SNE + 1;
// increment window
holdSNE = RCV_SNE;
// use updated SNE value
}
} else {
// jump backward over zero
holdSNE = RCV_SNE - 1;
// use pre-rollover SNE value
}
}
#ifdef SNEDEBUG
fprintf(stderr,"state RCV_SNE_FLAG = %1d\n",
RCV_SNE_FLAG);
fprintf(stderr,"state RCV_SNE = %08lx\n", RCV_SNE);
fprintf(stderr,"state RCV_PREV_SEQ = %08lx\n", RCV_PREV_SEQ);
#endif
return holdSNE;
}
int main() {
// variables used as input and output:
unsigned long SEG_SEQ; // input - received SEQ
unsigned long SNE; // output - SNE corresponding
// to received SEQ
// variables used to validate the computed SNE:
unsigned long SEG_HIGH; // input - xmitter side SNE
// -> SNE should match this value
unsigned long long BIG_PREV; // prev 64-bit total seqno
unsigned long long BIG_THIS = 0; // current 64-bit total seqno
// -> THIS, PREV should never jump
// more than half the SEQ space
char *prompt = "Input hex numbers only (0x is optional)\n\n") "\tHex input\n" "\t(2 hex numbers separated by whitespace," "each with 8 or fewer digits)";
char * prompt = "入力16進数のみ（0xはオプション）\ n \ n"） "\ thex入力\ n" "\ t（空白数で区切られた2桁数2桁以下）";
fprintf(stderr,"%s\n",prompt);
fprintf（stderr、 "％s \ n"、プロンプト）。
while (scanf("%lx %lx",&SEG_HIGH,&SEG_SEQ) == 2) {
BIG_PREV = BIG_THIS;
BIG_THIS = (((unsigned long long)SEG_HIGH) << 32)
| ((unsigned long long)SEG_SEQ);
// given SEG_SEQ, compute SNE
SNE = compute_sne(SEG_SEQ);
fprintf(stderr," SEG_SEQ = %08lx\n", SEG_SEQ);
fprintf(stderr," SNE = %08lx\n", SNE);
fprintf(stderr," SEG_HIGH = %08lx %s\n",SEG_HIGH,
(SEG_HIGH == SNE)? " - OK" : " - ERROR !!!!!!!");
fprintf(stderr,"\t\tthe jump was %16llx %s %s\n",
distance(BIG_PREV,BIG_THIS),
((BIG_PREV < BIG_THIS)?"+":"-"),
(((distance(BIG_PREV,BIG_THIS)) > 0x7FFFFFFF)
? "ILLEGAL JUMP" : "."));
fprintf(stderr,"\n");
fprintf(stderr,"\n");
fprintf(stderr,"%s\n",prompt);
fprintf（stderr、 "％s \ n"、プロンプト）。
}
}
<CODE ENDS>
The following numbers are used to validate SNE variants and are shown in the order they legitimately could be received. Each line represents a single 64-bit number, represented as two hexadecimal 32-bit numbers with a space between. The numbers are formatted for use in the example code provided in Section 5.
以下の数字はSNE変異体を検証するために使用され、それらが合法的に受信され得る順序で示されている。各行は、間の間隔を持つ2つの16進数32ビット数として表される単一の64ビット数を表します。数字は、セクション5で提供されているコード例で使用するためにフォーマットされています。
A correctly operating extended sequence number system can receive the least-significant half (the right side) and compute the correct most-significant half (the left side) correctly. It specifically tests both forward and backward jumps in received values that represent legitimate reordering.
正しく動作している拡張シーケンス番号システムは、最下位半分（右側）を受け取り、正しい最上位半分（左側）を正しく計算できます。正当な並べ替えを表す受信値で順方向と後方へのジャンプの両方を特にテストします。
00000000 00000000 00000000 30000000 00000000 90000000 00000000 70000000 00000000 a0000000 00000001 00000001 00000000 e0000000 00000001 00000000 00000001 7fffffff 00000001 00000000 00000001 50000000 00000001 80000000 00000001 00000001 00000001 40000000 00000001 90000000 00000001 b0000000 00000002 0fffffff 00000002 20000000 00000002 90000000 00000002 70000000 00000002 A0000000 00000003 00004000 00000002 D0000000 00000003 20000000 00000003 90000000 00000003 70000000 00000003 A0000000 00000004 00004000 00000003 D0000000
00000003 70000000 000000000 00000003 D0000000
Sequence numbers and their extensions can be useful in a variety of security contexts. Because the extension part (most-significant half) is determined by the previously exchanged sequence values (least-significant half), the extension should not be considered as adding entropy for the purposes of message authentication or encryption.
シーケンス番号とその拡張機能は、さまざまなセキュリティコンテキストで役立ちます。延長部（最上位半分）は、以前に交換されたシーケンス値（最下位半分）によって決定されるため、メッセージ認証または暗号化の目的のためにエントロピーの追加と見なされるべきではありません。
This document has no IANA actions.
この文書にはIANAの行動がありません。
[IEN74] Plummmer, W., "Sequence Number Arithmetic", IEN-74, September 1978.
[IEN74] Plummmer、W、「シーケンス番号算術」、IEN-74、1978年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https：//www.rfc-editor.org/info/rfc793>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.
[RFC1982] ELZ、R.およびR. BUSH、「シリアル番号算術」、RFC 1982、DOI 10.17487 / RFC1982、1996年8月、<https：//www.rfc-editor.org/info/rfc1982>。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC5925] Touch、J.、Mankin、A.、R.ボニカ、「The TCP認証オプション」、RFC 5925、DOI 10.17487 / RFC5925、2010年6月、<https：//www.rfc-editor.org/info/ RFC5925>。
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., "TCP Extensions for High Performance", RFC 7323, DOI 10.17487/RFC7323, September 2014, <https://www.rfc-editor.org/info/rfc7323>.
[RFC7323] Borman、D.、Braden、B.、Jacobson、V.、およびR.Scheffenegger、ED。、「高性能のためのTCP拡張」、RFC 7323、DOI 10.17487 / RFC7323、2014年9月、<https：//www.rfc-editor.org/info/rfc7323>。
Acknowledgments
謝辞
The need for this document was first noted by Juhamatti Kuusisaari in April 2020 during discussions of the pseudocode in RFC 5925.
この文書の必要性は、RFC 5925の疑似コードの議論の間に、2020年4月にJuhamatti Kuusisaariによって最初に投稿されました。
Author's Address
作者の住所
Joe Touch Manhattan Beach, CA 90266 United States of America
Joe Touch Manhattan Beach、CA 90266アメリカ合衆国
Phone: +1 (310) 560-0334
Email: touch@strayalpha.com