[要約] RFC 8507は、Simple Internet Protocol (SIP) の仕様を定義しています。このRFCの目的は、SIPを使用してネットワーク上でのリアルタイム通信を容易にするための標準化を提供することです。
Independent Submission S. Deering
Request for Comments: 8507 Retired
Category: Historic R. Hinden, Ed.
ISSN: 2070-1721 Check Point Software
December 2018
Simple Internet Protocol (SIP) Specification
Simple Internet Protocol（SIP）仕様
Abstract
概要
This document is published for the historical record. The Simple Internet Protocol was the basis for one of the candidates for the IETF's Next Generation (IPng) work that became IPv6.
このドキュメントは、歴史的記録のために公開されています。 Simple Internet Protocolは、IPv6になったIETFの次世代（IPng）作業の候補の1つの基礎でした。
The publication date of the original Internet-Draft was November 10, 1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable.
元のインターネットドラフトの発行日は1992年11月10日でした。これはここでは実質的に変更されずに提示されており、完全なドキュメントではなく、実装可能であるようにも意図されていません。
The paragraph that follows is the Abstract from the original draft.
次の段落は、元のドラフトの要約です。
This document specifies a new version of IP called SIP, the Simple Internet Protocol. It also describes the changes needed to ICMP, IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast.
このドキュメントでは、SIP（Simple Internet Protocol）と呼ばれる新しいバージョンのIPを指定しています。また、SIPと連携するために、ICMP、IGMP、およびTCPやUDPなどのトランスポートプロトコルに必要な変更についても説明します。関連ドキュメント[SIP-ADDR]では、自動構成、ホストとサブネットのモビリティ、およびマルチキャストの問題を含む、SIPのアドレッシングとルーティングの側面について説明しています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントはInternet Standards Trackの仕様ではありません。歴史的な記録として掲載されています。
This document defines a Historic Document for the Internet community. 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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc8507.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8507で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Preface .........................................................3
2. Introduction ....................................................3
3. Terminology .....................................................4
4. SIP Header Format ...............................................5
5. Addresses .......................................................6
5.1. Text Representation of Addresses ...........................6
5.2. Unicast Addresses ..........................................6
5.3. Multicast Addresses ........................................8
5.4. Special Addresses ..........................................9
6. Packet Size Issues .............................................12
7. Source Routing Header ..........................................13
8. Fragmentation Header ...........................................14
9. Changes to Other Protocols .....................................16
9.1. Changes to ICMP ...........................................16
9.2. Changes to IGMP ...........................................20
9.3. Changes to Transport Protocols ............................21
9.4. Changes to Link-Layer Protocols ...........................22
10. Security Considerations .......................................22
11. Acknowledgments ...............................................23
12. Informative References ........................................23
Appendix A. SIP Design Rationale ..................................25
Appendix B. Future Directions .....................................25
Authors' Addresses ................................................26
This document is published for the historical record.
このドキュメントは、歴史的記録のために公開されています。
Simple IP (SIP) was the basis for one of the candidates for the IETF's Next Generation (IPng) work; see "The Recommendation for the IP Next Generation Protocol" [RFC1752]. The original 1992 Internet-Draft describing SIP is published here as part of the record of that work.
シンプルIP（SIP）は、IETFの次世代（IPng）作業の候補の1つの基礎でした。 「IP次世代プロトコルの推奨事項」[RFC1752]を参照してください。 SIPを説明する最初の1992年のインターネットドラフトは、その作業の記録の一部としてここに公開されています。
SIP evolved into SIP Plus [RFC1710], which was assessed as a candidate for IPng [RFC1752] and led eventually to the development of IPv6, first published as [RFC1883]. The current specification for IPv6 is [RFC8200].
SIPはSIP Plus [RFC1710]に進化し、IPng [RFC1752]の候補として評価され、最終的に[RFC1883]として公開されたIPv6の開発につながりました。 IPv6の現在の仕様は[RFC8200]です。
The original Internet-Draft describing the Simple Internet Protocol was written by Steve Deering, and the Internet-Draft was posted on November 10, 1992. The contents of this document are unchanged from that Internet-Draft, except for clarifications in the Abstract, the addition of this section, modifications to the authors' information, the updating of references, removal of the IANA considerations, and minor formatting changes.
Simple Internet Protocolを説明するオリジナルのインターネットドラフトはSteve Deeringによって作成され、インターネットドラフトは1992年11月10日に投稿されました。このドキュメントの内容は、要約の明確化を除いて、そのインターネットドラフトから変更されていません。このセクションの追加、作成者の情報の変更、参照の更新、IANAの考慮事項の削除、および書式の小さな変更。
It should be noted that the original draft was not complete and that no attempt has been made to complete it. This document is not intended to be implementable.
元のドラフトは完全ではなく、それを完成させる試みは行われていないことに注意してください。このドキュメントは実装可能であるように意図されていません。
SIP is a new version of IP. Its salient differences from IP version 4 [RFC791], subsequently referred to as "IPv4", are:
SIPはIPの新しいバージョンです。後に「IPv4」と呼ばれるIPバージョン4 [RFC791]との主な違いは次のとおりです。
o expansion of addresses to 64 bits,
o アドレスの64ビットへの拡張
o simplification of the IP header by eliminating some inessential fields, and
o 重要でないフィールドを削除することによるIPヘッダーの簡素化、および
o relaxation of length restrictions on optional data, such as source-routing information.
o ソースルーティング情報などのオプションデータの長さ制限の緩和。
SIP retains the IP model of globally-unique addresses, hierarchically-structured for efficient routing. Increasing the address size from 32 to 64 bits allows more levels of hierarchy to be encoded in the addresses, enough to enable efficient routing in an internet with tens of thousands of addressable devices in every office, every residence, and every vehicle in the world. Keeping the addresses fixed-length and relatively compact facilitates high-performance router and host implementation, and keeps the bandwidth overhead of the SIP headers almost as low as IPv4.
SIPは効率的なルーティングのために階層的に構造化された、グローバルに一意のアドレスのIPモデルを保持します。アドレスサイズを32ビットから64ビットに増やすと、より多くのレベルの階層をアドレスにエンコードできるようになり、世界中のすべてのオフィス、住居、およびすべての車両に数万のアドレス指定可能なデバイスを備えたインターネットで効率的なルーティングが可能になります。アドレスを固定長で比較的コンパクトに保つと、高性能のルーターとホストの実装が容易になり、SIPヘッダーの帯域幅オーバーヘッドをIPv4と同じくらい低く保つことができます。
The elimination of inessential fields also contributes to high-performance implementation, and to the likelihood of correct implementation. A change in the way that optional data, such as source-routing information, is encoded allows for more efficient forwarding and less stringent limits on the length of such data.
重要でないフィールドの排除は、高性能の実装、および正しい実装の可能性にも貢献します。ソースルーティング情報などのオプションのデータがエンコードされる方法が変更されたため、転送がより効率的になり、そのようなデータの長さの制限が緩和されました。
Despite these changes, SIP remains very similar to IPv4. This similarity makes it easy to understand SIP (for those who already understand IPv4), makes it possible to reuse much of the code and data structures from IPv4 in an implementation of SIP (including almost all of ICMP and IGMP), and makes it straightforward to translate between SIP packets and IPv4 packets for transition purposes [IPAE].
これらの変更にもかかわらず、SIPはIPv4と非常によく似ています。この類似性により、SIP（IPv4を既に理解している人）を理解しやすくなり、SIP（ほとんどすべてのICMPとIGMPを含む）の実装でIPv4のコードとデータ構造の多くを再利用でき、簡単になります。移行目的でSIPパケットとIPv4パケットを変換する方法[IPAE]。
The subsequent sections of this document specify SIP and its associated protocols without much explanation of why the design choices were made the way they were. Appendix A presents the rationale for those aspects of SIP that differ from IPv4.
このドキュメントの後続のセクションでは、SIPとそれに関連するプロトコルを指定しますが、なぜ設計の選択がそのように行われたのかについてはあまり説明しません。付録Aは、IPv4とは異なるSIPの側面の根拠を示しています。
system - a device that implements SIP.
システム-SIPを実装するデバイス。
router - a system that forwards SIP packets.
ルーター-SIPパケットを転送するシステム。
host - any system that is not a router.
ホスト-ルーターではないシステム。
link - a communication facility or medium over which systems can communicate at the link layer, i.e., the layer immediately below SIP.
リンク-システムがリンク層、つまりSIPのすぐ下の層で通信できる通信設備または媒体。
interface - a system's attachment point to a link.
インターフェース-システムのリンクへの接続点。
address - a SIP-layer identifier for an interface or a group of interfaces.
address-インターフェースまたはインターフェースのグループのSIPレイヤー識別子。
subnet - in the SIP unicast addressing hierarchy, a lowest-level (finest-grain) cluster of addresses, sharing a common address prefix (i.e., high-order address bits). Typically, all interfaces attached to the same link have addresses in the same subnet; however, in some cases, a single link may support more than one subnet, or a single subnet may span more than one link.
サブネット-SIPユニキャストアドレッシング階層において、共通のアドレスプレフィックス（つまり、上位アドレスビット）を共有する、最低レベル（細粒度）のアドレスのクラスター。通常、同じリンクに接続されているすべてのインターフェースには、同じサブネット内のアドレスがあります。ただし、場合によっては、単一のリンクが複数のサブネットをサポートすることや、単一のサブネットが複数のリンクにまたがることがあります。
link MTU - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed in one piece over a link (where a packet is a SIP header plus payload).
リンクMTU-リンク（パケットはSIPヘッダーとペイロード）で1つにまとめて伝送できる最大伝送単位（オクテット単位の最大パケットサイズ）。
path MTU - the minimum link MTU of all the links in a path between a source system and a destination system.
パスMTU-ソースシステムと宛先システム間のパス内のすべてのリンクの最小リンクMTU。
packetization layer - any protocol layer above SIP that is responsible for packetizing data to fit within outgoing SIP packets. Typically, transport-layer protocols, such as TCP, are packetization protocols, but there may also be higher-layer packetization protocols, such as protocols implemented on top of UDP.
パケット化層-データをパケット化して発信SIPパケット内に収めるSIP上のプロトコル層。通常、TCPなどのトランスポート層プロトコルはパケット化プロトコルですが、UDPの上に実装されたプロトコルなど、上位層のパケット化プロトコルも存在する場合があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Payload Type | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version 4-bit IP version number = decimal 6. <to be confirmed>
バージョン4ビットIPバージョン番号= 10進数6。<未確認>
Reserved 28-bit reserved field. Initialized to zero for transmission; ignored on reception.
予約済みの28ビット予約フィールド。送信用にゼロに初期化されました。受信時には無視されます。
Payload Length 16-bit unsigned integer. Length of payload, i.e., the rest of the packet following the SIP header, in octets.
ペイロード長16ビット符号なし整数。ペイロードの長さ、つまり、SIPヘッダーに続くパケットの残りの部分（オクテット単位）。
Payload Type 8-bit selector. Identifies the type of payload, e.g., TCP.
ペイロードタイプ8ビットセレクタ。ペイロードのタイプ（TCPなど）を識別します。
Hop Limit 8-bit unsigned integer. Decremented by 1 by each system that forwards the packet. The packet is discarded if Hop Limit is decremented to zero.
ホップ制限8ビットの符号なし整数。パケットを転送するシステムごとに1ずつ減ります。ホップ制限がゼロにデクリメントされると、パケットは破棄されます。
Source Address 64 bits. See "Addresses" section, following.
送信元アドレス64ビット。以下の「アドレス」セクションを参照してください。
Destination Address 64 bits. See "Addresses" section, following.
宛先アドレス64ビット。以下の「アドレス」セクションを参照してください。
SIP addresses are 64 bits (8 octets) long. The text representation of a SIP addresses is 16 hexadecimal digits, with a colon between the 4th and 5th digits, and optional colons between any subsequent pair of digits. Leading zeros must not be dropped. Examples:
SIPアドレスは64ビット（8オクテット）の長さです。 SIPアドレスのテキスト表現は16桁の16進数で、4桁目と5桁目の間にコロンがあり、その後の数字のペアの間にはオプションのコロンがあります。先頭のゼロは削除しないでください。例：
0123:4567:89AB:CDEF
0123:456789ABCDEF
0123：456789 ABSDev
0123:456789AB:CDE:F
Programs that read the text representation of SIP addresses must be insensitive to the presence or absence of optional colons. Programs that write the text representation of a SIP address should use the first format above (i.e., colons after the 4th, 8th, and 12th digits), in the absence of any knowledge of the structure or preferred format of the address, such as knowledge of the format in which it was originally read.
SIPアドレスのテキスト表現を読み取るプログラムは、オプションのコロンの有無に影響されないようにする必要があります。 SIPアドレスのテキスト表現を書き込むプログラムは、知識などのアドレスの構造または優先フォーマットの知識がない場合、上記の最初のフォーマット（つまり、4、8、および12桁目以降のコロン）を使用する必要があります。最初に読み取られた形式の
The presence of at least one colon in the text representation allows SIP addresses to be easily distinguished from both domain names and the text representation of IPv4 addresses.
テキスト表現に少なくとも1つのコロンがあると、SIPアドレスをドメイン名とIPv4アドレスのテキスト表現の両方から簡単に区別できます。
A SIP unicast address is a globally-unique identifier for a single interface, i.e., no two interfaces in a SIP internet may have the same unicast address. A single interface may, however, have more than one unicast address.
SIPユニキャストアドレスは、単一のインターフェースのグローバルに一意の識別子です。つまり、SIPインターネットの2つのインターフェースが同じユニキャストアドレスを持つことはできません。ただし、単一のインターフェイスに複数のユニキャストアドレスが含まれる場合があります。
A system considers its own unicast address(es) to have the following structure, where different addresses may have different values for n:
システムは、独自のユニキャストアドレスを次の構造であると見なします。ここで、アドレスが異なるとnの値が異なる場合があります。
| n bits | 64-n bits |
+----------------------------------------------------+------------+
| subnet prefix |interface ID|
+----------------------------------------------------+------------+
To know the length of the subnet prefix, the system is required to associate with each of its addresses a 'subnet mask' of the following form:
サブネットプレフィックスの長さを知るには、システムはそのアドレスのそれぞれに次の形式の「サブネットマスク」を関連付ける必要があります。
| n bits | 64-n bits |
+----------------------------------------------------+------------+
|1111111111111111111111111111111111111111111111111111|000000000000|
+----------------------------------------------------+------------+
A system may have a subnet mask of all-ones, which means that the system belongs to a subnet containing exactly one system -- itself.
システムには、すべて1のサブネットマスクがある場合があります。つまり、システムは、1つのシステム自体を含むサブネットに属しています。
A system acquires its subnet mask(s) at the same time, and by the same mechanism, as it acquires its address(es), for example, by manual configuration or by a dynamic configuration protocol such as BOOTP [RFC951].
システムは、たとえば手動構成やBOOTP [RFC951]などの動的構成プロトコルによってアドレスを取得するのと同じメカニズムで、同時にサブネットマスクを取得します。
Hosts are ignorant of any further structure in a unicast address.
ホストは、ユニキャストアドレスのそれ以上の構造を無視します。
Routers may acquire, through manual configuration or the operation of routing protocols, additional masks that identify higher-level clusters in a hierarchical addressing plan. For example, the routers within a single site would typically have a 'site mask', such as the following:
ルーターは、手動構成またはルーティングプロトコルの操作を通じて、階層型アドレス指定計画でより高いレベルのクラスターを識別する追加のマスクを取得できます。たとえば、単一のサイト内のルーターには通常、次のような「サイトマスク」があります。
| m bits | 64-m bits |
+-----------------------------------------+-----------------------+
|11111111111111111111111111111111111111111|00000000000000000000000|
+-----------------------------------------+-----------------------+
by which they could deduce the following structure in the site's addresses:
これにより、サイトのアドレスで次の構造を推測できます。
| m bits | p bits | 64-m-p bits|
+-----------------------------------------+----------+------------+
| site prefix |subnet ID|interface ID|
+-----------------------------------------+----------+------------+
All knowledge by SIP systems of the structure of unicast addresses is based on possession of such masks -- there is no "wired-in" knowledge of unicast address formats.
ユニキャストアドレスの構造に関するSIPシステムによるすべての知識は、そのようなマスクの所有に基づいています。ユニキャストアドレス形式の「有線」知識はありません。
The SIP Addressing and Routing document [SIP-ADDR] proposes two hierarchical addressing plans, one based on a hierarchy of SIP service providers, and one based on a geographic hierarchy.
SIPアドレッシングとルーティングのドキュメント[SIP-ADDR]は、2つの階層型アドレッシングプランを提案しています。1つはSIPサービスプロバイダーの階層に基づいており、もう1つは地理的階層に基づいています。
A SIP multicast address is an identifier for a group of interfaces. An interface may belong to any number of multicast groups. Multicast addresses have the following format:
SIPマルチキャストアドレスは、インターフェイスのグループの識別子です。インターフェイスは、任意の数のマルチキャストグループに属することができます。マルチキャストアドレスの形式は次のとおりです。
|1| 7 | 4 | 4 | 48 bits |
+-+-------+----+----+---------------------------------------------+
|C|1111111|flgs|scop| group ID |
+-+-------+----+----+---------------------------------------------+
where:
ただし：
C = IPv4 compatibility flag; see [IPAE].
C = IPv4互換性フラグ。 [IPAE]を参照してください。
1111111 in the rest of the first octet identifies the address as being a multicast address.
最初のオクテットの残りの1111111は、アドレスをマルチキャストアドレスとして識別します。
+-+-+-+-+
flgs is a set of 4 flags: |0|0|0|T|
+-+-+-+-+
the high-order 3 flags are reserved, and must be initialized to 0.
高位3フラグは予約されており、0に初期化する必要があります。
T = 0 indicates a permanently-assigned ("well-known") multicast address, assigned by the global internet numbering authority.
T = 0は、グローバルインターネット番号付け機関によって割り当てられた、永続的に割り当てられた（「既知の」）マルチキャストアドレスを示します。
T = 1 indicates a non-permanently-assigned ("transient") multicast address.
T = 1は、永続的に割り当てられていない（「一時的な」）マルチキャストアドレスを示します。
scop is a 4-bit multicast scope value:
scopは4ビットのマルチキャストスコープ値です。
0 reserved 1 intra-system scope 2 intra-link scope 3 (unassigned) 4 (unassigned) 5 intra-site scope 6 (unassigned) 7 (unassigned) 8 intra-metro scope 9 (unassigned) A (unassigned) B intra-country scope C (unassigned) D (unassigned) E global scope F reserved
0予約済み1システム内スコープ2イントラリンクスコープ3（未割り当て）4（未割り当て）5サイト内スコープ6（未割り当て）7（未割り当て）8メトロ内スコープ9（未割り当て）A（未割り当て）B国内スコープC（未割り当て）D（未割り当て）EグローバルスコープF予約済み
group ID identifies the multicast group, either permanent or transient, within the given scope.
グループIDは、指定されたスコープ内の永続的または一時的なマルチキャストグループを識別します。
The "meaning" of a permanently-assigned multicast address is independent of the scope value. For example, if the "NTP servers group" is assigned a permanent multicast address with a group ID of 43 (hex), then:
永続的に割り当てられたマルチキャストアドレスの「意味」は、スコープ値とは無関係です。たとえば、「NTPサーバーグループ」にグループID 43（16進数）の永続的なマルチキャストアドレスが割り当てられている場合、次のようになります。
7F01:000000000043 means all NTP servers on the same system as the sender.
7F01：000000000043は、送信者と同じシステム上のすべてのNTPサーバーを意味します。
7F02:000000000043 means all NTP servers on the same link as the sender.
7F02：000000000043は、送信者と同じリンク上のすべてのNTPサーバーを意味します。
7F05:000000000043 means all NTP servers at the same site as the sender.
7F05：000000000043は、送信者と同じサイトにあるすべてのNTPサーバーを意味します。
7F0E:000000000043 means all NTP servers in the internet.
7F0E：000000000043は、インターネット内のすべてのNTPサーバーを意味します。
Non-permanently-assigned multicast addresses are meaningful only within a given scope. For example, a group identified by the non-permanent, intra-site multicast address 7F15:000000000043 at one site bears no relationship to a group using the same address at a different site, nor to a non-permanent group using the same group ID with different scope, nor to a permanent group with the same group ID.
永続的に割り当てられていないマルチキャストアドレスは、特定のスコープ内でのみ意味があります。たとえば、あるサイトの非永続的なサイト内マルチキャストアドレス7F15：000000000043で識別されるグループは、別のサイトの同じアドレスを使用するグループや、同じグループIDを使用する非永続的なグループとは関係ありません。スコープが異なり、同じグループIDを持つ永続的なグループにも適用されません。
There are a number of "special purpose" SIP addresses:
「特別な目的」のSIPアドレスは多数あります。
The Unspecified Address: 0000:0000:0000:0000
This address shall never be assigned to any system. It may be used wherever an address appears, to indicate the absence of an address. One example of its use is in the Source Address field of a SIP packet sent by an initializing host, before it has learned its own address.
このアドレスは、どのシステムにも割り当てられません。アドレスが存在しない場所を示すために、アドレスが現れる場所であればどこでも使用できます。その使用例の1つは、初期化ホストが自身のアドレスを学習する前に、初期化ホストによって送信されたSIPパケットのソースアドレスフィールドにあります。
The Loopback Address: 0000:0000:0000:0001
This address may be used by a system to send a SIP packet to itself.
このアドレスは、システムがSIPパケットをそれ自体に送信するために使用できます。
Anyone Addresses: <prefix><zero>
Addresses of this form may be used to send to the "nearest" system (according the routing protocols' measure of distance) that "knows" it has a unicast address prefix of <prefix>.
この形式のアドレスは、（ルーティングプロトコルの距離の測定に従って）<プレフィックス>のユニキャストアドレスプレフィックスを「知っている」ことを「最も近い」システムに送信するために使用できます。
Since hosts know only their subnet prefix(es), and no higher-level prefixes, a host with the following address:
ホストはサブネットプレフィックスのみを認識し、上位レベルのプレフィックスは認識しないため、次のアドレスを持つホスト：
+----------------------------------------------+----------------+
| subnet prefix = A |interface ID = B|
+----------------------------------------------+----------------+
shall recognize only the following Anyone address as identifying itself:
自分自身を識別するものとして、次のAnyoneアドレスのみを認識します。
+----------------------------------------------+----------------+
| subnet prefix = A |0000000000000000|
+----------------------------------------------+----------------+
An intra-site router that knows that one of its addresses has the format:
そのアドレスの1つが次の形式であることを知っているサイト内ルーター：
+-------------------------------+--------------+----------------+
| site prefix = X |subnet ID = Y|interface ID = Z|
+-------------------------------+--------------+----------------+
shall accept packets sent to either of the following two Anyone addresses as if they had been sent to the router's own address:
次の2つのAnyoneアドレスのいずれかに送信されたパケットを、ルーター自体のアドレスに送信されたかのように受け入れます。
+-------------------------------+-------------------------------+
| site prefix = X |0000000000000000000000000000000|
+-------------------------------+-------------------------------+
+-------------------------------+--------------+----------------+
| site prefix = X |subnet ID = Y|0000000000000000|
+-------------------------------+--------------+----------------+
Anyone Addresses work as follows:
誰でもアドレスは次のように機能します。
If any system belonging to subnet A sends a packet to subnet A's Anyone address, the packet shall be looped-back within the sending system itself, since it is the nearest system to itself with the subnet A prefix. If a system outside of subnet A sends a packet to subnet A's Anyone address, the packet shall be accepted by the first router on subnet A that the packet reaches.
サブネットAに属するシステムがパケットをサブネットAのAnyoneアドレスに送信する場合、パケットはサブネットAの接頭辞を持つそれ自体に最も近いシステムであるため、送信システム自体内でループバックされます。サブネットAの外部のシステムがパケットをサブネットAのAnyoneアドレスに送信する場合、パケットは、パケットが到達するサブネットAの最初のルーターによって受け入れられます。
Similarly, a packet sent to site X's Anyone address from outside of site X shall be accepted by the first encountered router belonging to site X, i.e., one of site X's boundary routers. If a higher-level prefix P identifies, say, a particular service provider, then a packet sent to <P> <zero> from outside of provider P's facilities shall be delivered to the nearest entry router into P's facilities.
同様に、サイトXの外部からサイトXのAnyoneアドレスに送信されたパケットは、サイトXに属する最初に遭遇したルーター、つまりサイトXの境界ルーターの1つによって受け入れられます。上位レベルのプレフィックスPが特定のサービスプロバイダーを識別する場合、プロバイダーPの施設外から<P> <ゼロ>に送信されたパケットは、Pの施設内の最も近いエントリルーターに配信されます。
Anyone addresses are most commonly used in conjunction with the SIP source routing header, to cause a packet to be routed via one or more specified "transit domains", without the need to identify individual routers in those domains.
誰でもアドレスが最もよく使用されるのは、SIPソースルーティングヘッダーと組み合わせて、ドメイン内の個々のルーターを識別する必要なく、1つ以上の指定された "中継ドメイン"経由でパケットをルーティングすることです。
The value zero is reserved at each level of every unicast address hierarchy, to serve as an Anyone address for that level.
値0は、すべてのユニキャストアドレス階層の各レベルで予約され、そのレベルのAnyoneアドレスとして機能します。
The Reserved Multicast Address: 7F0s:0000:0000:0000
This multicast address (with any scope value, s) is reserved, and shall never be assigned to any multicast group.
このマルチキャストアドレス（スコープ値sを含む）は予約されており、マルチキャストグループに割り当てられません。
The All Systems Addresses: 7F01:0000:0000:0001
7F02:0000:0000:0001
These multicast addresses identify the group of all SIP systems, within scope 1 (intra-system) or 2 (intra-link).
これらのマルチキャストアドレスは、スコープ1（システム内）または2（リンク内）内のすべてのSIPシステムのグループを識別します。
The All Hosts Addresses: 7F01:0000:0000:0002
7F02:0000:0000:0002
These multicast addresses identify the group of all SIP hosts, within scope 1 (intra-system) or 2 (intra-link).
これらのマルチキャストアドレスは、スコープ1（システム内）または2（リンク内）内のすべてのSIPホストのグループを識別します。
The All Routers Addresses: 7F01:0000:0000:0003
7F02:0000:0000:0003
These multicast addresses identify the group of all SIP routers, within scope 1 (intra-system) or 2 (intra-link).
これらのマルチキャストアドレスは、スコープ1（システム内）または2（リンク内）内のすべてのSIPルーターのグループを識別します。
A host is required to recognize the following addresses as identifying itself: its own unicast addresses, the Anyone addresses with the same subnet prefixes as its unicast addresses, the Loopback address, the All Systems and All Hosts addresses, and any other multicast addresses to which the host belongs.
ホストは、自身を識別するものとして次のアドレスを認識する必要があります：自身のユニキャストアドレス、ユニキャストアドレスと同じサブネットプレフィックスを持つAnyoneアドレス、ループバックアドレス、すべてのシステムとすべてのホストアドレス、およびその他のマルチキャストアドレスホストが属しています。
A router is required to recognize the following addresses as identifying itself: its own unicast addresses, the Anyone addresses with the same subnet or higher-level prefixes as its unicast addresses, the Loopback address, the All Systems and All Routers addresses, and any other multicast addresses to which the host belongs.
ルーターは、自身を識別するものとして次のアドレスを認識する必要があります：自身のユニキャストアドレス、ユニキャストアドレスと同じサブネットまたは上位レベルのプレフィックスを持つAnyoneアドレス、ループバックアドレス、すべてのシステムおよびすべてのルーターアドレス、その他ホストが属するマルチキャストアドレス。
SIP requires that every link in the internet have an MTU of 576 octets or greater. On any link that cannot convey a 576-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below SIP.
SIPでは、インターネットのすべてのリンクのMTUが576オクテット以上である必要があります。 576オクテットのパケットを1つにまとめて送信できないリンクでは、リンク固有のフラグメンテーションと再構成をSIPの下のレイヤーで提供する必要があります。
(Note: this minimum link MTU is NOT the same as the one in IPv4. In IPv4, the minimum link MTU is 68 octets [ [RFC791], page 25 ]; 576 octets is the minimum reassembly buffer size required in an IPv4 system, which has nothing to do with link MTUs.)
（注：この最小リンクMTUはIPv4のものとは異なります。IPv4では、最小リンクMTUは68オクテット[[RFC791]、page 25]です。576オクテットはIPv4システムで必要な最小再構成バッファーサイズです。これはリンクMTUとは関係ありません。）
From each link to which a system is directly attached, the system must be able to accept packets as large as that link's MTU. Links that have a configurable MTU, such as PPP links [RFC1661], should be configured with an MTU of 600 octets or greater.
システムが直接接続されている各リンクから、システムはそのリンクのMTUと同じ大きさのパケットを受け入れることができる必要があります。 PPPリンク[RFC1661]などの構成可能なMTUを持つリンクは、600オクテット以上のMTUで構成する必要があります。
SIP systems are expected to implement Path MTU Discovery [RFC1191], in order to discover and take advantage of paths with MTU greater than 576 octets. However, a minimal SIP implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 576 octets, and omit implementation of Path MTU Discovery.
SIPシステムは、MTUが576オクテットを超えるパスを検出して利用するために、Path MTU Discovery [RFC1191]を実装することが期待されています。ただし、最小限のSIP実装（たとえば、ブートROM内）では、送信するパケットを576オクテット以下に制限するだけで、パスMTUディスカバリの実装を省略できます。
Path MTU Discovery requires support both in the SIP layer and in the packetization layers. A system that supports Path MTU Discovery at the SIP layer may serve packetization layers that are unable to adapt to changes of the path MTU. Such packetization layers must limit themselves to sending packets no longer than 576 octets, even when sending to destinations that belong to the same subnet.
パスMTUディスカバリーでは、SIPレイヤーとパケット化レイヤーの両方でのサポートが必要です。 SIPレイヤーでパスMTUディスカバリーをサポートするシステムは、パスMTUの変更に適応できないパケット化レイヤーを提供する場合があります。このようなパケット化レイヤーは、同じサブネットに属する宛先に送信する場合でも、送信するパケットが576オクテット以下に制限される必要があります。
(Note: Unlike IPv4, it is unnecessary in SIP to set a "Don't Fragment" flag in the packet header in order to perform Path MTU Discovery; that is an implicit attribute of every SIP packet. Also, those parts of the RFC-1191 procedures that involve use of a table of MTU "plateaus" do not apply to SIP, because the SIP version of the "Datagram Too Big" message always identifies the exact MTU to be used.)
（注：IPv4とは異なり、SIPでは、すべてのSIPパケットの暗黙的な属性であるパスMTUディスカバリーを実行するためにパケットヘッダーに「Do n't Fragment」フラグを設定する必要はありません。また、RFCのこれらの部分MTU「プラトー」のテーブルの使用を伴う-1191手順は、「データグラムが大きすぎます」メッセージのSIPバージョンが常に使用する正確なMTUを識別するため、SIPには適用されません。
A Payload Type of <TBD> in the immediately preceding header indicates the presence of this Source Routing header:
直前のヘッダーのペイロードタイプ<TBD>は、このソースルーティングヘッダーの存在を示します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs | Next Addr | Payload Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Address[0] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Address[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Address[Num Addrs - 1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved Initialized to zero for transmission; ignored on reception.
送信用にゼロに初期化されています。受信時には無視されます。
Num Addrs Number of addresses in the Source Routing header.
Num Addrsソースルーティングヘッダーのアドレス数。
Next Addr Index of next address to be processed; initialized to 0 by the originating system.
処理される次のアドレスのNext Addrインデックス。元のシステムによって0に初期化されます。
Payload Type Identifies the type of payload following the Source Routing header.
ペイロードタイプソースルーティングヘッダーに続くペイロードのタイプを識別します。
A Source Routing header is not examined or processed until it reaches the system identified in the Destination Address field of the SIP header. In that system, dispatching on the Payload Type of the SIP (or subsequent) header causes the Source Routing module to be invoked, which performs the following algorithm:
ソースルーティングヘッダーは、SIPヘッダーの宛先アドレスフィールドで識別されるシステムに到達するまで、検査または処理されません。そのシステムでは、SIP（または後続の）ヘッダーのペイロードタイプでディスパッチすると、次のアルゴリズムを実行するソースルーティングモジュールが呼び出されます。
o If Next Addr < Num Addrs, swap the SIP Destination Address and Address[Next Addr], increment Next Addr by one, and re-submit the packet to the SIP module for forwarding to the next destination.
o Next Addr <Num Addrsの場合は、SIP Destination AddressとAddress [Next Addr]を入れ替え、Next Addrを1つ増やし、パケットをSIPモジュールに再送信して、次の宛先に転送します。
o If Next Addr = Num Addrs, dispatch to the local protocol module identified by the Payload Type field in the Source Routing header.
o Next Addr = Num Addrsの場合、Source RoutingヘッダーのPayload Typeフィールドで識別されるローカルプロトコルモジュールにディスパッチします。
o If Next Addr > Num Addrs, send an ICMP Parameter Problem message to the Source Address, pointing to the Num Addrs field.
o [次のアドレス]> [番号アドレス]の場合、[Num Address]フィールドをポイントして、ソースアドレスにICMPパラメータ問題メッセージを送信します。
A Payload Type of <TBD> in the immediately preceding header indicates the presence of this Fragmentation header:
直前のヘッダーのペイロードタイプ<TBD>は、このFragmentationヘッダーの存在を示しています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 M| Fragment Offset | Payload Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Identification A value that changes on each packet sent with the same Source Address, Destination Address, and preceding Payload Type.
識別同じ送信元アドレス、送信先アドレス、および先行するペイロードタイプで送信された各パケットで変化する値。
M flag 1 = more fragments; 0 = last fragment.
Mフラグ1 =その他のフラグメント。 0 =最後のフラグメント。
Fragment Offset The offset, in 8-octet chunks, of the following payload, relative to the original, unfragmented payload.
フラグメントオフセット元のフラグメント化されていないペイロードに対する、次のペイロードのオフセット（8オクテットチャンク単位）。
Payload Type Identifies the type of payload following the Fragmentation header.
ペイロードタイプフラグメンテーションヘッダーに続くペイロードのタイプを識別します。
Reserved Initialized to zero for transmission; ignored on reception.
送信用にゼロに初期化されています。受信時には無視されます。
The Fragmentation header is NOT intended to support general, SIP-layer fragmentation. In particular, SIP routers shall not fragment a SIP packet that is too big for the MTU of its next hop, except in the special cases described below; in the normal case, such a packet results in an ICMP Packet Too Big message being sent back to its source, for use by the source system's Path MTU Discovery algorithm.
Fragmentationヘッダーは、一般的なSIP層のフラグメンテーションをサポートすることを目的としていません。特に、SIPルーターは、次の特別な場合を除いて、ネクストホップのMTUに対して大きすぎるSIPパケットをフラグメント化しないでください。通常の場合、このようなパケットは、ソースシステムのパスMTU検出アルゴリズムで使用するために、ICMPパケットが大きすぎるというメッセージをソースに送り返します。
The special cases for which the Fragmentation header is intended are the following:
Fragmentationヘッダーが意図されている特殊なケースは次のとおりです。
o A SIP packet that is "tunneled", either by encapsulation within another SIP packet or by insertion of a Source Routing header en-route, may, after the addition of the extra header fields, exceed the MTU of the tunnel's path; if the original packet is 576 octets or less in length, the tunnel entry system cannot respond to the source with a Packet Too Big message, and therefore must insert a Fragmentation header and fragment the packet to fit within the tunnel's MTU.
o 別のSIPパケット内のカプセル化またはソースルーティングヘッダーの挿入による「トンネル」されたSIPパケットは、追加のヘッダーフィールドを追加した後、トンネルのパスのMTUを超えることがあります。元のパケットの長さが576オクテット以下の場合、トンネルエントリシステムは送信元にPacket Too Bigメッセージで応答できないため、断片化ヘッダーを挿入し、トンネルのMTU内に収まるようにパケットをフラグメント化する必要があります。
o An IPv4 fragment that is translated into a SIP packet, or an unfragmented IPv4 packet that is translated into too long a SIP packet to fit in the remaining path MTU, must include the SIP Fragmentation header, so that it may be properly reassembled at the destination SIP system.
o SIPパケットに変換されるIPv4フラグメント、または長すぎるSIPパケットに変換されて残りのパスMTUに収まらないフラグメント化されていないIPv4パケットには、宛先で適切に再構成できるように、SIPフラグメンテーションヘッダーを含める必要がありますSIPシステム。
Every SIP system must support SIP fragmentation and reassembly, since any system may be configured to serve as a tunnel entry or exit point, and any SIP system may be destination of IPv4 fragments. All SIP systems must be capable of reassembling, from fragments, a SIP packet of up to 1024 octets in length, including the SIP header; a system may be capable of assembling packets longer than 1024 octets.
どのシステムもトンネルの入口または出口ポイントとして機能するように構成でき、どのSIPシステムもIPv4フラグメントの宛先になる可能性があるため、すべてのSIPシステムはSIPの断片化と再構成をサポートする必要があります。すべてのSIPシステムは、SIPヘッダーを含め、長さが最大1024オクテットのSIPパケットをフラグメントから再構成できる必要があります。システムは、1024オクテットより長いパケットを組み立てることができる場合があります。
Routers do not examine or process Fragmentation headers of packets that they forward; only at the destination system is the Fragmentation header acted upon (i.e., reassembly performed), as a result of dispatching on the Payload Type of the preceding header.
ルーターは、転送するパケットのフラグメンテーションヘッダーを検査または処理しません。宛先システムでのみ、先行するヘッダーのペイロードタイプでディスパッチした結果として、フラグメンテーションヘッダーが機能します（つまり、再構成が実行されます）。
Fragmentation and reassembly employ the same algorithm as IPv4, with the following exceptions:
断片化と再構成は、IPv4と同じアルゴリズムを使用しますが、次の例外があります。
o All headers up to and including the Fragmentation header are repeated in each fragment; no headers or data following the Fragmentation header are repeated in each fragment.
o Fragmentationヘッダーまでのすべてのヘッダーは、各フラグメントで繰り返されます。フラグメント化ヘッダーに続くヘッダーやデータは、各フラグメントで繰り返されません。
o the Identification field is increased to 32 bits, to decrease the risk of wraparound of that field within the maximum packet lifetime over very high-throughput paths.
o 識別フィールドは32ビットに増加し、非常に高スループットのパスでの最大パケットライフタイム内でのフィールドのラップアラウンドのリスクを低減します。
The similarity of the algorithm and the field layout to that of IPv4 enables existing IPv4 fragmentation and reassembly code and data structures to be re-used with little modification.
アルゴリズムとフィールドレイアウトがIPv4と類似しているため、既存のIPv4フラグメンテーションおよび再構成コードとデータ構造をほとんど変更せずに再利用できます。
Upgrading IPv4 to SIP entails changes to the associated control protocols, ICMP and IGMP, as well as to the transport layer, above, and possibly to the link-layer, below. This section identifies those changes.
IPv4をSIPにアップグレードすると、関連する制御プロトコルであるICMPとIGMPだけでなく、上記のトランスポート層、場合によっては以下のリンク層も変更されます。このセクションでは、これらの変更について説明します。
SIP uses a subset of ICMP [[RFC792], [RFC950], [RFC1122], [RFC1191], [RFC1256]], with a few minor changes and some additions. The presence of an ICMP header is indicated by a Payload Type of 1.
SIPはICMP [[RFC792]、[RFC950]、[RFC1122]、[RFC1191]、[RFC1256]]のサブセットを使用し、いくつかの小さな変更といくつかの追加を行います。 ICMPヘッダーの存在は、ペイロードタイプ1で示されます。
One change to all ICMP messages is that, when used with SIP, the ICMP checksum includes a pseudo-header, like TCP and UDP, consisting of the SIP Source Address, Destination Address, Payload Length, and Payload Type (see section 8.3).
すべてのICMPメッセージに対する1つの変更点は、SIPで使用される場合、ICMPチェックサムに、SIP送信元アドレス、宛先アドレス、ペイロード長、およびペイロードタイプで構成されるTCPやUDPなどの疑似ヘッダーが含まれることです（セクション8.3を参照）。
There are a set of ICMP messages called "error messages", each of which, for IPv4, carries the IPv4 header plus 64 bits or more of data from the packet that invoked the error message. When used with SIP, ICMP error messages carry the first 256 octets of the invoking SIP packet, or the entire invoking packet if it is shorter than 256 octets.
「エラーメッセージ」と呼ばれるICMPメッセージのセットがあり、それぞれがIPv4の場合、IPv4ヘッダーと、エラーメッセージを呼び出したパケットからの64ビット以上のデータを伝送します。 SIPで使用する場合、ICMPエラーメッセージは、呼び出し元のSIPパケットの最初の256オクテット、または256オクテットより短い場合は呼び出し元のパケット全体を伝達します。
For most of the ICMP message types, the packets retain the same format and semantics as with IPv4; however, some of the fields are given new names to match SIP terminology.
ほとんどのICMPメッセージタイプでは、パケットはIPv4と同じ形式とセマンティクスを保持します。ただし、一部のフィールドには、SIP用語に一致する新しい名前が付けられています。
The changes to specific message types are as follows:
特定のメッセージタイプに対する変更は次のとおりです。
Destination Unreachable
宛先に到達できません
The following Codes have different names when used with SIP:
次のコードは、SIPで使用すると異なる名前になります。
1 - destination address unreachable (IPv4 "host unreachable") 7 - destination address unknown (IPv4 "dest. host unknown") 2 - payload type unknown (IPv4 "protocol unreachable") 4 - packet too big (IPv4 "fragmentation needed and DF set")
1-宛先アドレスに到達できません（IPv4 "host unreachable"）7-宛先アドレスが不明（IPv4 "dest。host unknown"）2-ペイロードタイプが不明（IPv4 "protocol unreachable"）4-パケットが大きすぎます（IPv4 "フラグメンテーションが必要であり、DFセットする"）
The following Codes retain the same names when used with SIP:
次のコードは、SIPで使用した場合、同じ名前を保持します。
3 - port unreachable 5 - source route failed 8 - source host isolated 13 - communication administratively prohibited
3-ポートに到達できません5-ソースルートに障害が発生しました8-ソースホストが分離されました13-通信が管理上禁止されています
The following Codes are not used with SIP:
次のコードはSIPでは使用されません。
0 - net unreachable 6 - destination network unknown 9 - comm. with dest. network administratively prohibited 10 - comm. with dest. host administratively prohibited 11 - network unreachable for type of service 12 - host unreachable for type of service
0-到達不能なネット6-宛先ネットワークが不明9-通信。宛先と。ネットワークは管理上禁止されています10-通信。宛先と。ホストは管理上禁止されています11-サービスの種類に対してネットワークに到達できません12-サービスの種類に対してホストに到達できません
For "packet too big" messages (Code 4), the minimum legal value in the Next-Hop MTU field [RFC1191] is 576.
「パケットが大きすぎる」メッセージ（コード4）の場合、Next-Hop MTUフィールド[RFC1191]の有効な最小値は576です。
Time Exceeded
時間超過
The name of Code 0 is changed to "hop limit exceeded in transit".
コード0の名前が「転送中にホップ制限を超えました」に変更されました。
Parameter Problem
パラメータの問題
The Pointer field is extended to 16 bits and moved to the low-order end of the second 32-bit word, as follows:
次のように、ポインターフィールドは16ビットに拡張され、2番目の32ビットワードの下位側に移動されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| first 256 octets of the invoking packet |
| |
Redirect
リダイレクト
Only Code 1 is used for SIP, meaning "redirect packets for the destination address".
SIPにはコード1のみが使用されます。つまり、「宛先アドレスへのパケットのリダイレクト」を意味します。
The Redirect header is modified for SIP, to accommodate the 64-bit address of the "preferred router" and to retain 64-bit alignment, as follows:
次のように、「優先ルーター」の64ビットアドレスに対応し、64ビットアライメントを保持するために、SIPのリダイレクトヘッダーが変更されています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Preferred Router +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| first 256 octets of the invoking packet |
| |
Router Advertisement
ルーター広告
The format of the Router Advertisement message is changed to:
ルーターアドバタイズメッセージの形式が次のように変更されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num Addrs |Addr Entry Size| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Router Address[0] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved[0] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Router Address[1] +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference Level[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved[1] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
The value in the Addr Entry Size field is 4, and all of the Reserved fields are initialized to zero by senders and ignored by receivers.
Addr Entry Sizeフィールドの値は4で、Reservedフィールドはすべて送信側によってゼロに初期化され、受信側によって無視されます。
Router Solicitation
ルーター要請
No changes.
変更なし。
Echo and Echo Reply
エコーとエコー応答
No changes.
変更なし。
The following ICMP message types are not used with SIP:
次のICMPメッセージタイプはSIPでは使用されません。
Source Quench Timestamp Timestamp Reply Information Request Information Reply Address Mask Request Address Mask Reply
ソースクエンチタイムスタンプタイムスタンプ返信情報リクエスト情報返信アドレスマスクリクエストアドレスマスク返信
SIP uses the Internet Group Management Protocol, IGMP [RFC1112]. The presence of an IGMP header is indicated by a Payload Type of 2.
SIPは、インターネットグループ管理プロトコル、IGMP [RFC1112]を使用します。 IGMPヘッダーの存在は、ペイロードタイプ2で示されます。
When used with SIP, the IGMP checksum includes a pseudo-header, like TCP and UDP, consisting of the SIP Source Address, Destination Address, Payload Length, and Payload Type (see section 8.3).
SIPで使用する場合、IGMPチェックサムには、TCPやUDPなどのSIP送信元アドレス、宛先アドレス、ペイロード長、およびペイロードタイプで構成される疑似ヘッダーが含まれます（セクション8.3を参照）。
The format of an IGMP Host Membership Query message becomes:
IGMPホストメンバーシップクエリメッセージの形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of an IGMP Host Membership Report message becomes:
IGMPホストメンバーシップレポートメッセージの形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For both message types, the Version number remains 1, and the Reserved fields are set to zero by senders and ignored by receivers.
どちらのメッセージタイプでも、バージョン番号は1のままで、予約済みフィールドは送信者によってゼロに設定され、受信者によって無視されます。
The service interface to SIP has some differences from IPv4's service interface. Existing transport protocols that use IPv4 must be changed to operate over SIP's service interface. The differences from IPv4 are:
SIPへのサービスインターフェイスは、IPv4のサービスインターフェイスといくつかの違いがあります。 IPv4を使用する既存のトランスポートプロトコルは、SIPのサービスインターフェイスで動作するように変更する必要があります。 IPv4との違いは次のとおりです。
o Any addresses passed across the interface are 64 bits long, rather than 32 bits.
o インターフェイスを介して渡されるアドレスは、32ビットではなく64ビット長です。
o The following IPv4 variables are not passed across the interface: Precedence, Type-of-Service, Identifier, Don't Fragment Flag
o 次のIPv4変数はインターフェイスを介して渡されません：優先順位、サービスの種類、識別子、フラグメントしないフラグ
o SIP options have a different format than IPv4 options. (For SIP, "options" are all headers between, and not including, the SIP header and the transport header. The only IPv4 option currently specified for SIP is Loose Source Routing.
o SIPオプションの形式はIPv4オプションとは異なります。 （SIPの場合、「オプション」はSIPヘッダーとトランスポートヘッダーの間のすべてのヘッダーです（SIPヘッダーとトランスポートヘッダーは含みません）。現在SIPに指定されているIPv4オプションは、Loose Source Routingのみです。
o ICMP error messages for SIP that are passed up to the transport layer carry the first 256 octets of the invoking SIP packet.
o トランスポート層に渡されるSIPのICMPエラーメッセージには、呼び出し元のSIPパケットの最初の256オクテットが含まれます。
Transport protocols that use IPv4 addresses for their own purposes, such as identifying connection state or inclusion in a pseudo-header checksum, must be changed to use 64-bit SIP addresses for those purposes instead.
接続状態の識別や疑似ヘッダーチェックサムへの組み込みなど、独自の目的でIPv4アドレスを使用するトランスポートプロトコルは、代わりに64ビットSIPアドレスを使用するように変更する必要があります。
For SIP, the pseudo-header checksums of TCP, UDP, ICMP, and IGMP include the SIP Source Address, Destination Address, Payload Length, and Payload Type, with the following caveats:
SIPの場合、TCP、UDP、ICMP、およびIGMPの疑似ヘッダーチェックサムには、SIP送信元アドレス、宛先アドレス、ペイロード長、およびペイロードタイプが含まれますが、次の警告があります。
o If the packet contains a Source Routing header, the destination address used in the pseudo-header checksum is that of the final destination.
o パケットにソースルーティングヘッダーが含まれている場合、疑似ヘッダーチェックサムで使用される宛先アドレスは、最終宛先のアドレスです。
o The Payload Length used in the pseudo-header checksum is the length of the transport-layer packet, including the transport header.
o 疑似ヘッダーチェックサムで使用されるペイロード長は、トランスポートヘッダーを含むトランスポート層パケットの長さです。
o The Payload Type used in the pseudo-header checksum is the Payload Type from the header immediately preceding the transport header.
o 疑似ヘッダーチェックサムで使用されるペイロードタイプは、トランスポートヘッダーの直前のヘッダーのペイロードタイプです。
o When added to the pseudo-header checksum, the Payload Type is treated as the left octet of a 16-bit word, with zeros in the the right octet, when viewed in IP standard octet order.
o 疑似ヘッダーチェックサムに追加されると、ペイロードタイプは、16ビットワードの左のオクテットとして扱われ、IP標準のオクテット順で表示すると、右のオクテットにゼロが含まれます。
o If either of the two addresses used in the pseudo-header checksum has its high-order bit set to 1, only the low-order 32-bits of that address shall be used in the sum. The high-order bit is used to indicate that the addressed system is an IPv4 system, and that the low-order 32-bits of the address contain that system's IPv4 address [IPAE].
o 疑似ヘッダーチェックサムで使用される2つのアドレスのいずれかで、上位ビットが1に設定されている場合、合計ではそのアドレスの下位32ビットのみが使用されます。上位ビットは、アドレス指定されたシステムがIPv4システムであること、およびアドレスの下位32ビットにそのシステムのIPv4アドレスが含まれていることを示すために使用されます[IPAE]。
The semantics of SIP service differ from IPv4 service in three ways that may affect some transport protocols:
SIPサービスのセマンティクスは、一部のトランスポートプロトコルに影響を与える可能性のある3つの点でIPv4サービスと異なります。
(1) SIP does not enforce maximum packet lifetime. Any transport protocol that relies on IPv4 to limit packet lifetime must take this change into account, for example, by providing its own mechanisms for detecting and discarding obsolete packets.
（1）SIPは最大のパケット存続時間を強制しません。 IPv4に依存してパケットの有効期間を制限するトランスポートプロトコルでは、たとえば、古いパケットを検出して破棄する独自のメカニズムを提供するなど、この変更を考慮する必要があります。
(2) SIP does not checksum its own header fields. Any transport protocol that relies on IPv4 to assure the integrity of the source and destinations addresses, packet length, and transport protocol identifier must take this change into account. In particular, when used with SIP, the UDP checksum is mandatory, and ICMP and IGMP are changed to use a pseudo-header checksum.
（2）SIPは自身のヘッダーフィールドのチェックサムを行いません。送信元と宛先のアドレス、パケット長、およびトランスポートプロトコル識別子の整合性を保証するためにIPv4に依存するトランスポートプロトコルは、この変更を考慮する必要があります。特に、SIPで使用する場合、UDPチェックサムは必須であり、ICMPおよびIGMPは疑似ヘッダーチェックサムを使用するように変更されます。
(3) SIP does not (except in special cases) fragment packets that exceed the MTU of their delivery paths. Therefore, a transport protocol must not send packets longer than 576 octets unless it implements Path MTU Discovery [RFC1191] and is capable of adapting its transmitted packet size in response to changes of the path MTU.
（3）SIPは（特別な場合を除いて）配信パスのMTUを超えるパケットをフラグメント化しません。したがって、トランスポートプロトコルは、パスMTUディスカバリ[RFC1191]を実装し、パスMTUの変更に応じて送信パケットサイズを調整できる場合を除き、576オクテットを超えるパケットを送信してはなりません。
Link-layer media that have an MTU less than 576 must be enhanced with a link-specific fragmentation and reassembly mechanism, to support SIP.
576未満のMTUを持つリンク層メディアは、SIPをサポートするために、リンク固有のフラグメンテーションおよび再構成メカニズムで拡張する必要があります。
For links on which ARP is used by IPv4, the identical ARP protocol is used for SIP. The low-order 32-bits of SIP addresses are used wherever IPv4 addresses would appear; since ARP is used only among systems on the same subnet, the high-order 32-bits of the SIP addresses may be inferred from the subnet prefix (assuming the subnet prefix is at least 32 bits long). [This is subject to change -- see Appendix B.]
IPv4でARPが使用されているリンクの場合、SIPには同じARPプロトコルが使用されます。下位32ビットのSIPアドレスは、IPv4アドレスが現れる場所で使用されます。 ARPは同じサブネット上のシステム間でのみ使用されるため、SIPアドレスの上位32ビットはサブネットプレフィックスから推測される場合があります（サブネットプレフィックスが少なくとも32ビットであると想定）。 [これは変更される可能性があります-付録Bを参照してください。]
<to be done>
<実施予定>
The author acknowledges the many helpful suggestions and the words of encouragement from Dave Clark, Dave Crocker, Deborah Estrin, Bob Hinden, Christian Huitema, Van Jacobson, Jeff Mogul, Dave Nichols, Erik Nordmark, Dave Oran, Craig Partridge, Scott Shenker, Paul Tsuchiya, Lixia Zhang, the members of End-to-End Research Group and the IPAE Working Group, and the participants in the big-internet and sip mailing lists. He apologizes to those whose names he has not explicitly listed. [If you want to be on the list in the next draft, just let him know!]
著者は、Dave Clark、Dave Crocker、Deborah Estrin、Bob Hinden、Christian Huitema、Van Jacobson、Jeff Mogul、Dave Nichols、Erik Nordmark、Dave Oran、Craig Partridge、Scott Shenker、Paulからの多くの役立つ提案と励ましの言葉を認めます土屋、Lixia Zhang、End-to-End Research GroupおよびIPAEワーキンググループのメンバー、ビッグインターネットおよびsipメーリングリストの参加者。彼は名前を明示的に挙げていない人々に謝罪します。 [次のドラフトのリストに載りたい場合は、彼に知らせてください！]
Editor's note: Steve Deering was employed by the Xerox Palo Alto Research Center in Palo Alto, CA USA when this work was done.
編集者注：Steve Deeringは、この作業が行われたときに米国カリフォルニア州パロアルトにあるXerox Palo Alto Research Centerに採用されました。
[IPAE] Crocker, D. and R. Hinden, "IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP", Work in Progress, draft-crocker-ip-encaps-01, November 1992.
[IPAE]クロッカーD.およびR.ヒンデン、「IPアドレスカプセル化（IPAE）：新しいIPを導入するためのメカニズム」、進行中の作業、draft-crocker-ip-encaps-01、1992年11月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<https://www.rfc-editor.org/info/rfc791>。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<https://www.rfc-editor.org/info/rfc792>。
[RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August 1985, <https://www.rfc-editor.org/info/rfc950>.
[RFC950] Mogul、J.およびJ. Postel、「インターネット標準サブネット手順」、STD 5、RFC 950、DOI 10.17487 / RFC0950、1985年8月、<https://www.rfc-editor.org/info/rfc950> 。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, DOI 10.17487/RFC0951, September 1985, <https://www.rfc-editor.org/info/rfc951>.
[RFC951] Croft、W. and J. Gilmore、 "Bootstrap Protocol"、RFC 951、DOI 10.17487 / RFC0951、September 1985、<https://www.rfc-editor.org/info/rfc951>。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、DOI 10.17487 / RFC1112、1989年8月、<https://www.rfc-editor.org/info/rfc1112>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<https://www.rfc-editor.org/info/rfc1191>。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, DOI 10.17487/RFC1256, September 1991, <https://www.rfc-editor.org/info/rfc1256>.
[RFC1256] Deering、S。、編、「ICMPルーター発見メッセージ」、RFC 1256、DOI 10.17487 / RFC1256、1991年9月、<https://www.rfc-editor.org/info/rfc1256>。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <https://www.rfc-editor.org/info/rfc1661>.
[RFC1661] Simpson、W.、Ed。、 "The Point-to-Point Protocol（PPP）"、STD 51、RFC 1661、DOI 10.17487 / RFC1661、July 1994、<https://www.rfc-editor.org / info / rfc1661>。
[RFC1710] Hinden, R., "Simple Internet Protocol Plus White Paper", RFC 1710, DOI 10.17487/RFC1710, October 1994, <https://www.rfc-editor.org/info/rfc1710>.
[RFC1710] Hinden、R。、「Simple Internet Protocol Plus White Paper」、RFC 1710、DOI 10.17487 / RFC1710、1994年10月、<https://www.rfc-editor.org/info/rfc1710>。
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, DOI 10.17487/RFC1752, January 1995, <https://www.rfc-editor.org/info/rfc1752>.
[RFC1752] Bradner、S。およびA. Mankin、「IP次世代プロトコルの推奨事項」、RFC 1752、DOI 10.17487 / RFC1752、1995年1月、<https://www.rfc-editor.org/info/rfc1752 >。
[RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, December 1995, <https://www.rfc-editor.org/info/rfc1883>.
[RFC1883] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 1883、DOI 10.17487 / RFC1883、1995年12月、<https://www.rfc-editor.org/info/ rfc1883>。
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.
[RFC8200] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、STD 86、RFC 8200、DOI 10.17487 / RFC8200、2017年7月、<https://www.rfc-editor.org / info / rfc8200>。
[SIP-ADDR] Deering, S., "Simple Internet Protocol (SIP) Addressing and Routing", Work in Progress, November 1992.
[SIP-ADDR] Deering、S。、「Simple Internet Protocol（SIP）Addressing and Routing」、Work in Progress、1992年11月。
<this section still to be done>
<このセクションはまだ完了していません>
Fields present in IPv4, but absent in SIP:
IPv4には存在するが、SIPには存在しないフィールド：
Header Length Not needed; SIP header length is fixed.
ヘッダー長必要ありません。 SIPヘッダー長は固定です。
Precedence & Type of Service Not used; transport-layer Port fields (or perhaps a to-be-defined value in the Reserved field of the SIP header) may be used for classifying packets at a granularity finer than host-to-host, as required for special handling.
優先順位とサービスの種類使用されません。トランスポート層のポートフィールド（またはおそらくSIPヘッダーの予約済みフィールドの未定義の値）は、特別な処理の必要に応じて、ホスト間より細かい粒度でパケットを分類するために使用できます。
Header Checksum Not used; transport pseudo-header checksum protects destinations from accepting corrupted packets.
ヘッダーチェックサム使用されません。トランスポート疑似ヘッダーチェックサムは、破損したパケットを受け入れないように宛先を保護します。
Need to justify:
正当化する必要がある：
change of Total Length -> Payload Length, excluding header change of Protocol -> Payload Type change of Time to Live -> Hop Limit movement of fragmentation fields out of fixed header bigger minimum MTU, and reliance on PMTU Discovery
全長の変更->ペイロードの長さ、プロトコルのヘッダー変更を除く->ペイロードタイプの存続時間の変更->固定ヘッダーの大きい最小MTUからのフラグメンテーションフィールドのホップリミット移動、およびPMTU検出への依存
SIP as specified above is a fully functional replacement for IPv4, with a number of improvements, particularly in the areas of scalability of routing and addressing, and performance. Some additional improvements are still under consideration:
上記のSIPは、IPv4の完全に機能的な代替品であり、特にルーティングとアドレッシングのスケーラビリティ、およびパフォーマンスの面で多くの改良が加えられています。いくつかの追加の改善はまだ検討中です：
o ARP may be modified to carry full 64-bit addresses, and to use link-layer multicast addresses, rather than broadcast addresses.
o ARPは、完全な64ビットアドレスを伝送し、ブロードキャストアドレスではなくリンク層マルチキャストアドレスを使用するように変更できます。
o The 28-bit Reserved field in the SIP header may be defined as a "Flow ID", or partitioned into a Type of Service field and a Flow ID field, for classifying packets deserving of special handling, e.g., non-default quality of service or real-time service. On the other hand, the transport-layer port fields may be adequate for performing any such classification. (One possibility would be simply to remove the port fields from TCP & UDP and append them to the SIP header, as in XNS.)
o SIPヘッダーの28ビット予約フィールドは、「デフォルトのサービス品質」などの特別な処理に値するパケットを分類するために、「フローID」として定義するか、タイプオブサービスフィールドとフローIDフィールドに分割できます。またはリアルタイムサービス。一方、トランスポート層のポートフィールドは、そのような分類を実行するのに十分な場合があります。 （1つの可能性は、XNSのように、単にTCP＆UDPからポートフィールドを削除してSIPヘッダーに追加することです。）
o A new ICMP "destination has moved" message may defined, for re-routing to mobile hosts or subnets, and to domains that have changed their address prefixes.
o モバイルホストまたはサブネット、およびアドレスプレフィックスが変更されたドメインに再ルーティングするために、新しいICMP「宛先が移動しました」メッセージが定義される場合があります。
o An explicit Trace Route message or option may be defined; the current IPv4 traceroute scheme will work fine with SIP, but it does not work for multicast, for which it has become very apparent that management and debugging tools are needed.
o 明示的なトレースルートメッセージまたはオプションを定義できます。現在のIPv4 tracerouteスキームはSIPで正常に機能しますが、管理およびデバッグツールが必要であることが非常に明らかになっているマルチキャストでは機能しません。
o A new Host-to-Router protocol may be specified, encompassing the requirements of router discovery, black-hole detection, auto- configuration of subnet prefixes, "beaconing" for mobile hosts, and, possibly, address resolution. The OSI End System To Intermediate System Protocol may serve as a good model for such a protocol.
o ルーター発見、ブラックホール検出、サブネットプレフィックスの自動設定、モバイルホストの「ビーコン」、および場合によってはアドレス解決の要件を含む、新しいホスト対ルータープロトコルを指定できます。 OSI End System To Intermediate Systemプロトコルは、このようなプロトコルの優れたモデルとして機能します。
o The requirement that SIP addresses be strictly bound to interfaces may be relaxed, so that, for example, a system might have fewer addresses than interfaces. There is some experience with this approach in the current Internet, with the use of "unnumbered links" in routing protocols such as OSPF.
o SIPアドレスをインターフェイスに厳密にバインドするという要件が緩和されるため、たとえば、システムのアドレスがインターフェイスよりも少なくなる場合があります。現在のインターネットでは、OSPFなどのルーティングプロトコルで「番号なしリンク」を使用して、このアプローチにある程度の経験があります。
o Authentication and integrity-assurance mechanisms for all clients of SIP, including ICMP and IGMP, may be specified, possibly based on the Secure Data Network System (SNDS) SP-3 or SP-4 protocol.
o ICMPおよびIGMPを含むSIPのすべてのクライアントの認証および整合性保証メカニズムは、おそらくセキュアデータネットワークシステム（SNDS）SP-3またはSP-4プロトコルに基づいて指定できます。
Authors' Addresses
著者のアドレス
Stephen E. Deering Retired Vancouver, British Columbia Canada
スティーブンE.ディアーリングカナダ、ブリティッシュコロンビア州バンクーバー
Robert M. Hinden (editor) Check Point Software 959 Skyway Road San Carlos, CA 94070 USA
Robert M. Hinden（編集者）Check Point Software 959 Skyway Road San Carlos、CA 94070 USA
Email: bob.hinden@gmail.com