INTERNET-DRAFT Robert Hinden / Sun Microsystems November 11, 1992 Steve Deering / Xerox PARC Dave Crocker / The Branch Office IPv7 Criteria Analysis for IP Address Encapsulation (IPAE) and the Simple Internet Protocol (SIP) Abstract -------- This document describes how the IPv7 proposal called IP Address Encapsulation (IPAE) meets the evaluation criteria established by the Internet Engineering Steering Group and described in "RFC-1380 IESG Deliberations on Routing and Addressing". IPAE is currently developed to be a transition mechanism for a new IP protocol. This document focuses on the specific case of using IPAE to transition to the Simple IP Protocol (SIP). It addresses the criteria against both IPAE and SIP. This document also includes how IPAE meets the criteria described by Craig Partridge in a message titled "Criteria for selecting IPv7" sent to the Big-Internet mailing list on 22-October-1992. Status Of This Memo ------------------- Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. This Internet Draft expires at the end of March 1993. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Distribution of this memo is unlimited. Expires: April 11, 1993 [Page 1] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 Acknowledgements ---------------- This document is based on the work of the IP Address Encapsulation Working Group and the Simple IP Working of the Internet Engineering Task Force. Dave Crocker is the chair of IPAE working group and Steve Deering is the inventor of SIP and vice-chair of the SIP Working Group. Christian Huitema is the chair of the SIP working group. The authors would also like to thank Erik Nordmark, Geoff Mulligan, and Bob Gilligan for their help providing inputs and comments on this document. 1. INTRODUCTION IP Address Encapsulation (IPAE) [CROCKER92] was developed to be a transition mechanism for a new IP protocol. This document focuses on the specific case of using IPAE to transition to the Simple IP Protocol (SIP) [DEERING92a]. It addresses the criteria against both IPAE and SIP. This document describes how IPAE and SIP meet the evaluation criteria established by the Internet Engineering Steering Group and described in "RFC-1380 IESG Deliberations on Routing and Addressing" [GROSS92]. This document also includes how IPAE and SIP meet the criteria described by Craig Partridge in a message titled "Criteria for selecting IPv7" sent to the Big- Internet mailing list on 22-October-1992. The following definitions apply to the remainder of the document. An IPv4 host implements only IPv4. An IPAE host implements IPv4, SIP, and SIP encapsulated in IPv4. A SIP host only implements SIP. 2. IESG EVALUATION CRITERIA This section describes how IPAE and SIP meet the IESG criteria. The IESG criteria are delineated by ">>". 2.1 DESCRIPTION OF THE PROPOSED SCHEME >> B.1 Description of the Proposed Scheme >> >> A complete description of the proposed routing and addressing >> architecture should be supplied. This should be at the level of >> detail where the functionality and complexity of the scheme can be >> clearly understood. It should describe how the proposal solves the Expires: April 11, 1993 [Page 2] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 >> basic problems of IP address exhaustion and router resource overload. IPAE and SIP are described in detail in the following documents currently being published as Internet Drafts: IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP [CROCKER92] Simple Internet Protocol (SIP) Specification [DEERING92a] Simple Internet Protocol (SIP) Addressing and Routing [DEERING92b] In summary the IPAE proposal uses IP encapsulation and translation between IPv4 and SIP to transition to a new IP protocol, namely SIP. It can be first deployed in existing border routers to solve the current routing explosion problems and later deployed in hosts to solve the IP network address exhaustion problem. The final step is to run pure SIP in all network devices that desire global communication. 2.2 CHANGES REQUIRED The IPAE proposal introduces two new packet formats at the Internet layer. These header formats are referred to as SIP and IPAE. SIP is a new Internet Protocol header carrying larger addresses and with streamlined functionality. IPAE is the SIP header format encapsulated within an IPv4 header. We call the larger Internet addresses carried in the SIP header a "SIP address." We refer to the traditional 4-byte addresses simply as IP addresses. The IPAE proposal includes several transition steps. These steps in time-order are: 1) Border routers are modified to add support for the IPAE and SIP packet formats in addition to IPv4. 2) Hosts that need global communication are modified to add support for the IPAE and SIP packet formats in addition to IPv4. 3) The remaining routers are modified to add support for the IPAE and SIP packet formats in addition to IPv4. This step is optional. 4) Hosts and routers operating within sites that contain no IPv4-only hosts or routers may be modified to remove support for Expires: April 11, 1993 [Page 3] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 the IPv4 and IPAE packet formats. This step is optional. The response is divided into separate sections for each of these transition steps. >> B.2 Changes Required >> >> All changes to existing protocols should be documented and new >> protocols which need to be developed and/or deployed should be >> specified and described. This should enumerate all protocols which >> are not currently in widespread operational deployment in the >> Internet. The only new protocol required to be implemented is IPAE (SIP over IP). Overall the following protocols will be required to change to implement IPAE and SIP: Modifications to ICMP Modifications to Internet Group Multicast Protocol (IGMP) Modifications to BGP4 to support SIP addresses Modifications to selected IGP's to support SIP addresses Modifications to TCP and UDP pseudo-header checksum calculation Modifications to any protocol or application above IP that uses or handles IP addresses to support the larger SIP addresses. DNS extended to support SIP addresses and IP Address->SIP Address mapping SNMP MIBs modified to support SIP addresses. The detail of when each change is required is described in the following sections. >> Changes should also be grouped by the devices and/or functions they >> affect. This should include at least the following: >> >> - Protocol changes in hosts >> - Protocol changes in exterior router >> - Protocol changes in interior router >> - Security and Authentication Changes >> - Domain name system changes >> - Network management changes >> - Changes required to operations tools (e.g., ping, trace- Expires: April 11, 1993 [Page 4] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 >> route, etc) >> - Changes to operational and administration procedures 1) Add IPAE and SIP to Border Routers (Short Term) No changes to Hosts required. Selected border (exterior) routers support three packet formats: IPv4, IPAE, and SIP. These routers also implement modified ICMP, and modified BGP4. Mapping tables implemented to translate IP addresses into SIP addresses to simplify routing. Remaining exterior routers unchanged. No changes to interior routers. No changes to Security and Authentication. No changes to DNS. Network management support for MIBs in Border Routers for IPAE, modified ICMP, and modified BGP4. Extensions to existing operational tools (e.g. Ping, Traceroute) to support larger addresses needed for Border router operation. Existing IP tools continue to function. Existing IP operational and administrative procedures continue to function. New procedures needed for operation of border routers. 2) Add IPAE and SIP Support to Hosts Needing Global Communication (Medium Term) Hosts support three packet formats: IPv4, IPAE, SIP. These hosts also support modified ICMP, IGMP, TCP, UDP, and applications. No change in border routers from previous stage. Remaining exterior routers unchanged. No change to interior routers. Security and Authentication procedures extended to work with SIP addresses. A new resource record type is added to the DNS to store SIP host addresses. The existing "A" record type is unchanged. Hosts that Expires: April 11, 1993 [Page 5] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 support IPv4/IPAE/SIP are given both resource records. Hosts that support only IPv4 may continue to have only A records. However performance improves if IPv4-only hosts are given both records. IP address -> SIP Address mapping also added. Network management support for MIBs in Hosts. No additional tool changes for this step. Existing IP operational and administrative procedures continue to function. New procedures needed for operation of IPAE hosts. 3) Add IPAE and SIP Support to All Routers (Long Term & Optional) The remaining routers (interior and exterior) implement three packet formats: IPv4, IPAE, and SIP. These routers also implement modified ICMP and router discovery protocols. No changes to Hosts in this step. No change in border router from previous stages. Remaining exterior routers implement IPv4/IPAE/SIP, modified ICMP, and modified BGP4. Interior routers implement SIP and modified IGP's. No Security and Authentication changes in this step. No changes to DNS in this step. Network management support for MIBs in routers. No additional tool changes for this step. Existing IP operational and administrative procedures continue to function. New procedures needed for operation of IPv4/IPAE/SIP routers. 4) Remove IPv4 and IPAE support from hosts and routers. Hosts and routers running in sites having no hosts or routers understanding only IPv4 do not have to support IPv4 and IPAE packet formats. This step is optional. It should not be implemented in sites that still have IPv4-only hosts or routers. >> The changes should also include if hosts and routers have their Expires: April 11, 1993 [Page 6] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 >> current IP addresses changed. All existing IP devices are not required to change their IP addresses. >> The impact and changes to the existing set of TCP/IP protocols should >> be described. This should include at a minimum: >> >> - IP No change. >> - ICMP New SIP redirect defined and addition of a pseudo-header checksum to ICMP checksum calculation when communicating between SIP hosts. >> - DNS A new resource record type is added to the DNS to store SIP host addresses. The existing "A" record type is unchanged. Hosts that support IPv4/IPAE/SIP are given both resource records. Hosts that support only IPv4 may continue to have only A records. However performance improves if IPv4-only hosts are given both records. IP address -> SIP Address mapping also added. >> - ARP/RARP No changes. >> - TCP No change except for pseudo checksum calculation. Connections between hosts that support IPv4/IPAE/SIP and hosts that support only IPv4 use low order 32-bits of address for pseudo checksum calculation. Connections between hosts that support IPv4/IPAE/SIP will automatically use the IPAE or SIP packet format and will use the SIP addresses for pseudo checksum calculation. TCP modified to handler longer SIP addresses for matching incoming packets to the appropriate connection state. >> - UDP Same as for TCP. >> - FTP Modified to use SIP addresses. Expires: April 11, 1993 [Page 7] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 >> - RPC Modified to use SIP addresses. >> - SNMP Changes to existing MIBs that carry IP addresses. >> The impact on protocols which use IP addresses as data should be >> specifically addressed. These will need to be modified to carry SIP addresses. Note that the text representation of SIP addresses enables them to be distinguished from both IP addresses and domain names. This should simplify the addition of SIP address capability to existing user interfaces, e.g., wherever the text form of an IP address currently appears. 2.3 IMPLEMENTATION EXPERIENCE >> B.3 Implementation Experience >> >> A description of implementation experience with the proposal should be >> supplied. This should include the how much of the proposal was >> implemented and hard it was to implement. If it was implemented by >> modifying existing code, the extent of the modifications should be >> described. Implementations are underway at Sun Microsystems, Silicon Graphics, Proteon, and Digital Equipment Corporation. The implementation at Sun has focused on the transport and internet layers using modified telnet and ping programs that handle bigger addresses. The core of this implementation is a combined internet layer that handles IP, SIP and IPAE packet formats. The implementation can act as a IP/SIP/IPAE host, an IP router, a SIP/IPAE router, as well as a border router. Most of the host, router and border router functionality has been implemented and tested. IP hosts have communicated with IPAE hosts both directly and using an IPAE (encapsulating/decapsulating) border router. IPAE hosts have communicated with IPAE hosts on the same subnet (using SIP without any encapsulating IPv4 header), through IP routers and through border/IPAE routers. Complex details like path MTU discovery work in the presence of encapsulating border routers. Expires: April 11, 1993 [Page 8] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 The changes to the transport protocols were quite simple. In addition to the necessary modifications to TCP and UDP to handle bigger addresses there were only some minor modifications to the pseudo-header checksum calculation logic, the connection identification logic, and adding the interpretation of all the possible ICMP error packet formats. The modifications to the internet layer consists of changes to the routing table and extensions to handle the different packet formats. The routing table was modified to handle bigger addresses in such a way that the same table can be used for IP routing, SIP routing and IP->SIP address mappings. The changes to handle the IP, IPAE, and SIP header formats were fairly simple, especially since the choice of header format to use when transmitting was driven from the routing table. In addition ICMP was modified to conditionally use the SIP pseudo-header checksum and to include SIP headers in the ICMP error packets. In summary, the following code is working to date: - Host sending/receiving IPv4/SIP/IPAE datagrams including SIP fragmentation (SIP fragmentation code was taken directly form the IP fragmentation/reassembly code) - Router forwarding all of the above - Border router translating between IP and SIP (both directions) including modifying ICMP checksum and mapping IP fragments to SIP fragments and vice versa - Host and router generating and host consuming ICMP error messages that contain IPv4 or SIP header in the "original datagram" part - The host can also handle ICMP error messages from IP routers (where the "original datagram" contains both IP and SIP headers) - Border router mapping IPv4/ICMP error packets received from IP routers to SIP/ICMP error packet and sending them back to the "SIP" source. (includes adjusting the mtu in ICMP "packet too big" to take into account the encapsulation header) Future modifications include adding support for the new ICMP redirect message. The DEC implementation is currently focusing on IPAE and SIP host functionality. The code is currently being debugged. A TCP dump program has also been modified to decode SIP and IPAE datagrams. Expires: April 11, 1993 [Page 9] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 SGI is currently working on a SIP/IPAE decoding module for their network traffic analysis package called NetVisualizer. 2.4 LARGE INTERNET SUPPORT >> B.4 >> >> The proposal should describe how it will scale to support a large >> internet of 10^^9 networks. It should describe how the proposed >> routing and addressing architecture will work to support an internet >> of this size. This should include, as appropriate, a description of >> the routing hierarchy, how the routing and addressing will be >> organized, how different layers of the routing interact (e.g., >> interior and exterior, or L1, L2, L3, etc), and relationship between >> addressing and routing. >> >> The addressing proposed should include a description of how addresses >> will be assigned, who owns the addresses (e.g. user or service >> provider), and whether there are restrictions in address assignment or >> topology. SIP address are 64 bits long. For purposes of scalable routing, they are divided into variable-length subfields, with the field boundaries being identified by 64-bit masks that are carried in routing updates and stored in routing tables, as with CIDR [FULLER92]. The variable-length subfields allow considerable flexibility in assigning a hierarchical structure to the SIP addresses. The SIP Addressing and Routing document [DEERING92b] proposes two general structures for unicast addresses, one based on a service-provider hierarchy and one based on a geographic hierarchy. Both hierarchies can be accommodated in the same 64-bit space. For analyzing the scalability of the geographic ("metro-based") addresses, assume the following address layout. (This is not the only possible layout. In particular, it is not necessary to define fixed boundaries as illustrated; more efficient use could be made of the address space by allowing the boundaries to vary for different countries and for different sites.) |1| 15 | 32 | 16 | +-+------+--------+--------+--------+--------+--------+--------+--------+ |C| country + | site ID | intra-site | | | metro ID | | part | +-+------+--------+--------+--------+--------+--------+--------+--------+ The 15-bit country + metro ID field is internally structured into two parts, one identifying the country and one identifying the metropolitan Expires: April 11, 1993 [Page 10] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 area in which a site is connected to the public Internet. By using a variable-length encoding, whereby large countries are assigned more metro IDs than small countries, less than 3/8ths of that 15-bit address space is required to cover all of the metropolitan areas in the world (based on a United Nations projection for national populations in the year 2025, and a generous estimate of one metro area for every one million people; see [DEERING92b] for details). Within each metro, there are 32 bits of address space available to identify individual customer sites. Those 32 bits may be internally structured (e.g., divided into sub-regions of the metro area or divided among service providers operating in the metro area), or treated as a flat field used as a key to a database lookup, for mapping site ID to topological location. In either case, it is sufficient to address hundreds of millions of sites, enough to support the attachment of every office and household in the metro area. Each site gets 16 bits of address space (65,536 address) to identify internal subnets and hosts. This is equivalent to assigning an IP Class B network number to every house, apartment, and office. Those few sites, that might require a larger address space, such as large campuses, may obtain multiple, contiguous site IDs. Thus, SIP metro-based addresses can be seen to scale to at least 10^12 customer sites (10^4 metro areas times 10^8 sites per metro), and 10^16 hosts (assuming 10^4 hosts per site). Furthermore, it is possible to route to that many destinations without burdening any router with a routing table larger than 10^4 entries. A similar analysis for a provider-based address hierarchy is more difficult, because it has hard to predict how many providers must be accommodated and how many subscribers they each are likely to have. It is probable that there will be many small providers with relatively small numbers of subscribers, and a small number of large providers with very many subscribers. The use of masks and variable-length subfields in SIP allows the address space to be used efficiently in such cases, i.e., it is not necessary to give every provider enough address space to handle the subscriber base of the largest provider. For a rough estimate of the scalability of SIP provider-based addresses, consider the following address layout: |1| 15 | 16 | 16 | 16 | +-+------+--------+--------+--------+--------+--------+--------+--------+ |C| country + | subscriber ID |intra-subscriber | | | provider ID | | | part | +-+------+--------+--------+--------+--------+--------+--------+--------+ Expires: April 11, 1993 [Page 11] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 More than half of the initial 15-bit field, i.e., more than 30,000 values, is available for identifying providers, after the assignment of metro IDs and the multicast prefix is taken into account. If there turn out to be more providers than that in the world, it is highly likely that many of them will operate within the confines of a single metro area or a few metro areas, in which case they can be given identifying prefixes from the metro-based address space. The remaining 48 bits of the address are structured for the convenience of the individual provider and its subscribers. Assume a very simple, fixed hierarchy consisting of three 16-bit subfields, the first two used by the provider to reach an individual subscriber, and the last one used within the subscribers facilities (again, equivalent to an IP Class B address per subscriber, recognizing that a subscriber with a large internal internet may obtain a bigger piece of address space from the provider). If the provider's routers can support up to 10,000 entries at each level of its two-level hierarchy, then that provider can support up to 100,000,000 subscribers, and the scaling limit for provider-based addresses is roughly the same as for metro-based addresses: 10^12 subscribers (10^4 providers times 10^8 subscribers per provider), and 10^16 hosts (assuming 10^4 hosts per site). Note that the encoding of IPv4 addresses within SIP addresses (C-bit = 1) can conform to either the metro-based hierarchy or the provider-based hierarchy. The "intra-site" or "intra-subscriber" part of such SIP addresses consists of those bits of the IP address following the IP "network number", and therefore may range between 8 bits (for a Class C network) and 24 bits (for a Class A network). Routing of SIP packets is performed in the same way, and using the same routing protocols, as contemporary IPv4 or CLNP, modified as necessary to handle 64-bit addresses and masks. The approach is the same as that proposed for CLNP/TUBA, using a variety of routing protocols (e.g., OSPF, BGP, IDRP), composed hierarchically according to the addressing hierarchy. (Metro-based routing is a somewhat more complicated than that; see [DEERING92b] for details.) Regarding assignment and ownership of SIP addresses: global authority, such as ISOC: - assigns blocks of metro IDs to national authorities. - assigns blocks of provider IDs to national authorities. - assigns well-known multicast addresses. national authority, such as national chapter of ISOC: - assigns individual metro IDs to metropolitan areas. Expires: April 11, 1993 [Page 12] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 - assigns individual provider IDs to providers. - assigns individual site IDs to sites, and maintains site ID registry; may assign blocks of site IDs to providers for subsequent assignment to their subscribers, under condition that, once assigned, a site ID becomes bound to the site, regardless of provider, and is registered in the national registry. provider: - assigns individual subscriber IDs to subscribers, structured for the convenience of the provider. - may assign individual site IDs to subscriber sites, if so delegated by the national authority. site/subscriber: - assigns intra-site or intra-subscriber part, i.e., subnet IDs and interface IDs. - annually confirms continued use of site ID(s) with the national authority; lack of such confirmation frees the site ID for re-use by another site after one more year passes. 2.5 SYNTAX AND SEMANTICS OF NAMES, IDENTIFIERS AND ADDRESSES >> B.5 Syntax and semantics of names, identifiers and addresses >> >> Proposals should address the manner in which data sources and >> sinks are identified and addressed, describe how current domain >> names and IP addresses would be used/translated/mapped in their >> scheme, how proposed new identifier and address fields and >> semantics are used, and should describe the issues involved in >> administration of these id and address spaces according to their >> proposal. The deployment plan should address how these new >> semantics would be introduced and backward compatibility >> maintained. >> >> Any overlays in the syntax of these protocol structures should be >> clearly identified and conflicts resulting from syntactic overlay >> of functionality should be clearly addressed in the discussion of >> the impact on administrative assignment. Data sources and sinks are identified by their Domain Names and their SIP addresses. The Domain Names are identical to those currently used. The SIP addresses are an extension to current IP addresses, with 32-bits of global address information pre-pended to the existing 32-bit addresses. The new bits are organized into an administrative hierarchy, permitting both geographic-based and provider-based addressing. The full scheme is: Expires: April 11, 1993 [Page 13] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 Country Provider/Metropolitan Subscriber/Site IP Address In reality, the high-order 32 bits extend the IP Network address field, so that sites will have their Subnetwork and Host IP address fields held constant, but will have IP Network address assigned by their provider or Metropolitan Internet eXchange. While IP addresses continue to be globally administered, however, the two sets of 32-bits will be assigned independently. Support for SIP addresses by the Domain Name service requires new resource records and a new in-addr table. Because each SIP address is an extension to an IP address, Domain Name Service servers do not need to maintain separate, internal data bases. Instead they can treat IP and SIP accesses as different views onto the same data base. Mapping between SIP and IP addresses is straightforward, since SIP addresses are an extension to IP addresses. As long as IP addresses remain unique, then simple removal of the top 32 bits is needed to convert from SIP to IP. To map from IP to SIP will require a translation table, possibly maintained through the Domain Name Service. Addresses can be administered by the same system currently in place for administering IP addresses. Country references will use the CCITT E.163 Detailed Country Code (DCC) scheme, with metropolitan numeric references that derive from the DCC authorities. Administrations which wish to support SIP and/or IPAE will obtain their SIP network address from the appropriate authority. These references can be used in parallel with continued use of IP addresses. IPAE is specifically designed to support a wide range of backward- compatibility requirements. The SIP address has been tailored to support this. In addition to the straightforward benefits of using a SIP address that is a simple extension to an IP address, the SIP address format contain a bit (called the Compatibility bit) which indicates whether the referenced node is using IP or IPAE/SIP. Hence a site does not need to consult special tables, or otherwise maintain any state information about a node, other than to have a copy of their address. Further, SIP specifies tailoring the transport-level pseudo-header checksum to use only the lower 32-bits of the SIP address, if the remote site is an IP site. This means that a gateway providing translation between IP and IPAE/SIP works only with the internetwork-sublayer headers and does not need to touch any transport-level information. The IPAE spec provides for IP-SIP, IP/IPAE, IPAE/IPAE, and IPAE/SIP interactions, either directly or through use of translating gateways. This range of options permits hosts and routers to make independent decisions to support IPAE and SIP and to be able to communicate with Expires: April 11, 1993 [Page 14] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 other IPAE and SIP nodes as soon as they, too, add support. 2.6 PERFORMANCE IMPACT >> B.6 Performance Impact >> >> The performance impact of the new routing and addressing architecture >> should be evaluated. It should be compared against the current state >> of the art with the current IP. The performance evaluation for >> routers and hosts should include packets-per-second and memory usage >> projections, and bandwidth usage for networks. Performance should be >> evaluated for both high speed speed and low speed lines. >> >> Performance for routers (table size and computational load) and >> network bandwidth consumption should be projected based on the >> following projected data points: >> >> -Domains 10^^3 10^^4 10^^5 10^^6 10^^7 10^^8 >> -Networks 10^^4 10^^5 10^^6 10^^7 10^^8 10^^9 >> -Hosts 10^^6 10^^7 10^^8 10^^9 10^^10 10^^11 Forwarding performance of IPAE and SIP should be equal or better than current IPv4. For IPAE, there is the non-negligible bandwidth cost of carrying the extra header (4% of 576-byte packet), plus the CPU overhead of encapsulating and decapsulating SIP in IP. SIP has a number of features which should give similar or even superior performance to IPv4. These include: Small Header (24 bytes vs. 20 for IPv4) No checksum 64-bit alignment of addresses No options in header 64-bit addresses These features should offset the following disadvantages: 24 byte header instead of 20 byte implies a very small increase in bandwidth overhead (0.7% for 576-byte packets; less for larger packets). Expires: April 11, 1993 [Page 15] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 Longer addresses may increase route lookup time (how much, depends on lookup algorithm -- radix tree vs. hash) on current-generation processors; will become insignificant, and maybe even beneficial, on future, 64-bit processors. For loose-source-routed packets, SIP should have significant performance advantage over IP, since intermediate routers need not examine the source route. Memory usage should grow far less than linearly. Space allocated for IP addresses will double. Bandwidth usage will be very similar to IPv4. The SIP header is only four bytes longer than IPv4. SIP will work very well on both high speed and low speed lines. Additional header compression schemes will provide very good results because only the TTL field in SIP changes, there is no checksum and no Identifier. 2.7 SUPPORT FOR TCP/IP HOSTS THAN DO NOT SUPPORT THE NEW ARCHITECTURE >> B.7 Support for TCP/IP hosts than do not support the new architecture >> >> The proposal should describe how hosts which do not support the new >> architecture will be supported -- whether they receive full services >> and can communicate with the whole Internet, or if they will receive >> limited services. Also, describe if a translation service be provided >> between old and new hosts? If so, where will be this be done. For the transition period when IPv4 addresses are still globally unique (i.e. before the Internet runs out of IP network addresses) IPAE provides direct communication between IPv4, IPAE, and pure SIP hosts. All hosts will be able to communicate to all other hosts regardless of which protocol they implement. Translation service will be done in border routers. Similarity between SIP and IP makes translation straightforward. After IP network addresses have run out, IPAE will permit IPv4 hosts to communicate with SIP hosts with in a site. Translation can also be done between SIP hosts and IPv4 hosts in the same site by interior routers. IPAE is designed to provide convenient interoperation between IP-IP, SIP-IP, IP-SIP, IP-IPAE, and SIP-IPAE. This permits participants to make conversions as convenient, rather than according to a imposed schedule with "flag" days. Further, the burden of supporting "dual stack" operation is essentially eliminated. Translation gateways will Expires: April 11, 1993 [Page 16] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 not need to maintain tables that specify which hosts have converted and which hosts have not. 2.8 EFFECT ON USER COMMUNITY >> B.8 Effect on User Community >> >> The large and growing installed base of IP systems comprises people, >> as well as software and machines. The proposal should describe >> changes in understanding and procedures that are used by the people >> involved in internetworking. This should include new and/or changes >> in concepts, terminology, and organization. The effect on the user community should be very small. All of the concepts and most of the terminology, formats, and software in IPAE and SIP are based on existing IP concepts. SIP is in every regard a new version of IP. No new concepts or terminology are introduced. Anyone who understands how IPv4 works and operates, can understand the details of SIP in a very short amount of time since it is only a modification to current IP. The amount of training required to existing personnel should be very small. 2.9 DEPLOYMENT PLAN DESCRIPTION >> B.9 Deployment Plan Description >> >> The proposal should include a deployment plan. It should include the >> steps required to deploy it. Each step should include the devices and >> protocols which are required to change and what benefits are derived >> at each step. This should also include at each step if hosts and >> routers are required to run the current and proposed internet >> protocol. >> >> A schedule should be included, with justification showing that the >> schedule is realistic. The protocol and device changes required for each step are described in section 2.2 of this document. In summary the basic steps in the transition plan are: 1) Deploy IPAE in Border Routers 2) Deploy IPAE in hosts needing global communication 3) Deploy SIP in all routers Expires: April 11, 1993 [Page 17] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 A proposed schedule for this transition plan is as follows: 1. IETF Adopts IPAE Plan Jan 93 2. Complete specifications and protocol changes Jul 93 3. Deploy IPAE in Border Routers and Jan 94 Implement DNS Changes 4. Start IPAE Deployment in Hosts Jan 94 5. Complete IPAE Deployment in Hosts Jan 98 6. Deploy SIP in Routers and Hosts (not required) The time to complete the specifications (step 2) should be easy to accomplish in 6 months. The work to date has been done by a small group of people in about 6 months. IPAE could be deployed in the initial set of border routers (NSFNET) six months later. Current experience with implementing the protocol shows it to be easy to implement. Assuming that code was developed while the specifications were being finalized, it should be feasible to turn on IPAE in border routers in Jan 94. This deployment would provide immediate relief to the backbone the routing explosion problems. IPAE in hosts can start to be deployed as soon as the border routers are running IPAE. In fact, hosts can deploy IPAE before the border routers implement IPAE as long as the DNS mappings are installed. Step 5 needs to be done before the IPv4 addresses run out. Our current estimate of this is about five years from now. It is reasonable to expect that the majority of hosts in the Internet could implement and deploy IPAE within five years. There is no firm date requirement to complete the deployment of SIP in all routers. It can be done on a local site-by-site basis. There is no requirement to tie this to an overall internet transition plan. 2.10 SECURITY IMPACT >> B.10 Security Impact >> >> The impact on current and future security plans should be >> addressed. Specifically do current security mechanisms such as >> address and protocol port filtering work in the same manner as >> they do today, and what is the effect on security and >> authentication schemes currently under development. Existing security mechanisms can be extended to work with SIP addresses and would work in the manner essentially the same as they do today. Also the SIP mechanism for extension headers allows security options to Expires: April 11, 1993 [Page 18] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 be defined which would not fit in the options space of IPv4. 2.11 FUTURE EVOLUTION >> B.11 Future Evolution >> >> The proposal should describe how it lays a foundation for solving >> emerging internet problems such as security/authentication, mobility, >> resource allocation, accounting, high packet rates, etc. SIP is a fully functional replacement for IPv4, with a number of improvements, particularly in the areas of scalability of routing and addressing, and of performance. SIP would serve as an excellent base for solving the emerging Internet problems indicated above. For example: ARP may be modified to carry full 64-bit addresses, and to use link-layer multicast addresses, rather than broadcast addresses. The 28-bit Reserved field in the SIP header may be defined as a "Flow ID", or partitioned into a Type of Service field and a Flow ID field, for classifying packets deserving special handling, e.g., non-default quality of service or real-time service. On the other hand, the transport-layer port fields may be adequate for performing any such classification. (One possibility would be simply to remove the port fields from TCP & UDP and append them to the SIP header, as in XNS.) A new ICMP "destination has moved" message may be defined, for re- routing to mobile hosts or subnets, and to domains that have changed their address prefixes. An explicit Trace Route message or option may be defined; the current IPv4 traceroute scheme will work fine with SIP, but it does not work for multicast, for which it has become very apparent that management and debugging tools are needed. A new Host-to-Router protocol may be specified, encompassing the requirements of router discovery, black-hole detection, auto- configuration of subnet prefixes, "beaconing" for mobile hosts, and, possibly, address resolution. The OSI End System To Intermediate System Protocol may serve as a good model for such a protocol. The requirement that SIP addresses be strictly bound to interfaces may be relaxed, so that, for example, a system might have fewer addresses than interfaces. There is some experience with this Expires: April 11, 1993 [Page 19] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 approach in the current Internet, with the use of "unnumbered links" in routing protocols such as OSPF. Authentication and integrity-assurance mechanisms for all clients of SIP, including ICMP and IGMP, may be specified, possibly based on the Secure Data Network System (SDNS) SP-3 or SP-4 protocol. 3. CRAIG PARTRIDGE CRITERIA >> 1. The protocol must allow a straightforward transition plan from >> the current IPv4. >> >> [If we can't transition to the new protocol, then no matter how wonderful >> it is, we'll never get to it.] IPAE provides a straightforward flexible transition plan. It is first deployed in (~100) selected border routers. This provides an immediate and permanent solution to the IP Routing explosion problems. The next step is to deploy IPAE in hosts. This step does not have to be completed until the Internet approaches the time when IP Network addresses are close to running out. This should provide enough time to convert the majority of hosts in the internet. During this transition period (~5 year) border routers will provide translation services between IP only and IPAE hosts. Direct communication is only provided between IPAE and IP hosts only during the transition between sites globally, and after IP address are no longer globally unique, inside of a site. The last step of the transition, converting all routers to SIP is independent of the Internet addressing and routing problems, and can be done at the convenience of individual sites and service providers. >> 2. The protocol must scale to allow the addressing of billions of >> end-systems. >> >> [If we cannot address all hosts in some fashion, presumably we cannot >> connect them all to the network, and we cannot hope to route data to >> them.] This topic was discussed in detail in section 2.4 "LARGE INTERNET SUPPORT". >> 3. The protocol must permit the use of routing schemes which allow >> routing tables to grow at a rate much less than linearly with the >> number of constituent networks. >> >> [If we can't route then connecting all those hosts is worthless, but >> without connected hosts, there's no point in routing. Thus this is >> third.] >> Expires: April 11, 1993 [Page 20] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 >> (As a rough sanity check for any scheme, assume that an inexpensive >> router [costing $5K 1992 USD] in the year 2000 will have around 1 gigabyte >> of router table memory and at that time there will be about 2 million >> networks and 75 million end-systems). As mentioned under the previous addressing discussion, the SIP addressing hierarchy can keep the number of routes handled by any one router down to 10^4, which is within the capacity of current-generation routers, let alone future ones. Flat addressing to millions of sites within a metro area could benefit from large, cheap memories, but they are not essential (could use disk storage and RAM-based caches instead). >> 4. The protocol must work across an internetwork with individual link >> speeds ranging from a few kilobits per second to hundreds of gigabits >> per second. By work, we mean we have hopes that it can come close to >> filling the link at high speeds, but scales gracefully to deal with >> low speeds. >> >> [The joy of IP is that it works over just about anything. That ease >> of adding new technologies must be maintained. I believe this range >> of speed is right for the next twenty years, though it may be we should >> say terabits at the high-end]. SIP is well suited to both fast and slow link speeds. Its small header size (24 bytes) makes it well suited to slow links, as is IPv4. Its fixed length headers, lack of a checksum and options fields, small structured addresses (8 bytes), and 64-bit field alignment should make it possible to achieve very high-speed forwarding rates. >> 5. The protocol must support an unreliable datagram delivery service. >> >> [We like IP's datagram service and it seems to work very well. So >> let's keep it. But clearly it matters less than being able to get >> the data from here to there, which points 1-4 cover]. SIP is a datagram protocol which evolved from IPv4. The basic service it provides is an unreliable datagram service. >> 6. The protocol must allow for both unicast and multicast addressing. >> >> [So far, we've done well with unicast and broadcast but broadcast >> scales far less well than multicast. We can fight about whether >> we should say "local" multicast, i.e. just on the local subnet here, >> and make wide-area multicast a lesser priority. Certainly the >> ability to send to more than one peer in a message has proved >> important. This is an enhancement to the datagram delivery service >> so it pre-supposes 5]. Expires: April 11, 1993 [Page 21] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 SIP and IPAE supports both unicast and multicast. Addresses formats have been defined for both type of addresses. The extensions to the Internet Group Multicast Protocol (IGMP) to support the SIP addresses is straight forward and is limited to supporting the larger addresses. IPAE allows multicast groups to be formed between both IP and SIP hosts. >> 7. The protocol must support some means for cost recovery. >> >> NOTE: this doesn't say billing. Just that commercial providers need >> to be able to puzzle out some way to charge for services. Charging >> based on leased-line rates, etc., as we do today, is OK. >> >> [If we don't have the right services, billing for them isn't useful, >> so this goes below the previous 6 points]. IPAE and SIP support the current schemes used for IP. SIP does not have any defined features in this area that are not in IPv4. SIP allows extensions headers to be carried. It would be easy to design a new extension header which carries information which could be used to collect accounting information that could be used for cost recovery. >> 8. The protocol should support guaranteed flows. >> >> [Multimedia is on our desk top. The IETF multicast shows we can do >> it over internetworks, with some hitches. We must accept that multimedia >> is part of the networking future. If we better understood the problem, >> I'd put this about the starred line. Most folks believe that multicast >> delivery of flows is important, so it falls below multicast.] SIP includes a 28-bit field, currently marked as Reserved, which is intended to be later used as a flow identifier. The designers of SIP believe that when the research work on flows is completed, that this field could be redefined to carry a flow identifier. >> 9. The protocol should support mobile hosts. >> >> [Again, mobility is becoming increasingly important. Look at the portables >> that everyone is carrying. Note the strength of the Apple commercial >> showing someone automatically connecting up her Powerbook to her computer >> back in the office. I think conferencing and multimedia support from >> your regular office computer is more important than mobility, thus >> this falls after 8]. SIP is compatible with the current work in mobility. The current two main approaches to mobility (loose source route and encapsulation) are both very compatible with SIP. SIP's source routing mechanism (in an extension header) does not impose a performance reduction in intermediate routers. Due to the small size of the SIP headers it would Expires: April 11, 1993 [Page 22] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 even be reasonable to encapsulate SIP in another SIP header. >> 10. The protocol should permit the use of security in the network. >> >> [This is not just for the military, but for banks, etc. And note >> all the folks who want to put security in for their local installations. >> Right now, I think the market values security slightly less than >> functionality, which is why it lands here]. The extension header capacity feature in SIP is very well suited to the definition of new security options. It eliminates the problems with the limited length of IPv4's current option lengths. >> 11. The protocol should permit easy and largely distribution >> configuration and operation. >> >> [People complain that IP is hard to manage. We cannot plug and play. >> It would be nice to fix that problem. But I think people care more >> about the previous 10 items] Currently SIP is no better or no worse in this area than IPv4. The authors of this proposal encourage continued work in this area in the Internet. This is an important area which needs additional work. >> 12. The protocol should permit policy routing. >> >> [I'm most concerned with policy routing in the form of choosing carriers. >> We'd like to do it, and it would benefit the commercial community. But >> in the scheme of things, making life easier for local installations is >> probably more important than making life easy for carriers.] SIP is compatible with the current approaches to policy routing in the internet. It can support source routes and provides for efficient encapsulation. 4.0 REFERENCES [CROCKER92] Crocker, D., Hinden, R., Gilligan, R., "IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP", November 1992. [DEERING92a] Deering, S., "Simple Internet Protocol (SIP) Specification", November 1992. [DEERING92b] Deering, S., "Simple Internet Protocol (SIP) Addressing and Routing SIP Addressing and Routing", November 1992. Expires: April 11, 1993 [Page 23] INTERNET DRAFT IPv7 Criteria Analysis for IPAE and SIP 11-Nov-92 [FULLER92] Fuller, V., Li, T., Yu, J., Varadhan, K., "RFC 1338 - "Supernetting: an Address Assignment and Aggregation Strategy", June 1992. [GROSS92] Gross, P., Almquist, P., "RFC-1380 - IESG Deliberations on Routing and Addressing", November, 1992. Expires: April 11, 1993 FORMFEED[Page 24]