Laguna of Cakel

결론

TCP 옵션은 인터넷 통신을 원활하게 할 수 있게 서로 규격을 정하고 여러 방면에서 효율적인 통신을 할 수 있게 해줍니다. 그리고 지금도 이 통신을 어떻게 하면 더 빠르고 안정적으로 할 수 있을지 연구 중입니다.

 출처 정리

http://www.freesoft.org/CIE/Course/Section4/8.htm
http://www.zdnet.co.kr/builder/dev/web/0,39031700,39129847,00.htm
http://www.ietf.org/rfc/rfc4413.txt
http://www.iana.org/assignments/tcp-parameters
http://www.simson.net/thesis/pki2.pdf
http://en.wikipedia.org/wiki/FTP_Software
http://www.usenet.com/newsgroups/comp.arch/msg03781.html
http://en.wikipedia.org/wiki/Space_Communications_Protocol_Specifications
http://nost.gsfc.nasa.gov/wwwclassic/documents/pdf/CCSDS-714.0-B-1.pdf
http://www.crhc.uiuc.edu/wireless/talks/tcp-wireless-tutorial.ppt
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008045552b.html
http://www.isi.edu/tcpsat/list/archive/0942.html
http://www.kinx-idc.net/support/network_dictionary.asp?strSearchText=SNAP
http://www.cs.rutgers.edu/~muthu/draft-bellovin-tcpcomp-00.txt

253, 254 : RFC3692-style Experiment

 RFC 3692 형식의 실험

 2.  IANA Considerations

 IANA 고려 사항

 2.1.  IP Protocol Field

 2.1 IP 프로토콜 영역

 Assignment of new values for the IP Protocol field requires an IETF Standards Action per [RFC 2780].  For the purposes of experimentation and testing, IANA has assigned the two values 253 and 254 for this purpose.  These values have been allocated from the upper end of the available number space in order to make them easy to identify by having them stand out relative to the existing assignments that have been made.

 IP 프로토콜 영역의 새 값 할당은 IETF 표준 활동 허가가 필요합니다. 실험과 시험 목적을 위해 IANA 는 253, 254 두 개의 값을 할당했습니다. 이들은 끝에 위치하여 근처 할당 값과 쉽게 구별할 수 있게 했습니다.

 2.2.  Existing Name Spaces

 2.2 존재하는 네임스페이스(이름 공간)

Numerous name spaces exist for which no values have been reserved for experimentation or testing purpose.  Experimental values for such protocols can of course be assigned through the normal process of publishing an RFC that documents the details of such an allocation. To simplify the process in those cases where the publication of a documentation just for the purpose of assigning an experimental allocation seems overkill, experimental values can be made through IESG Approval [RFC 2434].

많은 네임스페이스(이름 공간)들이 다른 시험을 위하거나 실험 목적으로 값이 존재 되어서는 안 되기에 (이들이) 존재합니다. 물론 실험값은 RFC 문서상의 정상적인 절차에 따른 할당이 가능합니다. IESG 승인(RFC 2434 참고)을 통해 만들어진 값 할당 실험만 하는데 문서화를 하는 절차가 과하다고 여겨지는 경우 이 간소화를 시킬 목적으로 사용됩니다.

25: 할당되지 않음(12/18/2000)

24: SNAP

24: SNAP(subnet network access protocol)

참고 : http://www.kinx-idc.net/support/network_dictionary.asp?strSearchText=SNAP

Subnetwork Access Protocol(서브네트워크 액세스 프로토콜)의 약어. 서브네트워크의 네트워크 엔티티와  엔드 시스템의 네트워크 엔터티(개체) 사이에서 실행되는 인터넷 프로토콜. SNAP는 IEEE 네트워크에서 IP 데이터그램과 ARP 메시지를 캡슐화하는 표준적인 방식을 지정한다. 종단 시스템의 SNAP 엔티티는 서브네트워크의 서비스를 활용하며, 데이터 전송, 연결 관리, QoS 선택 등의 세 가지 주요 기능을 수행합니다.

23: 손상 경험

참고: http://www.isi.edu/tcpsat/list/archive/0942.html

The Corruption Experienced Option provides a means for a TCP connection to react to data loss caused by corruption differently than to loss caused by congestion. Currently, TCP assumes that all loss is a result of congestion. When losses are due to corruption, TCP's congestion response is inappropriate, and has a negative effect on throughput. Use of the Explicit Corruption Notification option is only appropriate in networks where congestion is explicitly signaled. In the absence of an explicit corruption signal, loss is assumed to be due to congestion, and congestion recovery mechanisms are invoked. There remains a further issue, which is the coincidence of corruption in one portion of the network and severe congestion in another. The case in which (all) congestion signals fail either due to congestion collapse or corruption of the congestion signals is under study.

 손상 경험 옵션은 TCP 연결에서 혼잡으로 인한 손실이 발생했다는 옵션 값입니다. 현재는 TCP는 모든 손실이 혼잡으로 발생했다고 가정합니다. 손실이 손상으로 발생했을 때, TCP 혼잡 반응은 적절하지 않으며, 결과적으로 처리량에 부정적인 영향을 줍니다. 명백한 손상 알림은 명시적으로 혼잡이 발생했을 때 적절하게 쓰일 수 있습니다. 혼잡으로 인해 손실이 발생했다고 가정하고 혼잡 복구 구현을 시도합니다. 이는 나중에 있을지 모를 다른 네트워크 간의 심각한 혼잡으로 인한 손상 발생을 대비 하기 위해서입니다. 혼잡 붕괴로 실패 신호나 혼잡으로 인한 손상으로 인한 신호는 현재 연구 중입니다.

(RFC 문서에 다루지 않으므로 따로 조사하여 추가했습니다.)

22. Record boundary

 22: 레코드 경계

참고:

http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a008045552b.html

 Feature Overview

The X.25 Record Boundary Preservation for Data Communications Networks feature enables hosts using TCP/IP-based protocols to exchange data with devices that use the X.25 protocol, retaining the logical record boundaries indicated by use of the X.25 "more data" bit (M-bit).

 특징 간략 보기

호스트가 TCP/IP 기반 프로토콜에서 X. 25 프로토콜을 사용하는 기기들과 X. 25의 사용을 가리키는 논리적 레코드 경계를 유지하는 데이터 통신 네트워크 X. 25레코드 경계 보호(M-비트 이상) 기능입니다.

