idnits 2.17.1 draft-ietf-catnip-common-arch-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-26) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 716 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** 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 70 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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: 'Chapin93' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'Perlman92' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC791' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 618, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'RFC801' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'RFC1234' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC1247' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'RFC1287' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'RFC1335' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'RFC1338' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC1347' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC1466' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC1475' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'RFC1476' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC1561' is defined on line 660, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Chapin93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Perlman92' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Downref: Normative reference to an Unknown state RFC: RFC 801 ** Downref: Normative reference to an Historic RFC: RFC 1234 ** Obsolete normative reference: RFC 1247 (Obsoleted by RFC 1583) ** Downref: Normative reference to an Informational RFC: RFC 1287 ** Downref: Normative reference to an Informational RFC: RFC 1335 ** Obsolete normative reference: RFC 1338 (Obsoleted by RFC 1519) ** Downref: Normative reference to an Historic RFC: RFC 1347 ** Obsolete normative reference: RFC 1466 (Obsoleted by RFC 2050) ** Obsolete normative reference: RFC 1475 (Obsoleted by RFC 6814) ** Downref: Normative reference to an Experimental RFC: RFC 1476 ** Downref: Normative reference to an Experimental RFC: RFC 1561 Summary: 24 errors (**), 0 flaws (~~), 19 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPng White Paper Michael McGovern 2 Internet Draft Sunspot Graphics 3 Robert Ullmann 4 Lotus Development Corporation 6 CATNIP: Common Architecture for the Internet 7 9 Status of this Memo 11 This document was submitted to the IETF IPng area in response to 12 RFC 1550 Publication of this document does not imply acceptance 13 by the IPng area of any ideas expressed within. Comments should 14 be submitted to the big-internet@munnari.oz.au mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its Areas, 20 and its Working Groups. Note that other groups may also distribute 21 working documents as Internet Drafts. 23 Internet Drafts are draft documents valid for a maximum of six 24 months. Internet Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 Please check the 1id-abstracts.txt listing contained in the 30 internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, 31 nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the 32 current status of any Internet Draft. 34 Executive Summary 36 This paper describes a common architecture for the network 37 layer protocol. The Common Architecture for Next Generation 38 Internet Protocol (CATNIP) provides a compressed form of the 39 existing network layer protocols. Each compression is defined 40 so that the resulting network protocol data units are identical 41 in format. The fixed part of the compressed format is 16 bytes 42 in length, and may often be the only part transmitted on the subnetwork. 44 With some attention paid to details, it is possible for a transport 45 layer protocol (such as TCP) to operate properly with one end system 46 using one network layer (e.g. IP version 4) and the other using some 47 other network protocol, such as CLNP. Using the CATNIP definitions, all 48 the existing transport layer protocols used on connectionless network 49 services will operate over any existing network layer protocol. 51 The CATNIP uses cache handles to provide both rapid identification 52 of the next hop in high performance routing as well as abbreviation of 53 the network header by permitting the addresses to be omitted when a 54 valid cache handle is available. The fixed part of the network layer 55 header carries the cache handles. 57 The cache handles are either provided by feedback from the downstream 58 router in response to offered traffic, or explicitly provided as part of 59 the establishment of a circuit or flow through the network. When used 60 for flows, the handle is the locally significant flow identifier. 62 When used for circuits, the handle is the layer 3 peer-to-peer logical 63 channel identifier, and permits a full implementation of network-layer 64 connection-oriented service if the routers along the path provide 65 sufficient features. At the same time, the packet format of the 66 connectionless service is retained, and hop by hop fully addressed 67 datagrams can be used at the same time. Any intermediate model between 68 the connection oriented and the connectionless service can thus be 69 provided over cooperating routers. 71 CATNIP Objectives 73 The first objective of the CATNIP is a practical recognition of the existing 74 state of internetworking, and an understanding that any approach must 75 encompass the entire problem. While it is common in the IP Internet to 76 dismiss CLNP with various amusing phrases, it is hardly realistic. 78 The CATNIP integrates CLNP, IP, and IPX. The CATNIP design provides 79 for any of the transport layer protocols in use, for example TP4, CLTP, TCP, 80 UDP, IPX and SPX to run over any of the network layer protocol formats: CLNP, 81 IP (version 4), IPX, and the CATNIP. 83 Incremental Infrastructure Deployment 85 The best use of the CATNIP is to begin to build a common Internet 86 infrastructure. The routers and other components of the common system 87 are able to use a single consistent addressing method, and common terms 88 of reference for other aspects of the system. 90 The CATNIP is designed to be incrementally deployable in the strong sense: 91 you can plop a CATNIP system down in place of any existing network 92 component and continue to operate normally with no reconfiguration. 93 (Note: not "just a little". None at all. The number of "little changes" 94 suggested by some proposals, and the utterly enormous amount of 95 documentation, training, and administrative effort then required, 96 astounds the present authors.) The vendors do all of the work. 98 There are also no external requirements; no "border routers", no 99 requirement that administrators apply specific restrictions to their 100 network designs, define special tables, or add things to the DNS. 101 When the end users and administrators fully understand the combined system, 102 they will want to operate differently, but in no case will they 103 be forced. Not even in small ways. Networks and end user 104 organizations operate under sufficient constraints on deployment of 105 systems anyway; they do not need a new network architecture adding to 106 the difficulty. 108 Typically deployment will occur as part of normal upgrade revisions of 109 software, and due to the "swamping" of the existing base as the network 110 grows. (When the Internet grows by a factor of 5, at least 80% will then 111 be "new" systems.) The users of the network may then take advantage of 112 the new capabilities. Some of the performance improvements will be 113 automatic, others may require some administrative understanding to get 114 to the best performance level. 116 The CATNIP definitions provide stateless translation of network 117 datagrams to and from CATNIP and, by implication, directly between the 118 other network layer protocols. A CATNIP-capable system implementing the 119 full set of definitions can interoperate with any existing protocol. 120 Various subsets of the full capability may be provided by some vendors. 122 No Address Translation 124 Note that there is no "address translation" in the CATNIP specification. 125 (While it may seem odd to state a negative objective, this is worth 126 saying as people seem to assume the opposite.) There are no "mapping 127 tables", no magic ways of digging translations out of the DNS or X.500, 128 no routers looking up translations or asking other systems for them. 130 Addresses are modified with a simple algorithmic mapping, a mapping that 131 is no more than using specific prefixes for IP and IPX addresses. Not a 132 large set of prefixes; one prefix. The entire existing IP version 4 133 network is mapped with one prefix and the IPX global network with one 134 other prefix. (The IP mapping does provide for future assignment of 135 other IANA/IPv4 domains that are disjoint from the existing one.) 137 This means that there is no immediate effect on addresses embedded in 138 higher level protocols. 140 Higher level protocols not using the full form (those native to IP and 141 IPX) will eventually be extended to use the full addressing to extend 142 their usability over all of the network layers. 144 No Legacy Systems 146 The CATNIP leaves no systems behind: with no reconfiguration, any system 147 presently capable of IP, CLNP, or IPX retains at least the connectivity it 148 has now. With some administrative changes (such as assigning IPX 149 domain addresses to some CLNP hosts for example) on other systems, 150 unmodified systems may gain significant connectivity. IPX systems with 151 registered network numbers may gain the most. 153 Limited Scope 155 The CATNIP defines a common network layer packet format and 156 basic architecture. It intentionally does not specify ES-IS methods, 157 routing, naming systems, autoconfiguration and other subjects not part 158 of the core Internet wide architecture. The related problems and their 159 (many) solutions are not within the scope of the specification of the 160 basic common network layer. 162 Existing Addresses and Network Numbers 164 The Internet's version 4 numbering system has proven to be very 165 flexible, (mostly) expandable, and simple. In short: it works. 166 However, there are two problems. Neither was considered serious when 167 the CATNIP was first developed in 1988 and 1989, but both are now of 168 major concern: 170 o The division into network, and then subnet, is insufficient. 171 Almost all sites need a network assignment large enough to 172 subnet. At the top of the hierarchy, there is a need to assign 173 administrative domains. 175 o As bit-packing is done to accomplish the desired network 176 structure, the 32-bit limit causes more and more aggravation. 178 Another major addressing system used in open internetworking is the OSI 179 method of specifying Network Service Access Points (NSAPs). The NSAP 180 consists of an authority and format identifier, a number assigned to 181 that authority, an address assigned by that authority, and a selector 182 identifying the next layer (transport layer) protocol. This is actually 183 a general multi-level hierarchy, often obscured by the details of 184 specific profiles. (For example, CLNP doesn't specify 20 octet NSAPs, it 185 allows any length. But various GOSIPs profile the NSAP as 20 octets, and 186 IS-IS makes specific assumptions about the last 1-8 octets. And so on.) 188 The NSAP does not directly correspond to an IP address, as the selector 189 in IP is separate from the address. The concept that does correspond is 190 the NSAP less the selector, called the Network Entity Title or NET. (An 191 unfortunate acronym, but one we will use to avoid repeating the full 192 term.) The usual definition of NET is an NSAP with the selector set to 193 0; the NET used here omits the 0 selector. 195 There is also a network numbering system used by IPX, a product of 196 Novell, Inc. (referred to from here on as Novell) and other vendors making 197 compatible software. While IPX is not yet well connected into a global network, 198 it has a larger installed base than either of the other network layers. 200 Network Layer Address 202 The network layer address looks like: 204 +----------+----------+---------------+---------------+ 205 | length | AFI | IDI ... | DSP ... | 206 +----------+----------+---------------+---------------+ 208 The fields are named in the usual OSI terminology although that leads to 209 an oversupply of acronyms. Here are more detailed descriptions of each field: 211 length: the number of bytes (octets) in the remainder of the 212 address. 214 AFI: the Authority and Format Identifier. A single byte 215 value, from a set of well-known values registered by 216 ISO, that determines the semantics of the IDI field 218 IDI: the Initial Domain Identifier, a number assigned by the 219 authority named by the AFI, formatted according to the 220 semantics implied by the AFI, that determines the 221 authority for the remainder of the address. 223 DSP: Domain Specific Part, an address assigned by the 224 authority identified by the value of the IDI. 226 Note that there are several levels of authority. ISO, for 227 example, identifies (with the AFI) a set of numbering authorities (like 228 X.121, the numbering plan for the PSPDN, or E.164, the numbering plan 229 for the telephone system). Each authority numbers a set of organizations 230 or individuals or other entities. (For example, E.164 assigns 231 16172477959 to me as a telephone subscriber.) 233 The entity then is the authority for the remainder of the address. I can 234 do what I please with the addresses starting with (AFI=E.164) 235 (IDI=16172477959). Note that this is a delegation of authority, and not 236 an embedding of a data-link address (the telephone number) in a network layer 237 address. The actual routing of the network layer address has nothing to do 238 with the authority numbering. 240 The domain-specific part is variable length, and can be allocated in 241 whatever way the authority identified by the AFI+IDI desires. 243 Network Layer Datagram 245 The common architecture format for network layer datagrams is described 246 below. The design is a balance between use on high performance networks 247 and routers, and a desire to minimize the number of bits in the fixed 248 header. The CATNIP avoids the mistake of making the fixed field too 249 small. Using the current state of processor technology as a reference, 250 the fixed header is all loaded into CPU registers on the first memory 251 cycle, and it all fits within the operation bandwidth. The header leaves 252 the remaining data aligned on the header size (128 bits); with 64 bit 253 addresses present and no options it leaves the transport header 256 bit 254 aligned. 256 On very slow and low performance networks, the fixed header is still 257 fairly small, and could be further compressed by methods similar to 258 those used with IP version 4 on links that consider every bit precious. 259 In between, it fits nicely into ATM cells and radio packets, leaving 260 sufficient space for the transport header and application data. 262 +---------------+---------------+-+-+-+-+-+-+-+-+---------------+ 263 | NLPID (70) | Header Size |D|S|R|M|E| MBZ | Time to Live | 264 +---------------+---------------+-+-+-+-+-+-+-+-+---------------+ 265 | Forward Cache Identifier | 266 +---------------------------------------------------------------+ 267 | Datagram Length | 268 +---------------------------------------------------------------+ 269 | Transport Protocol | Checksum | 270 +---------------------------------------------------------------+ 271 | Destination Address ... | 272 +---------------------------------------------------------------+ 273 | Source Address ... | 274 +---------------------------------------------------------------+ 275 | Options ... | 276 +---------------------------------------------------------------+ 278 NLPID: The first byte (the network layer protocol identifier in OSI) is 279 an 8 bit constant 70 (hex). This corresponds to Internet Version 7. 281 Header Length: The header length is a 8-bit count of the number of 32-bit 282 words in the header. This allows the header to be up to 1020 283 bytes in length. 285 Flags: This byte is a small set of flags determining the datagram header format 286 and the processing semantics. The last three bits are reserved, and must 287 be set to zero. (Note that the corresponding bits in CLNP version 1 are 288 001, since this byte is the version field. This may be useful.) 290 Destination Address Omitted: When the destination address omitted (DAO) flag 291 is zero, the destination address is present as shown in the datagram 292 format diagram. When a datagram is sent with an FCI that identifies the 293 destination and the DAO flag is set, the address does not appear in 294 the datagram. 296 Source Address Omitted: The source address omitted (SAO) flag is zero when the 297 source address is present in the datagram. When datagram is sent with 298 an FCI that identifies the source and the SAO flag is set, the source 299 address is omitted from the datagram. 301 Report Fragmentation Done: When this bit (RFD) is set, an intermediate router 302 that fragments the datagram (because it is larger than the next 303 subnetwork MTU) should report the event with an ICMP Datagram Too Big 304 message. (Unlike IP version 4, which uses DF for MTU discovery, the RFD 305 flag allows the fragmented datagram to be delivered.) 307 Mandatory Router Option: The mandatory router option (MRO) flag indicates that 308 routers forwarding the datagram must look at the network header 309 options. 310 If not set, an intermediate router should not look at the header 311 options. 312 (But it may anyway; this is a necessary consequence of transparent 313 network layer translation, which may occur anywhere.) 315 The destination host, or an intermediate router doing 316 translation, must look at the header options regardless of 317 the setting of the MRO flag. 319 A router doing fragmentation will normally only use the RFD flag in 320 options to determine whether options should be copied within the 321 fragmentation code path. (It might also recognize and elide null 322 options.) If the MRO flag is not set, the router may not act on an 323 option even though it copies it properly during fragmentation. 325 If there are no options present, MRO should always be zero, so that 326 routers can follow the no-option profile path in their implementation. 327 (Remember that the presence of options cannot be divined from the header 328 length, since the addresses are variable length.) 330 Error Report Suppression: The ERS flag is set to suppress the sending of 331 error reports by any system (whether host or router) receiving or 332 forwarding the datagram. The system may log the error, increment 333 network management counters, and take any similar action, but ICMP 334 error messages or CNLP error reports must not be sent. 336 The ERS flag is normally set on ICMP messages and other network layer 337 error reports. It does not suppress the normal response to ICMP queries 338 or similar network layer queries (CNLP echo request). 340 If both the RFD and ERS flags are set, the fragmentation report is sent. 341 (This definition allows a larger range of possibilities than simply 342 over-riding the RFD flag would; a sender not desiring this behavior can 343 see to it that RFD is clear.) 345 Time To Live: The time to live is a 8-bit count, nominally in seconds. Each 346 hop is required to decrement TTL by at least one. A hop that holds a 347 datagram for an unusual amount of time (more than 2 seconds, a typical 348 example being a wait for a subnetwork connection establishment) should 349 subtract the entire waiting time in seconds (rounded upward) from the 350 TTL. 352 Forward Cache Identifier: Each datagram carries a 32 bit field, called 353 "forward cache identifier", that is updated (if the information is 354 available) at each hop. This field's value is derived from ICMP 355 messages sent back by the next hop router, a routing protocol (e.g. 356 RAP), or some other method. The FCI is used to expedite routing 357 decisions by preserving knowledge where possible between consecutive 358 routers. It can also be used to make datagrams stay within reserved 359 flows, circuits, and mobile host tunnels. If an FCI is not available, 360 this field must be zero, the SAO and DAO flags must be clear, and both 361 destination and source addresses must appear in the datagram. 363 Datagram Length: The 32-bit length of the entire datagram in octets. 364 A datagram can therefore be up to 4294967295 bytes in overall length. 365 Particular networks normally impose lower limits. 367 Transport Protocol: The transport layer protocol. For example, TCP is 6. 369 Checksum: The checksum is a 16-bit checksum of the entire header, using the 370 familiar algorithm used in IP version 4. 372 Destination: The destination address, a count byte followed by the 373 destination NSAP with the zero selector omitted. This field is present 374 only if the DAO flag is zero. If the count field is not 3 modulo 4 375 (the destination is not an integral multiple of 32-bit words) zero 376 bytes are added to pad to the next multiple of 32 bits. These pad 377 bytes are not required to be ignored: routers may rely on them being 378 zero. 380 Source: The source address, in the same format as the destination. Present only 381 if the SAO flag is zero. The source is padded in the same way as 382 destination to arrive at a 32-bit boundary. 384 Options: Options may follow. They are variable length, and always 385 32-bit aligned. If the MRO flag in the header is not set, routers will 386 usually not look at or take action on any option, regardless of the 387 setting of the class field. 389 Multicasting 391 The multicast-enable option permits multicast forwarding of the CATNIP 392 datagram on subnetworks that directly support media layer multicasting. This 393 is a vanishing species, even in 10 Mbps Ethernet, given the increasing 394 prevalence of switching hubs. It also (perhaps more usefully) permits a router 395 to forward the datagram on multiple paths when a multicast routing algorithm 396 has established such paths. There is no option data. 398 Note that there is no special address space for multicasting in the 399 CATNIP. Multicast destination addresses can be allocated anywhere by any 400 administration or authority. This supports a number of differing models 401 of addressing. It does require that the transport layer protocol know 402 that the destination is multicast; this is desireable in any case. (For 403 example, the transport will probably want to set the ERS flag.) 405 On an IEEE 802.x (ISO 8802.x) type media, the last 23 bits of the 406 address (not including the 0 selector) are used in combination with the 407 multicast group address assigned to the Internet to form the media 408 address when forwarding a datagram with the multicast enable option from 409 a router to an attached network provided that the datagram was not 410 received on that network with either multicast or broadcast media 411 addressing. A host may send a multicast datagram either to the media 412 multicast address (the IP catenet model,) or media unicast to a router 413 which is expected to repeat it to the multicast address within the 414 entire level I area or to repeat copies to the appropriate end systems 415 within the area on non-broadcast media (the more general CLNP model.) 417 Network Layer Translation 419 The translating host or router must reassemble datagrams that have been 420 fragmented before translation. Where the translation is being done by 421 the destination host (for example, the case of a native CATNIP host 422 receiving IP version 4 datagrams), this is similar to the present 423 fragmentation model. 425 When it is being done by an intermediate router (acting as an 426 internetwork layer gateway) the router should use all of source, 427 destination, and datagram ID for identification of fragments. Note that 428 destination is used implicitly in the usual reassembly at the 429 destination. If the fragments take different paths through the net, and 430 arrive at different translation points, the datagram is lost. 432 The objective of translation is to be able to upgrade systems, both 433 hosts and routers, in whatever order desired by their owners. 434 Organizations must be able to upgrade any given system without 435 reconfiguration or modification of any other, and existing hosts must be 436 able to interoperate essentially forever. (Non-CATNIP routers will 437 probably be effectively eliminated at some point, except where they 438 exist in their own remote or isolated corners.) 440 Each CATNIP system, whether host or router, must be able to recognize 441 adjacent systems in the topology that are (only) IP version 4, CLNP, or 442 IPX and call the appropriate translation routine just before sending the 443 datagram. 445 OSI CNLP 447 The translation between CLNP and the CATNIP compressed form 448 of the datagrams is the simplest case for CATNIP, since the addresses 449 are the same and need not be extended. The resulting CATNIP datagrams 450 may omit the source and destination addresses as explained previously, 451 and may be mixed with uncompressed datagrams on the same subnetwork 452 link. Alternatively, a subnetwork may operate entirely in the CATNIP, 453 converting all transit traffic to CATNIP datagrams, even if FCIs that would 454 make the compression effective are not available. 456 Similarly, all network datagram formats with CATNIP mappings may 457 be compressed into the common form, providing a uniform transit 458 network service, with common routing protocols (such as IS-IS). 460 Internet Protocol 462 All existing version 4 numbers are defined as belonging to the Internet 463 by using a new AFI, to be assigned to IANA by the ISO. This document 464 uses 192 at present for clarity in examples; it is to be replaced with 465 the assigned AFI. The AFI specifies that the IDI is two bytes long, 466 containing an administrative domain number. 468 The AD (Administrative Domain), identifies an administration which may 469 be an international authority (such as the existing InterNIC), a national 470 administration, or a large multi-organization (e.g., a government). The 471 idea is that there should not be more than a few hundred of these at 472 first, and eventually thousands or tens of thousands at most. 474 AD numbers are assigned by IANA. Initially, the only assignment is the 475 number 0.0, assigned to the InterNIC, encompassing the entire existing 476 version 4 Internet. 478 The mapping from/to version 4 IP addresses: 480 +----------+----------+---------------+---------------------+ 481 | length | AFI | IDI ... | DSP ... | 482 +----------+----------+---------------+---------------------+ 483 | 7 | 192 | AD number | version 4 address | 484 +----------+----------+---------------+---------------------+ 486 While the address (DSP) is initially always the 4 byte, version 4 487 address, it can be extended to arbitrary levels of subnetting within the 488 existing Internet numbering plan. Hosts with DSPs longer than 4 bytes 489 will not be able to interoperate with version 4 hosts. 491 Novell IPX 493 The Internetwork Packet Exchange protocol, developed by Novell based on 494 the XNS protocol (Xerox Network System) has many of the same 495 capabilities as the Internet and OSI protocols. At first look, it 496 appears to confuse the network and transport layers, as IPX includes 497 both the network layer service and the user datagram service of the 498 transport layer, while SPX (sequenced packet exchange) includes the IPX 499 network layer and provides service similar to TCP or TP4. This turns out 500 to be mostly a matter of the naming and ordering of fields in the 501 packets, rather than any architectural difference. 503 IPX uses a 32-bit LAN network number, implicitly concatenated with the 504 48-bit MAC layer address to form an Internet address. Initially, the 505 network numbers were not assigned by any central authority, and thus 506 were not useful for inter-organizational traffic without substantial 507 prior arrangement. There is now an authority established by Novell to 508 assign unique 32-bit numbers and blocks of numbers to organizations that 509 desire inter-organization networking with the IPX protocol. 511 The Novell/IPX numbering plan uses an ICD, to be assigned, to designate 512 an address as an IPX address. This means Novell uses the authority 513 (AFI=47)(ICD=Novell) and delegates assignments of the following 32 bits. 515 An IPX address in the common form looks like: 517 +----------+----------+---------------+---------------------+ 518 | length | AFI | IDI ... | DSP ... | 519 +----------+----------+---------------+---------------------+ 520 | 13 | 47 (hex) | Novell ICD | network+MAC address | 521 +----------+----------+---------------+---------------------+ 523 This will always be followed by two bytes of zero padding when it 524 appears in a common network layer datagram. Note that the socket numbers 525 included in the native form IPX address are part of the transport layer. 527 SIPP 529 It may seem a little odd to describe the interaction with SIPP (version 530 6 of IP) which is now only another experimental candidate for the next 531 generation of network layer protocols. However, if SIPP is deployed, 532 whether or not as the protocol of choice for replacement of IP version 533 4, there will then be four network protocols to accommodate. It is 534 prudent to investigate how SIPP could then be integrated into the common 535 addressing plan and datagram format. 537 SIPP defines 64 bit addresses, which are included in the NSAP addressing 538 plan under the Internet AFI as AD number 0.1. It is not clear at this 539 time what administration will hold the authority for the SIPP numbering 540 plan. 542 +----------+----------+---------------+---------------------+ 543 | length | AFI | IDI ... | DSP ... | 544 +----------+----------+---------------+---------------------+ 545 | 11 | 192 | AD (0.1) | SIPP 64 bit address | 546 +----------+----------+---------------+---------------------+ 548 The SIPP addressing method (the definition of the 64 bits) will not be 549 described here. We note only that in the cases in which SIPP is 550 intended to interoperate directly with IP version 4, the last 32 bits of 551 the address is the IP version 4 address. This permits a convenient set 552 of translations without disturbing the transport protocols. 554 The SIPP proposal also includes an encapsulated-tunnel proposal called 555 IPAE, to address some of the issues that are designed into CATNIP. 556 The CATNIP direct translation does not use the SIPP-IPAE packet formats. 557 IPAE also specifies a "mapping table" for prefixes. This table is kept 558 up-to-date by periodic FTP transfers from a "central site." The CATNIP 559 definitions leave the problem of prefix selection when converting into 560 SIPP firmly within the scope of the SIPP-IPAE proposal, and possible methods 561 are not described here. 563 In translating from SIPP (IPv6) to CATNIP (IPv7), the only unusual aspect 564 is that SIPP defines some things that are normally considered options to 565 be "payloads" overloaded onto the transport protocol numbering space. 566 Fortunately, the only one that need be considered is fragmentation; a 567 fragmented SIPP datagram must be reassembled prior to conversion. Other 568 "payloads" such as routing are ignored (translated verbatim) and will 569 normally simply fail to achieve the desired effect. 571 Translation to SIPP is simple, except for the difficult problem of 572 inventing the "prefix" if an implementation wants to support translating 573 Internet AD 0.0 numbers into the SIPP addressing domain. 575 Internet DNS 577 CATNIP addresses are represented in the DNS with the NSAP RR. The data 578 in the resource record is the NSAP, including the zero selector at the 579 end. The zone file syntax for the data is a string of hexadecimal 580 digits, with a period "." inserted between any two octets where desired 581 for readability. For example: 583 The inverse (PTR) zone is .NSAP, with the CATNIP address (reversed). 584 That is, like .IN-ADDR.ARPA, but with .NSAP instead. The octets are 585 represented as hexadecimal numbers, with leading 0's. (Zero is always 586 written as ".00.") 588 This respects the difference in actual authority: the IANA is the 589 authority for the entire space rooted in .IN-ADDR.ARPA. in the version 4 590 Internet, while in the new Internet it holds the authority only for 591 C0.NSAP. The domain 00.00.C0.NSAP is to be delegated by IANA to the 592 InterNIC. (Understanding that in present practice the InterNIC is the 593 operator of the authoritative root.) 595 Security 597 The CATNIP design permits the direct use of the present proposals for 598 network layer security being developed in the IPSEC WG of the IETF. 599 There are a number of detailed requirements; the most relevent being 600 that network layer datagram translation must not affect (cannot affect) 601 the transport layers, since the TPDU is mostly inaccessible to the 602 router. For example, the translation into IPX will only work if the port 603 numbers are shadowed into the plaintext security header. 605 References 607 [Chapin93] A. Lyman Chapin, David M. Piscitello. Open Systems 608 Networking. Addison-Wesley, Reading, Massachusetts, 609 1993. 611 [Perlman92] Radia Perlman. Interconnections: Bridges and Routers. 612 Addison-Wesley. Reading, Massachusetts, 1992. 614 [RFC791] Jon Postel, editor. Internet Protocol. DARPA Internet 615 Program Protocol Specification, ISI/USC, September, 616 1981. 618 [RFC792] Jon Postel, editor. Internet Control Message Protocol. 619 DARPA Internet Program Protocol Specification, ISI/USC, 620 September, 1981. 622 [RFC793] Jon Postel, editor. Transmission Control Protocol. DARPA 623 Internet Program Protocol Specification, ISI/USC, 624 September, 1981. 626 [RFC801] Jon Postel, NCP/TCP transition plan. November, 1981. 628 [RFC1191] J. Mogul, S. Deering. Path MTU Discovery. November, 629 1990. 631 [RFC1234] D. Provan. Tunneling IPX Traffic through IP Networks. 632 Novell, Inc., June, 1991. 634 [RFC1247] J. Moy. OSPF Version 2. Proteon, Inc., July, 1991. 636 [RFC1287] D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby. 637 Towards the Future Internet Architecture. December, 638 1991. 640 [RFC1335] Z. Wang, J. Crowcroft, Two-tier address structure for 641 the Internet: A solution to the problem of address space 642 exhaustion. May, 1992. 644 [RFC1338] V. Fuller, T. Li, J. Yu, K. Varadhan. Supernetting: an 645 Address Assignment and Aggregation Strategy. June, 1992. 647 [RFC1347] R. W. Callon. TCP and UDP with Bigger Addresses (TUBA), 648 A simple proposal for Internet addressing and routing. 649 June, 1992. 651 [RFC1466] E. Gerich. Guidelines for Managemnet of IP Address 652 Space. Merit, May, 1993. 654 [RFC1475] Robert Ullmann. TP/IX: The Next Internet. Process 655 Software Corporation. June, 1993. 657 [RFC1476] Robert Ullmann. RAP: Internet Route Access Protocol. 658 Process Software Corporation. June, 1993. 660 [RFC1561] D. Piscitello. Use of ISO CLNP in TUBA Environments. 661 Core Competence. December, 1993. 663 Author's Addresses 665 Michael McGovern 666 Sunspot Graphics 668 EMAIL: scrivner@world.std.com 670 Robert Ullmann 671 Lotus Development Corporation 672 1 Rogers Street 673 Cambridge, MA 02142 675 Phone: +1 617 693 1315 676 Email: rullmann@crd.lotus.com