idnits 2.17.1 draft-historic-simple-ip-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([SIP-ADDR]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 181 has weird spacing: '...terface a s...' == Line 201 has weird spacing: '...n layer any p...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 6, 2018) is 2058 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 815 -- Looks like a reference, but probably isn't: '1' on line 823 ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Deering 3 Internet-Draft Retired 4 Intended status: Historic R. Hinden, Ed. 5 Expires: March 10, 2019 Check Point Software 6 September 6, 2018 8 Simple Internet Protocol (SIP) Specification 9 draft-historic-simple-ip-03 11 Abstract 13 This document is published for the historical record. The Simple 14 Internet Protocol was the basis for one of the candidates for the 15 IETF's Next Generation (IPng) work that became IPv6. 17 The publication date of the original Internet-Draft was November 10, 18 1992. It is presented here substantially unchanged and is neither a 19 complete document nor intended to be implementable. 21 The paragraph that follows is the Abstract from the original draft. 23 This document specifies a new version of IP called SIP, the Simple 24 Internet Protocol. It also describes the changes needed to ICMP, 25 IGMP, and transport protocols such as TCP and UDP, in order to work 26 with SIP. A companion document [SIP-ADDR] describes the addressing 27 and routing aspects of SIP, including issues of auto-configuration, 28 host and subnet mobility, and multicast. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 10, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 4. SIP Header Format . . . . . . . . . . . . . . . . . . . . . . 5 80 5. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 5.1. Text Representation of Addresses . . . . . . . . . . . . 6 82 5.2. Unicast Addresses . . . . . . . . . . . . . . . . . . . . 6 83 5.3. Multicast Addresses . . . . . . . . . . . . . . . . . . . 8 84 5.4. Special Addresses . . . . . . . . . . . . . . . . . . . . 9 85 6. Packet Size Issues . . . . . . . . . . . . . . . . . . . . . 12 86 7. Source Routing Header . . . . . . . . . . . . . . . . . . . . 13 87 8. Fragmentation Header . . . . . . . . . . . . . . . . . . . . 15 88 9. Changes to Other Protocols . . . . . . . . . . . . . . . . . 16 89 9.1. Changes to ICMP . . . . . . . . . . . . . . . . . . . . . 17 90 9.2. Changes to IGMP . . . . . . . . . . . . . . . . . . . . . 21 91 9.3. Changes to Transport Protocols . . . . . . . . . . . . . 21 92 9.4. Changes to Link-Layer Protocols . . . . . . . . . . . . . 23 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 Appendix A. SIP Design Rationale . . . . . . . . . . . . . . . . 25 97 Appendix B. Future Directions . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 100 1. Preface 102 This document is published for the historical record. 104 Simple IP (SIP) was the basis for one of the candidates for the 105 IETF's Next Generation (IPng) work, see "The Recommendation for the 106 IP Next Generation Protocol [RFC1752]. The original 1992 Internet 107 Draft describing SIP is published here as part of the record of that 108 work. 110 SIP evolved into SIP Plus [RFC1710] which was assessed as a candidate 111 for IPng [RFC1752] and led eventually to the development of IPv6 112 first published as [RFC1883]. The current specification for IPv6 is 113 [RFC8200]. 115 The original Internet-Draft describing the Simple IP protocol was 116 written by Steve Deering and the Internet Draft was posted on 117 November 10, 1992. The contents of this document are unchanged from 118 this Internet Draft, except for clarifications in the Abstract, the 119 addition of this section, modifications to the authors' information, 120 updating references, removing the IANA considerations, and minor 121 formatting changes. 123 It should be noted that the original draft was not complete and that 124 no attempt has been made to complete it. This document is not 125 intended to be implementable. 127 2. Introduction 129 SIP is a new version of IP. Its salient differences from IP version 130 4 [RFC0791], subsequently referred to as "IPv4", are: 132 * expansion of addresses to 64 bits, 134 * simplification of the IP header by eliminating some inessential 135 fields, and 137 * relaxation of length restrictions on optional data, such as 138 source-routing information. 140 SIP retains the IP model of globally-unique addresses, 141 hierarchically- structured for efficient routing. Increasing the 142 address size from 32 to 64 bits allows more levels of hierarchy to be 143 encoded in the addresses, enough to enable efficient routing in an 144 internet with tens of thousands of addressable devices in every 145 office, every residence, and every vehicle in the world. Keeping the 146 addresses fixed-length and relatively compact facilitates high- 147 performance router and host implementation, and keeps the bandwidth 148 overhead of the SIP headers almost as low as IPv4. 150 The elimination of inessential fields also contributes to high- 151 performance implementation, and to the likelihood of correct 152 implementation. A change in the way that optional data, such as 153 source-routing information, is encoded allows for more efficient 154 forwarding and less stringent limits on the length of such data. 156 Despite these changes, SIP remains very similar to IPv4. This 157 similarity makes it easy to understand SIP (for those who already 158 understand IPv4), makes it possible to reuse much of the code and 159 data structures from IPv4 in an implementation of SIP (including 160 almost all of ICMP and IGMP), and makes it straightforward to 161 translate between SIP packets and IPv4 packets for transition 162 purposes [IPAE]. 164 The subsequent sections of this document specify SIP and its 165 associated protocols without much explanation of why the design 166 choices were made the way they were. Appendix A presents the 167 rationale for those aspects of SIP that differ from IPv4. 169 3. Terminology 171 system a device that implements SIP. 173 router a system that forwards SIP packets. 175 host any system that is not a router. 177 link a communication facility or medium over which systems 178 can communicate at the link layer, i.e., the layer 179 immediately below SIP. 181 interface a system's attachment point to a link. 183 address a SIP-layer identifier for an interface or a group of 184 interfaces. 186 subnet in the SIP unicast addressing hierarchy, a lowest-level 187 (finest-grain) cluster of addresses, sharing a common 188 address prefix (i.e., high-order address bits). 189 Typically, all interfaces attached to the same link have 190 addresses in the same subnet; however, in some cases, a 191 single link may support more than one subnet, or a 192 single subnet may span more than one link. 194 link MTU the maximum transmission unit, i.e., maximum packet size 195 in octets, that can be conveyed in one piece over a link 196 (where a packet is a SIP header plus payload). 198 path MTU the minimum link MTU of all the links in a path between 199 a source system and a destination system. 201 packetization layer any protocol layer above SIP that is responsible 202 for packetizing data to fit within outgoing SIP packets. 203 Typically, transport-layer protocols, such as TCP, are 204 packetization protocols, but there may also be higher- 205 layer packetization protocols, such as protocols 206 implemented on top of UDP. 208 4. SIP Header Format 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 |Version| Reserved | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Payload Length | Payload Type | Hop Limit | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | | 216 + Source Address + 217 | | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | | 220 + Destination Address + 221 | | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Version 4-bit IP version number = decimal 6. 227 Reserved 28-bit reserved field. Initialized to zero 228 for transmission; ignored on reception. 230 Payload Length 16-bit unsigned integer. Length of payload, 231 i.e., the rest of the packet following the SIP 232 header, in octets. 234 Payload Type 8-bit selector. Identifies the type of 235 payload, e.g., TCP. 237 Hop Limit 8-bit unsigned integer. Decremented by 1 by 238 each system that forwards the packet. The 239 packet is discarded if Hop Limit is 240 decremented to zero. 242 Source Address 64 bits. See "Addresses" section, following. 244 Destination Address 64 bits. See "Addresses" section, following. 246 5. Addresses 248 5.1. Text Representation of Addresses 250 SIP addresses are 64 bits (8 octets) long. The text representation 251 of a SIP addresses is 16 hexadecimal digits, with a colon between the 252 4th and 5th digits, and optional colons between any subsequent pair 253 of digits. Leading zeros must not be dropped. Examples: 255 0123:4567:89AB:CDEF 257 0123:456789ABCDEF 259 0123:456789AB:CDE:F 261 Programs that read the text representation of SIP addresses must be 262 insensitive to the presence or absence of optional colons. Programs 263 that write the text representation of a SIP address should use the 264 first format above (i.e., colons after the 4th, 8th, and 12th 265 digits), in the absence of any knowledge of the structure or 266 preferred format of the address, such as knowledge of the format in 267 which it was originally read. 269 The presence of at least one colon in the text representation allows 270 SIP addresses to be easily distinguished from both domain names and 271 the text representation of IPv4 addresses. 273 5.2. Unicast Addresses 275 A SIP unicast address is a globally-unique identifier for a single 276 interface, i.e., no two interfaces in a SIP internet may have the 277 same unicast address. A single interface may, however, have more 278 than one unicast address. 280 A system considers its own unicast address(es) to have the following 281 structure, where different addresses may have different values for n: 283 | n bits | 64-n bits | 284 +----------------------------------------------------+------------+ 285 | subnet prefix |interface ID| 286 +----------------------------------------------------+------------+ 288 To know the length of the subnet prefix, the system is required to 289 associate with each of its addresses a 'subnet mask' of the following 290 form: 292 | n bits | 64-n bits | 293 +----------------------------------------------------+------------+ 294 |1111111111111111111111111111111111111111111111111111|000000000000| 295 +----------------------------------------------------+------------+ 297 A system may have a subnet mask of all-ones, which means that the 298 system belongs to a subnet containing exactly one system -- itself. 300 A system acquires its subnet mask(s) at the same time, and by the 301 same mechanism, as it acquires its address(es), for example, by 302 manual configuration or by a dynamic configuration protocol such as 303 BOOTP [RFC0951] 305 Hosts are ignorant of any further structure in a unicast address. 307 Routers may acquire, through manual configuration or the operation of 308 routing protocols, additional masks that identify higher-level 309 clusters in a hierarchical addressing plan. For example, the routers 310 within a single site would typically have a 'site mask', such as the 311 following: 313 | m bits | 64-m bits | 314 +-----------------------------------------+-----------------------+ 315 |11111111111111111111111111111111111111111|00000000000000000000000| 316 +-----------------------------------------+-----------------------+ 318 by which they could deduce the following structure in the site's 319 addresses: 321 | m bits | p bits | 64-m-p bits| 322 +-----------------------------------------+----------+------------+ 323 | site prefix |subnet ID|interface ID| 324 +-----------------------------------------+----------+------------+ 326 All knowledge by SIP systems of the structure of unicast addresses is 327 based on possession of such masks -- there is no "wired-in" knowledge 328 of unicast address formats. 330 The SIP Addressing and Routing document [SIP-ADDR] proposes two 331 hierarchical addressing plans, one based on a hierarchy of SIP 332 service providers, and one based on a geographic hierarchy. 334 5.3. Multicast Addresses 336 A SIP multicast address is an identifier for a group of interfaces. 337 An interface may belong to any number of multicast groups. Multicast 338 addresses have the following format: 340 |1| 7 | 4 | 4 | 48 bits | 341 +-+-------+----+----+---------------------------------------------+ 342 |C|1111111|flgs|scop| group ID | 343 +-+-------+----+----+---------------------------------------------+ 345 where: 347 C = IPv4 compatibility flag; see [IPAE]. 349 1111111 in the rest of the first octet identifies the address as 350 being a multicast address. 352 +-+-+-+-+ 353 flgs is a set of 4 flags: |0|0|0|T| 354 +-+-+-+-+ 356 the high-order 3 flags are reserved, and must be initialized to 357 0. 359 T = 0 indicates a permanently-assigned ("well-known") multicast 360 address, assigned by the global internet numbering 361 authority. 363 T = 1 indicates a non-permanently-assigned ("transient") 364 multicast address. 366 scop is a 4-bit multicast scope value: 368 0 reserved 369 1 intra-system scope 370 2 intra-link scope 371 3 (unassigned) 372 4 (unassigned) 373 5 intra-site scope 374 6 (unassigned) 375 7 (unassigned) 376 8 intra-metro scope 377 9 (unassigned) 378 A (unassigned) 379 B intra-country scope 380 C (unassigned) 381 D (unassigned) 382 E global scope 383 F reserved 385 group ID identifies the multicast group, either permanent or 386 transient, within the given scope. 388 The "meaning" of a permanently-assigned multicast address is 389 independent of the scope value. For example, if the "NTP servers 390 group" is assigned a permanent multicast address with a group ID of 391 43 (hex), then: 393 7F01:000000000043 means all NTP servers on the same system as the 394 sender. 396 7F02:000000000043 means all NTP servers on the same link as the 397 sender. 399 7F05:000000000043 means all NTP servers at the same site as the 400 sender. 402 7F0E:000000000043 means all NTP servers in the internet. 404 Non-permanently-assigned multicast addresses are meaningful only 405 within a given scope. For example, a group identified by the non- 406 permanent, intra-site multicast address 7F15:000000000043 at one site 407 bears no relationship to a group using the same address at a 408 different site, nor to a non-permanent group using the same group ID 409 with different scope, nor to a permanent group with the same group 410 ID. 412 5.4. Special Addresses 414 There are a number of "special purpose" SIP addresses: 416 The Unspecified Address: 0000:0000:0000:0000 417 This address shall never be assigned to any system. It may be 418 used wherever an address appears, to indicate the absence of an 419 address. One example of its use is in the Source Address field 420 of a SIP packet sent by an initializing host, before it has 421 learned its own address. 423 The Loopback Address: 0000:0000:0000:0001 425 This address may be used by a system to send a SIP packet to 426 itself. 428 Anyone Addresses: 430 Addresses of this form may be used to send to the "nearest" 431 system (according the routing protocols' measure of distance) 432 that "knows" it has a unicast address prefix of . 434 Since hosts know only their subnet prefix(es), and no higher- 435 level prefixes, a host with the following address: 437 +-----------------------------------------------+----------------+ 438 | subnet prefix = A |interface ID = B| 439 +-----------------------------------------------+----------------+ 441 shall recognize only the following Anyone address as 442 identifying itself: 444 +-----------------------------------------------+----------------+ 445 | subnet prefix = A |0000000000000000| 446 +-----------------------------------------------+----------------+ 448 An intra-site router that knows that one of its addresses has 449 the format: 451 +--------------------------------+--------------+----------------+ 452 | site prefix = X |subnet ID = Y|interface ID = Z| 453 +--------------------------------+--------------+----------------+ 454 shall accept packets sent to either of the following two Anyone 455 addresses as if they had been sent to the router's own address: 457 +--------------------------------+-------------------------------+ 458 | site prefix = X |0000000000000000000000000000000| 459 +--------------------------------+-------------------------------+ 461 +--------------------------------+--------------+----------------+ 462 | site prefix = X |subnet ID = Y|0000000000000000| 463 +--------------------------------+--------------+----------------+ 465 Anyone Addresses work as follows: 467 If any system belonging to subnet A sends a packet to subnet 468 A's Anyone address, the packet shall be looped-back within 469 the sending system itself, since it is the nearest system to 470 itself with the subnet A prefix. If a system outside of 471 subnet A sends a packet to subnet A's Anyone address, the 472 packet shall be accepted by the first router on subnet A 473 that the packet reaches. 475 Similarly, a packet sent to site X's Anyone address from 476 outside of site X shall be accepted by the first encountered 477 router belonging to site X, i.e., one of site X's boundary 478 routers. If a higher-level prefix P identifies, say, a 479 particular service provider, then a packet sent to

480 from outside of provider P's facilities shall be 481 delivered to the nearest entry router into P's facilities. 483 Anyone addresses are most commonly used in conjunction with the 484 SIP source routing header, to cause a packet to be routed via 485 one or more specified "transit domains", without the need to 486 identify individual routers in those domains. 488 The value zero is reserved at each level of every unicast 489 address hierarchy, to serve as an Anyone address for that 490 level. 492 The Reserved Multicast Address: 7F0s:0000:0000:0000 493 This multicast address (with any scope value, s) is reserved, 494 and shall never be assigned to any multicast group. 496 The All Systems Addresses: 7F01:0000:0000:0001 497 7F02:0000:0000:0001 499 These multicast addresses identify the group of all SIP 500 systems, within scope 1 (intra-system) or 2 (intra-link). 502 The All Hosts Addresses: 7F01:0000:0000:0002 503 7F02:0000:0000:0002 505 These multicast addresses identify the group of all SIP hosts, 506 within scope 1 (intra-system) or 2 (intra-link). 508 The All Routers Addresses: 7F01:0000:0000:0003 509 7F02:0000:0000:0003 511 These multicast addresses identify the group of all SIP 512 routers, within scope 1 (intra-system) or 2 (intra-link). 514 A host is required to recognize the following addresses as 515 identifying itself: its own unicast addresses, the Anyone addresses 516 with the same subnet prefixes as its unicast addresses, the Loopback 517 address, the All Systems and All Hosts addresses, and any other 518 multicast addresses to which the host belongs. 520 A router is required to recognize the following addresses as 521 identifying itself: its own unicast addresses, the Anyone addresses 522 with the same subnet or higher-level prefixes as its unicast 523 addresses, the Loopback address, the All Systems and All Routers 524 addresses, and any other multicast addresses to which the host 525 belongs. 527 6. Packet Size Issues 529 SIP requires that every link in the internet have an MTU of 576 530 octets or greater. On any link that cannot convey a 576-octet packet 531 in one piece, link-specific fragmentation and reassembly must be 532 provided at a layer below SIP. 534 (Note: this minimum link MTU is NOT the same as the one in IPv4. 535 In IPv4, the minimum link MTU is 68 octets [ [RFC0791], page 25 ]; 536 576 octets is the minimum reassembly buffer size required in an 537 IPv4 system, which has nothing to do with link MTUs.) 539 From each link to which a system is directly attached, the system 540 must be able to accept packets as large as that link's MTU. Links 541 that have a configurable MTU, such as PPP links [RFC1661], should be 542 configured with an MTU of 600 octets or greater. 544 SIP systems are expected to implement Path MTU Discovery [RFC1191], 545 in order to discover and take advantage of paths with MTU greater 546 than 576 octets. However, a minimal SIP implementation (e.g., in a 547 boot ROM) may simply restrict itself to sending packets no larger 548 than 576 octets, and omit implementation of Path MTU Discovery. 550 Path MTU Discovery requires support both in the SIP layer and in the 551 packetization layers. A system that supports Path MTU Discovery at 552 the SIP layer may serve packetization layers that are unable to adapt 553 to changes of the path MTU. Such packetization layers must limit 554 themselves to sending packets no longer than 576 octets, even when 555 sending to destinations that belong to the same subnet. 557 (Note: Unlike IPv4, it is unnecessary in SIP to set a "Don't 558 Fragment" flag in the packet header in order to perform Path MTU 559 Discovery; that is an implicit attribute of every SIP packet. 560 Also, those parts of the RFC-1191 procedures that involve use of a 561 table of MTU "plateaus" do not apply to SIP, because the SIP 562 version of the "Datagram Too Big" message always identifies the 563 exact MTU to be used.) 565 7. Source Routing Header 567 A Payload Type of in the immediately preceding header indicates 568 the presence of this Source Routing header: 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Reserved | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Num Addrs | Next Addr | Payload Type | Reserved | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 + Address[0] + 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | | 580 + Address[1] + 581 | | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 . . . 584 . . . 585 . . . 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | | 588 + Address[Num Addrs - 1] + 589 | | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Reserved Initialized to zero for transmission; ignored 593 on reception. 595 Num Addrs Number of addresses in the Source Routing 596 header. 598 Next Addr Index of next address to be processed; 599 initialized to 0 by the originating system. 601 Payload Type Identifies the type of payload following the 602 Source Routing header. 604 A Source Routing header is not examined or processed until it reaches 605 the system identified in the Destination Address field of the SIP 606 header. In that system, dispatching on the Payload Type of the SIP 607 (or subsequent) header causes the Source Routing module to be 608 invoked, which performs the following algorithm: 610 o If Next Addr < Num Addrs, swap the SIP Destination Address and 611 Address[Next Addr], increment Next Addr by one, and re-submit the 612 packet to the SIP module for forwarding to the next destination. 614 o If Next Addr = Num Addrs, dispatch to the local protocol module 615 identified by the Payload Type field in the Source Routing header. 617 o If Next Addr > Num Addrs, send an ICMP Parameter Problem message 618 to the Source Address, pointing to the Num Addrs field. 620 8. Fragmentation Header 622 A Payload Type of in the immediately preceding header indicates 623 the presence of this Fragmentation header: 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Identification | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 |0 0 M| Fragment Offset | Payload Type | Reserved | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Identification A value that changes on each packet sent with 632 the same Source Address, Destination Address, 633 and preceding Payload Type. 635 M flag 1 = more fragments; 0 = last fragment. 637 Fragment Offset The offset, in 8-octet chunks, of the 638 following payload, relative to the original, 639 unfragmented payload. 641 Payload Type Identifies the type of payload following the 642 Fragmentation header. 644 Reserved Initialized to zero for transmission; ignored 645 on reception. 647 The Fragmentation header is NOT intended to support general, SIP- 648 layer fragmentation. In particular, SIP routers shall not fragment a 649 SIP packet that is too big for the MTU of its next hop, except in the 650 special cases described below; in the normal case, such a packet 651 results in an ICMP Packet Too Big message being sent back to its 652 source, for use by the source system's Path MTU Discovery algorithm. 654 The special cases for which the Fragmentation header is intended are 655 the following: 657 * A SIP packet that is "tunneled", either by encapsulation within 658 another SIP packet or by insertion of a Source Routing header 659 en-route, may, after the addition of the extra header fields, 660 exceed the MTU of the tunnel's path; if the original packet is 661 576 octets or less in length, the tunnel entry system cannot 662 respond to the source with a Packet Too Big message, and 663 therefore must insert a Fragmentation header and fragment the 664 packet to fit within the tunnel's MTU. 666 * An IPv4 fragment that is translated into a SIP packet, or an 667 unfragmented IPv4 packet that is translated into too long a SIP 668 packet to fit in the remaining path MTU, must include the SIP 669 Fragmentation header, so that it may be properly reassembled at 670 the destination SIP system. 672 Every SIP system must support SIP fragmentation and reassembly, since 673 any system may be configured to serve as a tunnel entry or exit 674 point, and any SIP system may be destination of IPv4 fragments. All 675 SIP systems must be capable of reassembling, from fragments, a SIP 676 packet of up to 1024 octets in length, including the SIP header; a 677 system may be capable of assembling packets longer than 1024 octets. 679 Routers do not examine or process Fragmentation headers of packets 680 that they forward; only at the destination system is the 681 Fragmentation header acted upon (i.e., reassembly performed), as a 682 result of dispatching on the Payload Type of the preceding header. 684 Fragmentation and reassembly employ the same algorithm as IPv4, with 685 the following exceptions: 687 * All headers up to and including the Fragmentation header are 688 repeated in each fragment; no headers or data following the 689 Fragmentation header are repeated in each fragment. 691 * the Identification field is increased to 32 bits, to decrease 692 the risk of wraparound of that field within the maximum packet 693 lifetime over very high-throughput paths. 695 The similarity of the algorithm and the field layout to that of IPv4 696 enables existing IPv4 fragmentation and reassembly code and data 697 structures to be re-used with little modification. 699 9. Changes to Other Protocols 701 Upgrading IPv4 to SIP entails changes to the associated control 702 protocols, ICMP and IGMP, as well as to the transport layer, above, 703 and possibly to the link-layer, below. This section identifies those 704 changes. 706 9.1. Changes to ICMP 708 SIP uses a subset of ICMP [ [RFC0792], [RFC0950], [RFC1122], 709 [RFC1191], [RFC1256]] , with a few minor changes and some additions. 710 The presence of an ICMP header is indicated by a Payload Type of 1. 712 One change to all ICMP messages is that, when used with SIP, the ICMP 713 checksum includes a pseudo-header, like TCP and UDP, consisting of 714 the SIP Source Address, Destination Address, Payload Length, and 715 Payload Type (see section 8.3). 717 There are a set of ICMP messages called "error messages", each of 718 which, for IPv4, carries the IPv4 header plus 64 bits or more of data 719 from the packet that invoked the error message. When used with SIP, 720 ICMP error messages carry the first 256 octets of the invoking SIP 721 packet, or the entire invoking packet if it is shorter than 256 722 octets. 724 For most of the ICMP message types, the packets retain the same 725 format and semantics as with IPv4; however, some of the fields are 726 given new names to match SIP terminology. 728 The changes to specific message types are as follows: 730 Destination Unreachable 732 The following Codes have different names when used with SIP: 734 1 - destination address unreachable (IPv4 "host 735 unreachable") 736 7 - destination address unknown (IPv4 "dest. host unknown") 737 2 - payload type unknown (IPv4 "protocol unreachable") 738 4 - packet too big (IPv4 "fragmentation needed and DF set") 740 The following Codes retain the same names when used with SIP: 742 3 - port unreachable 743 5 - source route failed 744 8 - source host isolated 745 13 - communication administratively prohibited 747 The following Codes are not used with SIP: 749 0 - net unreachable 750 6 - destination network unknown 751 9 - comm. with dest. network administratively prohibited 752 10 - comm. with dest. host administratively prohibited 753 11 - network unreachable for type of service 754 12 - host unreachable for type of service 756 For "packet too big" messages (Code 4), the minimum legal value 757 in the Next-Hop MTU field [RFC1191] is 576. 759 Time Exceeded 761 The name of Code 0 is changed to "hop limit exceeded in 762 transit". 764 Parameter Problem 766 The Pointer field is extended to 16 bits and moved to the low- 767 order end of the second 32-bit word, as follows: 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Type | Code | Checksum | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Reserved | Pointer | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | | 775 | first 256 octets of the invoking packet | 776 | | 778 Redirect 780 Only Code 1 is used for SIP, meaning "redirect packets for the 781 destination address". 783 The Redirect header is modified for SIP, to accommodate the 784 64-bit address of the "preferred router" and to retain 64-bit 785 alignment, as follows: 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Type | Code | Checksum | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Reserved | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | | 793 + Preferred Router + 794 | | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | | 797 | first 256 octets of the invoking packet | 798 | | 800 Router Advertisement 802 The format of the Router Advertisement message is changed to: 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Type | Code | Checksum | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Num Addrs |Addr Entry Size| Lifetime | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | | 810 + Router Address[0] + 811 | | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Preference Level[0] | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Reserved[0] | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | | 818 + Router Address[1] + 819 | | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Preference Level[1] | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | Reserved[1] | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | . | 826 | . | 827 | . | 829 The value in the Addr Entry Size field is 4, and all of the 830 Reserved fields are initialized to zero by senders and ignored 831 by receivers. 833 Router Solicitation 835 No changes. 837 Echo and Echo Reply 839 No changes. 841 The following ICMP message types are not used with SIP: 843 Source Quench 844 Timestamp 845 Timestamp Reply 846 Information Request 847 Information Reply 848 Address Mask Request 849 Address Mask Reply 851 9.2. Changes to IGMP 853 SIP uses the Internet Group Management Protocol, IGMP [RFC1112]. The 854 presence of an IGMP header is indicated by a Payload Type of 2. 856 When used with SIP, the IGMP checksum includes a pseudo-header, like 857 TCP and UDP, consisting of the SIP Source Address, Destination 858 Address, Payload Length, and Payload Type (see section 8.3). 860 The format of an IGMP Host Membership Query message becomes: 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 |Version| Type | Reserved | Checksum | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Reserved | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 The format of an IGMP Host Membership Report message becomes: 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 |Version| Type | Reserved | Checksum | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | Reserved | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | | 876 + Multicast Address + 877 | | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 For both message types, the Version number remains 1, and the 881 Reserved fields are set to zero by senders and ignored by receivers. 883 9.3. Changes to Transport Protocols 885 The service interface to SIP has some differences from IPv4's service 886 interface. Existing transport protocols that use IPv4 must be 887 changed to operate over SIP's service interface. The differences 888 from IPv4 are: 890 * Any addresses passed across the interface are 64 bits long, 891 rather than 32 bits. 893 * The following IPv4 variables are not passed across the 894 interface: Precedence, Type-of-Service, Identifier, Don't 895 Fragment Flag 897 * SIP options have a different format than IPv4 options. (For 898 SIP, "options" are all headers between, and not including, the 899 SIP header and the transport header. The only IPv4 option 900 currently specified for SIP is Loose Source Routing. 902 * ICMP error messages for SIP that are passed up to the transport 903 layer carry the first 256 octets of the invoking SIP packet. 905 Transport protocols that use IPv4 addresses for their own purposes, 906 such as identifying connection state or inclusion in a pseudo-header 907 checksum, must be changed to use 64-bit SIP addresses for those 908 purposes instead. 910 For SIP, the pseudo-header checksums of TCP, UDP, ICMP, and IGMP 911 include the SIP Source Address, Destination Address, Payload Length, 912 and Payload Type, with the following caveats: 914 * If the packet contains a Source Routing header, the destination 915 address used in the pseudo-header checksum is that of the final 916 destination. 918 * The Payload Length used in the pseudo-header checksum is the 919 length of the transport-layer packet, including the transport 920 header. 922 * The Payload Type used in the pseudo-header checksum is the 923 Payload Type from the header immediately preceding the 924 transport header. 926 * When added to the pseudo-header checksum, the Payload Type is 927 treated as the left octet of a 16-bit word, with zeros in the 928 the right octet, when viewed in IP standard octet order. 930 * If either of the two addresses used in the pseudo-header 931 checksum has its high-order bit set to 1, only the low-order 932 32-bits of that address shall be used in the sum. The high- 933 order bit is used to indicate that the addressed system is an 934 IPv4 system, and that the low-order 32-bits of the address 935 contain that system's IPv4 address [IPAE]. 937 The semantics of SIP service differ from IPv4 service in three ways 938 that may affect some transport protocols: 940 (1) SIP does not enforce maximum packet lifetime. Any transport 941 protocol that relies on IPv4 to limit packet lifetime must 942 take this change into account, for example, by providing its 943 own mechanisms for detecting and discarding obsolete packets. 945 (2) SIP does not checksum its own header fields. Any transport 946 protocol that relies on IPv4 to assure the integrity of the 947 source and destinations addresses, packet length, and 948 transport protocol identifier must take this change into 949 account. In particular, when used with SIP, the UDP checksum 950 is mandatory, and ICMP and IGMP are changed to use a pseudo- 951 header checksum. 953 (3) SIP does not (except in special cases) fragment packets that 954 exceed the MTU of their delivery paths. Therefore, a 955 transport protocol must not send packets longer than 576 956 octets unless it implements Path MTU Discovery [RFC1191] and 957 is capable of adapting its transmitted packet size in 958 response to changes of the path MTU. 960 9.4. Changes to Link-Layer Protocols 962 Link-layer media that have an MTU less than 576 must be enhanced with 963 a link-specific fragmentation and reassembly mechanism, to support 964 SIP. 966 For links on which ARP is used by IPv4, the identical ARP protocol is 967 used for SIP. The low-order 32-bits of SIP addresses are used 968 wherever IPv4 addresses would appear; since ARP is used only among 969 systems on the same subnet, the high-order 32-bits of the SIP 970 addresses may be inferred from the subnet prefix (assuming the subnet 971 prefix is at least 32 bits long). [This is subject to change -- see 972 Appendix B.] 974 10. Security Considerations 976 978 11. Acknowledgments 980 The author acknowledges the many helpful suggestions and the words of 981 encouragement from Dave Clark, Dave Crocker, Deborah Estrin, Bob 982 Hinden, Christian Huitema, Van Jacobson, Jeff Mogul, Dave Nichols, 983 Erik Nordmark, Dave Oran, Craig Partridge, Scott Shenker, Paul 984 Tsuchiya, Lixia Zhang, the members of End-to-End Research Group and 985 the IPAE Working Group, and the participants in the big-internet and 986 sip mailing lists. He apologizes to those whose names he has not 987 explicitly listed. [If you want to be on the list in the next draft, 988 just let him know!] 990 Editor's note: Stephen E. Deering was employed by the Xerox Palo Alto 991 Research Center in Palo Alto, CA USA when this work was done. 993 12. References 995 [IPAE] Crocker, D. and R. Hinden, "IP Address Encapsulation 996 (IPAE): A Mechanism for Introducing a New IP", , June 997 2002, . 1000 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 1001 10.17487/RFC0791, September 1981, . 1004 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1005 RFC 792, DOI 10.17487/RFC0792, September 1981, 1006 . 1008 [RFC0950] Mogul, J. and J. Postel, "Internet Standard Subnetting 1009 Procedure", STD 5, RFC 950, DOI 10.17487/RFC0950, August 1010 1985, . 1012 [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, 1013 DOI 10.17487/RFC0951, September 1985, . 1016 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1017 RFC 1112, DOI 10.17487/RFC1112, August 1989, 1018 . 1020 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 1021 Communication Layers", STD 3, RFC 1122, DOI 10.17487/ 1022 RFC1122, October 1989, . 1025 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1026 DOI 10.17487/RFC1191, November 1990, . 1029 [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1030 1256, DOI 10.17487/RFC1256, September 1991, 1031 . 1033 [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 1034 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, 1035 . 1037 [RFC1710] Hinden, R., "Simple Internet Protocol Plus White Paper", 1038 RFC 1710, DOI 10.17487/RFC1710, October 1994, 1039 . 1041 [RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP 1042 Next Generation Protocol", RFC 1752, DOI 10.17487/RFC1752, 1043 January 1995, . 1045 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1046 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, 1047 December 1995, . 1049 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1050 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/ 1051 RFC8200, July 2017, . 1054 [SIP-ADDR] 1055 Deering, S., "Simple Internet Protocol (SIP) Addressing 1056 and Routing", Internet Draft , November 1992. 1058 Appendix A. SIP Design Rationale 1060 1062 Fields present in IPv4, but absent in SIP: 1064 Header Length Not needed; SIP header length is fixed. 1066 Precedence & 1067 Type of Service Not used; transport-layer Port fields (or 1068 perhaps a to-be-defined value in the Reserved 1069 field of the SIP header) may be used for 1070 classifying packets at a granularity finer than 1071 host-to-host, as required for special handling. 1073 Header Checksum Not used; transport pseudo-header checksum 1074 protects destinations from accepting corrupted 1075 packets. 1077 Need to justify: 1079 change of Total Length -> Payload Length, excluding header 1080 change of Protocol -> Payload Type 1081 change of Time to Live -> Hop Limit 1082 movement of fragmentation fields out of fixed header 1083 bigger minimum MTU, and reliance on PMTU Discovery 1085 Appendix B. Future Directions 1087 SIP as specified above is a fully functional replacement for IPv4, 1088 with a number of improvements, particularly in the areas of 1089 scalability of routing and addressing, and performance. Some 1090 additional improvements are still under consideration: 1092 * ARP may be modified to carry full 64-bit addresses, and to use 1093 link-layer multicast addresses, rather than broadcast 1094 addresses. 1096 * The 28-bit Reserved field in the SIP header may be defined as a 1097 "Flow ID", or partitioned into a Type of Service field and a 1098 Flow ID field, for classifying packets deserving of special 1099 handling, e.g., non-default quality of service or real-time 1100 service. On the other hand, the transport-layer port fields 1101 may be adequate for performing any such classification. (One 1102 possibility would be simply to remove the port fields from TCP 1103 & UDP and append them to the SIP header, as in XNS.) 1105 * A new ICMP "destination has moved" message may defined, for re- 1106 routing to mobile hosts or subnets, and to domains that have 1107 changed their address prefixes. 1109 * An explicit Trace Route message or option may be defined; the 1110 current IPv4 traceroute scheme will work fine with SIP, but it 1111 does not work for multicast, for which it has become very 1112 apparent that management and debugging tools are needed. 1114 * A new Host-to-Router protocol may be specified, encompassing 1115 the requirements of router discovery, black-hole detection, 1116 auto- configuration of subnet prefixes, "beaconing" for mobile 1117 hosts, and, possibly, address resolution. The OSI End System 1118 To Intermediate System Protocol may serve as a good model for 1119 such a protocol. 1121 * The requirement that SIP addresses be strictly bound to 1122 interfaces may be relaxed, so that, for example, a system might 1123 have fewer addresses than interfaces. There is some experience 1124 with this approach in the current Internet, with the use of 1125 "unnumbered links" in routing protocols such as OSPF. 1127 * Authentication and integrity-assurance mechanisms for all 1128 clients of SIP, including ICMP and IGMP, may be specified, 1129 possibly based on the Secure Data Network System (SNDS) SP-3 or 1130 SP-4 protocol. 1132 Authors' Addresses 1134 Stephen E. Deering 1135 Retired 1136 Vancouver, British Columbia 1137 Canada 1139 Robert M. Hinden (editor) 1140 Check Point Software 1141 959 Skyway Road 1142 San Carlos, CA 94070 1143 USA 1145 Email: bob.hinden@gmail.com