When to Use Record Boundary Preservation

언제 레코드 경계 보호가 쓰이는가

Before the introduction of the X.25 Record Boundary Preservation for Data Communications Networks feature, Cisco IOS software provided two methods for enabling the exchange of data between X.25 hosts and hosts using TCP/IP-based protocols: protocol translation and X.25 over TCP (XOT). Protocol translation supports a variety of configurations, including translation of a data stream between an X.25 circuit that is using X.29 and a TCP session. The X.29 protocol is an integral part of protocol translation. One aspect of X.29 is that it is asymmetric and allows the packaging of data into X.25 packets to be controlled in one direction only. The TCP protocol is stream-oriented, rather than packet-oriented. TCP does not attach significance to TCP datagram boundaries, and those boundaries can change when a datagram is retransmitted. This inability to preserve boundaries makes protocol translation appropriate only for configurations in which the X.25 packet boundary is not significant.

데이터(자료) 통신 네트워크 기능으로 X. 25레코드 경계 보호를 소기 하기 전에, Cisco IOS 소프트웨어는 두 가지 방식으로 X. 25 호스트와 TCP/IP 쓰는 호스트들 간에 사용하는 데이터 교환을 제공합니다. X. 25 와 TCP 간의 프로토콜 번역 (XOT). 프로토콜 번역은 X. 29와 TCP 세션을 사용하는 X. 25회로 간의 데이터스트림 설정을 포함한 다양한 설정을 지원합니다. X. 29는 프로토콜 번역의 통합 부분들 중 하나입니다. X. 29의 한 방면으로 비 대칭적이고 데이터를 X. 25 패킷으로 보낼 수 있게 묶어서 단방향으로 보낼 수 있도록 해줍니다. TCP 프로토콜은 패킷-기반보다 스트림-기반입니다. TCP는 TCP 데이터 그램 경계에 대한 중요성을 같이 붙이지 않으며, 이들 경개는 데이터그램이 재전송할 때에 바뀔 수 있습니다. X. 25 패킷 경계에 관한 설정만 통한 프로토콜 번역을 보존하지 못하는 것은 중요하지 않습니다.

 The XOT feature allows X.25 packets to be forwarded over a TCP session. This allows full control over the X.25 circuit, but the host terminating the TCP session must implement the XOT protocol and the X.25 packet layer protocol. The Record Boundary Preservation (RBP) feature offers a solution positioned between these two options: it allows logical message boundaries to be indicated without requiring the TCP host to be aware of X.25 protocol details.

  XOT 기능은 X. 25 패킷이 TCP로 보낼 수 있게 해줍니다. 이는 X. 25회로를 제어할 수 있지만 호스트가 TCP 세션을 끝낼 낼 때에는 XOT 프로토콜과 X. 25 패킷 레이어 프로토콜로 구현되어야 합니다. 레코드 경계 보존(RBP) 기능은 두 가지 옵션을 사이에 위치합니다. 이는 X. 25 프로토콜에 대한 상세한 정보를 알지 않은 상태에서 논리적 메시지 경계를 가리키게 해줍니다.

(RFC 문서에 다루지 않으므로 따로 조사하여 추가했습니다.)

  21: Selective negative ACKs

 참고 : http://www.crhc.uiuc.edu/wireless/talks/tcp-wireless-tutorial.ppt

 Satellite Transport Protocol (STP) [Henderson98]

 Uses split connection approach Protocol on satellite channel different from TCP

- selective negative acks when receiver detects losses
- no retransmission timer
- transmitter periodically requests receiver to ack received data
- reduces reverse channel bandwidth usage when losses are rare

위성 전송 프로토콜(STP – 꼭 STP에만 한정되지는 않음)

- TCP으로부터 다른 위성채널 프로토콜에서 갈려진 프로토콜 연결을 할 때 사용합니다.
- selective negative acks 수신자가 손실을 탐지했을 때 발생합니다.
- 재송신 타이머가 없음
- 주기적으로 받은 자료에 대한 ACK 송신
- 손실시 역채널 대역폭의 사용 양을 줄이는 경우는 드뭅니다.

      20 - 26;

 These non-RFC option types are not considered in this document. This only means that their behavior is not described in detail, as a compression scheme is not expected to be optimized for these options.  However, any unrecognized option must be carried by a TCP compression scheme transparently, in order to work efficiently in the presence of new or rare options.

 이들 비-RFC 옵션 값은 이 문서에서는 고려되지 않습니다. 이것은 단지 압축 틀에서 이들 옵션 값을 최적화를 고려하지 않아도 되기 때문에 자세히 이야기하지 않는 것입니다. 하지만, 새롭거나 잘 쓰이지 않는 옵션에서 효율적으로 작동하기 위해서 어떠한 알지 못하는 옵션 값이라도 TCP 압축 틀이 투명(명확)하게 보내어 져야 합니다.

 The above list covers options known at the time of writing.  Other options are expected to be defined.  It is important that any future options can be handled by a header compression scheme.  The processing of as-yet undefined options cannot be optimised but, at the very least, unknown options should be carried transparently.

  상위에서 다루는 옵션들은 글을 쓸 때 알려진 것들입니다. 다른 옵션들은 정의 되길 기대되는 것들입니다. 이는 이후 어떤 옵션 값들이 헤더 압축 틀에 의해 다루어 질 수 있다는 것을 의미합니다. 알려지지 않은 옵션 값들은 최적화할 수는 없지만, 적어도 알 수 없는 옵션 값은 투명성을 지니고 전송이 되어야 합니다.

 The current model for TCP options is that an option is negotiated in the SYN exchange and used thereafter, if the negotiation succeeds. This leads to some assumptions about the presence of options (being only on packets with the SYN flag set, or appearing on every packet, for example).  Where such assumptions hold true, it may be possible to optimise compression of options slightly.  However, it is seen as undesirable to be so constrained, as there is no guarantee that option handling and negotiation will remain the same in the future. Also note that a compressor may not process the SYN packets of a flow and cannot, therefore, be assumed to know which options have been negotiated.

  현재 TCP 옵션 모델은 SYN 교환 시에 교섭(니고시에이션)이 완성되며 만약 교섭이 성공했다면 이는 다른 옵션의 존재에 대한 가정을 이끌 수 있습니다. (예. SYN 플래그가 설정되어 있는 패킷에 한정 또는 어떤 패킷) 그런 가정이 사실인 곳에, 옵션 핸들링(다루기)과 교환이 이후에도 계속 남아 있으므로, 가볍게 옵션 압축을 최적화 하는 것이 가능합니다. 또한, 압축기는 흐름 속에 있는 SYN 패킷을 바꾸어서는 안 되며 따라서 어떤 옵션이 교환되는지 가정할 수 없습니다..

