idnits 2.17.1 draft-deering-sip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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. ** There are 52 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 62 instances of lines with control characters in the document. ** 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: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 731 -- Looks like a reference, but probably isn't: '1' on line 739 -- Possible downref: Non-RFC (?) normative reference: ref. 'IPAE' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIP-ADDR' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Steve Deering 3 November 10, 1992 Xerox PARC 5 Simple Internet Protocol (SIP) 6 Specification 8 Abstract 10 This document specifies a new version of IP called SIP, the Simple 11 Internet Protocol. It also describes the changes needed to ICMP, IGMP, 12 and transport protocols such as TCP and UDP, in order to work with SIP. 13 A companion document [SIP-ADDR] describes the addressing and routing 14 aspects of SIP, including issues of auto-configuration, host and subnet 15 mobility, and multicast. 17 Contents 19 Status of this Memo 21 1. Introduction 22 2. Terminology 23 3. SIP Header Format 24 4. Addresses 25 4.1 Text Representation of Addresses 26 4.2 Unicast Addresses 27 4.3 Multicast Addresses 28 4.4 Special Addresses 29 5. Packet Size Issues 30 6. Source Routing Header 31 7. Fragmentation Header 32 8. Changes to Other Protocols 33 8.1 Changes to ICMP 34 8.2 Changes to IGMP 35 8.3 Changes to Transport Protocols 36 8.4 Changes to Link-Layer Protocols 38 Appendix A. SIP Design Rationale 39 Appendix B. Future Directions 41 Security Considerations 42 Acknowledgments 43 Author's Address 44 References 46 Status of this Memo 48 Internet Drafts are working documents of the Internet Engineering Task 49 Force (IETF), its Areas, and its Working Groups. Note that other groups 50 may also distribute working documents as Internet Drafts. 52 Internet Drafts are draft documents valid for a maximum of six months. 53 This Internet Draft expires on April 10, 1993. Internet Drafts may be 54 updated, replaced, or obsoleted by other documents at any time. It is not 55 appropriate to use Internet Drafts as reference material or to cite them 56 other than as a "working draft" or "work in progress." 58 Please check the I-D abstract listing contained in each Internet Draft 59 directory to learn the current status of this or any other Internet Draft. 61 Distribution of this memo is unlimited. 63 1. Introduction 65 SIP is a new version of IP. Its salient differences from IP version 4 66 [RFC-791], subsequently referred to as "IPv4", are: 68 o expansion of addresses to 64 bits, 70 o simplification of the IP header by eliminating some inessential 71 fields, and 73 o relaxation of length restrictions on optional data, such as 74 source-routing information. 76 SIP retains the IP model of globally-unique addresses, hierarchically- 77 structured for efficient routing. Increasing the address size from 32 78 to 64 bits allows more levels of hierarchy to be encoded in the addresses, 79 enough to enable efficient routing in an internet with tens of thousands 80 of addressable devices in every office, every residence, and every 81 vehicle in the world. Keeping the addresses fixed-length and relatively 82 compact facilitates high-performance router and host implementation, 83 and keeps the bandwidth overhead of the SIP headers almost as low as IPv4. 85 The elimination of inessential fields also contributes to high-performance 86 implementation, and to the likelihood of correct implementation. A 87 change in the way that optional data, such as source-routing information, 88 is encoded allows for more efficient forwarding and less stringent 89 limits on the length of such data. 91 Despite these changes, SIP remains very similar to IPv4. This similarity 92 makes it easy to understand SIP (for those who already understand IPv4), 93 makes it possible to reuse much of the code and data structures from 94 IPv4 in an implementation of SIP (including almost all of ICMP and IGMP), 95 and makes it straightforward to translate between SIP packets and IPv4 96 packets for transition purposes [IPAE]. 98 The subsequent sections of this document specify SIP and its associated 99 protocols without much explanation of why the design choices were made 100 the way they were. Appendix A presents the rationale for those aspects 101 of SIP that differ from IPv4. 103 2. Terminology 105 system - a device that implements SIP. 107 router - a system that forwards SIP packets. 109 host - any system that is not a router. 111 link - a communication facility or medium over which systems 112 can communicate at the link layer, i.e., the layer 113 immediately below SIP. 115 interface - a system's attachment point to a link. 117 address - a SIP-layer identifier for an interface or a group of 118 interfaces. 120 subnet - in the SIP unicast addressing hierarchy, a lowest-level 121 (finest-grain) cluster of addresses, sharing a common 122 address prefix (i.e., high-order address bits). 123 Typically, all interfaces attached to the same link have 124 addresses in the same subnet; however, in some cases, 125 a single link may support more than one subnet, or a 126 single subnet may span more than one link. 128 link MTU - the maximum transmission unit, i.e., maximum packet size 129 in octets, that can be conveyed in one piece over a link 130 (where a packet is a SIP header plus payload). 132 path MTU - the minimum link MTU of all the links in a path between 133 a source system and a destination system. 135 packetization 136 layer - any protocol layer above SIP that is responsible for 137 packetizing data to fit within outgoing SIP packets. 138 Typically, transport-layer protocols, such as TCP, are 139 packetization protocols, but there may also be higher- 140 layer packetization protocols, such as protocols 141 implemented on top of UDP. 143 3. SIP Header Format 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 |Version| Reserved | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Payload Length | Payload Type | Hop Limit | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | | 151 + Source Address + 152 | | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | | 155 + Destination Address + 156 | | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Version 4-bit IP version number = decimal 6. 160 162 Reserved 28-bit reserved field. Initialized to zero 163 for transmission; ignored on reception. 165 Payload Length 16-bit unsigned integer. Length of payload, 166 i.e., the rest of the packet following the 167 SIP header, in octets. 169 Payload Type 8-bit selector. Identifies the type of 170 payload, e.g., TCP. 172 Hop Limit 8-bit unsigned integer. Decremented by 1 173 by each system that forwards the packet. 174 The packet is discarded if Hop Limit is 175 decremented to zero. 177 Source Address 64 bits. See "Addresses" section, following. 179 Destination Address 64 bits. See "Addresses" section, following. 181 4. Addresses 183 4.1 Text Representation of Addresses 185 SIP addresses are 64 bits (8 octets) long. The text representation of a 186 SIP addresses is 16 hexadecimal digits, with a colon between the 4th and 187 5th digits, and optional colons between any subsequent pair of digits. 188 Leading zeros must not be dropped. Examples: 190 0123:4567:89AB:CDEF 192 0123:456789ABCDEF 194 0123:456789AB:CDE:F 196 Programs that read the text representation of SIP addresses must be 197 insensitive to the presence or absence of optional colons. Programs 198 that write the text representation of a SIP address should use the first 199 format above (i.e., colons after the 4th, 8th, and 12th digits), in the 200 absence of any knowledge of the structure or preferred format of the 201 address, such as knowledge of the format in which it was originally read. 203 The presence of at least one colon in the text representation allows 204 SIP addresses to be easily distinguished from both domain names and 205 the text representation of IPv4 addresses. 207 4.2 Unicast Addresses 209 A SIP unicast address is a globally-unique identifier for a single 210 interface, i.e., no two interfaces in a SIP internet may have the same 211 unicast address. A single interface may, however, have more than one 212 unicast address. 214 A system considers its own unicast address(es) to have the following 215 structure, where different addresses may have different values for n: 217 | n bits | 64-n bits | 218 +----------------------------------------------------+------------+ 219 | subnet prefix |interface ID| 220 +----------------------------------------------------+------------+ 222 To know the length of the subnet prefix, the system is required to 223 associate with each of its addresses a 'subnet mask' of the following 224 form: 226 | n bits | 64-n bits | 227 +----------------------------------------------------+------------+ 228 |1111111111111111111111111111111111111111111111111111|000000000000| 229 +----------------------------------------------------+------------+ 231 A system may have a subnet mask of all-ones, which means that the system 232 belongs to a subnet containing exactly one system -- itself. 234 A system acquires its subnet mask(s) at the same time, and by the 235 same mechanism, as it acquires its address(es), for example, by 236 manual configuration or by a dynamic configuration protocol such as 237 BOOTP [RFC-BOOTP?]. 239 Hosts are ignorant of any further structure in a unicast address. 241 Routers may acquire, through manual configuration or the operation of 242 routing protocols, additional masks that identify higher-level clusters 243 in a hierarchical addressing plan. For example, the routers within 244 a single site would typically have a 'site mask', such as the following: 246 | m bits | 64-m bits | 247 +-----------------------------------------+-----------------------+ 248 |11111111111111111111111111111111111111111|00000000000000000000000| 249 +-----------------------------------------+-----------------------+ 251 by which they could deduce the following structure in the site's 252 addresses: 254 | m bits | p bits | 64-m-p bits| 255 +-----------------------------------------+----------+------------+ 256 | site prefix |subnet ID|interface ID| 257 +-----------------------------------------+----------+------------+ 259 All knowledge by SIP systems of the structure of unicast addresses is 260 based on possession of such masks -- there is no "wired-in" knowledge 261 of unicast address formats. 263 The SIP Addressing and Routing document [SIP-ADDR] proposes two 264 hierarchical addressing plans, one based on a hierarchy of SIP 265 service providers, and one based on a geographic hierarchy. 267 4.3 Multicast Addresses 269 A SIP multicast address is an identifier for a group of interfaces. 270 An interface may belong to any number of multicast groups. Multicast 271 addresses have the following format: 273 |1| 7 | 4 | 4 | 48 bits | 274 +-+-------+----+----+---------------------------------------------+ 275 |C|1111111|flgs|scop| group ID | 276 +-+-------+----+----+---------------------------------------------+ 278 where: 280 C = IPv4 compatibility flag; see [IPAE]. 282 1111111 in the rest of the first octet identifies the address as 283 being a multicast address. 285 +-+-+-+-+ 286 flgs is a set of 4 flags: |0|0|0|T| 287 +-+-+-+-+ 289 the high-order 3 flags are reserved, and must be initialized to 0. 291 T = 0 indicates a permanently-assigned ("well-known") multicast 292 address, assigned by the global internet numbering authority. 294 T = 1 indicates a non-permanently-assigned ("transient") multicast 295 address. 297 scop is a 4-bit multicast scope value: 299 0 reserved 300 1 intra-system scope 301 2 intra-link scope 302 3 (unassigned) 303 4 (unassigned) 304 5 intra-site scope 305 6 (unassigned) 306 7 (unassigned) 307 8 intra-metro scope 308 9 (unassigned) 309 A (unassigned) 310 B intra-country scope 311 C (unassigned) 312 D (unassigned) 313 E global scope 314 F reserved 316 group ID identifies the multicast group, either permanent or 317 transient, within the given scope. 319 The "meaning" of a permanently-assigned multicast address is independent 320 of the scope value. For example, if the "NTP servers group" is assigned 321 a permanent multicast address with a group ID of 43 (hex), then: 323 7F01:000000000043 means all NTP servers on the same system as the sender. 325 7F02:000000000043 means all NTP servers on the same link as the sender. 327 7F05:000000000043 means all NTP servers at the same site as the sender. 329 7F0E:000000000043 means all NTP servers in the internet. 331 Non-permanently-assigned multicast addresses are meaningful only within 332 a given scope. For example, a group identified by the non-permanent, 333 intra-site multicast address 7F15:000000000043 at one site bears no 334 relationship to a group using the same address at a different site, nor 335 to a non-permanent group using the same group ID with different scope, 336 nor to a permanent group with the same group ID. 338 4.4 Special Addresses 340 There are a number of "special purpose" SIP addresses: 342 The Unspecified Address: 0000:0000:0000:0000 344 This address shall never be assigned to any system. It may be used 345 wherever an address appears, to indicate the absence of an address. 346 One example of its use is in the Source Address field of a SIP 347 packet sent by an initializing host, before it has learned its 348 own address. 350 The Loopback Address: 0000:0000:0000:0001 352 This address may be used by a system to send a SIP packet to itself. 354 Anyone Addresses: 356 Addresses of this form may be used to send to the "nearest" system 357 (according the routing protocols' measure of distance) that "knows" 358 it has a unicast address prefix of . 360 Since hosts know only their subnet prefix(es), and no higher-level 361 prefixes, a host with the following address: 363 +------------------------------------------------+----------------+ 364 | subnet prefix = A |interface ID = B| 365 +------------------------------------------------+----------------+ 367 shall recognize only the following Anyone address as identifying 368 itself: 370 +------------------------------------------------+----------------+ 371 | subnet prefix = A |0000000000000000| 372 +------------------------------------------------+----------------+ 374 An intra-site router that knows that one of its addresses has the 375 format: 377 +---------------------------------+--------------+----------------+ 378 | site prefix = X |subnet ID = Y|interface ID = Z| 379 +---------------------------------+--------------+----------------+ 381 shall accept packets sent to either of the following two Anyone 382 addresses as if they had been sent to the router's own address: 384 +---------------------------------+-------------------------------+ 385 | site prefix = X |0000000000000000000000000000000| 386 +---------------------------------+-------------------------------+ 388 +---------------------------------+--------------+----------------+ 389 | site prefix = X |subnet ID = Y|0000000000000000| 390 +---------------------------------+--------------+----------------+ 391 Anyone Addresses work as follows: 393 If any system belonging to subnet A sends a packet to subnet A's 394 Anyone address, the packet shall be looped-back within the sending 395 system itself, since it is the nearest system to itself with the 396 subnet A prefix. If a system outside of subnet A sends a packet to 397 subnet A's Anyone address, the packet shall be accepted by the first 398 router on subnet A that the packet reaches. 400 Similarly, a packet sent to site X's Anyone address from outside of 401 site X shall be accepted by the first encountered router belonging 402 to site X, i.e., one of site X's boundary routers. If a higher-level 403 prefix P identifies, say, a particular service provider, then a 404 packet sent to

