Independent Submission S. Deering
Request for Comments: 8507 Retired
Category: Historic R. Hinden, Ed.
ISSN: 2070-1721 Check Point Software
December 2018
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
简单互联网协议（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.
这份文件是为了历史记录而出版的。简单的互联网协议是IETF下一代（IPng）工作的候选协议之一，即IPv6的基础。
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的IP的新版本，即简单Internet协议。它还描述了为了使用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.
本文件不是互联网标准跟踪规范；它是为了历史记录而出版的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受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
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）工作候选之一的基础；请参阅“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]的候选，并最终导致IPv6的开发，最初发布为[RFC1883]。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.
描述简单互联网协议的原始互联网草案由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
SIP保留了全局唯一地址的IP模型，采用分层结构以实现高效路由。将地址大小从32位增加到64位允许在地址中编码更多层次结构，足以在互联网中实现高效路由，在世界上每个办公室、每个住宅和每个车辆中都有数以万计的可寻址设备。保持
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头的带宽开销几乎与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实现中重用IPv4中的大部分代码和数据结构（包括几乎所有的ICMP和IGMP）成为可能，并使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给出了SIP不同于IPv4的那些方面的基本原理。
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.
地址-一个接口或一组接口的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报头加有效负载）。
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| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Payload Type | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version 4-bit IP version number = decimal 6. <to be confirmed>
版本4位IP版本号=十进制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位十六进制数字，第4位和第5位之间有一个冒号，任何后续数字对之间有可选冒号。不得删除前导零。示例：
0123:4567:89AB:CDEF
0123:4567:89AB:CDEF
0123:456789ABCDEF
0123:456789ABCDEF
0123:456789AB:CDE:F
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.
文本表示中至少有一个冒号，使得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 internet中的任何两个接口都不能具有相同的单播地址。然而，单个接口可能有多个单播地址。
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|
+----------------------------------------------------+------------+
| 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|
+----------------------------------------------------+------------+
| 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.
一个系统可能有一个包含所有系统的子网掩码，这意味着该系统属于一个子网，该子网只包含一个系统本身。
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|
+-----------------------------------------+-----------------------+
| 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|
+-----------------------------------------+----------+------------+
| 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]提出了两种分层寻址计划，一种基于SIP服务提供商的层次结构，另一种基于地理层次结构。
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 |
+-+-------+----+----+---------------------------------------------+
|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|
+-+-+-+-+
+-+-+-+-+
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)
0保留1系统内范围2链路内范围3（未分配）4（未分配）5站点内范围6（未分配）7（未分配）8城域内范围9（未分配）A（未分配）B国家内范围C（未分配）
D (unassigned) E global scope F reserved
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（十六进制）的永久多播地址，则：
7F01:000000000043 means all NTP servers on the same system as the sender.
7F01:0000000000 43表示与发送方位于同一系统上的所有NTP服务器。
7F02:000000000043 means all NTP servers on the same link as the sender.
7F02:0000000000 43表示与发送方位于同一链路上的所有NTP服务器。
7F05:000000000043 means all NTP servers at the same site as the sender.
7F05:0000000000 43表示与发送方位于同一站点的所有NTP服务器。
7F0E:000000000043 means all NTP servers in the internet.
7F0E:0000000000 43表示internet中的所有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:0000000000 43标识的组与在不同站点使用相同地址的组、使用相同组ID的具有不同作用域的非永久性组以及具有相同组ID的永久性组没有关系。
There are a number of "special purpose" SIP addresses:
有许多“特殊用途”SIP地址：
The Unspecified Address: 0000:0000:0000:0000
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.
不得将此地址分配给任何系统。它可用于任何出现地址的地方，以表示没有地址。其使用的一个例子是，在初始化主机读入自己的地址之前，在SIP数据包的源地址字段中。
The Loopback Address: 0000:0000:0000:0001
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>
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>.
这种形式的地址可用于发送到“最近的”系统（根据路由协议的距离度量），该系统“知道”它的单播地址前缀为<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|
+----------------------------------------------+----------------+
+----------------------------------------------+----------------+
| subnet prefix = A |interface ID = B|
+----------------------------------------------+----------------+
shall recognize only the following Anyone address as identifying itself:
应仅将以下地址识别为识别自身：
+----------------------------------------------+----------------+
| subnet prefix = A |0000000000000000|
+----------------------------------------------+----------------+
+----------------------------------------------+----------------+
| subnet prefix = A |0000000000000000|
+----------------------------------------------+----------------+
An intra-site router that knows that one of its addresses has the format:
知道其地址之一具有以下格式的站点内路由器：
+-------------------------------+--------------+----------------+
| site prefix = X |subnet ID = Y|interface ID = Z|
+-------------------------------+--------------+----------------+
+-------------------------------+--------------+----------------+
| 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:
应接受发送至以下两个任意地址之一的数据包，就像它们已发送至路由器自己的地址一样：
+-------------------------------+-------------------------------+
| site prefix = X |0000000000000000000000000000000|
+-------------------------------+-------------------------------+
+-------------------------------+-------------------------------+
| site prefix = X |0000000000000000000000000000000|
+-------------------------------+-------------------------------+
+-------------------------------+--------------+----------------+
| site prefix = X |subnet ID = Y|0000000000000000|
+-------------------------------+--------------+----------------+
+-------------------------------+--------------+----------------+
| 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的任何地址发送数据包，则该数据包应在发送系统本身内循环，因为该数据包是与子网A前缀最近的系统。如果子网a之外的系统向子网a的任何地址发送数据包，则数据包到达的子网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的任何地址的数据包应被属于站点X的第一个遇到的路由器（即站点X的边界路由器之一）接受。如果更高级别的前缀P识别（例如）特定的服务提供商，则从提供商P的设施外部发送到<P><zero>的数据包应被传送到最近的进入路由器，进入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.
Anywhere地址通常与SIP源路由报头结合使用，以使数据包通过一个或多个指定的“传输域”进行路由，而无需识别这些域中的各个路由器。
The value zero is reserved at each level of every unicast address hierarchy, to serve as an Anyone address for that level.
值0保留在每个单播地址层次结构的每个级别，用作该级别的任何人地址。
The Reserved Multicast Address: 7F0s:0000:0000:0000
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
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
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
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.
主机需要将以下地址识别为标识自身的地址：其自己的单播地址、与其单播地址具有相同子网前缀的任何地址、环回地址、所有系统和所有主机地址，以及主机所属的任何其他多播地址。
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.
路由器需要将以下地址识别为识别自身的地址：其自身的单播地址、具有与其单播地址相同子网或更高级别前缀的任何地址、环回地址、所有系统和所有路由器地址，以及主机所属的任何其他多播地址。
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要求internet中的每个链路都有576个八位字节或更大的MTU。在任何不能完整传输576八位组数据包的链路上，必须在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]，第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一样大的数据包。具有可配置MTU的链路（如PPP链路[RFC1661]）应配置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发现[RFC1191]，以便发现并利用MTU大于576个八位字节的路径。然而，最小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中不需要在数据包头中设置“不分段”标志来执行路径MTU发现；这是每个SIP数据包的隐式属性。此外，RFC-1191过程中涉及使用MTU“平台”表的部分不适用于SIP，因为SIP版本的“数据报太大”消息始终标识要使用的确切MTU。）
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
要处理的下一个地址的下一个地址索引；由原始系统初始化为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目的地地址和地址[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，则调度到由源路由报头中的有效负载类型字段标识的本地协议模块。
o If Next Addr > Num Addrs, send an ICMP Parameter Problem message to the Source Address, pointing to the Num Addrs field.
o 如果Next Addr>Num Addrs，则向源地址发送一条ICMP参数问题消息，指向Num Addrs字段。
A Payload Type of <TBD> in the immediately preceding header indicates the presence of this Fragmentation header:
前一个标头中的有效负载类型<TBD>表示存在此碎片标头：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 M| Fragment Offset | Payload Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
Fragment Offset以下有效载荷相对于原始未分段有效载荷的偏移量，以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.
碎片标头不支持一般的SIP层碎片。特别是，SIP路由器不应分割对于其下一跳的MTU来说太大的SIP包，除非在下面描述的特殊情况下；在正常情况下，这样的数据包会导致ICMP数据包过大的消息被发送回其源，以供源系统的路径MTU发现算法使用。
The special cases for which the Fragmentation header is intended are the following:
碎片标头适用的特殊情况如下：
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个八位字节或更短，则隧道入口系统无法使用数据包过大的消息响应源，因此必须插入分段头并将数据包分段以适合隧道的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系统都必须支持SIP分段和重组，因为任何系统都可以配置为作为隧道入口或出口点，并且任何SIP系统都可能是IPv4片段的目的地。所有SIP系统必须能够从片段重新组装长度高达1024个八位字节的SIP数据包，包括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 在每个片段中重复碎片标头之前（包括碎片标头）的所有标头；在每个片段中，碎片标头后面没有重复的标头或数据。
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消息的一个变化是，当与SIP一起使用时，ICMP校验和包括一个伪报头，如TCP和UDP，由SIP源地址、目标地址、有效负载长度和有效负载类型组成（见第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“主机不可访问”）7-目标地址未知（IPv4“目标主机未知”）2-负载类型未知（IPv4“协议不可访问”）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-与目标通信。网络管理禁止与dest进行10次通信。管理禁止的主机11-服务类型无法访问网络12-服务类型无法访问主机
For "packet too big" messages (Code 4), the minimum legal value in the Next-Hop MTU field [RFC1191] is 576.
对于“数据包太大”消息（代码4），下一跳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位，并移动到第二个32位字的低位，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| first 256 octets of the invoking packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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".
只有代码1用于SIP，这意味着“将数据包重定向到目标地址”。
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:
针对SIP修改重定向头，以适应“首选路由器”的64位地址并保持64位对齐，如下所示：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Preferred Router +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| first 256 octets of the invoking packet |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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，发送方将所有保留字段初始化为零，接收方将忽略这些字段。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of an IGMP Host Membership Report message becomes:
IGMP主机成员资格报告消息的格式为：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Multicast Address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 通过接口传递的任何地址的长度都是64位，而不是32位。
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指定的唯一IPv4选项是松散源路由。
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 当添加到伪报头校验和时，当以IP标准八位字节顺序查看时，有效负载类型被视为16位字的左八位字节，右八位字节中有零。
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 如果在伪报头校验和中使用的两个地址中的任何一个的高阶位设置为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服务的语义在三个方面不同于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发现[rfc191]，并且能够响应路径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.
MTU小于576的链路层介质必须使用特定于链路的碎片和重组机制进行增强，以支持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协议。无论IPv4地址出现在何处，都会使用低阶32位SIP地址；由于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 Tsuchiya、Lixia Zhang、，端到端研究组和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.
编者按：这项工作完成时，史蒂夫·迪林受雇于美国加州帕洛阿尔托的施乐帕洛阿尔托研究中心。
[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]Crocker，D.和R.Hinden，“IP地址封装（IPAE）：引入新IP的机制”，正在进行的工作，草稿-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/RFC07911981年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.和J.Gilmore，“引导协议”，RFC 951，DOI 10.17487/RFC09511985年9月<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.，Ed.“互联网主机的要求-通信层”，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，“MTU发现路径”，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.，Ed.，“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]辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661，DOI 10.17487/RFC16611994年7月<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.，“简单互联网协议加白皮书”，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.，“简单互联网协议（SIP）寻址和路由”，正在进行的工作，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字段，用于对需要特殊处理的分组进行分类，例如，非默认服务质量或实时服务。另一方面，传输层端口字段可能足以执行任何此类分类。（一种可能是简单地从TCP和UDP中删除端口字段，并将它们附加到SIP头中，如XNS中所示。）
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“destination has moved”（目的地已移动）消息，用于重新路由到移动主机或子网以及已更改其地址前缀的域。
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跟踪路由方案可以与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端系统到中间系统协议可以作为此类协议的良好模型。
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 可能基于安全数据网络系统（SNDS）SP-3或SP-4协议，指定SIP所有客户端（包括ICMP和IGMP）的身份验证和完整性保证机制。
Authors' Addresses
作者地址
Stephen E. Deering Retired Vancouver, British Columbia Canada
斯蒂芬·迪林退休于加拿大不列颠哥伦比亚省温哥华
Robert M. Hinden (editor) Check Point Software 959 Skyway Road San Carlos, CA 94070 USA
Robert M.Hinden（编辑）美国加利福尼亚州圣卡洛斯市Skyway路959号检查点软件94070
Email: bob.hinden@gmail.com
Email: bob.hinden@gmail.com