(RFC 문서에 다루지 않으므로 따로 조사하여 추가했습니다.)

20: SCPS Capabilities

20: SCPS 기능

참고

http://en.wikipedia.org/wiki/Space_Communications_Protocol_Specifications"

http://nost.gsfc.nasa.gov/wwwclassic/documents/pdf/CCSDS-714.0-B-1.pdf

The Space Communications Protocol Specifications (SCPS) are a set of extensions to existing protocols and new protocols developed by the Consultative Committee for Space Data Systems (CCSDS) to improve performance of Internet protocols in space environments. The SCPS protocol stack consists of:

 우주 통신 프로토콜 규정(SCPS)는 기존의 프로토콜의 확장이면서 우주 환경 속에서 향상된 통신을 위해 우주 자료 시스템 자문회(SCPS)에 의해 규정된 새로운 인터넷 프토토콜 입니다. SCPS 는 다음의 스택으로 프로토콜 구성되어 있습니다.

 SCPS-FP -- A set of extensions to FTP to make it more bit efficient and to add advanced features such as record update within a file and integrity checking on file transfers.

 SCPS-FP – 기존 FTP 의 확장으로 좀 더 비트에 효율적이고 파일 전송에 무결성 검사 내 레코드 업데이트(갱신) 같은 추가 전문적인 기능이 담겨 있는 프로토콜입니다.

  SCPS-TP -- A set of TCP options and sender-side modifications to improve TCP performance in stressed environments including long delays, high bit error rates, and significant assymetries. The SCPS-TP options are TCP options registered with the Internet Assigned Numbers Authority (IANA) and hence SCPS-TP is compatible with other well-behaved TCP implementations.

 SCPS-TP – 송신자가 높은 오류 수정비, 그리고 방대한 비대칭, 오래된 지연을 포함하는 악조건의 환경에서 수행할 수 있게 TCP를 수정한 TCP 옵션입니다. SCPS-TP 옵션들은 TCP 옵션으로 인터넷 번호 할당 기관(IANA, 아이아나)에 등록되어 있으므로 다른 TCP 구현과 잘 호환이 됩니다.

 SCPS-SP -- A security protocol comparable to IPsec

 SCPS-SP – IPSEC 과 호환이 되는 보안 프로토콜입니다.

 SCPS-NP -- A bit-efficient network protocol analogous to but not interoperable with IP The SCPS protocol that has seen the most use commercially is SCPS-TP, usually deployed as a Performance Enhancing Proxy (PEP) to improve TCP performance over satellite links.

 IP와 내부 호환되지는 않지만 비트-효율성을 지닌 네트워크 프로토콜입니다. 상업적으로 잘 쓰는 것은 SCPS-TP 이고 보통, 위성 링크를 통한 TCP 성능을 개선하기 위한 성능 개선 프록시를 쓰는데 시용 됩니다.

      19: MD5 Digest

 19: MD5 다이제스트(고유 문자)

 Every segment sent on a TCP connection to be protected against spoofing will contain the 16-byte MD5 digest produced by applying the MD5 algorithm to a concatenated block of data [13].

 모든 TCP 연결 상에 있는 세그먼트들은 위장(스푸핑)에 보호하기 위해 MD5 알고리듬 기반으로 16 바이트로 구성이 적용되어 자료의 블록에 겹쳐집니다.

 Upon receiving a signed segment, the receiver must validate it by calculating its own digest from the same data (using its own key) and comparing the two digests.  A failing comparison must result in the segment's being dropped and must not produce any response back to the sender.  Logging the failure is probably advisable.

 서명이 있는 세그먼트를 받자마자, 수신자는 자신만의 고유 문자를 기반으로 자료를 계산하고 두 고유문자를 비교 합니다. 비교 결과 다르다면 그 세그먼트는 반드시 버려져야 하고 수신자에게 가르쳐 주어서는 안 됩니다. 실패 기록은 아마도 도움이 될 겁니다.

 Unlike other TCP extensions (e.g., the Window Scale option [7]), the absence of the option in the SYN-ACK segment must not cause the sender to disable its sending of signatures.  This negotiation is typically done to prevent some TCP implementations from misbehaving upon receiving options in non- SYN segments.  This is not a problem for this option, since the SYN-ACK sent during connection negotiation will not be signed and will thus be ignored.  The connection will never be made, and non-SYN segments with options will never be sent.  More importantly, the sending of signatures must be under the complete control of the application, not at the mercy of a remote host not understanding the option.  MD5 digest information should, like any cryptographically secure data, be incompressible.  Therefore the compression scheme must simply transparently carry this option, if it occurs.

 다른 TCP 확장들과 달리(예. 윈도 비율 옵션), 이 옵션 값이 SYN-ACK 세그먼트 상에 없을 때에는 송신자의 서명을 중단 시켜서는 안 됩니다. 이런 규칙은 비-SYN 세그먼트를 받았을 때 잘못 행동할 수 있음에 대한 TCP 구현의 예방책으로 보통 쓰입니다. 이는 SYN-ACK 연결 시에는 서명되지 않고 따라서 무시되기 때문에 크게 문제가 되지 않습니다. 이 연결은 절대 이루어지지 않으며, 옵션 값을 가진 비-SYN 세그먼트들은 보내질 수 없습니다. 더욱 중요한 것은 송신자의 서명은 완벽한 응용프로그램의 제어 안에 두어야 하고 원격 호스트에서 이 옵션을 알아서는 안됩니다. MD5 자료는 다른 보안 자료들처럼 압축해서는 안 됩니다. 그러므로 압축 틀에서는 이 자료에 대해 투명성을 두어야만 합니다.

16 - 18: These non-RFC option types are not considered in this document.

비 RFC 옵션 형식은 이 문서에 다루지 않습니다.

(RFC 문서에서 다루지 않으므로 따로 조사하여 추가했습니다.)

