idnits 2.17.1 draft-ietf-ipae-ipv7-criteria-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-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any ** 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 -- Found 1 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 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 57 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** 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 112: '...2.2 CHANGES REQUIRED...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'CROCKER92' -- Possible downref: Non-RFC (?) normative reference: ref. 'DEERING92a' -- Possible downref: Non-RFC (?) normative reference: ref. 'DEERING92b' ** Obsolete normative reference: RFC 1338 (ref. 'FULLER92') (Obsoleted by RFC 1519) ** Downref: Normative reference to an Informational RFC: RFC 1380 (ref. 'GROSS92') Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Robert Hinden / Sun Microsystems 2 November 11, 1992 Steve Deering / Xerox PARC 3 Dave Crocker / The Branch Office 5 IPv7 Criteria Analysis 6 for IP Address Encapsulation (IPAE) 7 and the Simple Internet Protocol (SIP) 9 Abstract 10 -------- 12 This document describes how the IPv7 proposal called IP Address 13 Encapsulation (IPAE) meets the evaluation criteria established by the 14 Internet Engineering Steering Group and described in "RFC-1380 IESG 15 Deliberations on Routing and Addressing". IPAE is currently developed 16 to be a transition mechanism for a new IP protocol. This document 17 focuses on the specific case of using IPAE to transition to the Simple 18 IP Protocol (SIP). It addresses the criteria against both IPAE and SIP. 20 This document also includes how IPAE meets the criteria described by 21 Craig Partridge in a message titled "Criteria for selecting IPv7" sent 22 to the Big-Internet mailing list on 22-October-1992. 24 Status Of This Memo 25 ------------------- 27 Internet Drafts are working documents of the Internet Engineering Task 28 Force (IETF), its Areas, and its Working Groups. Note that other groups 29 may also distribute working documents as Internet Drafts. 31 Internet Drafts are draft documents valid for a maximum of six months. 32 This Internet Draft expires at the end of March 1993. Internet Drafts 33 may be updated, replaced, or obsoleted by other documents at any time. 34 It is not appropriate to use Internet Drafts as reference material or to 35 cite them other than as a "working draft" or "work in progress." 37 Please check the I-D abstract listing contained in each Internet Draft 38 directory to learn the current status of this or any other Internet 39 Draft. 41 Distribution of this memo is unlimited. 43 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 45 Acknowledgements 46 ---------------- 48 This document is based on the work of the IP Address Encapsulation 49 Working Group and the Simple IP Working of the Internet Engineering Task 50 Force. Dave Crocker is the chair of IPAE working group and Steve 51 Deering is the inventor of SIP and vice-chair of the SIP Working Group. 52 Christian Huitema is the chair of the SIP working group. 54 The authors would also like to thank Erik Nordmark, Geoff Mulligan, and 55 Bob Gilligan for their help providing inputs and comments on this 56 document. 58 1. INTRODUCTION 60 IP Address Encapsulation (IPAE) [CROCKER92] was developed to be a 61 transition mechanism for a new IP protocol. This document focuses on 62 the specific case of using IPAE to transition to the Simple IP Protocol 63 (SIP) [DEERING92a]. It addresses the criteria against both IPAE and 64 SIP. 66 This document describes how IPAE and SIP meet the evaluation criteria 67 established by the Internet Engineering Steering Group and described in 68 "RFC-1380 IESG Deliberations on Routing and Addressing" [GROSS92]. 70 This document also includes how IPAE and SIP meet the criteria described 71 by Craig Partridge in a message titled "Criteria for selecting IPv7" 72 sent to the Big- Internet mailing list on 22-October-1992. 74 The following definitions apply to the remainder of the document. An 75 IPv4 host implements only IPv4. An IPAE host implements IPv4, SIP, and 76 SIP encapsulated in IPv4. A SIP host only implements SIP. 78 2. IESG EVALUATION CRITERIA 80 This section describes how IPAE and SIP meet the IESG criteria. The 81 IESG criteria are delineated by ">>". 83 2.1 DESCRIPTION OF THE PROPOSED SCHEME 85 >> B.1 Description of the Proposed Scheme 86 >> 87 >> A complete description of the proposed routing and addressing 88 >> architecture should be supplied. This should be at the level of 89 >> detail where the functionality and complexity of the scheme can be 90 >> clearly understood. It should describe how the proposal solves the 91 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 93 >> basic problems of IP address exhaustion and router resource overload. 95 IPAE and SIP are described in detail in the following documents 96 currently being published as Internet Drafts: 98 IP Address Encapsulation (IPAE): A Mechanism for Introducing a New 99 IP [CROCKER92] 101 Simple Internet Protocol (SIP) Specification [DEERING92a] 103 Simple Internet Protocol (SIP) Addressing and Routing [DEERING92b] 105 In summary the IPAE proposal uses IP encapsulation and translation 106 between IPv4 and SIP to transition to a new IP protocol, namely SIP. It 107 can be first deployed in existing border routers to solve the current 108 routing explosion problems and later deployed in hosts to solve the IP 109 network address exhaustion problem. The final step is to run pure SIP 110 in all network devices that desire global communication. 112 2.2 CHANGES REQUIRED 114 The IPAE proposal introduces two new packet formats at the Internet 115 layer. These header formats are referred to as SIP and IPAE. SIP is a 116 new Internet Protocol header carrying larger addresses and with 117 streamlined functionality. IPAE is the SIP header format encapsulated 118 within an IPv4 header. 120 We call the larger Internet addresses carried in the SIP header a "SIP 121 address." We refer to the traditional 4-byte addresses simply as IP 122 addresses. 124 The IPAE proposal includes several transition steps. These steps in 125 time-order are: 127 1) Border routers are modified to add support for the IPAE and 128 SIP packet formats in addition to IPv4. 130 2) Hosts that need global communication are modified to add 131 support for the IPAE and SIP packet formats in addition to 132 IPv4. 134 3) The remaining routers are modified to add support for the 135 IPAE and SIP packet formats in addition to IPv4. This 136 step is optional. 138 4) Hosts and routers operating within sites that contain no 139 IPv4-only hosts or routers may be modified to remove support for 141 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 143 the IPv4 and IPAE packet formats. This step is optional. 145 The response is divided into separate sections for each of these 146 transition steps. 148 >> B.2 Changes Required 149 >> 150 >> All changes to existing protocols should be documented and new 151 >> protocols which need to be developed and/or deployed should be 152 >> specified and described. This should enumerate all protocols which 153 >> are not currently in widespread operational deployment in the 154 >> Internet. 156 The only new protocol required to be implemented is IPAE (SIP over IP). 157 Overall the following protocols will be required to change to implement 158 IPAE and SIP: 160 Modifications to ICMP 162 Modifications to Internet Group Multicast Protocol (IGMP) 164 Modifications to BGP4 to support SIP addresses 166 Modifications to selected IGP's to support SIP addresses 168 Modifications to TCP and UDP pseudo-header checksum calculation 170 Modifications to any protocol or application above IP that uses or 171 handles IP addresses to support the larger SIP addresses. 173 DNS extended to support SIP addresses and IP Address->SIP Address 174 mapping 176 SNMP MIBs modified to support SIP addresses. 178 The detail of when each change is required is described in the following 179 sections. 181 >> Changes should also be grouped by the devices and/or functions they 182 >> affect. This should include at least the following: 183 >> 184 >> - Protocol changes in hosts 185 >> - Protocol changes in exterior router 186 >> - Protocol changes in interior router 187 >> - Security and Authentication Changes 188 >> - Domain name system changes 189 >> - Network management changes 190 >> - Changes required to operations tools (e.g., ping, trace- 191 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 193 >> route, etc) 194 >> - Changes to operational and administration procedures 196 1) Add IPAE and SIP to Border Routers (Short Term) 198 No changes to Hosts required. 200 Selected border (exterior) routers support three packet formats: 201 IPv4, IPAE, and SIP. These routers also implement modified ICMP, 202 and modified BGP4. 204 Mapping tables implemented to translate IP addresses into SIP 205 addresses to simplify routing. 207 Remaining exterior routers unchanged. 209 No changes to interior routers. 211 No changes to Security and Authentication. 213 No changes to DNS. 215 Network management support for MIBs in Border Routers for IPAE, 216 modified ICMP, and modified BGP4. 218 Extensions to existing operational tools (e.g. Ping, Traceroute) to 219 support larger addresses needed for Border router operation. 220 Existing IP tools continue to function. 222 Existing IP operational and administrative procedures continue to 223 function. New procedures needed for operation of border routers. 225 2) Add IPAE and SIP Support to Hosts Needing Global Communication 226 (Medium Term) 228 Hosts support three packet formats: IPv4, IPAE, SIP. These hosts 229 also support modified ICMP, IGMP, TCP, UDP, and applications. 231 No change in border routers from previous stage. Remaining 232 exterior routers unchanged. 234 No change to interior routers. 236 Security and Authentication procedures extended to work with SIP 237 addresses. 239 A new resource record type is added to the DNS to store SIP host 240 addresses. The existing "A" record type is unchanged. Hosts that 242 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 244 support IPv4/IPAE/SIP are given both resource records. Hosts that 245 support only IPv4 may continue to have only A records. However 246 performance improves if IPv4-only hosts are given both records. IP 247 address -> SIP Address mapping also added. 249 Network management support for MIBs in Hosts. 251 No additional tool changes for this step. 253 Existing IP operational and administrative procedures continue to 254 function. New procedures needed for operation of IPAE hosts. 256 3) Add IPAE and SIP Support to All Routers (Long Term & Optional) 258 The remaining routers (interior and exterior) implement three 259 packet formats: IPv4, IPAE, and SIP. These routers also implement 260 modified ICMP and router discovery protocols. 262 No changes to Hosts in this step. 264 No change in border router from previous stages. Remaining 265 exterior routers implement IPv4/IPAE/SIP, modified ICMP, and 266 modified BGP4. 268 Interior routers implement SIP and modified IGP's. 270 No Security and Authentication changes in this step. 272 No changes to DNS in this step. 274 Network management support for MIBs in routers. 276 No additional tool changes for this step. 278 Existing IP operational and administrative procedures continue to 279 function. New procedures needed for operation of IPv4/IPAE/SIP 280 routers. 282 4) Remove IPv4 and IPAE support from hosts and routers. 284 Hosts and routers running in sites having no hosts or routers 285 understanding only IPv4 do not have to support IPv4 and IPAE packet 286 formats. 288 This step is optional. It should not be implemented in sites that 289 still have IPv4-only hosts or routers. 291 >> The changes should also include if hosts and routers have their 292 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 294 >> current IP addresses changed. 296 All existing IP devices are not required to change their IP addresses. 298 >> The impact and changes to the existing set of TCP/IP protocols should 299 >> be described. This should include at a minimum: 300 >> 301 >> - IP 303 No change. 305 >> - ICMP 307 New SIP redirect defined and addition of a pseudo-header checksum to 308 ICMP checksum calculation when communicating between SIP hosts. 310 >> - DNS 312 A new resource record type is added to the DNS to store SIP host 313 addresses. The existing "A" record type is unchanged. Hosts that 314 support IPv4/IPAE/SIP are given both resource records. Hosts that 315 support only IPv4 may continue to have only A records. However 316 performance improves if IPv4-only hosts are given both records. IP 317 address -> SIP Address mapping also added. 319 >> - ARP/RARP 321 No changes. 323 >> - TCP 325 No change except for pseudo checksum calculation. Connections between 326 hosts that support IPv4/IPAE/SIP and hosts that support only IPv4 use 327 low order 32-bits of address for pseudo checksum calculation. 328 Connections between hosts that support IPv4/IPAE/SIP will automatically 329 use the IPAE or SIP packet format and will use the SIP addresses for 330 pseudo checksum calculation. 332 TCP modified to handler longer SIP addresses for matching incoming 333 packets to the appropriate connection state. 335 >> - UDP 337 Same as for TCP. 339 >> - FTP 341 Modified to use SIP addresses. 343 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 345 >> - RPC 347 Modified to use SIP addresses. 349 >> - SNMP 351 Changes to existing MIBs that carry IP addresses. 353 >> The impact on protocols which use IP addresses as data should be 354 >> specifically addressed. 356 These will need to be modified to carry SIP addresses. 358 Note that the text representation of SIP addresses enables them to be 359 distinguished from both IP addresses and domain names. This should 360 simplify the addition of SIP address capability to existing user 361 interfaces, e.g., wherever the text form of an IP address currently 362 appears. 364 2.3 IMPLEMENTATION EXPERIENCE 366 >> B.3 Implementation Experience 367 >> 368 >> A description of implementation experience with the proposal should be 369 >> supplied. This should include the how much of the proposal was 370 >> implemented and hard it was to implement. If it was implemented by 371 >> modifying existing code, the extent of the modifications should be 372 >> described. 374 Implementations are underway at Sun Microsystems, Silicon Graphics, 375 Proteon, and Digital Equipment Corporation. 377 The implementation at Sun has focused on the transport and internet 378 layers using modified telnet and ping programs that handle bigger 379 addresses. The core of this implementation is a combined internet layer 380 that handles IP, SIP and IPAE packet formats. The implementation can 381 act as a IP/SIP/IPAE host, an IP router, a SIP/IPAE router, as well as a 382 border router. 384 Most of the host, router and border router functionality has been 385 implemented and tested. IP hosts have communicated with IPAE hosts both 386 directly and using an IPAE (encapsulating/decapsulating) border router. 387 IPAE hosts have communicated with IPAE hosts on the same subnet (using 388 SIP without any encapsulating IPv4 header), through IP routers and 389 through border/IPAE routers. Complex details like path MTU discovery 390 work in the presence of encapsulating border routers. 392 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 394 The changes to the transport protocols were quite simple. In addition 395 to the necessary modifications to TCP and UDP to handle bigger addresses 396 there were only some minor modifications to the pseudo-header checksum 397 calculation logic, the connection identification logic, and adding the 398 interpretation of all the possible ICMP error packet formats. 400 The modifications to the internet layer consists of changes to the 401 routing table and extensions to handle the different packet formats. 402 The routing table was modified to handle bigger addresses in such a way 403 that the same table can be used for IP routing, SIP routing and IP->SIP 404 address mappings. The changes to handle the IP, IPAE, and SIP header 405 formats were fairly simple, especially since the choice of header format 406 to use when transmitting was driven from the routing table. In addition 407 ICMP was modified to conditionally use the SIP pseudo-header checksum 408 and to include SIP headers in the ICMP error packets. 410 In summary, the following code is working to date: 412 - Host sending/receiving IPv4/SIP/IPAE datagrams including SIP 413 fragmentation (SIP fragmentation code was taken directly form the 414 IP fragmentation/reassembly code) 416 - Router forwarding all of the above 418 - Border router translating between IP and SIP (both directions) 419 including modifying ICMP checksum and mapping IP 420 fragments to SIP fragments and vice versa 422 - Host and router generating and host consuming ICMP error 423 messages that contain IPv4 or SIP header in the "original 424 datagram" part 426 - The host can also handle ICMP error messages from IP routers 427 (where the "original datagram" contains both IP and SIP 428 headers) 430 - Border router mapping IPv4/ICMP error packets received from 431 IP routers to SIP/ICMP error packet and sending them back to 432 the "SIP" source. (includes adjusting the mtu in ICMP "packet 433 too big" to take into account the encapsulation header) 435 Future modifications include adding support for the new ICMP redirect 436 message. 438 The DEC implementation is currently focusing on IPAE and SIP host 439 functionality. The code is currently being debugged. A TCP dump 440 program has also been modified to decode SIP and IPAE datagrams. 442 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 444 SGI is currently working on a SIP/IPAE decoding module for their network 445 traffic analysis package called NetVisualizer. 447 2.4 LARGE INTERNET SUPPORT 449 >> B.4 450 >> 451 >> The proposal should describe how it will scale to support a large 452 >> internet of 10^^9 networks. It should describe how the proposed 453 >> routing and addressing architecture will work to support an internet 454 >> of this size. This should include, as appropriate, a description of 455 >> the routing hierarchy, how the routing and addressing will be 456 >> organized, how different layers of the routing interact (e.g., 457 >> interior and exterior, or L1, L2, L3, etc), and relationship between 458 >> addressing and routing. 459 >> 460 >> The addressing proposed should include a description of how addresses 461 >> will be assigned, who owns the addresses (e.g. user or service 462 >> provider), and whether there are restrictions in address assignment or 463 >> topology. 465 SIP address are 64 bits long. For purposes of scalable routing, they 466 are divided into variable-length subfields, with the field boundaries 467 being identified by 64-bit masks that are carried in routing updates and 468 stored in routing tables, as with CIDR [FULLER92]. The variable-length 469 subfields allow considerable flexibility in assigning a hierarchical 470 structure to the SIP addresses. The SIP Addressing and Routing document 471 [DEERING92b] proposes two general structures for unicast addresses, one 472 based on a service-provider hierarchy and one based on a geographic 473 hierarchy. Both hierarchies can be accommodated in the same 64-bit 474 space. 476 For analyzing the scalability of the geographic ("metro-based") 477 addresses, assume the following address layout. (This is not the only 478 possible layout. In particular, it is not necessary to define fixed 479 boundaries as illustrated; more efficient use could be made of the 480 address space by allowing the boundaries to vary for different countries 481 and for different sites.) 483 |1| 15 | 32 | 16 | 484 +-+------+--------+--------+--------+--------+--------+--------+--------+ 485 |C| country + | site ID | intra-site | 486 | | metro ID | | part | 487 +-+------+--------+--------+--------+--------+--------+--------+--------+ 489 The 15-bit country + metro ID field is internally structured into two 490 parts, one identifying the country and one identifying the metropolitan 491 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 493 area in which a site is connected to the public Internet. By using a 494 variable-length encoding, whereby large countries are assigned more 495 metro IDs than small countries, less than 3/8ths of that 15-bit address 496 space is required to cover all of the metropolitan areas in the world 497 (based on a United Nations projection for national populations in the 498 year 2025, and a generous estimate of one metro area for every one 499 million people; see [DEERING92b] for details). 501 Within each metro, there are 32 bits of address space available to 502 identify individual customer sites. Those 32 bits may be internally 503 structured (e.g., divided into sub-regions of the metro area or divided 504 among service providers operating in the metro area), or treated as a 505 flat field used as a key to a database lookup, for mapping site ID to 506 topological location. In either case, it is sufficient to address 507 hundreds of millions of sites, enough to support the attachment of every 508 office and household in the metro area. 510 Each site gets 16 bits of address space (65,536 address) to identify 511 internal subnets and hosts. This is equivalent to assigning an IP Class 512 B network number to every house, apartment, and office. Those few 513 sites, that might require a larger address space, such as large 514 campuses, may obtain multiple, contiguous site IDs. 516 Thus, SIP metro-based addresses can be seen to scale to at least 10^12 517 customer sites (10^4 metro areas times 10^8 sites per metro), and 10^16 518 hosts (assuming 10^4 hosts per site). Furthermore, it is possible to 519 route to that many destinations without burdening any router with a 520 routing table larger than 10^4 entries. 522 A similar analysis for a provider-based address hierarchy is more 523 difficult, because it has hard to predict how many providers must be 524 accommodated and how many subscribers they each are likely to have. It 525 is probable that there will be many small providers with relatively 526 small numbers of subscribers, and a small number of large providers with 527 very many subscribers. The use of masks and variable-length subfields 528 in SIP allows the address space to be used efficiently in such cases, 529 i.e., it is not necessary to give every provider enough address space to 530 handle the subscriber base of the largest provider. 532 For a rough estimate of the scalability of SIP provider-based addresses, 533 consider the following address layout: 535 |1| 15 | 16 | 16 | 16 | 536 +-+------+--------+--------+--------+--------+--------+--------+--------+ 537 |C| country + | subscriber ID |intra-subscriber | 538 | | provider ID | | | part | 539 +-+------+--------+--------+--------+--------+--------+--------+--------+ 540 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 542 More than half of the initial 15-bit field, i.e., more than 30,000 543 values, is available for identifying providers, after the assignment of 544 metro IDs and the multicast prefix is taken into account. If there turn 545 out to be more providers than that in the world, it is highly likely 546 that many of them will operate within the confines of a single metro 547 area or a few metro areas, in which case they can be given identifying 548 prefixes from the metro-based address space. 550 The remaining 48 bits of the address are structured for the convenience 551 of the individual provider and its subscribers. Assume a very simple, 552 fixed hierarchy consisting of three 16-bit subfields, the first two used 553 by the provider to reach an individual subscriber, and the last one used 554 within the subscribers facilities (again, equivalent to an IP Class B 555 address per subscriber, recognizing that a subscriber with a large 556 internal internet may obtain a bigger piece of address space from the 557 provider). If the provider's routers can support up to 10,000 entries 558 at each level of its two-level hierarchy, then that provider can support 559 up to 100,000,000 subscribers, and the scaling limit for provider-based 560 addresses is roughly the same as for metro-based addresses: 10^12 561 subscribers (10^4 providers times 10^8 subscribers per provider), and 562 10^16 hosts (assuming 10^4 hosts per site). 564 Note that the encoding of IPv4 addresses within SIP addresses (C-bit = 565 1) can conform to either the metro-based hierarchy or the provider-based 566 hierarchy. The "intra-site" or "intra-subscriber" part of such SIP 567 addresses consists of those bits of the IP address following the IP 568 "network number", and therefore may range between 8 bits (for a Class C 569 network) and 24 bits (for a Class A network). 571 Routing of SIP packets is performed in the same way, and using the same 572 routing protocols, as contemporary IPv4 or CLNP, modified as necessary 573 to handle 64-bit addresses and masks. The approach is the same as that 574 proposed for CLNP/TUBA, using a variety of routing protocols (e.g., 575 OSPF, BGP, IDRP), composed hierarchically according to the addressing 576 hierarchy. 578 (Metro-based routing is a somewhat more complicated than that; see 579 [DEERING92b] for details.) 581 Regarding assignment and ownership of SIP addresses: 583 global authority, such as ISOC: 584 - assigns blocks of metro IDs to national authorities. 585 - assigns blocks of provider IDs to national authorities. 586 - assigns well-known multicast addresses. 588 national authority, such as national chapter of ISOC: 589 - assigns individual metro IDs to metropolitan areas. 591 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 593 - assigns individual provider IDs to providers. 594 - assigns individual site IDs to sites, and maintains site ID 595 registry; may assign blocks of site IDs to providers for 596 subsequent assignment to their subscribers, under condition that, 597 once assigned, a site ID becomes bound to the site, regardless 598 of provider, and is registered in the national registry. 600 provider: 601 - assigns individual subscriber IDs to subscribers, structured 602 for the convenience of the provider. 603 - may assign individual site IDs to subscriber sites, if so 604 delegated by the national authority. 606 site/subscriber: 607 - assigns intra-site or intra-subscriber part, i.e., subnet IDs 608 and interface IDs. 609 - annually confirms continued use of site ID(s) with the national 610 authority; lack of such confirmation frees the site ID for 611 re-use by another site after one more year passes. 613 2.5 SYNTAX AND SEMANTICS OF NAMES, IDENTIFIERS AND ADDRESSES 615 >> B.5 Syntax and semantics of names, identifiers and addresses 616 >> 617 >> Proposals should address the manner in which data sources and 618 >> sinks are identified and addressed, describe how current domain 619 >> names and IP addresses would be used/translated/mapped in their 620 >> scheme, how proposed new identifier and address fields and 621 >> semantics are used, and should describe the issues involved in 622 >> administration of these id and address spaces according to their 623 >> proposal. The deployment plan should address how these new 624 >> semantics would be introduced and backward compatibility 625 >> maintained. 626 >> 627 >> Any overlays in the syntax of these protocol structures should be 628 >> clearly identified and conflicts resulting from syntactic overlay 629 >> of functionality should be clearly addressed in the discussion of 630 >> the impact on administrative assignment. 632 Data sources and sinks are identified by their Domain Names and their 633 SIP addresses. The Domain Names are identical to those currently used. 634 The SIP addresses are an extension to current IP addresses, with 32-bits 635 of global address information pre-pended to the existing 32-bit 636 addresses. The new bits are organized into an administrative hierarchy, 637 permitting both geographic-based and provider-based addressing. 639 The full scheme is: 641 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 643 Country Provider/Metropolitan Subscriber/Site IP Address 645 In reality, the high-order 32 bits extend the IP Network address field, 646 so that sites will have their Subnetwork and Host IP address fields held 647 constant, but will have IP Network address assigned by their provider or 648 Metropolitan Internet eXchange. While IP addresses continue to be 649 globally administered, however, the two sets of 32-bits will be assigned 650 independently. 652 Support for SIP addresses by the Domain Name service requires new 653 resource records and a new in-addr table. Because each SIP address is 654 an extension to an IP address, Domain Name Service servers do not need 655 to maintain separate, internal data bases. Instead they can treat IP 656 and SIP accesses as different views onto the same data base. 658 Mapping between SIP and IP addresses is straightforward, since SIP 659 addresses are an extension to IP addresses. As long as IP addresses 660 remain unique, then simple removal of the top 32 bits is needed to 661 convert from SIP to IP. To map from IP to SIP will require a 662 translation table, possibly maintained through the Domain Name Service. 664 Addresses can be administered by the same system currently in place for 665 administering IP addresses. Country references will use the CCITT E.163 666 Detailed Country Code (DCC) scheme, with metropolitan numeric references 667 that derive from the DCC authorities. 669 Administrations which wish to support SIP and/or IPAE will obtain their 670 SIP network address from the appropriate authority. These references 671 can be used in parallel with continued use of IP addresses. 673 IPAE is specifically designed to support a wide range of backward- 674 compatibility requirements. The SIP address has been tailored to 675 support this. In addition to the straightforward benefits of using a 676 SIP address that is a simple extension to an IP address, the SIP address 677 format contain a bit (called the Compatibility bit) which indicates 678 whether the referenced node is using IP or IPAE/SIP. Hence a site does 679 not need to consult special tables, or otherwise maintain any state 680 information about a node, other than to have a copy of their address. 681 Further, SIP specifies tailoring the transport-level pseudo-header 682 checksum to use only the lower 32-bits of the SIP address, if the remote 683 site is an IP site. This means that a gateway providing translation 684 between IP and IPAE/SIP works only with the internetwork-sublayer 685 headers and does not need to touch any transport-level information. 687 The IPAE spec provides for IP-SIP, IP/IPAE, IPAE/IPAE, and IPAE/SIP 688 interactions, either directly or through use of translating gateways. 689 This range of options permits hosts and routers to make independent 690 decisions to support IPAE and SIP and to be able to communicate with 691 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 693 other IPAE and SIP nodes as soon as they, too, add support. 695 2.6 PERFORMANCE IMPACT 697 >> B.6 Performance Impact 698 >> 699 >> The performance impact of the new routing and addressing architecture 700 >> should be evaluated. It should be compared against the current state 701 >> of the art with the current IP. The performance evaluation for 702 >> routers and hosts should include packets-per-second and memory usage 703 >> projections, and bandwidth usage for networks. Performance should be 704 >> evaluated for both high speed speed and low speed lines. 705 >> 706 >> Performance for routers (table size and computational load) and 707 >> network bandwidth consumption should be projected based on the 708 >> following projected data points: 709 >> 710 >> -Domains 10^^3 10^^4 10^^5 10^^6 10^^7 10^^8 711 >> -Networks 10^^4 10^^5 10^^6 10^^7 10^^8 10^^9 712 >> -Hosts 10^^6 10^^7 10^^8 10^^9 10^^10 10^^11 714 Forwarding performance of IPAE and SIP should be equal or better than 715 current IPv4. 717 For IPAE, there is the non-negligible bandwidth cost of carrying the 718 extra header (4% of 576-byte packet), plus the CPU overhead of 719 encapsulating and decapsulating SIP in IP. 721 SIP has a number of features which should give similar or even superior 722 performance to IPv4. These include: 724 Small Header (24 bytes vs. 20 for IPv4) 726 No checksum 728 64-bit alignment of addresses 730 No options in header 732 64-bit addresses 734 These features should offset the following disadvantages: 736 24 byte header instead of 20 byte implies a very small increase in 737 bandwidth overhead (0.7% for 576-byte packets; less for larger 738 packets). 740 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 742 Longer addresses may increase route lookup time (how much, depends 743 on lookup algorithm -- radix tree vs. hash) on current-generation 744 processors; will become insignificant, and maybe even beneficial, 745 on future, 64-bit processors. 747 For loose-source-routed packets, SIP should have significant performance 748 advantage over IP, since intermediate routers need not examine the 749 source route. 751 Memory usage should grow far less than linearly. Space allocated for IP 752 addresses will double. 754 Bandwidth usage will be very similar to IPv4. The SIP header is only 755 four bytes longer than IPv4. 757 SIP will work very well on both high speed and low speed lines. 758 Additional header compression schemes will provide very good results 759 because only the TTL field in SIP changes, there is no checksum and no 760 Identifier. 762 2.7 SUPPORT FOR TCP/IP HOSTS THAN DO NOT SUPPORT THE NEW ARCHITECTURE 764 >> B.7 Support for TCP/IP hosts than do not support the new architecture 765 >> 766 >> The proposal should describe how hosts which do not support the new 767 >> architecture will be supported -- whether they receive full services 768 >> and can communicate with the whole Internet, or if they will receive 769 >> limited services. Also, describe if a translation service be provided 770 >> between old and new hosts? If so, where will be this be done. 772 For the transition period when IPv4 addresses are still globally unique 773 (i.e. before the Internet runs out of IP network addresses) IPAE 774 provides direct communication between IPv4, IPAE, and pure SIP hosts. 775 All hosts will be able to communicate to all other hosts regardless of 776 which protocol they implement. Translation service will be done in 777 border routers. Similarity between SIP and IP makes translation 778 straightforward. 780 After IP network addresses have run out, IPAE will permit IPv4 hosts to 781 communicate with SIP hosts with in a site. Translation can also be done 782 between SIP hosts and IPv4 hosts in the same site by interior routers. 784 IPAE is designed to provide convenient interoperation between IP-IP, 785 SIP-IP, IP-SIP, IP-IPAE, and SIP-IPAE. This permits participants to 786 make conversions as convenient, rather than according to a imposed 787 schedule with "flag" days. Further, the burden of supporting "dual 788 stack" operation is essentially eliminated. Translation gateways will 789 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 791 not need to maintain tables that specify which hosts have converted and 792 which hosts have not. 794 2.8 EFFECT ON USER COMMUNITY 796 >> B.8 Effect on User Community 797 >> 798 >> The large and growing installed base of IP systems comprises people, 799 >> as well as software and machines. The proposal should describe 800 >> changes in understanding and procedures that are used by the people 801 >> involved in internetworking. This should include new and/or changes 802 >> in concepts, terminology, and organization. 804 The effect on the user community should be very small. All of the 805 concepts and most of the terminology, formats, and software in IPAE and 806 SIP are based on existing IP concepts. SIP is in every regard a new 807 version of IP. No new concepts or terminology are introduced. Anyone 808 who understands how IPv4 works and operates, can understand the details 809 of SIP in a very short amount of time since it is only a modification to 810 current IP. The amount of training required to existing personnel 811 should be very small. 813 2.9 DEPLOYMENT PLAN DESCRIPTION 815 >> B.9 Deployment Plan Description 816 >> 817 >> The proposal should include a deployment plan. It should include the 818 >> steps required to deploy it. Each step should include the devices and 819 >> protocols which are required to change and what benefits are derived 820 >> at each step. This should also include at each step if hosts and 821 >> routers are required to run the current and proposed internet 822 >> protocol. 823 >> 824 >> A schedule should be included, with justification showing that the 825 >> schedule is realistic. 827 The protocol and device changes required for each step are described in 828 section 2.2 of this document. 830 In summary the basic steps in the transition plan are: 832 1) Deploy IPAE in Border Routers 833 2) Deploy IPAE in hosts needing global communication 834 3) Deploy SIP in all routers 836 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 838 A proposed schedule for this transition plan is as follows: 840 1. IETF Adopts IPAE Plan Jan 93 841 2. Complete specifications and protocol changes Jul 93 842 3. Deploy IPAE in Border Routers and Jan 94 843 Implement DNS Changes 844 4. Start IPAE Deployment in Hosts Jan 94 845 5. Complete IPAE Deployment in Hosts Jan 98 846 6. Deploy SIP in Routers and Hosts (not required) 848 The time to complete the specifications (step 2) should be easy to 849 accomplish in 6 months. The work to date has been done by a small group 850 of people in about 6 months. 852 IPAE could be deployed in the initial set of border routers (NSFNET) six 853 months later. Current experience with implementing the protocol shows 854 it to be easy to implement. Assuming that code was developed while the 855 specifications were being finalized, it should be feasible to turn on 856 IPAE in border routers in Jan 94. This deployment would provide 857 immediate relief to the backbone the routing explosion problems. 859 IPAE in hosts can start to be deployed as soon as the border routers are 860 running IPAE. In fact, hosts can deploy IPAE before the border routers 861 implement IPAE as long as the DNS mappings are installed. 863 Step 5 needs to be done before the IPv4 addresses run out. Our current 864 estimate of this is about five years from now. It is reasonable to 865 expect that the majority of hosts in the Internet could implement and 866 deploy IPAE within five years. 868 There is no firm date requirement to complete the deployment of SIP in 869 all routers. It can be done on a local site-by-site basis. There is no 870 requirement to tie this to an overall internet transition plan. 872 2.10 SECURITY IMPACT 874 >> B.10 Security Impact 875 >> 876 >> The impact on current and future security plans should be 877 >> addressed. Specifically do current security mechanisms such as 878 >> address and protocol port filtering work in the same manner as 879 >> they do today, and what is the effect on security and 880 >> authentication schemes currently under development. 882 Existing security mechanisms can be extended to work with SIP addresses 883 and would work in the manner essentially the same as they do today. 884 Also the SIP mechanism for extension headers allows security options to 885 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 887 be defined which would not fit in the options space of IPv4. 889 2.11 FUTURE EVOLUTION 891 >> B.11 Future Evolution 892 >> 893 >> The proposal should describe how it lays a foundation for solving 894 >> emerging internet problems such as security/authentication, mobility, 895 >> resource allocation, accounting, high packet rates, etc. 897 SIP is a fully functional replacement for IPv4, with a number of 898 improvements, particularly in the areas of scalability of routing and 899 addressing, and of performance. SIP would serve as an excellent base 900 for solving the emerging Internet problems indicated above. For 901 example: 903 ARP may be modified to carry full 64-bit addresses, and to use 904 link-layer multicast addresses, rather than broadcast addresses. 906 The 28-bit Reserved field in the SIP header may be defined as a 907 "Flow ID", or partitioned into a Type of Service field and a Flow 908 ID field, for classifying packets deserving special handling, e.g., 909 non-default quality of service or real-time service. On the other 910 hand, the transport-layer port fields may be adequate for 911 performing any such classification. (One possibility would be 912 simply to remove the port fields from TCP & UDP and append them to 913 the SIP header, as in XNS.) 915 A new ICMP "destination has moved" message may be defined, for re- 916 routing to mobile hosts or subnets, and to domains that have 917 changed their address prefixes. 919 An explicit Trace Route message or option may be defined; the 920 current IPv4 traceroute scheme will work fine with SIP, but it does 921 not work for multicast, for which it has become very apparent that 922 management and debugging tools are needed. 924 A new Host-to-Router protocol may be specified, encompassing the 925 requirements of router discovery, black-hole detection, auto- 926 configuration of subnet prefixes, "beaconing" for mobile hosts, 927 and, possibly, address resolution. The OSI End System To 928 Intermediate System Protocol may serve as a good model for such a 929 protocol. 931 The requirement that SIP addresses be strictly bound to interfaces 932 may be relaxed, so that, for example, a system might have fewer 933 addresses than interfaces. There is some experience with this 935 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 937 approach in the current Internet, with the use of "unnumbered 938 links" in routing protocols such as OSPF. 940 Authentication and integrity-assurance mechanisms for all clients 941 of SIP, including ICMP and IGMP, may be specified, possibly based 942 on the Secure Data Network System (SDNS) SP-3 or SP-4 protocol. 944 3. CRAIG PARTRIDGE CRITERIA 946 >> 1. The protocol must allow a straightforward transition plan from 947 >> the current IPv4. 948 >> 949 >> [If we can't transition to the new protocol, then no matter how wonderful 950 >> it is, we'll never get to it.] 952 IPAE provides a straightforward flexible transition plan. It is first 953 deployed in (~100) selected border routers. This provides an immediate 954 and permanent solution to the IP Routing explosion problems. The next 955 step is to deploy IPAE in hosts. This step does not have to be 956 completed until the Internet approaches the time when IP Network 957 addresses are close to running out. This should provide enough time to 958 convert the majority of hosts in the internet. During this transition 959 period (~5 year) border routers will provide translation services 960 between IP only and IPAE hosts. Direct communication is only provided 961 between IPAE and IP hosts only during the transition between sites 962 globally, and after IP address are no longer globally unique, inside of 963 a site. The last step of the transition, converting all routers to SIP 964 is independent of the Internet addressing and routing problems, and can 965 be done at the convenience of individual sites and service providers. 967 >> 2. The protocol must scale to allow the addressing of billions of 968 >> end-systems. 969 >> 970 >> [If we cannot address all hosts in some fashion, presumably we cannot 971 >> connect them all to the network, and we cannot hope to route data to 972 >> them.] 974 This topic was discussed in detail in section 2.4 "LARGE INTERNET 975 SUPPORT". 977 >> 3. The protocol must permit the use of routing schemes which allow 978 >> routing tables to grow at a rate much less than linearly with the 979 >> number of constituent networks. 980 >> 981 >> [If we can't route then connecting all those hosts is worthless, but 982 >> without connected hosts, there's no point in routing. Thus this is 983 >> third.] 984 >> 985 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 987 >> (As a rough sanity check for any scheme, assume that an inexpensive 988 >> router [costing $5K 1992 USD] in the year 2000 will have around 1 gigabyte 989 >> of router table memory and at that time there will be about 2 million 990 >> networks and 75 million end-systems). 992 As mentioned under the previous addressing discussion, the SIP 993 addressing hierarchy can keep the number of routes handled by any one 994 router down to 10^4, which is within the capacity of current-generation 995 routers, let alone future ones. Flat addressing to millions of sites 996 within a metro area could benefit from large, cheap memories, but they 997 are not essential (could use disk storage and RAM-based caches instead). 999 >> 4. The protocol must work across an internetwork with individual link 1000 >> speeds ranging from a few kilobits per second to hundreds of gigabits 1001 >> per second. By work, we mean we have hopes that it can come close to 1002 >> filling the link at high speeds, but scales gracefully to deal with 1003 >> low speeds. 1004 >> 1005 >> [The joy of IP is that it works over just about anything. That ease 1006 >> of adding new technologies must be maintained. I believe this range 1007 >> of speed is right for the next twenty years, though it may be we should 1008 >> say terabits at the high-end]. 1010 SIP is well suited to both fast and slow link speeds. Its small header 1011 size (24 bytes) makes it well suited to slow links, as is IPv4. Its 1012 fixed length headers, lack of a checksum and options fields, small 1013 structured addresses (8 bytes), and 64-bit field alignment should make 1014 it possible to achieve very high-speed forwarding rates. 1016 >> 5. The protocol must support an unreliable datagram delivery service. 1017 >> 1018 >> [We like IP's datagram service and it seems to work very well. So 1019 >> let's keep it. But clearly it matters less than being able to get 1020 >> the data from here to there, which points 1-4 cover]. 1022 SIP is a datagram protocol which evolved from IPv4. The basic service 1023 it provides is an unreliable datagram service. 1025 >> 6. The protocol must allow for both unicast and multicast addressing. 1026 >> 1027 >> [So far, we've done well with unicast and broadcast but broadcast 1028 >> scales far less well than multicast. We can fight about whether 1029 >> we should say "local" multicast, i.e. just on the local subnet here, 1030 >> and make wide-area multicast a lesser priority. Certainly the 1031 >> ability to send to more than one peer in a message has proved 1032 >> important. This is an enhancement to the datagram delivery service 1033 >> so it pre-supposes 5]. 1035 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 1037 SIP and IPAE supports both unicast and multicast. Addresses formats 1038 have been defined for both type of addresses. The extensions to the 1039 Internet Group Multicast Protocol (IGMP) to support the SIP addresses is 1040 straight forward and is limited to supporting the larger addresses. 1041 IPAE allows multicast groups to be formed between both IP and SIP hosts. 1043 >> 7. The protocol must support some means for cost recovery. 1044 >> 1045 >> NOTE: this doesn't say billing. Just that commercial providers need 1046 >> to be able to puzzle out some way to charge for services. Charging 1047 >> based on leased-line rates, etc., as we do today, is OK. 1048 >> 1049 >> [If we don't have the right services, billing for them isn't useful, 1050 >> so this goes below the previous 6 points]. 1052 IPAE and SIP support the current schemes used for IP. SIP does not have 1053 any defined features in this area that are not in IPv4. SIP allows 1054 extensions headers to be carried. It would be easy to design a new 1055 extension header which carries information which could be used to 1056 collect accounting information that could be used for cost recovery. 1058 >> 8. The protocol should support guaranteed flows. 1059 >> 1060 >> [Multimedia is on our desk top. The IETF multicast shows we can do 1061 >> it over internetworks, with some hitches. We must accept that multimedia 1062 >> is part of the networking future. If we better understood the problem, 1063 >> I'd put this about the starred line. Most folks believe that multicast 1064 >> delivery of flows is important, so it falls below multicast.] 1066 SIP includes a 28-bit field, currently marked as Reserved, which is 1067 intended to be later used as a flow identifier. The designers of SIP 1068 believe that when the research work on flows is completed, that this 1069 field could be redefined to carry a flow identifier. 1071 >> 9. The protocol should support mobile hosts. 1072 >> 1073 >> [Again, mobility is becoming increasingly important. Look at the portables 1074 >> that everyone is carrying. Note the strength of the Apple commercial 1075 >> showing someone automatically connecting up her Powerbook to her computer 1076 >> back in the office. I think conferencing and multimedia support from 1077 >> your regular office computer is more important than mobility, thus 1078 >> this falls after 8]. 1080 SIP is compatible with the current work in mobility. The current two 1081 main approaches to mobility (loose source route and encapsulation) are 1082 both very compatible with SIP. SIP's source routing mechanism (in an 1083 extension header) does not impose a performance reduction in 1084 intermediate routers. Due to the small size of the SIP headers it would 1085 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 1087 even be reasonable to encapsulate SIP in another SIP header. 1089 >> 10. The protocol should permit the use of security in the network. 1090 >> 1091 >> [This is not just for the military, but for banks, etc. And note 1092 >> all the folks who want to put security in for their local installations. 1093 >> Right now, I think the market values security slightly less than 1094 >> functionality, which is why it lands here]. 1096 The extension header capacity feature in SIP is very well suited to the 1097 definition of new security options. It eliminates the problems with the 1098 limited length of IPv4's current option lengths. 1100 >> 11. The protocol should permit easy and largely distribution 1101 >> configuration and operation. 1102 >> 1103 >> [People complain that IP is hard to manage. We cannot plug and play. 1104 >> It would be nice to fix that problem. But I think people care more 1105 >> about the previous 10 items] 1107 Currently SIP is no better or no worse in this area than IPv4. The 1108 authors of this proposal encourage continued work in this area in the 1109 Internet. This is an important area which needs additional work. 1111 >> 12. The protocol should permit policy routing. 1112 >> 1113 >> [I'm most concerned with policy routing in the form of choosing carriers. 1114 >> We'd like to do it, and it would benefit the commercial community. But 1115 >> in the scheme of things, making life easier for local installations is 1116 >> probably more important than making life easy for carriers.] 1118 SIP is compatible with the current approaches to policy routing in the 1119 internet. It can support source routes and provides for efficient 1120 encapsulation. 1122 4.0 REFERENCES 1124 [CROCKER92] Crocker, D., Hinden, R., Gilligan, R., "IP Address 1125 Encapsulation (IPAE): A Mechanism for Introducing a New 1126 IP", November 1992. 1128 [DEERING92a] Deering, S., "Simple Internet Protocol (SIP) 1129 Specification", November 1992. 1131 [DEERING92b] Deering, S., "Simple Internet Protocol (SIP) 1132 Addressing and Routing SIP Addressing and Routing", 1133 November 1992. 1135 INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 1137 [FULLER92] Fuller, V., Li, T., Yu, J., Varadhan, K., "RFC 1338 - 1138 "Supernetting: an Address Assignment and Aggregation 1139 Strategy", June 1992. 1141 [GROSS92] Gross, P., Almquist, P., "RFC-1380 - IESG 1142 Deliberations on Routing and Addressing", November, 1143 1992.