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]