from outside of provider P's facilities 405 shall be delivered to the nearest entry router into P's facilities. 407 Anyone addresses are most commonly used in conjunction with the SIP 408 source routing header, to cause a packet to be routed via one or more 409 specified "transit domains", without the need to identify individual 410 routers in those domains. 412 The value zero is reserved at each level of every unicast address 413 hierarchy, to serve as an Anyone address for that level. 415 The Reserved Multicast Address: 7F0s:0000:0000:0000 417 This multicast address (with any scope value, s) is reserved, and 418 shall never be assigned to any multicast group. 420 The All Systems Addresses: 7F01:0000:0000:0001 421 7F02:0000:0000:0001 423 These multicast addresses identify the group of all SIP systems, 424 within scope 1 (intra-system) or 2 (intra-link). 426 The All Hosts Addresses: 7F01:0000:0000:0002 427 7F02:0000:0000:0002 429 These multicast addresses identify the group of all SIP hosts, 430 within scope 1 (intra-system) or 2 (intra-link). 432 The All Routers Addresses: 7F01:0000:0000:0003 433 7F02:0000:0000:0003 435 These multicast addresses identify the group of all SIP routers, 436 within scope 1 (intra-system) or 2 (intra-link). 438 A host is required to recognize the following addresses as identifying 439 itself: its own unicast addresses, the Anyone addresses with the same 440 subnet prefixes as its unicast addresses, the Loopback address, the 441 All Systems and All Hosts addresses, and any other multicast addresses 442 to which the host belongs. 444 A router is required to recognize the following addresses as identifying 445 itself: its own unicast addresses, the Anyone addresses with the same 446 subnet or higher-level prefixes as its unicast addresses, the Loopback 447 address, the All Systems and All Routers addresses, and any other multicast 448 addresses to which the host belongs. 450 5. Packet Size Issues 452 SIP requires that every link in the internet have an MTU of 576 octets or 453 greater. On any link that cannot convey a 576-octet packet in one piece, 454 link-specific fragmentation and reassembly must be provided at a layer 455 below SIP. 457 (Note: this minimum link MTU is NOT the same as the one in IPv4. 458 In IPv4, the minimum link MTU is 68 octets [RFC-791, page 25]; 459 576 octets is the minimum reassembly buffer size required in an 460 IPv4 system, which has nothing to do with link MTUs.) 462 From each link to which a system is directly attached, the system must be 463 able to accept packets as large as that link's MTU. Links that have a 464 configurable MTU, such as PPP links [RFC-PPP?], should be configured with 465 an MTU of 600 octets or greater. 467 SIP systems are expected to implement Path MTU Discovery [RFC-1191], in 468 order to discover and take advantage of paths with MTU greater than 576 469 octets. However, a minimal SIP implementation (e.g., in a boot ROM) may 470 simply restrict itself to sending packets no larger than 576 octets, and 471 omit implementation of Path MTU Discovery. 473 Path MTU Discovery requires support both in the SIP layer and in the 474 packetization layers. A system that supports Path MTU Discovery at the 475 SIP layer may serve packetization layers that are unable to adapt to 476 changes of the path MTU. Such packetization layers must limit themselves 477 to sending packets no longer than 576 octets, even when sending to 478 destinations that belong to the same subnet. 480 (Note: Unlike IPv4, it is unnecessary in SIP to set a "Don't Fragment" 481 flag in the packet header in order to perform Path MTU Discovery; that 482 is an implicit attribute of every SIP packet. Also, those parts of 483 the RFC-1191 procedures that involve use of a table of MTU "plateaus" 484 do not apply to SIP, because the SIP version of the "Datagram Too Big" 485 message always identifies the exact MTU to be used.) 487 6. Source Routing Header 489 A Payload Type of in the immediately preceding header indicates the 490 presence of this Source Routing header: 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Reserved | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Num Addrs | Next Addr | Payload Type | Reserved | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 + Address[0] + 499 | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | | 502 + Address[1] + 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 . . . 506 . . . 507 . . . 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | | 510 + Address[Num Addrs - 1] + 511 | | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Reserved Initialized to zero for transmission; ignored 515 on reception. 517 Num Addrs Number of addresses in the Source Routing header. 519 Next Addr Index of next address to be processed; 520 initialized to 0 by the originating system. 522 Payload Type Identifies the type of payload following the 523 Source Routing header. 525 A Source Routing header is not examined or processed until it reaches 526 the system identified in the Destination Address field of the SIP 527 header. In that system, dispatching on the Payload Type of the SIP 528 (or subsequent) header causes the Source Routing module to be invoked, 529 which performs the following algorithm: 531 o If Next Addr < Num Addrs, swap the SIP Destination Address and 532 Address[Next Addr], increment Next Addr by one, and re-submit the 533 packet to the SIP module for forwarding to the next destination. 535 o If Next Addr = Num Addrs, dispatch to the local protocol module 536 identified by the Payload Type field in the Source Routing header. 538 o If Next Addr > Num Addrs, send an ICMP Parameter Problem message 539 to the Source Address, pointing to the Num Addrs field. 541 7. Fragmentation Header 543 A Payload Type of in the immediately preceding header indicates the 544 presence of this Fragmentation header: 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Identification | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 |0 0 M| Fragment Offset | Payload Type | Reserved | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Identification A value that changes on each packet sent with 553 the same Source Address, Destination Address, 554 and preceding Payload Type. 556 M flag 1 = more fragments; 0 = last fragment. 558 Fragment Offset The offset, in 8-octet chunks, of the following 559 payload, relative to the original, unfragmented 560 payload. 562 Payload Type Identifies the type of payload following the 563 Fragmentation header. 565 Reserved Initialized to zero for transmission; ignored 566 on reception. 568 The Fragmentation header is NOT intended to support general, SIP-layer 569 fragmentation. In particular, SIP routers shall not fragment a SIP 570 packet that is too big for the MTU of its next hop, except in the special 571 cases described below; in the normal case, such a packet results in an 572 ICMP Packet Too Big message being sent back to its source, for use by the 573 source system's Path MTU Discovery algorithm. 575 The special cases for which the Fragmentation header is intended are the 576 following: 578 o A SIP packet that is "tunneled", either by encapsulation within 579 another SIP packet or by insertion of a Source Routing header 580 en-route, may, after the addition of the extra header fields, 581 exceed the MTU of the tunnel's path; if the original packet is 582 576 octets or less in length, the tunnel entry system cannot 583 respond to the source with a Packet Too Big message, and therefore 584 must insert a Fragmentation header and fragment the packet to fit 585 within the tunnel's MTU. 587 o An IPv4 fragment that is translated into a SIP packet, or an 588 unfragmented IPv4 packet that is translated into too long a SIP 589 packet to fit in the remaining path MTU, must include the SIP 590 Fragmentation header, so that it may be properly reassembled at 591 the destination SIP system. 593 Every SIP system must support SIP fragmentation and reassembly, since 594 any system may be configured to serve as a tunnel entry or exit point, 595 and any SIP system may be destination of IPv4 fragments. All SIP systems 596 must be capable of reassembling, from fragments, a SIP packet of up to 597 1024 octets in length, including the SIP header; a system may be capable 598 of assembling packets longer than 1024 octets. 600 Routers do not examine or process Fragmentation headers of packets that 601 they forward; only at the destination system is the Fragmentation header 602 acted upon (i.e., reassembly performed), as a result of dispatching on 603 the Payload Type of the preceding header. 605 Fragmentation and reassembly employ the same algorithm as IPv4, with 606 the following exceptions: 608 o All headers up to and including the Fragmentation header are 609 repeated in each fragment; no headers or data following the 610 Fragmentation header are repeated in each fragment. 612 o the Identification field is increased to 32 bits, to decrease 613 the risk of wraparound of that field within the maximum packet 614 lifetime over very high-throughput paths. 616 The similarity of the algorithm and the field layout to that of IPv4 617 enables existing IPv4 fragmentation and reassembly code and data 618 structures to be re-used with little modification. 620 8. Changes to Other Protocols 622 Upgrading IPv4 to SIP entails changes to the associated control protocols, 623 ICMP and IGMP, as well as to the transport layer, above, and possibly to 624 the link-layer, below. This section identifies those changes. 626 8.1 Changes to ICMP 628 SIP uses a subset of ICMP [RFC-792, RFC-950, RFC-1122, RFC-1191, RFC-1256], 629 with a few minor changes and some additions. The presence of an ICMP 630 header is indicated by a Payload Type of 1. 632 One change to all ICMP messages is that, when used with SIP, the ICMP 633 checksum includes a pseudo-header, like TCP and UDP, consisting of the 634 SIP Source Address, Destination Address, Payload Length, and Payload 635 Type (see section 8.3). 637 There are a set of ICMP messages called "error messages", each of which, 638 for IPv4, carries the IPv4 header plus 64 bits or more of data from the 639 packet that invoked the error message. When used with SIP, ICMP error 640 messages carry the first 256 octets of the invoking SIP packet, or the 641 entire invoking packet if it is shorter than 256 octets. 643 For most of the ICMP message types, the packets retain the same format 644 and semantics as with IPv4; however, some of the fields are given new 645 names to match SIP terminology. 647 The changes to specific message types are as follows: 649 Destination Unreachable 651 The following Codes have different names when used with SIP: 653 1 - destination address unreachable (IPv4 "host unreachable") 654 7 - destination address unknown (IPv4 "dest. host unknown") 655 2 - payload type unknown (IPv4 "protocol unreachable") 656 4 - packet too big (IPv4 "fragmentation needed and DF set") 658 The following Codes retain the same names when used with SIP: 660 3 - port unreachable 661 5 - source route failed 662 8 - source host isolated 663 13 - communication administratively prohibited 665 The following Codes are not used with SIP: 667 0 - net unreachable 668 6 - destination network unknown 669 9 - comm. with dest. network administratively prohibited 670 10 - comm. with dest. host administratively prohibited 671 11 - network unreachable for type of service 672 12 - host unreachable for type of service 673 For "packet too big" messages (Code 4), the minimum legal value 674 in the Next-Hop MTU field [RFC-1191] is 576. 676 Time Exceeded 678 The name of Code 0 is changed to "hop limit exceeded in transit". 680 Parameter Problem 682 The Pointer field is extended to 16 bits and moved to the low-order 683 end of the second 32-bit word, as follows: 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Type | Code | Checksum | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Reserved | Pointer | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | | 691 | first 256 octets of the invoking packet | 692 | | 694 Redirect 696 Only Code 1 is used for SIP, meaning "redirect packets for the 697 destination address". 699 The Redirect header is modified for SIP, to accommodate the 64-bit 700 address of the "preferred router" and to retain 64-bit alignment, 701 as follows: 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type | Code | Checksum | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Reserved | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | | 709 + Preferred Router + 710 | | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | | 713 | first 256 octets of the invoking packet | 714 | | 716 Router Advertisement 718 The format of the Router Advertisement message is changed to: 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Type | Code | Checksum | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Num Addrs |Addr Entry Size| Lifetime | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | | 726 + Router Address[0] + 727 | | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Preference Level[0] | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Reserved[0] | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | | 734 + Router Address[1] + 735 | | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Preference Level[1] | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Reserved[1] | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | . | 742 | . | 743 | . | 745 The value in the Addr Entry Size field is 4, and all of the Reserved 746 fields are initialized to zero by senders and ignored by receivers. 748 Router Solicitation 750 No changes. 752 Echo and Echo Reply 754 No changes. 756 The following ICMP message types are not used with SIP: 758 Source Quench 759 Timestamp 760 Timestamp Reply 761 Information Request 762 Information Reply 763 Address Mask Request 764 Address Mask Reply 766 8.2 Changes to IGMP 768 SIP uses the Internet Group Management Protocol, IGMP [RFC-1112]. 769 The presence of an IGMP header is indicated by a Payload Type of 2. 771 When used with SIP, the IGMP checksum includes a pseudo-header, like TCP 772 and UDP, consisting of the SIP Source Address, Destination Address, 773 Payload Length, and Payload Type (see section 8.3). 775 The format of an IGMP Host Membership Query message becomes: 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 |Version| Type | Reserved | Checksum | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | Reserved | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 The format of an IGMP Host Membership Report message becomes: 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 |Version| Type | Reserved | Checksum | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Reserved | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | | 791 + Multicast Address + 792 | | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 For both message types, the Version number remains 1, and the Reserved 796 fields are set to zero by senders and ignored by receivers. 798 8.3 Changes to Transport Protocols 800 The service interface to SIP has some differences from IPv4's service 801 interface. Existing transport protocols that use IPv4 must be changed 802 to operate over SIP's service interface. The differences from IPv4 are: 804 o Any addresses passed across the interface are 64 bits long, rather 805 than 32 bits. 807 o The following IPv4 variables are not passed across the interface: 808 Precedence, Type-of-Service, Identifier, Don't Fragment Flag 810 o SIP options have a different format than IPv4 options. (For SIP, 811 "options" are all headers between, and not including, the SIP header 812 and the transport header. The only IPv4 option currently specified 813 for SIP is Loose Source Routing. 815 o ICMP error messages for SIP that are passed up to the transport 816 layer carry the first 256 octets of the invoking SIP packet. 818 Transport protocols that use IPv4 addresses for their own purposes, 819 such as identifying connection state or inclusion in a pseudo-header 820 checksum, must be changed to use 64-bit SIP addresses for those purposes 821 instead. 823 For SIP, the pseudo-header checksums of TCP, UDP, ICMP, and IGMP include 824 the SIP Source Address, Destination Address, Payload Length, and Payload 825 Type, with the following caveats: 827 o If the packet contains a Source Routing header, the destination 828 address used in the pseudo-header checksum is that of the final 829 destination. 831 o The Payload Length used in the pseudo-header checksum is the 832 length of the transport-layer packet, including the transport 833 header. 835 o The Payload Type used in the pseudo-header checksum is the 836 Payload Type from the header immediately preceding the transport 837 header. 839 o When added to the pseudo-header checksum, the Payload Type is 840 treated as the left octet of a 16-bit word, with zeros in the 841 the right octet, when viewed in IP standard octet order. 843 o If either of the two addresses used in the pseudo-header checksum 844 has its high-order bit set to 1, only the low-order 32-bits of 845 that address shall be used in the sum. The high-order bit is 846 used to indicate that the addressed system is an IPv4 system, 847 and that the low-order 32-bits of the address contain that system's 848 IPv4 address [IPAE]. 850 The semantics of SIP service differ from IPv4 service in three ways that 851 may affect some transport protocols: 853 (1) SIP does not enforce maximum packet lifetime. Any transport 854 protocol that relies on IPv4 to limit packet lifetime must 855 take this change into account, for example, by providing its 856 own mechanisms for detecting and discarding obsolete packets. 858 (2) SIP does not checksum its own header fields. Any transport 859 protocol that relies on IPv4 to assure the integrity of the 860 source and destinations addresses, packet length, and transport 861 protocol identifier must take this change into account. In 862 particular, when used with SIP, the UDP checksum is mandatory, 863 and ICMP and IGMP are changed to use a pseudo-header checksum. 865 (3) SIP does not (except in special cases) fragment packets that 866 exceed the MTU of their delivery paths. Therefore, a transport 867 protocol must not send packets longer than 576 octets unless 868 it implements Path MTU Discovery [RFC-1191] and is capable of 869 adapting its transmitted packet size in response to changes of 870 the path MTU. 872 8.4 Changes to Link-Layer Protocols 874 Link-layer media that have an MTU less than 576 must be enhanced with 875 a link-specific fragmentation and reassembly mechanism, to support SIP. 877 For links on which ARP is used by IPv4, the identical ARP protocol is 878 used for SIP. The low-order 32-bits of SIP addresses are used wherever 879 IPv4 addresses would appear; since ARP is used only among systems on 880 the same subnet, the high-order 32-bits of the SIP addresses may be 881 inferred from the subnet prefix (assuming the subnet prefix is at 882 least 32 bits long). [This is subject to change -- see Appendix B.] 884 Appendix A. SIP Design Rationale 886 888 Fields present in IPv4, but absent in SIP: 890 Header Length Not needed; SIP header length is fixed. 892 Precedence & 893 Type of Service Not used; transport-layer Port fields (or perhaps a 894 to-be-defined value in the Reserved field of the SIP 895 header) may be used for classifying packets at a 896 granularity finer than host-to-host, as required for 897 special handling. 899 Header Checksum Not used; transport pseudo-header checksum 900 protects destinations from accepting corrupted 901 packets. 903 Need to justify: 905 change of Total Length -> Payload Length, excluding header 906 change of Protocol -> Payload Type 907 change of Time to Live -> Hop Limit 908 movement of fragmentation fields out of fixed header 909 bigger minimum MTU, and reliance on PMTU Discovery 911 Appendix B. Future Directions 913 SIP as specified above is a fully functional replacement for IPv4, with 914 a number of improvements, particularly in the areas of scalability of 915 routing and addressing, and performance. Some additional improvements 916 are still under consideration: 918 o ARP may be modified to carry full 64-bit addresses, and to use 919 link-layer multicast addresses, rather than broadcast addresses. 921 o The 28-bit Reserved field in the SIP header may be defined as a 922 "Flow ID", or partitioned into a Type of Service field and a 923 Flow ID field, for classifying packets deserving of special 924 handling, e.g., non-default quality of service or real-time service. 925 On the other hand, the transport-layer port fields may be adequate 926 for performing any such classification. (One possibility would be 927 simply to remove the port fields from TCP & UDP and append them to 928 the SIP header, as in XNS.) 930 o A new ICMP "destination has moved" message may defined, for re-routing 931 to mobile hosts or subnets, and to domains that have changed their 932 address prefixes. 934 o An explicit Trace Route message or option may be defined; the current 935 IPv4 traceroute scheme will work fine with SIP, but it does not 936 work for multicast, for which it has become very apparent that 937 management and debugging tools are needed. 939 o A new Host-to-Router protocol may be specified, encompassing the 940 requirements of router discovery, black-hole detection, auto- 941 configuration of subnet prefixes, "beaconing" for mobile hosts, 942 and, possibly, address resolution. The OSI End System To Intermediate 943 System Protocol may serve as a good model for such a protocol. 945 o The requirement that SIP addresses be strictly bound to interfaces 946 may be relaxed, so that, for example, a system might have fewer 947 addresses than interfaces. There is some experience with this 948 approach in the current Internet, with the use of "unnumbered links" 949 in routing protocols such as OSPF. 951 o Authentication and integrity-assurance mechanisms for all clients of 952 SIP, including ICMP and IGMP, may be specified, possibly based on 953 the Secure Data Network System (SNDS) SP-3 or SP-4 protocol. 955 Security Considerations 957 959 Acknowledgments 961 The author acknowledges the many helpful suggestions and the words of 962 encouragement from Dave Clark, Dave Crocker, Deborah Estrin, Bob Hinden, 963 Christian Huitema, Van Jacobson, Jeff Mogul, Dave Nichols, Erik Nordmark, 964 Dave Oran, Craig Partridge, Scott Shenker, Paul Tsuchiya, Lixia Zhang, 965 the members of End-to-End Research Group and the IPAE Working Group, 966 and the participants in the big-internet and sip mailing lists. He 967 apologizes to those whose names he has not explicitly listed. [If you 968 want to be on the list in the next draft, just let him know!] 970 Author's Address 972 Steve Deering 973 Xerox Palo Alto Research Center 974 3333 Coyote Hill Road 975 Palo Alto, CA 94304 976 phone: (415) 812-4839 977 email: deering@parc.xerox.com 979 References 981 [IPAE] 983 [RFC-791] J. Postel. Internet Protocol. RFC-791, September, 1981. 985 [RFC-792] J. Postel. Internet Control Message Protocol. RFC-792, 986 September, 1981. 988 [RFC-950] 990 [RFC-1112] S. Deering. Host Extensions for IP Multicasting. RFC-1112, 991 August, 1989. 993 [RFC-1122] 995 [RFC-1191] 997 [RFC-1256] 999 [RFC-BOOTP?] 1001 [RFC-PPP?] 1003 [SIP-ADDR] S. Deering. Simple Internet Protocol (SIP) Addressing and 1004 Routing. Internet Draft, November, 1992.