idnits 2.17.1 draft-ietf-tuba-clnp-05.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-16) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 2) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 8 instances of lines with control characters in the document. ** The abstract seems to contain references ([3], [4], [5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 64: '... + MUST, SHALL, or MANDATORY -- the ...' RFC 2119 keyword, line 67: '... + SHOULD or RECOMMENDED -- the item...' RFC 2119 keyword, line 70: '... + MAY or OPTIONAL -- the item is tr...' RFC 2119 keyword, line 172: '...e processing of a CLNP datagram MAY be...' RFC 2119 keyword, line 174: '...UBA environments MUST be capable of pr...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 376 has weird spacing: '...er, and with ...' == Line 548 has weird spacing: '...ics and proce...' == Line 613 has weird spacing: '... of the param...' == Line 709 has weird spacing: '...on, and the p...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The final octet of the source address is reserved. It MAY be set to the protocol field value on transmission, and shall be ignored on reception (the value of zero MUST not be used). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: the router MUST not record its network entity title in the option. If recording of route has been terminated, this (second) octet has a value 255. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: + Error Reports MAY NOT be fragmented (hence, the fragmentation part is absent). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note 1: The current accepted practice for IP is that source quench should not be used; if it is used, implementations MUST not return a source quench packet for every relevant packet. TUBA/CLNP implementations are encouraged to adhere to these guidelines. Note 2: There are no corresponding CLNP Error Report Codes for the following ICMP error message types: - Protocol Unreachable (3, 2) - Port Unreachable (3, 3) [ED. There are error code points available in the ER type code block that can be used to identify these message types.] -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- 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) == Unused Reference: '17' is defined on line 1040, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Historic RFC: RFC 1347 (ref. '2') ** Obsolete normative reference: RFC 793 (ref. '3') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Unknown state RFC: RFC 994 (ref. '6') ** Obsolete normative reference: RFC 1139 (ref. '9') (Obsoleted by RFC 1574, RFC 1575) -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1237 (ref. '12') (Obsoleted by RFC 1629) -- No information found for draft-tuba-sysids - is the name correct? -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 1340 (ref. '15') (Obsoleted by RFC 1700) ** Downref: Normative reference to an Historic RFC: RFC 1108 (ref. '16') ** Obsolete normative reference: RFC 1349 (ref. '17') (Obsoleted by RFC 2474) Summary: 23 errors (**), 0 flaws (~~), 12 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 November 15, 1993 CLNP for TUBA Internet Draft 3 Use of ISO CLNP in TUBA Environments 5 7 David M. Piscitello 8 Bellcore 9 dave@sabre.bellcore.com 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 Areas, and its Working Groups. Note that other groups may also 16 distribute working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use 21 Internet Drafts as reference material or to cite them other than 22 as a "working draft" or "work in progress." 24 Please check the Internet Draft abstract listing contained in the 25 IETF Shadow Directories (cd internet-drafts) to learn the current 26 status of this or any other Internet Draft. 28 This Internet-Draft specifies a profile of the ISO/IEC 8473 29 Connectionless-mode Network Layer Protocol (CLNP, [1]) for use in 30 conjunction with RFC 1347, TCP/UDP over Bigger Addresses (TUBA, 31 [2]). This draft document will be submitted to the RFC editor as 32 a protocol specification. Distribution of this memo is unlimited. 33 Please send comments to dave@eve.bellcore.com. 35 Abstract 37 This document describes the use of CLNP to provide the lower- 38 level service expected by Transmission Control Protocol (TCP, 39 [3]) and User Datagram Protocol (UDP, [4]). CLNP provides 40 essentially the same datagram service as Internet Protocol (IP, 41 [5]), but offers a means of conveying bigger network addresses 42 (with additional structure, to aid routing). 44 While the protocols offer nearly the same services, IP and CLNP 45 are not identical. This document describes a means of preserving 46 the semantics of IP information that is absent from CLNP while 47 preserving consistency between the use of CLNP in Internet and 48 OSI environments. This maximizes the use of already-deployed CLNP 49 implementations. 51 Acknowledgments 53 Many thanks to Ross Callon (Wellfleet Communications), John 54 Curran (BBN), Cyndi Jung (3Com), Paul Brooks (UNSW), Brian 55 Carpenter (CERN), Keith Sklower (Cal Berkeley), Dino Farinacci 56 and Dave Katz (Cisco Systems), Rich Colella (NIST/NCSL) and David 57 Oran (DEC) for their assistance in composing this text. 59 Conventions 61 The following language conventions are used in the items of 62 specification in this document: 64 + MUST, SHALL, or MANDATORY -- the item is an absolute 65 requirement of the specification. 67 + SHOULD or RECOMMENDED -- the item should generally be 68 followed for all but exceptional circumstances. 70 + MAY or OPTIONAL -- the item is truly optional and may be 71 followed or ignored according to the needs of the 72 implementor. 74 1. Terminology 76 To the extent possible, this document is written in the language 77 of the Internet. For example, packet is used rather than 78 "protocol data unit", and "fragment" is used rather than 79 "segment". There are some terms that carry over from OSI; these 80 are, for the most part, used so that cross-reference between this 81 document and RFC 994 [6] or ISO/IEC 8473 is not entirely painful. 82 OSI acronyms are for the most part avoided. 84 2. Introduction 86 The goal of this specification is to allow compatible and 87 interoperable implementations to encapsulate TCP and UDP packets 88 in CLNP data units. In a sense, it is more of a "hosts 89 requirements" document for the network layer of TUBA 90 implementations than a protocol specification. It is assumed that 91 readers are familiar with RFC 791, RFC 792 [7], RFC 1122 [8], 92 and, to a lesser extent, RFC 994 and ISO/IEC 8473. This document 93 is compatible with (although more restrictive than) ISO/IEC 8473; 94 specifically, the order, semantics, and processing of CLNP header 95 fields is consistent between this and ISO/IEC 8473. 97 [Editor's Note: RFC 994 contains the Draft International Standard 98 version of ISO CLNP, in ASCII text. This is not the final version 99 of the ISO/IEC protocol specification; however, it should provide 100 sufficient background for the purpose of understanding the 101 relationship of CLNP to IP, and the means whereby IP information 102 is to be encoded in CLNP header fields. Postscript versions of 104 November 15, 1993 CLNP for TUBA Internet Draft 106 ISO CLNP and associated routing protocols are available via 107 anonymous FTP from merit.edu, and may be found in the directory 108 /pub/ISO/IEC. 110 3. Overview of CLNP 112 ISO CLNP is a datagram network protocol. It provides 113 fundamentally the same underlying service to a transport layer as 114 IP. CLNP provides essentially the same maximum datagram size, and 115 for those circumstances where datagrams may need to traverse a 116 network whose maximum packet size is smaller than the size of the 117 datagram, CLNP provides mechanisms for fragmentation (data unit 118 identification, fragment/total length and offset). Like IP, a 119 checksum computed on the CLNP header provides a verification that 120 the information used in processing the CLNP datagram has been 121 transmitted correctly, and a lifetime control mechanism ("Time to 122 Live") imposes a limit on the amount of time a datagram is 123 allowed to remain in the internet system. As is the case in IP, a 124 set of options provides control functions needed or useful in 125 some situations but unnecessary for the most common 126 communications. 128 Table 1 provides a high-level comparison of CLNP to IP: 130 Function | ISO CLNP | DOD IP 131 ------------------------|-----------------------|----------------------- 132 Header Length | indicated in octets | in 32-bit words 133 Version Identifier | 1 octet | 4 bits 134 Lifetime (Time to live) | 500 msec units | 1 sec units 135 Flags | Fragmentation allowed,| Don't Fragment, 136 | More Fragments | More Fragments, 137 | Suppress Error Reports| 138 Packet Type | 5 bits | 139 Fragment Length | 16 bits, in octets | 16 bits, in octets 140 Header Checksum | 16-bit (Fletcher) | 16-bit 141 Total Length | 16 bits, in octets | 142 Addressing | Variable length | 32-bit fixed 143 Data Unit Identifier | 16 bits | 16 bits 144 Fragment offset | 16 bits, in octets | 13 bits, 8-octet units 145 Higher Layer Protocol | Selector in address | PROTOcol (assigned #) 146 Options | Security | Security 147 | Priority | Precedence bits in TOS 148 | Complete Source Route | Strict Source Route 149 | Quality of Service | Type of Service 150 | Partial Source Route | Loose Source Route 151 | Record Route | Record Route 152 | Padding | Padding 153 | | Timestamp 155 Table 1. Comparison of IP to CLNP 157 Note that the encoding of options differs between the two 158 protocols, as do the means of higher level protocol 159 identification. Note also that CLNP and IP differ in the way 160 header and fragment lengths are represented, and that the 161 granularity of lifetime control (time-to-live) is finer in CLNP. 162 Some of these differences are not considered "issues", as CLNP 163 provides flexibility in the way that certain options may be 164 specified and encoded (this will facilitate the use and encoding 165 of certain IP options without change in syntax); others, e.g., 166 higher level protocol identification and timestamp, must be 167 accommodated in a transparent manner in this profile for correct 168 operation of TCP and UDP, and continued interoperability with OSI 169 implementations. Section 4 describes how header fields of CLNP 170 must be populated to satisfy the needs of TCP and UDP. 172 Errors detected during the processing of a CLNP datagram MAY be 173 reported using CLNP Error Reports. Implementations of CLNP for 174 TUBA environments MUST be capable of processing Error Reports 175 (this is consistent with the 1992 edition (2) of the ISO/IEC 176 8473 standard). Control messages (e.g., echo request/reply and 177 redirect) are similarly handled in CLNP, i.e., identified as 178 separate network layer packet types. The relationship between 179 CLNP Error and Control messages and Internet Control Message 180 Protocol (ICMP, [7]), and issues relating to the handling of 182 November 15, 1993 CLNP for TUBA Internet Draft 184 these messages is described in Section 5. 186 The composition and processing of a TCP pseudo-header when CLNP 187 is used to provide the lower-level service expected by TCP and 188 UDP is described in Section 6. 190 4. Proposed Internet Header using CLNP 192 A summary of the contents of the CLNP header, as it is proposed 193 for use in TUBA environments, is illustrated in Figure 4-1: 195 0 1 2 3 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | ........Data Link Header........ | NLP ID | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |Header Length | Version | Lifetime (TTL)|Flags| Type | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Fragment Length | Checksum | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Dest Addr Len | Destination Address... | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | ... Destination Address... | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | ... Destination Address... | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | ... Destination Address... | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | ... Destination Address... | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | PROTO field | Src Addr Len | Source Address... | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | ... Source Address... | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | ... Source Address... | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | ... Source Address... | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | ... Source Address... | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 |Source Address | Reserved | Data Unit Identifier | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Fragment Offset | Total Length of packet | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Options (see Table 1) | 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Data | 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Note that each tick mark represents one bit position. 236 Figure 4-1. CLNP for TUBA 238 Note 1: For illustrative purposes, Figure 4-1 depicts Destination and 239 Source Addresses having a length of 19 octets, including the 240 PROTO/reserved field. In general, addresses can be variable 241 length, up to a maximum of 20 octets, including the 242 PROTO/reserved field. 244 Note 2: Due to differences in link layer protocols, it is not possible 245 to ensure that the packet starts on an even alignment. Note, 246 however, that many link level protocols over which CLNP is operated 247 happen to use a odd length link (e.g., 802.2). (In 248 Figure 4-1, the rest of the CLNP packet is even-aligned.) 250 The encoding of CLNP fields for use in TUBA environments is as 251 follows. 253 4.1 Network Layer Protocol Identification (NLP ID) 255 This one-octet field identifies this as the ISO/IEC 8473 256 protocol; it MUST set to binary 1000 0001. 258 4.2 Header Length Indication (Header Length) 260 Header Length is the length of the CLNP header in octets, and 261 thus points to the beginning of the data. The value 255 is 262 reserved. The header length is the same for all fragments of the 263 same (original) CLNP packet. 265 4.3 Version 267 This one-octet field identifies the version of the protocol; it 268 MUST be set to a binary value 0000 0001. 270 4.4 Lifetime (TTL) 272 Like the TTL field of IP, this field indicates the maximum time 273 the datagram is allowed to remain in the internet system. If 274 this field contains the value zero, then the datagram MUST be 275 destroyed; a host, however, MUST NOT send a datagram with a 276 lifetime value of zero. This field is modified in internet 277 header processing. The time is measured in units of 500 278 milliseconds, but since every module that processes a datagram 279 MUST decrease the TTL by at least one even if it process the 280 datagram in less than 500 millisecond, the TTL must be thought of 281 only as an upper bound on the time a datagram may exist. The 282 intention is to cause undeliverable datagrams to be discarded, 284 November 15, 1993 CLNP for TUBA Internet Draft 286 and to bound the maximum CLNP datagram lifetime. [Like IP, the 287 colloquial usage of TTL in CLNP is as a coarse hop-count.] 289 Unless otherwise directed, a host SHOULD use a value of 255 as 290 the initial lifetime value. 292 4.5 Flags 294 Three flags are defined. These occupy bits 0, 1, and 2 of the 295 Flags/Type octet: 297 0 1 2 298 +---+---+---+ 299 | F | M | E | 300 | P | F | R | 301 +---+---+---+ 303 The Fragmentation Permitted (FP) flag, when set to a value of one 304 (1), is semantically equivalent to the "may fragment" value of 305 the Don't Fragment field of IP; similarly, when set to zero (0), 306 the Fragmentation Permitted flag is semantically equivalent to 307 the "Don't Fragment" value of the Don't Fragment Flag of IP. 309 [Editor's Note: If the Fragmentation Permitted field is set to 310 the value O, then the Data Unit Identifier, Fragment Offset, and 311 Total Length fields are not present. This denotes a single 312 fragment datagram. In such datagrams, the Fragment Length field 313 contains the total length of the datagram.] 315 The More Fragments flag of CLNP is semantically and syntactically 316 the same as the More Fragments flag of IP; a value of one (1) 317 indicates that more segments/fragments are forthcoming; a value 318 of zero (0) indicates that the last octet of the original packet 319 is present in this segment. 321 The Error Report (ER) flag is used to suppress the generation of 322 an error message by a host/router that detects an error during 323 the processing of a CLNP datagram; a value of one (1) indicates 324 that the host that originated this datagram thinks error reports 325 are useful, and would dearly love to receive one if a host/router 326 finds it necessary to discard its datagram(s). 328 4.6 Type field 330 The type field distinguishes data CLNP packets from Error Reports 331 from Echo packets. The following values of the type field apply: 333 0 1 2 3 4 5 6 7 334 +---+---+---+---+---+---+---+---+ 335 | flags | 1 | 1 | 1 | 0 | 0 | => Encoding of Type = data packet 336 +---+---+---+---+---+---+---+---+ 337 | flags | 0 | 0 | 0 | 0 | 1 | => Encoding of Type = error report 338 +---+---+---+---+---+---+---+---+ 339 | flags | 1 | 1 | 1 | 1 | 0 | => Encoding of Type = echo request 340 +---+---+---+---+---+---+---+---+ 341 | flags | 1 | 1 | 1 | 1 | 1 | => Encoding of Type = echo reply 342 +---+---+---+---+---+---+---+---+ 344 Error Report packets are described in Section 5. 346 Echo packets and their use are described in RFC 1139 [9]. 348 4.7 Fragment Length 350 Like the Total Length of the IP header, the Fragment length field 351 contains the length in octets of the fragment (i.e., this 352 datagram) including both header and data. 354 [Note: CLNP also may also have a Total Length field, that 355 contains the length of the original datagram; i.e., the sum of 356 the length of the CLNP header plus the length of the data 357 submitted by the higher level protocol, e.g., TCP or UDP. See 358 Section 4.12.] 360 4.8 Checksum 362 A checksum is computed on the header only. It MUST be verified at 363 each host/router that processes the packet; if header fields are 364 changed during processing (e.g., the Lifetime), the checksum is 365 modified. If the checksum is not used, this field MUST be coded 366 with a value of zero (0). See Appendix A for algorithms used in 367 the computation and adjustment of the checksum. Readers are 368 encouraged to see [10] for a description of an efficient 369 implementation of the checksum algorithm. 371 4.9 Addressing 373 CLNP uses OSI network service access point addresses (NSAPAs); 374 NSAPAs serve the same identification and location functions as an 375 IP address, plus the protocol selector value encoded in the IPv4 376 datagram header, and with additional hierarchy. General purpose 377 CLNP implementations MUST handle NSAP addresses of variable 378 length up to 20 octets, as defined in ISO/IEC 8348 [11]. TUBA 379 implementations, especially routers, MUST accommodate these as 380 well. Thus, for compatibility and interoperability with OSI use 381 of CLNP, the initial octet of the Destination Address is assumed 383 November 15, 1993 CLNP for TUBA Internet Draft 385 to be an Authority and Format Indicator, as defined in ISO/IEC 386 8348. NSAP addresses may be between 8 and 20 octets long 387 (inclusive). 389 TUBA implementations MUST support both ANSI and GOSIP style 390 addresses; these are described in RFC 1237 [12], and illustrated 391 in Figure 4-2. RFC 1237 describes the ANSI/GOSIP initial domain 392 parts as well as the format and composition of the domain 393 specific part. It is further recommended that TUBA 394 implementations support the assignment of system identifiers for 395 TUBA/CLNP hosts defined in [13] for the purposes of host address 396 autoconfiguration as described in [14]. Additional considerations 397 specific to the interpretation and encoding of the selector part 398 are described in sections 4.9.2 and 4.9.4. 400 _______________ 401 |<--__IDP_-->_|___________________________________ 402 |AFI_|__IDI___|___________<--_DSP_-->____________| 403 |_47_|__0005__|DFI_|AA_|Rsvd_|_RD_|Area_|ID_|Sel_| 404 octets |_1__|___2____|_1__|_3_|__2__|_2__|_2___|_6_|_1__| 406 Figure 4-2 (a): GOSIP Version 2 NSAP structure. 407 ______________ 408 |<--_IDP_-->_|_____________________________________ 409 |AFI_|__IDI__|____________<--_DSP_-->_____________| 410 |_39_|__840__|DFI_|_ORG_|Rsvd_|RD_|Area_|_ID_|Sel_| 411 octets |_1__|___2___|_1__|__3__|_2___|_2_|__2__|_6__|_1__| 413 Figure 4-2 (b): ANSI NSAP address format for DCC=840 415 Definitions: 416 IDP Initial Domain Part 417 AFI Authority and Format Identifier 418 IDI Initial Domain Identifier 419 DSP Domain Specific Part 420 DFI DSP Format Identifier 421 AA Administration Authority 422 ORG Organization Name (numeric form) 423 Rsvd Reserved 424 RD Routing Domain Identifier 425 Area Area Identifier 426 ID System Identifier 427 Sel NSAP Selector 429 4.9.1 Destination Address Length Indicator 431 This field indicates the length, in octets, of the Destination 432 Address. 434 4.9.2 Destination Address 436 This field contains an OSI NSAP address, as described in Section 437 4.9. It MUST always contain the address of the final 438 destination. (This is true even for packets containing a source 439 route option, see Section 4.13.4). 441 The final octet of the destination address MUST always contain 442 the value of the PROTO field, as defined in IP. The 8-bit PROTO 443 field indicates the next level protocol used in the data portion 444 of the CLNP datagram. The values for various protocols are 445 specified in "Assigned Numbers" [15]. For the PROTO field, the 446 value of zero (0) is reserved. 448 TUBA implementations that support TCP/UDP as well as OSI MUST use 449 the protocol value (1Dh, Internet decimal 29) reserved for ISO 450 transport protocol class 4. 452 4.9.3 Source Address Length Indicator 454 This field indicates the length, in octets, of the Source 455 Address. 457 4.9.4 Source Address 459 This field contains an OSI NSAP address, as described in Section 460 4.9. 462 The final octet of the source address is reserved. It MAY be set 463 to the protocol field value on transmission, and shall be ignored 464 on reception (the value of zero MUST not be used). 466 4.10 Data Unit Identifier 468 Like the Identification field of IP, this 16-bit field is used to 469 distinguish segments of the same (original) packet for the 470 purposes of reassembly. This field is present when the 471 fragmentation permitted flag is set to one. 473 4.11 Fragment Offset 475 Like the Fragment Offset of IP, this 16-bit is used to identify 476 the relative octet position of the data in this fragment with 477 respect to the start of the data submitted to CLNP; i.e., it 478 indicates where in the original datagram this fragment belongs. 479 The offset is measured in octets; the value of this field shall 480 always be a multiple of eight (8). This field is present when the 481 fragmentation permitted flag is set to one. 483 November 15, 1993 CLNP for TUBA Internet Draft 485 4.12 Total Length 487 The total length of the CLNP packet in octets is determined by 488 the originator and placed in the Total Length field of the 489 header. The Total Length field specifies the entire length of the 490 original datagram, including both the header and data. This field 491 MUST NOT be changed in any fragment of the original packet for 492 the duration of the packet lifetime. This field is present when 493 the fragmentation permitted flag is set to one. 495 4.13 Options 497 All CLNP options are "triplets" of the form , 498 , and . Both the parameter 499 code and length fields are always one octet long; the length 500 parameter value, in octets, is indicated in the parameter length 501 field. The following options are defined for CLNP for TUBA. 503 4.13.1 Security 505 The value of the parameter code field is binary 1100 0101. The 506 length field MUST be set to the length of a Basic (and Extended) 507 Security IP option(s) as identified in RFC1108 [16], plus 1. 508 Octet 1 of the security parameter value field -- the CLNP 509 Security Format Code -- is set to a binary value 0100 0000, 510 indicating that the remaining octets of the security field 511 contain either the Basic or Basic and Extended Security options 512 as identified in RFC 1108. This encoding points to the 513 administration of the source address (e.g., ISOC) as the 514 administration of the security option; it is thus distinguished 515 from the globally unique format whose definition is reserved for 516 OSI use. Implementations wishing to use a security option MUST 517 examine the PROTO field in the source address; if the value of 518 PROTO indicates the CLNP client is TCP or UDP, the security 519 option described in RFC1108 is used. 521 [Note: If IP options change, TUBA implementations MUST follow the 522 new recommendations. This RFC, or revisions thereof, must 523 document the new recommendations to assure compatibility.] 525 The formats of the Security option, encoded as a CLNP option, is 526 as follows. The CLNP option will be used to convey the Basic and 527 Extended Security options as sub-options; i.e., the exact 528 encoding of the Basic/Extended Security IP Option is carried in a 529 single CLNP Security Option, with the length of the CLNP Security 530 option reflecting the sum of the lengths of the Basic and 531 Extended Security IP Option. 533 +--------+--------+--------+--------+--------+------//-----+--- 534 |11000100|XXXXXXXX|01000000|10000010|YYYYYYYY| | ... 535 +--------+--------+--------+--------+--------+------//-----+------ 536 CLNP CLNP CLNP BASIC BASIC BASIC 537 OPTION OPTION FORMAT SECURITY OPTION OPTION 538 TYPE LENGTH CODE TYPE LENGTH VALUE 539 (197) (130) 541 ---+------------+------------+----//-------+ 542 ... | 10000101 | 000LLLLL | | 543 -----+------------+------------+----//-------+ 544 EXTENDED EXTENDED EXTENDED OPTION 545 OPTION OPTION VALUE 546 TYPE (133) LENGTH 548 The syntax, semantics and processing of the Basic and Extended 549 IP Security Options are defined in RFC 1108. 551 4.13.2 Quality of Service 553 [Note: Early drafts recommended the use of IP Type of Service as 554 specified in RFC 1349. There now appears to be a broad consensus 555 that this encoding is insufficient, and there is renewed interest 556 in exploring the utility of the "congestion experienced" flag 557 available in the CLNP QOS Maintenance option. This internet-draft 558 thus recommends the use of the QOS Maintenance option native to 559 CLNP.] 561 The Quality of Service Maintenance option allows the originator 562 of a CLNP datagram to convey information about the quality of 563 service requested by the originating upper layer process. Routers 564 MAY use this information as an aid in selecting a route when more 565 than one route satisfying other routing criteria is available and 566 the available routes are know to differ with respect to the 567 following qualities of service: ability to preserve sequence, 568 transit delay, cost, residual error probability. Through this 569 option, a router may also indicate that it is experiencing 570 congestion. 572 The encoding of this option is as follows: 574 +-----------+-----------+----------+ 575 | 1100 0011 | 0000 0001 | 110ABCDE | 576 +-----------+-----------+----------+ 577 CLNP QOS OPTION QOS FLAGS 578 TYPE (195) LENGTH 580 The value of the parameter code field MUST be set to a value of 581 binary 1100 0011 (the CLNP Quality of Service Option Code point). 583 November 15, 1993 CLNP for TUBA Internet Draft 585 The length field MUST be set to one (1). 587 Bits 8-6 MUST be set as indicated in the figure. The flags 588 "ABCDE" are interpreted as follows: 590 A=1 choose path that maintains sequence over 591 one that minimizes transit delay 592 A=0 choose path that minimizes transit delay over 593 one that maintains sequence 594 B=1 congestion experienced 595 B=0 no congestion to report 596 C=1 choose path that minimizes transit delay over 597 over low cost 598 C=0 choose low cost over path that 599 minimizes transit delay 600 D=1 choose pathe with low residual error probability over 601 one that minimizes transit delay 602 D=0 choose path that minimizes transit delay over 603 one with low residual error probability 604 E=1 choose path with low residual error probability over 605 low cost 606 E=0 choose path with low cost over one with low 607 residual error probability 609 4.13.3 Padding 611 The padding field is used to lengthen the packet header to a 612 convenient size. The parameter code field MUST be set to a value 613 of binary 1100 1100. The value of the parameter length field is 614 variable. The parameter value MAY contain any value; the contents 615 of padding fields MUST be ignored by the receiver. 617 +----------+----------+-----------+ 618 | 11001100 | LLLLLLLL | VVVV VVVV | 619 +----------+----------+-----------+ 621 4.13.4 Source Routing 623 Like the strict source route option of IP, the Complete Source 624 Route option of CLNP is used to specify the exact and entire 625 route an internet datagram MUST take. Similarly, the Partial 626 Source Route option of CLNP provides the equivalent of the loose 627 source route option of IP; i.e., a means for the source of an 628 internet datagram to supply (some) routing information to be used 629 by gateways in forwarding the internet datagram towards its 630 destination. The identifiers encoded in this option are network 631 entity titles, which are semantically and syntactically the same 632 as NSAPAs and which can be used to unambiguously identify a 633 network entity in an intermediate system (router). 635 The parameter code for Source Routing is binary 1100 1000. The 636 length of the source routing parameter value is variable. 638 The first octet of the parameter value is a type code, indicating 639 Complete Source Routing (binary 0000 0001) or Partial Source 640 Routing (binary 0000 0000). The second octet identifies the 641 offset of the next network entity title to be processed in the 642 list, relative to the start of the parameter (i.e., a value of 3 643 is used to identify the first address in the list). The offset 644 value is modified by each router using a complete source route or 645 by each listed router using a partial source route to point to 646 the next NET. 648 The third octet begins the list of network entity titles. Only 649 the NETs of intermediate systems are included in the list; the 650 source and destination addresses shall not be included. The list 651 consists of variable length network entity title entries; the 652 first octet of each entry gives the length of the network entity 653 title that comprises the remainder of the entry. 655 4.13.5 Record Route 657 Like the IP record route option, the Record route option of CLNP 658 is used to trace the route a CLNP datagram takes. A recorded 659 route consists of a list of network entity titles (see Source 660 Routing). The list is constructed as the CLNP datagram is 661 forwarded along a path towards its final destination. Only titles 662 of intermediate systems (routers) that processed the datagram are 663 included in the recorded route; the network entity title of the 664 originator of the datagram SHALL NOT be recorded in the list. 666 The parameter code for Record Route is binary 1100 1011. The 667 length of the record route parameter value is variable. 669 The first octet of the parameter value is a type code, indicating 670 Complete Recording of Route (0000 0001) or Partial Recording of 671 Route (0000 0000). When complete recording of route is selected, 672 reassembly at intermediate systems MAY be performed only when all 673 fragments of a given datagram followed the same route; partial 674 recording of route eliminates or "loosens" this constraint. 676 The second octet identifies the offset where the next network 677 entity title entry (see Source Routing) MAY be recorded (i.e., 678 the end of the current list), relative to the start of the 679 parameter. A value of 3 is used to identify the initial 680 recording position. The process of recording a network entity 681 title entry is as follows. A router adds the length of its 682 network entity title entry to the value of record route offset 683 and compares this new value to the record route list length 684 indicator; if the value does not exceed the length of the list, 685 entity title entry is recorded, and the offset value is 686 incremented by the value of the length of the network entity 687 title entry. Otherwise, the recording of route is terminated, and 689 November 15, 1993 CLNP for TUBA Internet Draft 691 the router MUST not record its network entity title in the 692 option. If recording of route has been terminated, this (second) 693 octet has a value 255. 695 The third octet begins the list of network entity titles. 697 4.13.6 Timestamp 699 [Editor's Note: There is no timestamp option in edition 1 of 700 ISO/IEC 8473, but the option has been proposed and submitted to 701 ISO/IEC JTC1/SC6.] 703 The parameter code value 1110 1110 is used to identify the 704 Timestamp option; the syntax and semantics of Timestamp are 705 identical to that defined in IP. 707 The Timestamp Option is defined in RFC 791. The CLNP parameter 708 code 1110 1110 is used rather than the option type code 68 to 709 identify the Timestamp option, and the parameter value conveys 710 the option length. Octet 1 of the Timestamp parameter value shall 711 be encoded as the pointer (octet 3 of IP Timestamp); octet 2 of 712 the parameter value shall be encoded as the overflow/format octet 713 (octet 4 of IP Timestamp); the remaining octets shall be used to 714 encode the timestamp list. The size is fixed by the source, and 715 cannot be changed to accommodate additional timestamp 716 information. 718 +--------+--------+--------+--------+ 719 |11101110| length | pointer|oflw|flg| 720 +--------+--------+--------+--------+ 721 | network entity title | 722 +--------+--------+--------+--------+ 723 | timestamp | 724 +--------+--------+--------+--------+ 725 | . | 726 . 728 [Note: This experimental RFC does not discuss multicasting. 729 Presently, there are proposals for multicast extensions for CLNP 730 in ISO/IEC/JTC1/SC6, and a parallel effort within TUBA. A future 731 revision to this RFC will incorporate any extensions to CLNP that 732 may be introduced as a result of the adoption of one of these 733 alternatives.] 734 5. Error Reporting and Control Message Handling 736 CLNP and IP differ in the way in which errors are reported to 737 hosts. In IP environments, the Internet Control Message Protocol 738 (ICMP, [7]) is used to return (error) messages to hosts that 739 originate packets that cannot be processed. ICMP messages are 740 transmitted as user data in IP datagrams. Unreachable 741 destinations, incorrectly composed IP datagram headers, IP 742 datagram discards due to congestion, and lifetime/reassembly time 743 exceeded are reported; the complete internet header that caused 744 the error plus (at least) 8 octets of the segment contained in 745 that IP datagram are returned to the sender as part of the ICMP 746 error message. For certain errors, e.g., incorrectly composed IP 747 datagram headers, the specific octet which caused the problem is 748 identified. 750 In CLNP environments, an unique message type, the Error Report 751 type, is used in the network layer protocol header to distinguish 752 Error Reports from CLNP datagrams. CLNP Error Reports are 753 generated on detection of the same types of errors as with ICMP. 754 Like ICMP error messages, the complete CLNP header that caused 755 the error is returned to the sender in the data portion of the 756 Error Report. Implementations SHOULD return at least 8 octets of 757 the datagram contained in the CLNP datagram to the sender of the 758 original CLNP datagram. Here too, for certain errors, the 759 specific octet which caused the problem is identified 761 A summary of the contents of the CLNP Error Report, as it is 762 proposed for use in TUBA environments, is illustrated in Figure 763 5-1: 765 November 15, 1993 CLNP for TUBA Internet Draft 767 0 1 2 3 768 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | ........Data Link Header........ | NLP ID | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 |Header Length | Version | Lifetime (TTL)| 000 | Type=ER | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | TOTAL Length of Error Report | Checksum | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Dest Addr Len | Destination Address... | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | ... Destination Address... | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 | ... Destination Address... | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | ... Destination Address... | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | ... Destination Address... | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | PROTO field | Src Addr Len | Source Address... | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | ... Source Address... | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | ... Source Address... | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | ... Source Address... | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | ... Source Address... | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | ... Source Address | Reason for Discard (type/len) | 797 | | 1100 0001 | 0000 0010 | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Reason for Discard | Options... | 800 | code | pointer | | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Options | 803 : : 804 | | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Data | 807 : : 808 | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Note that each tick mark represents one bit position. 812 Figure 5-1. Error Report Format 814 5.1 Rules for processing an Error Report 816 The following is a summary of the rules for processing an Error 817 Report: 819 + An Error Report is not generated to report a problem 820 encountered while processing an Error Report. 822 + Error Reports MAY NOT be fragmented (hence, the 823 fragmentation part is absent). 825 + The Reason for Discard Code field is populated with one of 826 the values from Table 5-1. 828 + The Pointer field is populated with number of the first 829 octet of the field that caused the Error Report to be 830 generated. If it is not possible to identify the offending 831 octet, this field MUST be zeroed. 833 + If the Priority or Type of Service option is present in the 834 errored datagram, the Error Report MUST specify the same 835 option, using the value specified in the original datagram. 837 + If the Security option is present in the errored datagram, 838 the Error Report MUST specify the same option, using the 839 value specified in the original datagram; if the Security 840 option is not supported by the intermediate system, no Error 841 Report is to be generated (i.e., "silently discard" the 842 received datagram). 844 + If the Complete Source Route option is specified in the 845 errored datagram, the Error Report MUST compose a reverse of 846 that route, and return the datagram along the same path. 848 5.2 Comparison of ICMP and CLNP Error Messages 850 Table 5-1 provides a loose comparison of ICMP message types and 851 codes to CLNP Error Type Codes (values in Internet decimal): 853 November 15, 1993 CLNP for TUBA Internet Draft 855 CLNP Error Type Codes | ICMP Message (Type, Code) 856 ----------------------------------|------------------------------------ 857 Reason not specified (0) | Parameter Problem (12, 0) 858 Protocol Procedure Error (1) | Parameter Problem (12, 0) 859 Incorrect Checksum (2) | Parameter Problem (12, 0) 860 PDU Discarded--Congestion (3) | Source Quench (4, 0) 861 Header Syntax Error (4) | Parameter problem (12, 0) 862 Need to Fragment could not (5) | Frag needed, DF set (3, 4) 863 Incomplete PDU received (6) | Parameter Problem (12, 0) 864 Duplicate Option (7) | Parameter Problem (12, 0) 865 Destination Unreachable (128) | Dest Unreachable,Net unknown (3, 0) 866 Destination Unknown (129) | Dest Unreachable,host unknown(3, 1) 867 Source Routing Error (144) | Source Route failed (3, 5) 868 Source Route Syntax Error (145) | Source Route failed (3, 5) 869 Unknown Address in Src Route(146) | Source Route failed (3, 5) 870 Path not acceptable (147) | Source Route failed (3, 5) 871 Lifetime expired (160) | TTL exceeded (11, 0) 872 Reassembly Lifetime Expired (161) | Reassembly time exceeded (11, 1) 873 Unsupported Option (176) | Parameter Problem (12, 0) 874 Unsupported Protocol Version(177) | Parameter problem (12, 0) 875 Unsupported Security Option (178) | Parameter problem (12, 0) 876 Unsupported Src Rte Option (179) | Parameter problem (12, 0) 877 Unsupported Rcrd Rte (180) | Parameter problem (12, 0) 878 Reassembly interference (192) | Reassembly time exceeded (11,1) 880 Table 5-1. Comparison of CLNP Error Reports to ICMP Error Messages 882 Note 1: The current accepted practice for IP is that source quench 883 should not be used; if it is used, implementations 884 MUST not return a source quench packet for every relevant packet. 885 TUBA/CLNP implementations are encouraged to adhere to these 886 guidelines. 887 Note 2: There are no corresponding CLNP Error Report Codes for the 888 following ICMP error message types: 889 - Protocol Unreachable (3, 2) 890 - Port Unreachable (3, 3) 891 [ED. There are error code points available in the ER type 892 code block that can be used to identify these message types.] 894 6. Pseudo-Header Considerations 896 A checksum is computed on UDP and TCP segments to verify the 897 integrity of the UDP/TCP segment. To further verify that the 898 UDP/TCP segment has arrived at its correct destination, a 899 pseudo-header consisting of information used in the delivery of 900 the UDP/TCP segment is composed and included in the checksum 901 computation. 903 To compute the checksum on a UDP or TCP segment prior to 904 transmission, implementations MUST compose a pseudo-header to the 905 UDP/TCP segment consisting of the following information that will 906 be used when composing the CLNP datagram: 908 + Destination Address Length Indicator 910 + Destination Address (including PROTO field) 912 + Source Address Length Indicator 914 + Source Address (including Reserved field) 916 + A two-octet encoding of the Protocol value 918 + TCP/UDP segment length 920 Figure 5-1 illustrates the resulting pseudo-header when both 921 source and destination addresses are maximum length. 923 0 1 2 3 924 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Dest Addr Len | Destination Address... | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | ... Destination Address... | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | ... Destination Address... | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | ... Destination Address... | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | ... Destination Address... | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | (PROTO) | Src Addr Len | Source Address... | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | ... Source Address... | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | ... Source Address... | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | ... Source Address... | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | ... Source Address... | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | ... | (Reserved) | Protocol | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | UDP/TCP segment length | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Figure 5-1. Pseudo-header 953 If the length of the {source address length field + source 954 address + destination address field + destination address } is 955 not an integral number of octets, a trailing 0x00 nibble is 956 padded. If GOSIP compliant NSAP addresses are used, this never 958 November 15, 1993 CLNP for TUBA Internet Draft 960 happens (this is known as the Farinacci uncertainty principle). 961 The last byte in the Destination Address has the value 0x06 for 962 TCP and 0x11 for UDP, and the Protocol field is encoded 0x0006 963 for TCP and 0x0011 for UDP. If needed, an octet of zero is added 964 to the end of the UDP/TCP segment to pad the datagram to a length 965 that is a multiple of 16 bits. 967 [Note: the pseudoheader is encoded in this manner to expedite 968 processing, as it allows implementations to grab a contiguous 969 stream of octets beginning at the destination address length 970 indicator and terminating at the final octet of the source 971 address; the PROTOCOL field is present to have a consistent 972 representation across IPv4 and CLNP/TUBA implementations.] 973 7. REFERENCES 975 [1] ISO/IEC 8473-1992. International Standards Organization -- Data 976 Communications -- Protocol for Providing the Connectionless-mode 977 Network Service, Edition 2. 979 [2] Callon, R., TCP/UDP over Bigger Addresses (TUBA), Request for 980 Comments 1347, Network Information Center, SRI 981 International, Menlo Park, CA, May 1992. 983 [3] Postel, J., Transmission Control Protocol (TCP). Request for 984 Comments 793, Network Information Center, SRI 985 International, Menlo Park, CA, 1981 September. 987 [4] Postel, J., User Datagram Protocol (UDP). Request for Comments 768, 988 Network Information Center, SRI International, Menlo Park, CA. 990 [5] Postel, J., Internet Protocol (IP). Request for Comments 791, 991 Network Information Center, SRI International, Menlo Park, 992 CA, 1981 September. 994 [6] Chapin, L., ISO DIS 8473, Protocol for Providing the 995 Connectionless Network Service. Request for Comments 994, 996 Network Information Center, SRI International, Menlo Park, CA, 997 1986 March. 999 [7] Postel, J. Internet Control Message Protocol. Request for 1000 Comments 792, Network Information Center, SRI International, 1001 Menlo Park, CA 1981 September. 1003 [8] Braden, R.,ed. Requirements for Internet hosts - communication layers 1004 Request for Comments 1122. Network Information Center, SRI 1005 International, Menlo Park, CA, 1989 October. 1007 [9] Hagens, R. and C. Wittbrodt, CLNP Ping, Request for Comments 1008 1139, Network Information Center, SRI International, Menlo 1009 Park, CA. 1993 May. 1011 [10] Sklower, K., 1013 [11] ISO/IEC 8348-1992. International Standards Organization--Data 1014 Communications--OSI Network Layer Service and Addressing. 1016 [12] Callon, R., NSAPA Guidelines for the Internet, 1017 Request for Comments RFC 1237, Network Information Center, SRI 1018 International, Menlo Park, CA. 1020 [13] Piscitello, D., Assignment of System Identifiers for TUBA/CLNP 1021 hosts, Internet-drafts (draft-tuba-sysids-01.txt). 1023 [14] ISO/IEC 9542:1988/PDAM 1. Information Processing Systems -- Data 1024 Communications -- End System to Intermediate System Routeing 1025 Exchange Protocol for use in conjunction with the protocol for 1027 November 15, 1993 CLNP for TUBA Internet Draft 1029 providing the connectionless-mode network service -- Amendment 1: 1030 Dynamic Discovery of OSI NSAP Addresses by End Systems. 1032 [15] Reynolds, J., and J. Postel, Assigned Numbers. 1033 Request for Comments 1340, Network Information Center, SRI 1034 International, Menlo Park, CA. 1992 July. 1036 [16] Kent, S., Security Option for IP, 1037 Request for Comments 1108, Network Information Center, SRI 1038 International, Menlo Park, CA. 1040 [17] Almquist, P., Type of Service in the Internet 1041 Protocol Suite. Request for Comments 1349, Network Information 1042 Center, SRI International, Menlo Park, CA. 1044 Appendix A. Checksum Algorithms (from ISO/IEC 8473) 1046 Symbols used in algorithms: 1047 c0, c1 variables used in the algorithms 1048 i position of octet in header (first 1049 octet is i=1) 1050 Bi value of octet i in the header 1051 n position of first octet of checksum (n=8) 1052 L Length of header in octets 1053 X Value of octet one of the checksum parameter 1054 Y Value of octet two of the checksum parameter 1056 Addition is performed in one of the two following modes: 1058 o+ modulo 255 arithmetic; 1060 o+ eight-bit one's complement arithmetic; 1062 The algorithm for Generating the Checksum Parameter Value is as 1063 follows: 1065 A. Construct the complete header with the value of the 1066 checksum parameter field set to zero; i.e., c0 <- c1 <- 0; 1068 B. Process each octet of the header sequentially from i=1 to L 1069 by: 1071 o+ c0 <- c0 + Bi 1073 o+ c1 <- c1 + c0 1075 C. Calculate X, Y as follows: 1077 o+ X <- (L - 8)(c0 - c1) modulo 255 1079 o+ Y <- (L - 7)(-C0) + c1 1081 D. If X = 0, then X <- 255 1083 E. If Y = 0, then Y <- 255 1085 F. place the values of X and Y in octets 8 and 9 of the 1086 header, respectively 1088 The algorithm for checking the value of the checksum parameter is 1089 as follows: 1091 A. If octets 8 and 9 of the header both contain zero, then the 1092 checksum calculation has succeeded; else if either but not 1093 both of these octets contains the value zero then the 1094 checksum is incorrect; otherwise, initialize: c0 <- c1 <- 0 1096 November 15, 1993 CLNP for TUBA Internet Draft 1098 B. Process each octet of the header sequentially from i = 1 to 1099 L by: 1101 o+ c0 <- c0 + Bi 1103 o+ c1 <- c1 + c0 1105 C. When all the octets have been processed, if c0 = c1 = 0, 1106 then the checksum calculation has succeeded, else it has 1107 failed. 1109 There is a separate algorithm to adjust the checksum parameter 1110 value when a octet has been modified (such as the TTL). Suppose 1111 the value in octet k is changed by Z = newvalue - oldvalue. If X 1112 and Y denote the checksum values held in octets n and n+1 1113 respectively, then adjust X and Y as follows: 1115 If X = 0 and Y = 0 then do nothing, else if X = 0 or Y = 0 then 1116 the checksum is incorrect, else: 1118 X <- (k - n - 1)Z + X modulo 255 1120 Y <- (n - k)Z + Y modulo 255 1122 If X = 0, then X <- 255; if Y = 0, then Y <- 255. 1124 In the example, n = 89; if the octet altered is the TTL (octet 1125 4), then k = 4. For the case where the lifetime is decreased by 1126 one unit (Z = -1), the assignment statements for the new values 1127 of X and Y in the immediately preceeding algorithm simplify to: 1129 X <- X + 5 Modulo 255 1131 Y <- Y - 4 Modulo 255