참고 - Re: Cray to commercialize Red Storm

(http://www.usenet.com/newsgroups/comp.arch/msg03781.html)

 That isn't too much different from the died-on-the-vine draft RFC for the TCP Trailer checksum option from the earlyish 1990's.  That one of course was only between TCPs - it basically exchanged the last two data bytes of the TCP segment with the checksum field of the TCP header, so validation of the checksum would remain as it was before.

 이것은 1990년도 초기에 열매를 맺지 못하고 끝이 난 RFC 초안에 있던 TCP Trailer checksum 옵션과 크게 다르지 않습니다. 이는 물론 두 TCP간에 한정 합니다 – 기본적으로 검사합 영역이 담긴 TCP 세그먼트의 마지막 두 데이터 바이트 교환해서 검사합이 이전과 다르지 않은지 확인하고 인증 값을 유지합니다.

16 - 18: These non-RFC option types are not considered in this document.

비 RFC 옵션 형식은 이 문서에 다루지 않습니다.

(RFC 문서에서 다루지 않으므로 따로 조사하여 추가했습니다.)

16 – Skeeter / 17 - Bubba

참고 http://www.simson.net/thesis/pki2.pdf

 - A Tale of Two Protocols -

두 프로토콜에 대한 이야기

 Skeeter and Bubba, FTP Software, 1991

Skeeter 와 Bubba, FTP Software(1986년 에 설립한 회사, 회사명을 인터넷 프로토콜에 넣은 최초의 회사. http://en.wikipedia.org/wiki/FTP_Software 참고)

 Levy, Kastenholz and Knowles realized that they could improve the security of TCP by putting a Diffie-Hellman key agreement step directly into TCP’s three-way handshake. The exchange was implemented with TCP options #16 (“Skeeter”) and #17(Bubba”). [Kas01] If a TCP implementation supporting these options made a connection to a second TCP implementation that supported the options, the two network stacks would used the protocol to decide upon a key and use that key to encrypt all future communications with the IDEA block cipher.[Lev04]

 Levy, Kastenholz 와 Knowles 는 TCP 에다가 Diffie-Hellman (디피-헬만) 키 동의 단계를 TCP 3-방향 핸드셰이킹을 하는데 넣어 보안을 강화할 수 있게 실현화시켰습니다. 이 TCP 옵션 값 교환은 TCP 옵션 16번(Skeeter)와 17번(Bubba)로 구현했었습니다. 만약 TCP 이들 옵션을 넣은 채로 연결이 되었고 이후 이를 지원하는 옵션이 담긴 TCP 연결이 이루어지고 있다면 두 네트워크 스택은 하나의 보안 키를 사용하고 그 키를 이후 IDEA(International Institute for Democracy and Electoral Assistance - 국제 민주와 선거 지원 협회) 블록 암호 통신에 쓸 거라고 결정했을 것입니다.

 Because there was no certification of the remote system, the Skeeter/Bubba scheme only provided defense against passive eavesdropping, not against an active attacker who could mount a man-in-the-middle attack. The project was abandoned for two reasons. First, an engineer at FTP thought that it would be wasteful to have computers calculate large prime numbers for every TCP connection (none of those working on the project had any training in cryptography and knew how to optimize the system). Second, people in the company who understood security criticized the solution because it was susceptible to the man-in-the-middle attack. Today the Bubba and Skeeter TCP options with the cryptic reference to “[Knowles]” in the Internet’s list of Assigned Number RFCs (e.g., RFC1700[RP94]) are the only remnants of the project

   왜냐하면, 원격지 시스템에 대한 보안이 없기 때문에 Skeeter/Bubba 틀은 적극적으로 중간에 끼어 도청하는 적극적 도청 방지가 아닌, 수동적 도청에 대한 방지책으로만 제공되었습니다. 이 프로젝트는 두 가지 이유로 폐기되었습니다. 첫째로 FTP 있던 설계 기술자는 매번 TCP 연결 시 소수 계산을 해야 하는 것은 낭비라고 생각했습니다. (아무도 이에 관한 지식이 없었으며, 이런 암호화 된 시스템에 대한 최적화를 한 사람이 없었습니다.) 둘째로 회사 내 보안을 이해하는 분들이 전송 중에 끼어들어 공격할 여지가 있다고 생각했기 때문입니다. (그래서 수동 적에만 보안을 한다는 것에 회의적). 오늘날 Budda 와 Skeeter TCP 옵션은 RFC 문서상에 “[Knowles]” 보안 참고 문구로만 남겨 있어 이 프로젝트의 잔여물로만 남아 있습니다.

15: Alternate Checksum Data

 15: 대체 검사합 자료

 This field is used only when the alternate checksum that is negotiated is longer than 16 bits.  These checksums will not fit in the checksum field of the TCP header and thus at least part of them must be put in an option. Whether the checksum is split between the checksum field in the TCP header and the option or the entire checksum is placed in the option is determined on a checksum-by-checksum basis.  The length of this option will depend on the choice of alternate checksum algorithm for this connection; see RFC 1146 [5].

 이 영역은 대체 검사합이 16비트 이상으로 구현되었을 때에만 사용됩니다. 이들 검사합은 TCP 헤더에 있는 검사합 부분에 맞지 않아지게 되므로 적어도 이 부분을 옵션에 넣어 주어야만 합니다. 검사합이 TCP 헤더 부분이나 전체 검사합 이건 간에 이 옵션은 검사합-과-검사합 간을 기본으로 결정되어야 합니다. 검사합의 길이는 그 연결에 대한 대체 검사합 알고리듬에 근간합니다. RFC 1146을 참고 하세요.

 If an alternative checksum was negotiated in the connection set-up, then this option may appear on all subsequent packets (if needed to carry the checksum data).  However, this option is in practice never seen, so the only requirement is that the header compression scheme be able to encode it.

 만약 대체 알고리듬이 연결 시에 쓰여지고 있다면, 이후 모든 패킷에 이 옵션값이 쓰여질 수 있습니다(만약 검사합 값을 옮길 필요가 있다면) 하지만 이 옵션 값은 실제로는 전혀 보여지 않습니다. 따라서 헤더 압축 틀이 이걸 부호화 시킬 때에만 요구 사항이 됩니다.

      14: Alternate Checksum Request

 14: 대체 검사합(체크썸) 요구

 This option may be sent in a SYN segment by a TCP to indicate that the TCP is prepared to both generate and receive checksums based on an alternate algorithm.  During communication, the alternate checksum replaces the regular TCP checksum in the checksum field of the TCP header.  Should the alternate checksum require more than 2 octets to transmit, either the checksum may be moved into a TCP Alternate Checksum Data Option and the checksum field of the TCP header be sent as zero, or the data may be split between the header field and the option. Alternate checksums are computed over the same data as the regular TCP checksum; see RFC 1146 [5].

 이 옵션은 TCP 가 다른 알고리듬을 바탕으로 만들어진 검사합 값을 만들거나 받을 준비가 되었다는 것을 의미하는 값으로 SYN 세그먼트에 있을 수 있습니다. 통신 중에, 대체 검사합 값은 보통 쓰는 TCP 헤더의 TCP 검사합을 대체 합니다. 대체 검사합 값은 2개 이상의 8진수의 값을 요구하며 TCP 헤더의 대체/정규 검사합 영역은 0 이거나 또는 자료가 헤더 영역이나 옵션으로 나눠져 있어야 합니다. 대체 검사합은 정규 TCP 검사합에서 하는 똑같은 자료를 바탕으로 계산을 해야 합니다. RFC 1146을 참고 하세요.

 This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.  It would only occur in connection set-up (SYN) packets.  Even if this option were used, it would not affect the handling of the checksum, since this should be carried transparently in any case.

 이 옵션도 현재 인터넷에서 거의(또는 전혀) 쓰이지 않기 때문에 부호화 시 헤더 압축 틀에서만 고려되는 사항 입니다. 연결 설정 패킷(뭉치)에서만 발생 될 수 있습니다. 사용했더라도, 검사합 값은 투명성을 유지한 채로 전송 돼야 하므로 검사합 값이 검사합을 다루는데 영향을 주어서는 안 됩니다.

      13: CC.ECHO

 13:CC.ECHO

 When a server host sends a segment, it echoes the connection count from the initial in a CC.ECHO option, which is used by the client host to validate the segment (see RFC 1644 [8]). This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.

   서버 호스트가 세그먼트를 보낼 때, 처음의 연결 횟수(CC)에서는 클라이언트 호스트에서 그 세그먼트가 유효하다는 표시하는데 쓰이는 CC.ECHO 옵션을 실어 보냅니다(RFC 1644를 참조 하세요). 이 옵션도 현재 인터넷에서 거의(또는 전혀) 쓰이지 않기 때문에 부호화 시 헤더 압축 틀에서만 고려되는 사항 입니다.

      11: Connection Count (CC)

 11: 연결 횟수(CC)

 This option is part of the implementation of TCP Accelerated Open (TAO) that effectively bypasses the TCP Three-Way Handshake (3WHS).  TAO introduces a 32-bit incarnation number, called a "connection count" (CC), that is carried in a TCP option in each segment.  A distinct CC value is assigned to each direction of an open connection.  The implementation assigns monotonically increasing CC values to successive connections that it opens actively or passively (see RFC 1644 [8]).  This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.

   이 옵션 값은 TCP 3-방향 핸드셰이크(3WHS 교신)를 효율적으로 통과시키는 TCP 악셀레이티드 오픈(가속된 공개 – T/TCP에서 공개한 연결 설정 시 패킷의 수를 줄일 수 있는 기술) (TAO)에서 구현한 것들 중에 일부 입니다. TAO 는 ‘연결-횟수’ (CC) 라 불리는 TCP 연결 옵션 상에 실려 구현화된 32-비트 번호를 소개했습니다. 떨어진 CC 값은 각 방향의 개방된 연결 방향이 부여됩니다. 단조로운 값의 증가는 성공적이고 적극적이거나 수동적인 공개 연결을 의미하는데 부여 됩니다. (RFC 1644를 참조 하세요). 이 옵션도 현재 인터넷에서 거의(또는 전혀) 쓰이지 않기 때문에 부호화 시 헤더 압축 틀에서만 고려되는 사항입니다.

      12: CC.NEW

 12: CC.NEW

 Correctness of the TAO mechanism requires that clients generate monotonically increasing CC values for successive connection initiations.  Receiving a CC.NEW causes the server to invalidate its cache entry and to do a 3WHS.  See RFC 1644 [8]. This option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.

   TAO 작동 방식에서 수정되어야 할 것이 클라이언트가 연결 초기화 시에 단조로운 CC 값을 생성해야 한다는 것입니다. CC.NEW를 받는다는 것은 서버에 가지고 있는 캐시 개체를 무효화시키고, 3WHS를 하게 해줍니다. RFC 1644 를 참조 하세요. 이 옵션도 현재 인터넷에서 거의(또는 전혀) 쓰이지 않기 때문에 부호화 시 헤더 압축 틀에서만 고려되는 사항입니다.

10: POC service profile

 10: POC 서비스 프로필

 This option serves to communicate the information necessary to carry out the job of the protocol -- the type of information that is typically found in the header of a TCP segment.  The Partial Order Connection option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.

   이 옵션 값은 POC 프로토콜의 작업을 수행하는데 필요한 정보를 통신하는 데 쓰입니다 – 이 정보의 형태는 보통 TCP 세그먼트의 헤더부분에서 발견 됩니다. 부분적 순차 연결 옵션은 (마찬가지로) 현재 거의(또는 전혀) 인터넷에서 쓰지 않습니다. 따라서 압축 틀에서 부호화할 때에만 요구 사항이 됩니다.

      9: Partial Order Connection (POC) permitted

 9: 부분 순차 연결(POC) 허용

 This option represents a simple indicator communicated between the two peer transport entities to establish the operation of the POC protocol.  See RFC 1693 [9].

 이 옵션 값은 두 전송 개체 간에 POC 프로토콜 작업을 설정하는데 필요한 표시기입니다. RFC 1693을 참조하세요.

 The Partial Order Connection option sees little (or no) use in the current Internet, so the only requirement is that the header compression scheme be able to encode it.

 부분 연결 설정 옵션은 현재 인터넷에서 거의(또는 전혀) 쓰지 않습니다. 따라서 압축 틀에서 부호화하려고 할 때에만 필요한 요구 사항입니다.

      8: Timestamps

 8: 타임 스탬프(시간 도장)

 This option carries two four-byte timestamp fields.  The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option.  The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echoes a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option.  When TSecr is not valid, its value must be zero.  The TSecr value will generally be from the most recent Timestamp option that was received; however, there are exceptions that are explained below.  A TCP may send the Timestamps option (TSopt) in an initial segment (i.e., a segment containing a SYN bit and no ACK bit), and it may send a TSopt in other segments only if it received a TSopt in the initial segment for the connection (see RFC 1323 [7]). Timestamps are quite commonly used.  If timestamp options are exchanged in the connection set-up phase, then they are expected to appear on all subsequent segments.  If this exchange does not happen, then they will not appear for the remainder of the flow.

 이 옵션은 2개의 4바이트 타임스탬프 영역을 전송합니다. 타임스탬프 값 영역(TSval)은 TCP 가 옵션을 전송하는 현재 값의 타임스탬프 시각의 가지고 있습니다. 타임스탬프 에코 응답 영역(TScr)은 단지 ACK 비트가 TCP 헤더에 존재할 때만 유효합니다. 유효하다면 이 값은 원격지 TCP 의 타임스탬프 옵션 영역의 TSVal 값이 에코(메아리) 되어 보내집니다. 유효하지 않다면 이 값은 0이 되어야 합니다. TSerc 값은 일반적으로 가장 최근에 받아진 타임스탬프 옵션 값이 되어야 합니다. 그 이유는 추후에 설명하겠습니다. TCP 는 초기 세그먼트에서 타임스탬프 옵션을 보낼 수 있습니다. (예. SYN 비트와 ACK 비트가 없는 세그먼트) 그리고 TSopt 값은 처음 연결에서 보낸 경우에만 다른 세그먼트에 보낼 수 있습니다. (RFC 1323) 타임스탬프는 자주 공통적으로 사용됩니다. 만약 타임스탬프 옵션이 연결 설정 단계에서 교환되었으면, 그들은 연속적인 세그먼트 상에서 나타나는 것을 예상할 수 있습니다. 만약에 교환이 일어나지 않는다면, 그들은 나머지 흐름에서도 나타나지 않을 것입니다.

 Because the value being carried is a timestamp, it is logical to expect that the entire value need not be carried.  There is no obvious pattern of increments that might be expected, however.

 하나의 타임스탬프를 가지고 오기 때문에, 전체 값에 계속 가지고 다닐 필요가 없습니다. 하지만, 예상할 수 있는 확실한 패턴이나 형태는 존재하지 않습니다.

 An important reason for using the timestamp option is to allow detection of sequence space wrap-around (Protection Against Wrapped Sequence-number, or PAWS, see RFC 1323 [7]).  It is not expected that this is a serious concern on the links on which TCP header compression would be deployed, but it is important that the integrity of this option be maintained.  This issue is discussed in, for example, RFC 3150 [32].  However, the proposed Eifel algorithm [35] makes use of timestamps, so it is currently recommended that timestamps be used for cellular-type links [34].

   타임스탬프를 쓰는 중요한 이유는 순차적인 랩-어라운드(엇갈려) 공간을 탐지할 수 있게 하기 위해서 입니다 (엇갈린 순차-번호에 대한 보호 또는 PAWS, RFC 1323을 참조 하세요). TCP 헤더가 압축되어 보내어지는 링크에는 그다지 신경 쓸 사항이 아니지만, 이 옵션의 무결성(결함 없음)이 보장되기 위해서는 중요합니다. 이 문제는 예를 들어 RFC 3150 에 명시되어 있습니다. 하지만 이펠 알고리듬(또는 알고리즘)으로 제안된 타임스탬프 생성이 사용되고 있어, 현재 휴대전화-형식의 링크에서(도) 쓰이는 것을 추천하고 있습니다.

With regard to compression, note that the range of resolutions for the timestamp suggested in RFC 1323 [7] is quite wide (1ms to 1s per 'tick').  This (along with the perhaps wide variation in RTT) makes it hard to select a set of encodings that will be optimal in all cases.

  압축에 관해서는 처리 범위가 타임스탬프가 제안된 RFC 1323을 참조 하면 그 범위는 꽤 넓습니다. (1ms에서 1초 당 ‘틱’) 이는 (RTT 의 다양한 변화에 따라 달라집니다.) 모든 경우에서 최적의 상태에서 부호화하기가 쉽지 않다는 걸 알게 해줍니다.

      7: Echo Reply

 7: 메아리(에코) 응답

 A TCP that receives a TCP Echo option containing four information bytes will return these same bytes in a TCP Echo Reply option.  This TCP Echo Reply option must be returned in the next segment (e.g., an ACK segment) that is sent.  If more than one Echo option is received before a reply segment is sent, the TCP must choose only one of the options to echo,

  TCP 는 TCP 에코 옵션에 담겨있는 4개의 정보 바이트로 구성된 값을 에코 응답 옵션으로 그대로 되돌려받을 수 있습니다. 이 TCP 에코 응답 옵션은 반드시 보내어진 다음 세그먼트에서 되돌려 받아야 합니다(예, ACK 세그먼트). 만약 응답 세그먼트가 보내기 전에 하나 이상의 에코 응답 옵션을 받았다면 TCP 는 반드시 에코를 보낼 하나의 옵션을 골라야 합니다.

Ignoring the others; specifically, it must choose the newest segment with the oldest sequence number (see RFC 1072 [4]).  The Echo Reply option is generally not used in practice – it is obsoleted by the Timestamp option.  However, for transparency it is desirable that a compression scheme be able to transport it.  (However, there is no benefit in attempting any more sophisticated treatment than viewing it as a generic 'option').

  다른 걸 무시하고, 구체적으로 가장 오래된 순서 번호에서 새 세그먼트를 선택해야 합니다. (RFC 1072 참고). 에코 응답 옵션은 일반적으로 쓰이지 않습니다 – 타임스탬프(시간도장) 옵션으로 대체되었습니다. 하지만, 투명성을 위해서 압축된 틀 안에서 전송되는 것이 바람직 합니다. (하지만, 일반적인 “선택사항”으로 간주하는 거 보다 더 정교한 취급으로 얻어지는 이득은 없습니다.) (에코 옵션과 동일 사항)

      6: Echo

 6: 에코(메아리)

 This option carries information that the receiving TCP may send back in a subsequent TCP Echo Reply option (see below).  A TCP may send the TCP Echo option in any segment, but only if a TCP Echo option was received in a SYN segment for the connection. When the TCP echo option is used for RTT measurement, it will be included in data segments, and the four information bytes will define the time at which the data segment was transmitted in any format convenient to the sender (see RFC 1072 [4]).

   이 옵션 값은 TCP 에코 릴레이(교대) 옵션 값을 받았을 때 다시 전송하는 자료를 담아 보낼 때 쓰여 집니다. TCP는 TCP 에코 옵션 값을 어떤 세그먼트(세그먼트)에 넣어서 보낼 수 있습니다만 연결을 위해서 SYN 세그먼트 내에서 TCP 에코를 받았을 때에만 가능합니다.

 The Echo option is generally not used in practice -- it is obsoleted by the Timestamp option.  However, for transparency it is desirable that a compression scheme be able to transport it.  (However, there is no benefit in attempting any treatment more sophisticated than viewing it as a generic 'option').

   에코 옵션은 일반적으로 실제 쓰이지 않습니다 – 타임스탬프(시간도장) 옵션으로 대체되었습니다. 하지만 투명성을 위해서 압축된 틀 안에서 전송되는 것이 바람직합니다. (하지만, 일반적인 “선택사항”으로 간주하는 거 보다 더 정교한 취급으로 얻어지는 이득은 없습니다.)

      5: SACK

 5: SACK

This option is to be used to convey extended acknowledgment information over an established connection.  Specifically, it is to be sent by a data receiver to inform the data transmitter of non-contiguous blocks of data that have been received and queued.  The data receiver awaits the receipt of data in later retransmissions to fill the gaps in sequence space between these blocks.  At that time, the data receiver acknowledges the data, normally by advancing the left window edge in the Acknowledgment Number field of the TCP header. It is important to understand that the SACK option will not change the meaning of the Acknowledgment Number field, whose value will still specify the left window edge, i.e., one byte beyond the last sequence number of fully received data (RFC 2018 [12]).

이 옵션 값은 성공한 연결을 통해 보내어지는 연장된 확인 정보를 전송하는데 쓰입니다. 엄밀히 말하면 비연속적인 자료(데이터) 블록이 보내어지고 예약(큐잉)되었다는 신호를 자료 수신기가 전송기에 보낼 때 사용합니다. 자료 수신기(데이터 리시버)는 블록 간의 비워진 공간을 다 채우기 위해 재전송을 다 받을 때까지 기다립니다. 그 동안 자료 수신기는 자료를 알리고, 보통 남은 윈도 끝을 TCP 헤더 부분의 확인 번호 영역 안에서 이동합니다. 이는 SACK 옵션 값이 여전히 남은 윈도 끝 영역을 표시(예를 들어 전부 받은 자료의 마지막 순서 번호를 넘는 하나의 바이트)하는 확인 번호 영역을 바꾸지 않는다는 것을 이해하는데 중요하게 작용합니다.

If SACK has been negotiated (through an exchange of SACK- Permitted options), then this option may occur when dropped segments are noticed by the receiver.  Because this identifies ranges of blocks within the receiver's window, it can be viewed as a base value with a number of offsets.  The base value (left edge of the first block) can be viewed as offset from the TCP acknowledgement number.  There can be up to 4 SACK blocks in a single option.  SACK blocks may occur in a number of segments (if there is more out-of-order data 'on the wire'), and this will typically extend the size of or add to the existing blocks.

만약 SACK 이 변경(SACK-Permitted(허용) 옵션 값의 교환을 통해)되었다면 이 옵션 값은 수신기에 의해 빠진 세그먼트를 알리는데 쓰일 수 있습니다. 그 이유는 이 값은 수신자의 윈도우 내에 블록의 범위를 확인하고, 이동 좌표 번호의 기준으로 볼 수 있기 때문입니다. 이 값(첫 번째 블록의 왼쪽 끝)은 TCP 인지 번호의 기본 좌표로 볼 수 있습니다. 단일 옵션 값으로 4개의 SACK 블록이 구성될 수 있습니다. SACK 블록은 세그먼트의 개수(만약 더 많은 자료가 ‘동신 선상에서’ 존재할 때)에서 발생할 수 있습니다. 그리고 일반적으로 값이 더 길어 지거나 기존의 블록들을 추가합니다.

Alternative proposals such as DSACK RFC 2883 [17] do not fundamentally change the behavior of the SACK block, from the point of view of the information contained within it.

대안으로 제시되는 것이 DSACK RFC 2883인데 기본적인 SACK 블록 안에 담겨 있는 자료의 시각에서 값의 성격을 바꾸지는 않습니다. (기본적으로 동일)

      3: Window Scale Option (WSopt)

 3: 윈도우(창 – 패킷확인 절차 없이 한 번에 보낼 수 있는 패킷의 수) 크기 옵션 값(WSopt)

 This option may be sent in a SYN segment by the TCP end-host to indicate that the sending TCP end-host is prepared to perform both send and receive window scaling, and (2) to communicate a scale factor to be applied to its receive window.

 이 옵션 값은 SYN 세그먼트 부분에 실려져 상호 TCP 종단 호스트들 간에 보내고 받는 윈도우 크기를 정하고 수신받는 값의 윈도우 배율 값을 통신하는데 쓰입니다.

 The scale factor is encoded logarithmically as a power of 2 (presumably to be implemented by binary shifts).  Note that the window in the SYN segment itself is never scaled (RFC 1072 [4]).  This option may be sent in an initial segment (i.e., in a segment with the SYN bit on and the ACK bit off).  It may also be sent in later segments, but only if a Window Scale option was received in the initial segment.  A Window Scale option in a segment without a SYN bit should be ignored.  The Window field in a SYN segment itself is never scaled (RFC 1323 [7]).

 배율은 로그 비율로 2의 자승의 형태로 부호화 됩니다. (2진 시프트 연산자를 통해 구현생각 됩니다.). SYN 세그먼트에 있는 윈도우 자체는 변하지 않는다는 걸 확인하세요. (RFC 1072) 옵션 값은 처음 세그먼트에 보내어 질 수 있습니다. (예를 들어 SYN 비트에 이 값이 붙어진 채 세그먼트 속에 존재하고 ACK 비트가 빠지었으면). 또한, 이후 세그먼트 값에 붙여질 수 있지만, 처음 보낼 때 윈도우 변경 옵션 값이 보내어졌을 때 한합니다. SYN 비트에 붙여지지 않은 윈도우 비율 옵션 값은 무시되어야 합니다. 다시 말하지만 SYN 세그먼트에 정해진 윈도우 크기는 변하지 않습니다. (RFC 1323)

 The use of window scaling does not affect the encoding of any other field during the lifetime of the flow.  Only the encoding of the window scaling option itself is important.  The window scale must be between 0 and 14 (inclusive).  Generally, smaller values would be expected (a window scale of 14 allows for a 1Gbyte window, which is extremely large).

  윈도의 비 변환(스케일링) 사용으로 값이 전송되는 동안 어떠한 다른 영역을 부호화(인코딩)하는데 영향을 주어서는 안 됩니다. 윈도우비 변환 값 자체를 부호화하는 것이 중요합니다. 변환 비는 반드시 0부터 14 까지(포함)만 허용됩니다. 일반적으로 작은 값이 예상됩니다. (윈도우 비 14인 값은 아주 큰 1GB 윈도를 허용하게 합니다.)

      4: SACK-Permitted

 4: SACK – 허용

 This option may be sent in a SYN by a TCP that has been extended to receive (and presumably to process) the SACK option once the connection has opened RFC 2018 [12].  There is no data in this option all that is required is for the presence of the option to be encoded.

   이 옵션 값은 계속 받기(그리고 작업이 될 예정)로 된 TCP 에 의해 SYN 세그먼트 속에 포함될 수 있습니다. SACK 옵션 값은 (한번) RFC 2018로 공개 되었습니다. 부호화 되기 위한 조건이 있는 옵션 값이 없습니다.

      2: Maximum Segment Size

 2: 최대 세그먼트 크기(조각 사이즈)

 If this option is present, then it communicates the maximum segment size that may be used to send a packet to this end- host.  This field must only be sent in the initial connection request (i.e., in segments with the SYN control bit set).  If this option is not used, any segment size is allowed RFC 793 [2].

 이 옵션 값이 존재한다면, 종단-호스트들 간의 보낼 수 있는 패킷의 최대 세그먼트 크기 값을 나타냅니다. 이 영역은 처음 연결 요청 시에만 보내야 합니다(예를 들어 SYN 제어 비트가 켜져 있는 세그먼트). 이 옵션 값이 없다면 RFC 793 에 정의된 세그먼트 크기에 근거하에 보내어 집니다.

 This option is very common.  The segment size is a 16-bit quantity.  Theoretically, this could take any value; however there are a number of values that are common.  For example, 1460 bytes is very common for TCP/IPv4 over Ethernet (though with the increased prevalence of tunnels, for example, smaller values such as 1400 have become more popular). 536 bytes is the default MSS value.  This may allow for common values to be encoded more efficiently.

 이 옵션 값은 아주 보편적입니다. 이 세그먼트 크기 값은 16-비트 길이로 되어 있습니다. 이론적으로 이 값은 어떤 값을 취할 수 있습니다만 보편적으로 쓰이는 값들이 있습니다. 예를 들면 이더넷을 통하는 TCP/IPv4에는 1460바이트가 쓰입니다. (추가로 예를 들면 비록 터널의 증가가 되었지만 이런 곳에서는 1400바이트가 더 자주 쓰입니다.) 기본적으로 536바이트가 최대 세그먼트 크기(MSS)로 사용됩니다. 이 옵션 값은 부호화된 값을 더욱 효율적으로 보내는데 사용될 수 있습니다.

      1: No-Operation

 1: 작업-없음

 This option code may be used between options, for example, to align the beginning of a subsequent option on a word boundary. There is no guarantee that senders will use this option, so receivers must be prepared to process options even if they do not begin on a word boundary RFC 793 [2].  There is no data associated with this option, so a compression scheme must simply be able to encode its presence.  This may be done by noting that the option simply maintains a certain alignment and that compression need only convey this alignment.  In this way, padding can just be removed.

 이 옵션 값(코드)은 옵션 값들 사이에 사용될 수 있습니다. 예를 들어 단어 경계(워드 바운더리) 사이 이후의 옵션 값을 맞추는데 시작 값으로 넣을 수 있습니다. 보내는 사람(송신자)이 이 옵션 값을 쓸 수 있으니깐 받는 사람(수신자)은 RFC 793 에 표시된 단어 경계를 시작 값이 없는 송신을 받을 준비를 해야 합니다.

4.3.2. Option Field Behavior

4.3.2 옵션 영역(필드) 성격

Generally speaking, all option fields have been classified as changing. This section describes the behavior of each option referenced within an RFC, listed by 'kind' indicator.

일반적으로 말해 모든 설정 영역(옵션 필드)은 변화에 따라 분류됩니다. 이 절에서는 각 RFC 에 참조되어 어떤 '성질'에 의해 분류된 옵션을 설명합니다.

0: End of Option List

0: 옵션 목록(옵션 리스트)의 끝

This option code indicates the end of the option list. This might not coincide with the end of the TCP header according to the Data Offset field. This is used at the end of all options, not at the end of each option, and it need only be used if the end of the options would not otherwise coincide with the end of the TCP header. Defined in RFC 793 [2].

이 옵션 번호(코드)는 옵션 목록의 끝이라는 것을 표시합니다. 이건 데이터 오프셋 영역에 따른 TCP 헤더의 끝과 일치하지 않을 수 있습니다. 이 값은 모든 옵션 값의 끝 부분에 사용되며, 각 옵션 값들의 끝은 아니고 TCP 헤더가 끝 부분과 관련이 없을 때 끝을 표시하는 데에 필요합니다. RFC 793 에 정의되어 있습니다.

There is no data associated with this option, so a compression scheme must simply be able to encode its presence. However, note that since this option marks the end of the list and the TCP options are 4-octet aligned, there may be octets of padding (defined to be '0' in [2]) after this option.

이 옵션 값에는 어떠한 (전송과 관련된) 데이터 값이 연관되어 있지 않습니다. 그러니 그 존재만으로 구별될 수 있게 간편하게 부호화시켜야 합니다. 하지만 이 값이 목록의 마지막을 표시하고 TCP 옵션 값이 4비트로 맞춰 있다면 이 옵션 값 뒤에 8진수의 끼워 넣어 맞추는 부분이 필요합니다.