RFC1752 - The Recommendation for the IP Next Generation Protocol

Network Working Group S. Bradner
Request for Comments: 1752 Harvard University
Category: Standards Track A. Mankin
ISI
January 1995
The Recommendation for the IP Next Generation Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document presents the recommendation of the IPng Area Directors
on what should be used to replace the current version of the Internet
Protocol. This recommendation was accepted by the Internet
Engineering Steering Group (IESG).
Table of Contents
1. Summary. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . . 4
3. A Direction for IPng . . . . . . . . . . . . . . . . . . 5
4. IPng Area. . . . . . . . . . . . . . . . . . . . . . . . 6
5. ALE Working Group. . . . . . . . . . . . . . . . . . . . 6
5.1 ALE Projections. . . . . . . . . . . . . . . . . . . . . 7
5.2 Routing Table Size . . . . . . . . . . . . . . . . . . . 7
5.3 Address Assignment Policy Recommendations. . . . . . . . 8
6. IPng Technical Requirements. . . . . . . . . . . . . . . 8
6.1 The IPng Technical Criteria document . . . . . . . . . . 9
7. IPng Proposals . . . . . . . . . . . . . . . . . . . . . 11
7.1 CATNIP. . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 SIPP. . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 TUBA. . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. IPng Proposal Reviews. . . . . . . . . . . . . . . . . . 13
8.1 CATNIP Reviews . . . . . . . . . . . . . . . . . . . . . 14
8.2 SIPP Reviews . . . . . . . . . . . . . . . . . . . . . . 15
8.3 TUBA Reviews . . . . . . . . . . . . . . . . . . . . . . 16
8.4 Summary of Proposal Reviews. . . . . . . . . . . . . . . 17
9. A Revised Proposal . . . . . . . . . . . . . . . . . . . 17
10 Assumptions . . . . . . . . . . . . . . . . . . . . . . 18
10.1 Criteria Document and Timing of Recommendation . . . . . 18
10.2 Address Length . . . . . . . . . . . . . . . . . . . . . 19
11. IPng Recommendation. . . . . . . . . . . . . . . . . . . 19
11.1 IPng Criteria Document and IPng. . . . . . . . . . . . . 20
11.2 IPv6. . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. IPv6 Overview . . . . . . . . . . . . . . . . . . . . . 21
12.1 IPv6 Header Format . . . . . . . . . . . . . . . . . . . 24
12.2 Extension Headers. . . . . . . . . . . . . . . . . . . . 25
12.2.1 Hop-by-Hop Option Header . . . . . . . . . . . . . . . . 25
12.2.2 IPv6 Header Options. . . . . . . . . . . . . . . . . . . 26
12.2.3 Routing Header . . . . . . . . . . . . . . . . . . . . . 27
12.2.4 Fragment Header. . . . . . . . . . . . . . . . . . . . . 28
12.2.5 Authentication Header. . . . . . . . . . . . . . . . . . 29
12.2.6 Privacy Header . . . . . . . . . . . . . . . . . . . . . 30
12.2.7 End-to-End Option Header . . . . . . . . . . . . . . . . 32
13. IPng Working Group . . . . . . . . . . . . . . . . . . . 32
14. IPng Reviewer . . . . . . . . . . . . . . . . . . . . . 33
15. Address Autoconfiguration. . . . . . . . . . . . . . . . 33
16. Transition . . . . . . . . . . . . . . . . . . . . . . . 34
16.1 Transition - Short Term. . . . . . . . . . . . . . . . . 35
16.2 Transition - Long Term . . . . . . . . . . . . . . . . . 36
17. Other Address Families . . . . . . . . . . . . . . . . . 37
18. Impact on Other IETF Standards . . . . . . . . . . . . . 38
19. Impact on non-IETF standards and on prodUCts . . . . . . 39
20. APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 39
21. Future of the IPng Area and Working Groups . . . . . . . 40
22. Security Considerations. . . . . . . . . . . . . . . . . 40
23. Authors" Addresses . . . . . . . . . . . . . . . . . . . 43
Appendix A Summary of Recommendations . . . . . . . . . . . . . 44
Appendix B IPng Area Directorate. . . . . . . . . . . . . . . . 45
Appendix C Documents Referred to the IPng Working Groups. . . . 46
Appendix D IPng Proposal Overviews. . . . . . . . . . . . . . . 46
Appendix E RFC1550 White Papers. . . . . . . . . . . . . . . . 47
Appendix F Additional References. . . . . . . . . . . . . . . . 48
Appendix G Acknowledgments. . . . . . . . . . . . . . . . . . . 52
1. Summary
The IETF started its effort to select a successor to IPv4 in late
1990 when projections indicated that the Internet address space would
become an increasingly limiting resource. Several parallel efforts
then started eXPloring ways to resolve these address limitations
while at the same time providing additional functionality. The IETF
formed the IPng Area in late 1993 to investigate the various
proposals and recommend how to proceed. We developed an IPng
technical criteria document and evaluated the various proposals
against it. All were found wanting to some degree. After this
evaluation, a revised proposal was offered by one of the working
groups that resolved many of the problems in the previous proposals.
The IPng Area Directors recommend that the IETF designate this
revised proposal as the IPng and focus its energy on bringing a set
of documents defining the IPng to Proposed Standard status with all
deliberate speed.
This protocol recommendation includes a simplified header with a
hierarchical address structure that permits rigorous route
aggregation and is also large enough to meet the needs of the
Internet for the foreseeable future. The protocol also includes
packet-level authentication and encryption along with plug and play
autoconfiguration. The design changes the way IP header options are
encoded to increase the flexibility of introducing new options in the
future while improving performance. It also includes the ability to
label traffic flows.
Specific recommendations include:
* current address assignment policies are adequate
* there is no current need to reclaim underutilized assigned network
numbers
* there is no current need to renumber major portions of the Internet
* CIDR-style assignments of parts of unassigned Class A address space
should be considered
* "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)"
[Deering94b] be adopted as the basis for IPng
* the documents listed in Appendix C be the foundation of the IPng
effort
* an IPng Working Group be formed, chaired by Steve Deering and Ross
Callon
* Robert Hinden be the document editor for the IPng effort
* an IPng Reviewer be appointed and that Dave Clark be the reviewer
* an Address Autoconfiguration Working Group be formed, chaired by
Dave Katz and Sue Thomson
* an IPng Transition Working Group be formed, chaired by Bob Gilligan
and TBA
* the Transition and Coexistence Including Testing Working Group be
chartered
* recommendations about the use of non-IPv6 addresses in IPv6
environments and IPv6 addresses in non-IPv6 environments be
developed
* the IESG commission a review of all IETF standards documents for
IPng implications
* the IESG task current IETF working groups to take IPng into account
* the IESG charter new working groups where needed to revise old
standards documents
* Informational RFCs be solicited or developed describing a few
specific IPng APIs
* the IPng Area and Area Directorate continue until main documents
are offered as Proposed Standards in late 1994
* support for the Authentication Header be required
* support for a specific authentication algorithm be required
* support for the Privacy Header be required
* support for a specific privacy algorithm be required
* an "IPng framework for firewalls" be developed
2. Background
Even the most farseeing of the developers of TCP/IP in the early
1980s did not imagine the dilemma of scale that the Internet faces
today. 1987 estimates projected a need to address as many as 100,000
networks at some vague point in the future. [Callon87] We will reach
that mark by 1996. There are many realistic projections of many
millions of interconnected networks in the not too distant future.
[Vecchi94, Taylor94]
Further, even though the current 32 bit IPv4 address structure can
enumerate over 4 billion hosts on as many as 16.7 million networks,
the actual address assignment efficiency is far less than that, even
on a theoretical basis. [Huitema94] This inefficiency is exacerbated
by the granularity of assignments using Class A, B and C addresses.
In August 1990 during the Vancouver IETF meeting, Frank Solensky,
Phill Gross and Sue Hares projected that the current rate of
assignment would exhaust the Class B space by March of 1994.
The then obvious remedy of assigning multiple Class C addresses in
place of Class B addresses introduced its own problem by further
expanding the size of the routing tables in the backbone routers
already growing at an alarming rate.
We faced the dilemma of choosing between accepting either limiting
the rate of growth and ultimate size of the Internet, or disrupting
the network by changing to new techniques or technologies.
The IETF formed the Routing and Addressing (ROAD) group in November
1991 at the Santa Fe IETF meeting to explore this dilemma and guide
the IETF on the issues. The ROAD group reported their work in March
1992 at the San Diego IETF meeting. [Gross92] The impact of the
recommendations ranged from "immediate" to "long term" and included
adopting the CIDR route aggregation proposal [Fuller93] for reducing
the rate of routing table growth and recommending a call for
proposals "to form working groups to explore separate approaches for
bigger Internet addresses."
In the late spring of 1992 the IAB issued "IP version 7" [IAB92],
concurring in the ROAD group"s endorsement of CIDR and also
recommending "an immediate IETF effort to prepare a detailed and
organizational plan for using CLNP as the basis for IPv7." After
spirited discussion, the IETF decided to reject the IAB"s
recommendation and issue the call for proposals recommended by the
ROAD group. This call was issued in July 1992 at the Boston IETF
meeting and a number of working groups were formed in response
During the July 1993 Amsterdam IETF meeting an IPng (IP Next
Generation) Decision Process (ipdecide) BOF was held. This BOF "was
intended to help re-focus attention on the very important topic of
making a decision between the candidates for IPng. The BOF focused on
the issues of who should take the lead in making the recommendation
to the community and what criteria should be used to reach the
recommendation." [Carpen93]
3. A Direction for IPng
In September 1993 Phill Gross, chair of the IESG issued "A Direction
for IPng". [Gross94] In this memo he summarized the results of the
ipdecide BOF and open IESG plenary in Amsterdam.
* The IETF needs to move toward closure on IPng.
* The IESG has the responsibility for developing an IPng
recommendation for the Internet community.
* The procedures of the recommendation-making process should be open
and published well in advance by the IESG.
* As part of this process, the IPng WGs may be given new milestones
and other guidance to aid the IESG.
* There should be ample opportunity for community comment prior to
final IESG recommendation.
The memo also announced "a temporary, ad hoc, "area" to deal
specifically with IPng issues." Phill asked two of the current IESG
members, Allison Mankin (Transport Services Area) and Scott Bradner
(Operational Requirements Area), to act as Directors for the new
area. The Area Directors were given a specific charge on how to
investigate the various IPng proposals and how to base their
recommendation to the IETF. It was also requested that a specific
recommendation be made.
* Establish an IPng directorate.
* Ensure that a completely open process is followed.
* Develop an understanding of the level of urgency and the time
constraints imposed by the rate of address assignment and rate of
growth in the routing tables.
* Recommend the adoption of assignment policy changes if warranted.
* Define the scope of the IPng effort based on the understanding of
the time constraints.
* Develop a clear and concise set of technical requirements and
decision criteria for IPng.
* Develop a recommendation about which of the current IPng candidates
to accept, if any.
4. IPng Area
After the IPng Area was formed, we recruited a directorate. (Appendix
B) The members of the directorate were chosen both for their general
and specific technical expertise. The individuals were then asked to
have their management authorize this participation in the process and
confirm that they understood the IETF process.
We took great care to ensure the inclusion of a wide spectrum of
knowledge. The directors are experts in security, routing, the needs
of large users, end system manufacturers, Unix and non-Unix
platforms, router manufacturers, theoretical researchers, protocol
architecture, and the operating regional, national, and international
networks. Additionally, several members of the directorate were
deeply involved in each of the IPng proposal working groups.
The directorate functions as a direction-setting and preliminary
review body as requested by the charge to the area. The directorate
engages in biweekly conference calls, participates in an internal
mailing list and corresponds actively on the Big-Internet mailing
list. The directorate held open meetings during the March 1994
Seattle and July 1994 Toronto IETF meetings as well as two additional
multi-day retreats. To ensure that the IPng process was as open as
possible, we took minutes during these meetings and then published
them. Additionally, we placed the archives of the internal IPng
mailing list on an anonymous FTP site. (Hsdndev.harvard.edu:
pub/ipng.)
5. ALE Working Group
We needed a reasonable estimate of the time remaining before we
exhausted the IPv4 address space in order to determine the scope of
the IPng effort. If the time remaining was about the same needed to
deploy a replacement, then we would have select the IPng which would
only fix the address limitations since we would not have enough time
to develop any other features. If more time seemed available, we
could consider additional improvements.
The IETF formed an Address Lifetime Expectations (ALE) Working Group
in 1993 "to develop an estimate for the remaining lifetime of the
IPv4 address space based on currently known and available
technologies." [Solens93a] Tony Li of Cisco Systems and Frank
Solensky of FTP Software are the co-chairs. The IETF also charged
the working group to consider if developing more stringent address
allocation and utilization policies might provide more time for the
transition.
5.1 ALE Projections
The ALE Working Group met during the November 1993 Houston,
[Solens93b] March 1994 Seattle [Bos93] and July 1994 Toronto
[Solens94] IETF meetings. They projected at the Seattle meeting,
later confirmed at the Toronto meeting that, using the current
allocation statistics, the Internet would exhaust the IPv4 address
space between 2005 and 2011.
Some members of the ipv4-ale and big-internet mailing lists called
into question the reliability of this projection. It has been
criticized as both too optimistic and as too pessimistic.
Some people pointed out that this type of projection makes an
assumption of no paradigm shifts in IP usage. If someone were to
develop a new "killer application", (for example cable-TV set top
boxes.) The resultant rise in the demand for IP addresses could make
this an over-estimate of the time available.
There may also be a problem with the data used to make the
projection. The InterNIC allocates IP addresses in large chunks to
regional Network Information Centers (NICs) and network providers.
The NICs and the providers then re-allocate addresses to their
customers. The ALE projections used the InterNIC assignments without
regard to the actual rate of assignment of addresses to the end
users. They did the projection this way since the accuracy of the
data seems quite a bit higher. While using this once-removed data
may add a level of over-estimation since it assumes the rate of large
block allocation will continue, this may not be the case.
These factors reduce the reliability of the ALE estimates but, in
general, they seem to indicate enough time remaining in the IPv4
address space to consider adding features in an IPng besides just
expanding the address size even when considering time required for
development, testing, and deployment.
5.2 Routing Table Size
Another issue in Internet scaling is the increasing size of the
routing tables required in the backbone routers. Adopting the CIDR
block address assignment and aggregating routes reduced the size of
the tables for awhile but they are now expanding again. Providers now
need to more aggressively advertise their routes only in aggregates.
Providers must also advise their new customers to renumber their
networks in the best interest of the entire Internet community.
The problem of exhausting the IPv4 address space may be moot if this
issue is ignored and if routers cannot be found that can keep up with
the table size growth. Before implementing CIDR the backbone routing
table was growing at a rate about 1.5 times as fast as memory
technology.
We should also note that even though IPng addresses are designed with
aggregation in mind switching to IPng will not solve the routing
table size problem unless the addresses are assigned rigorously to
maximize the affect of such aggregation. This efficient advertising
of routes can be maintained since IPng includes address
autoconfiguration mechanisms to allow easy renumbering if a customer
decides to switch providers. Customers who receive service from more
than one provider may limit the ultimate efficiency of any route
aggregation. [Rekhter94]
5.3 Address Assignment Policy Recommendations
The IESG Chair charged the IPng Area to consider recommending more
stringent assignment policies, reclaiming some addresses already
assigned, or making a serious effort to renumber significant portions
of the Internet. [Gross94]
The IPng Area Directors endorse the current address assignment
policies in view of the ALE projections. We do not feel that anyone
should take specific efforts to reclaim underutilized addresses
already assigned or to renumber forcefully major portions of the
Internet. We do however feel that we should all encourage network
service providers to assist new customers in renumbering their
networks to conform to the provider"s CIDR assignments.
The ALE Working Group recommends that we consider assigning CIDR-type
address blocks out of the unassigned Class A address space. The IPng
Area Directors concur with this recommendation.
6. IPng Technical Requirements
The IESG provided an outline in RFC1380 [Gross92] of the type of
criteria we should use to determine the suitability of an IPng
proposal. The IETF further refined this understanding of the
appropriate criteria with the recommendations of a Selection Criteria
BOF held during the November 1992 IETF meeting in Washington D.C.
[Almqu92] We felt we needed to get additional input for determining
the requirements and issued a call for white papers. [Bradner93] This
call, issued as RFC1550, intended to reach both inside and outside
the traditional IETF constituency to get the broadest possible
understanding of the requirements for a data networking protocol with
the broadest possible application.
We received twenty one white papers in response to the RFC1550
solicitation. ( Appendix E) We received responses from the
industries that many feel will be the major providers of data
networking services in the future; the cable TV industry [Vecchi94],
the cellular industry [Taylor94], and the electric power industry
[Skelton94]. In addition, we received papers that dealt with
military applications [Adam94, Syming94, Green94], ATM [Brazd94],
mobility [Simpson94], accounting [Brown94], routing [Estrin94a,
Chiappa94], security [Adam94, Bell94b, Brit94, Green94, Vecchi94,
Flei94], large corporate networking [Britt94, Fleisch94], transition
[Carpen94a, Heager94], market acceptance [Curran94, Britt94], host
implementations [Bound94], as well as a number of other issues.
[Bello94a, Clark94, Ghisel94]
These white papers, a Next Generation Requirements (ngreq) BOF
(chaired by Jon Crowcroft and Frank Kastenholz) held during the March
1994 Seattle IETF meeting, discussions within the IPng Area
Directorate and considerable discussion on the big-internet mailing
list were all used by Frank Kastenholz and Craig Partridge in
revising their earlier criteria draft [Kasten92] to produce
"Technical Criteria for Choosing IP The Next Generation (IPng)."
[Kasten94] This document is the "clear and concise set of technical
requirements and decision criteria for IPng" called for in the charge
from the IESG Chair. We used this document as the basic guideline
while evaluating the IPng proposals.
6.1 The IPng Technical Criteria document
The criteria described in this document include: (from Kasten94)
* complete specification - The proposal must completely describe the
proposed protocol. We must select an IPng by referencing specific
documents, not to future work.
* architectural simplicity - The IP-layer protocol should be as
simple as possible with functions located elsewhere that are more
appropriately performed at protocol layers other than the IP layer.
* scale - The IPng Protocol must allow identifying and addressing at
least 10**9 leaf-networks (and preferably much more)
* topological flexibility - The routing architecture and protocols
ofIPng must allow for many different network topologies. They must
not assume that the network"s physical structure is a tree.
* performance - A state of the art, commercial grade router must be
able to process and forward IPng traffic at speeds capable of fully
utilizing common, commercially available, high-speed media at the
time.
* robust service - The network service and its associated routing and
control protocols must be robust.
* transition - The protocol must have a straightforward transition
plan from IPv4.
* media independence - The protocol must work across an internetwork
of many different LAN, MAN, and WAN media, with individual link
speeds ranging from a ones-of-bits per second to hundreds of
gigabits per second.
* datagram service - The protocol must support an unreliable datagram
delivery service.
* configuration ease - The protocol must permit easy and largely
distributed configuration and operation. Automatic configuration of
hosts and routers is required.
* security - IPng must provide a secure network layer.
* unique names - IPng must assign unique names to all IP-Layer
objects in the global, ubiquitous, Internet. These names may or
may not have any location, topology, or routing significance.
* Access to standards - The protocols that define IPng and its
associated protocols should be as freely available and
redistributable as the IPv4 and related RFCs. There must be no
specification-related licensing fees for implementing or selling
IPng software.
* multicast support - The protocol must support both unicast and
multicast packet transmission. Dynamic and automatic routing of
multicasts is also required.
* extensibility - The protocol must be extensible; it must be able
to evolve to meet the future service needs of the Internet. This
evolution must be achievable without requiring network-wide
software upgrades.
* service classes - The protocol must allow network devices to
associate packets with particular service classes and provide them
with the services specified by those classes.
* mobility - The protocol must support mobile hosts, networks and
internetworks.
* control protocol - The protocol must include elementary support for
testing and debugging networks. (e.g., ping and traceroute)
* tunneling support - IPng must allow users to build private
internetworks on top of the basic Internet Infrastructure. Both
private IP-based internetworks and private non-IP-based (e.g., CLNP
or AppleTalk) internetworks must be supported.
7. IPng Proposals
By the time that the IPng Area was formed, the IETF had already aimed
a considerable amount of IETF effort at solving the addressing and
routing problems of the Internet. Several proposals had been made
and some of these reached the level of having a working group
chartered. A number of these groups subsequently merged forming
groups with a larger consensus. These efforts represented different
views on the issues which confront us and sought to optimize
different ASPects of the possible solutions.
By February 1992 the Internet community developed four separate
proposals for IPng [Gross92], "CNAT" [Callon92a], "IP Encaps"
[Hinden92a], "Nimrod" [Chiappa91], and "Simple CLNP" [Callon92b]. By
December 1992 three more proposals followed; "The P Internet
Protocol" (PIP) [Tsuchiya92], "The Simple Internet Protocol" (SIP)
[Deering92] and "TP/IX" [Ullmann93]. After the March 1992 San Diego
IETF meeting "Simple CLNP" evolved into "TCP and UDP with Bigger
Addresses" (TUBA) [Callon92c] and "IP Encaps" evolved into "IP
Address Encapsulation" (IPAE) [Hinden92b].
By November 1993, IPAE merged with SIP while still maintaining the
name SIP. This group then merged with PIP and the resulting working
group called themselves "Simple Internet Protocol Plus" (SIPP). At
the same time the TP/IX Working Group changed its name to "Common
Architecture for the Internet" (CATNIP).
None of these proposals were wrong nor were others right. All of the
proposals would work in some ways providing a path to overcome the
obstacles we face as the Internet expands. The task of the IPng Area
was to ensure that the IETF understand the offered proposals, learn
from the proposals and provide a recommendation on what path best
resolves the basic issues while providing the best foundation upon
which to build for the future.
The IPng Area evaluated three IPng proposals as they were described
in their RFC1550 white papers: CATNIP [McGovern94] , SIPP
[Hinden94a] and TUBA. [Ford94a]. The IESG viewed Nimrod as too much
of a research project for consideration as an IPng candidate. Since
Nimrod represents one possible future Internet routing strategy we
solicited a paper describing any requirements Nimrod would put on an
IPng to add to the requirements process. [Chiappa94]
7.1 CATNIP
"Common Architecture for the Internet (CATNIP) was conceived as a
convergence protocol. CATNIP integrates CLNP, IP, and IPX. The CATNIP
design provides for any of the transport layer protocols in use, for
example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the
network layer protocol formats: CLNP, IP (version 4), IPX, and
CATNIP. With some attention paid to details, it is possible for a
transport layer protocol (such as TCP) to operate properly with one
end system using one network layer (e.g., IP version 4) and the other
using some other network protocol, such as CLNP." [McGovern94]
"The objective is to provide common ground between the Internet, OSI,
and the Novell protocols, as well as to advance the Internet
technology to the scale and performance of the next generation of
internetwork technology."
"CATNIP supports OSI Network Service Access Point (NSAP) format
addresses. It also uses cache handles to provide both rapid
identification of the next hop in high performance routing as well as
abbreviation of the network header by permitting the addresses to be
omitted when a valid cache handle is available. The fixed part of the
network layer header carries the cache handles." [Sukonnik94]
7.2 SIPP
"Simple Internet Protocol Plus (SIPP) is a new version of IP which is
designed to be an evolutionary step from IPv4. It is a natural
increment to IPv4. It was not a design goal to take a radical step
away from IPv4. Functions which work in IPv4 were kept in SIPP.
Functions which didn"t work were removed. It can be installed as a
normal software upgrade in internet devices and is interoperable with
the current IPv4. Its deployment strategy was designed to not have
any "flag" days. SIPP is designed to run well on high performance
networks (e.g., ATM) and at the same time is still efficient for low
bandwidth networks (e.g., wireless). In addition, it provides a
platform for new internet functionality that will be required in the
near future." [Hinden94b]
"SIPP increases the IP address size from 32 bits to 64 bits, to
support more levels of addressing hierarchy and a much greater number
of addressable nodes. SIPP addressing can be further extended, in
units of 64 bits, by a facility equivalent to IPv4"s Loose Source and
Record Route option, in combination with a new address type called
"cluster addresses" which identify topological regions rather than
individual nodes."
"SIPP changes in the way IP header options are encoded allows for
more efficient forwarding, less stringent limits on the length of
options, and greater flexibility for introducing new options in the
future. A new capability is added to enable the labeling of packets
belonging to particular traffic "flows" for which the sender requests
special handling, such as non-default quality of service or "real-
time" service." [Hinden94a]
7.3 TUBA
"The TCP/UDP Over CLNP-Addressed Networks (TUBA) proposal seeks to
minimize the risk associated with migration to a new IP address
space. In addition, this proposal is motivated by the requirement to
allow the Internet to scale, which implies use of Internet
applications in a very large ubiquitous worldwide Internet. It is
therefore proposed that existing Internet transport and application
protocols continue to operate unchanged, except for the replacement
of 32-bit IP addresses with larger addresses. TUBA does not mean
having to move over to OSI completely. It would mean only replacing
IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would
run on top of CLNP." [Callon92c]
"The TUBA effort will expand the ability to route Internet packets by
using addresses which support more hierarchy than the current
Internet Protocol (IP) address space. TUBA specifies the continued
use of Internet transport protocols, in particular TCP and UDP, but
specifies their encapsulation in ISO 8473 (CLNP) packets. This will
allow the continued use of Internet application protocols such as
FTP, SMTP, TELNET, etc. TUBA seeks to upgrade the current system by
a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the
corresponding large Network Service Access Point (NSAP) address
space." [Knopper94]
"The TUBA proposal makes use of a simple long-term migration proposal
based on a gradual update of Internet Hosts (to run Internet
applications over CLNP) and DNS servers (to return larger addresses).
This proposal requires routers to be updated to support forwarding of
CLNP (in addition to IP). However, this proposal does not require
encapsulation nor translation of packets nor address mapping. IP
addresses and NSAP addresses may be assigned and used independently
during the migration period. Routing and forwarding of IP and CLNP
packets may be done independently." ([Callon92c]
8. IPng Proposal Reviews
The IPng Directorate discussed and reviewed the candidate proposals
during its biweekly teleconferences and through its mailing list. In
addition, members of the Big-Internet mailing list discussed many of
the aspects of the proposals, particularly when the Area Directors
posted several specific questions to stimulate discussion. [Big]
The directorate members were requested to each evaluate the proposals
in preparation for a two day retreat held near Chicago on May 19th
and 20th 1994. The retreat opened with a roundtable airing of the
views of each of the participants, including the Area Directors, the
Directorate and a number of guests invited by the working group
chairs for each for the proposals. [Knopper94b] We will publish
these reviews as well as a more detailed compendium review of each of
the proposals as companion memos.
The following table summarizes each of the three proposals reviewed
against the requirements in the IPng Criteria document. They do not
necessarily reflect the views of the Area Directors. "Yes" means the
reviewers mainly felt the proposal met the specific criterion. "No"
means the reviewers mainly felt the proposal did not meet the
criterion. "Mixed" means that the reviewers had mixed reviews with
none dominating. "Unknown" means that the reviewers mainly felt the
documentation did not address the criterion.
CATNIP SIPP TUBA
------ ---- ----
complete spec no yes mostly
simplicity no no no
scale yes yes yes
topological flex yes yes yes
performance mixed mixed mixed
robust service mixed mixed yes
transition mixed no mixed
media indepdnt yes yes yes
datagram yes yes yes
config. ease unknown mixed mixed
security unknown mixed mixed
unique names mixed mixed mixed
access to stds yes yes mixed
multicast unknown yes mixed
extensibility unknown mixed mixed
service classes unknown yes mixed
mobility unknown mixed mixed
control proto unknown yes mixed
tunneling unknown yes mixed
8.1 CATNIP Reviews
All the reviewers felt that CATNIP is not completely specified.
However, many of the ideas in CATNIP are innovative and a number of
reviewers felt CATNIP shows the best vision of all of the proposals.
The use of Network Service Attachment Point Addresses (NSAPs) is well
thought out and the routing handles are innovative.
While the goal of uniting three major protocol families, IP, ISO-CLNP
and Novell IPX is laudable our consensus was that the developers had
not developed detailed enough plans to support realizing that goal.
The plans they do describe suffer from the complexity of trying to be
the union of a number of existing network protocols. Some reviewers
felt that CATNIP is basically maps IPv4, IPX, and SIPP addresses into
NSAPs and, as such, does not deal with the routing problems of the
current and future Internet.
Additionally the reviewers felt that CATNIP has poor support for
multicasting and mobility and does not specifically deal with such
important topics as security and autoconfiguration.
8.2 SIPP Reviews
Most of the reviewers, including those predisposed to other
proposals, felt as one reviewer put it, that SIPP is an
"aesthetically beautiful protocol well tailored to compactly satisfy
today"s known network requirements." The SIPP Working Group has been
the most dynamic over the last year, producing a myriad of
documentation detailing almost all of the aspects necessary to
produce a complete protocol description.
The biggest problem the reviewers had with SIPP was with IPAE, SIPP"s
transition plan. The overwhelming feeling was that IPAE is fatally
flawed and could not be made to work reliably in an operational
Internet.
There was significant disagreement about the adequacy of the SIPP 64
bit address size. Although you can enumerate 10**15 end nodes in 64
bits people have different views about how much inefficiency real-
world routing plans introduce. [Huitema94] The majority felt that 64
bit addresses do not provide adequate space for the hierarchy
required to meet the needs of the future Internet. In addition since
no one has any experience with extended addressing and routing
concepts of the type proposed in SIPP, the reviewers generally felt
quite uncomfortable with this methodology. The reviewers also felt
that the design introduces some significant security issues.
A number of reviewers felt that SIPP did not address the routing
issue in any useful way. In particular, there has been no serious
attempt made at developing ways to abstract topology information or
to aggregate information about areas of the network.
Finally, most of the reviewers questioned the level of complexity in
the SIPP autoconfiguration plans as well as in SIPP in general, other
than the header itself.
8.3 TUBA Reviews
The reviewers generally felt that the most important thing that TUBA
has offers is that it is based on CLNP and there is significant
deployment of CLNP-capable routers throughout the Internet. There
was considerably less agreement that there was significant deployment
of CLNP-capable hosts or actual networks running CLNP. Another
strong positive for TUBA is the potential for convergence of ISO and
IETF networking standards. A number of reviewers pointed out that,
if TUBA were to be based on a changed CLNP then the advantage of an
existing deployed infrastructure would be lost and that the
convergence potential would be reduced.
A number of aspects of CLNP were felt to be a problem by the
reviewers including the inefficiencies introduced by the lack of any
particular Word alignment of the header fields, CLNP source route,
the lack of a flow ID field, the lack of a protocol ID field, and the
use of CLNP error messages in TUBA. The CLNP packet format or
procedures would have to be modified to resolve at least some of
these issues.
There seems to be a profound disagreement within the TUBA community
over the question of the ability of the IETF to modify the CLNP
standards. In our presentation in Houston we said that we felt that
"clone and run" was a legitimate process. This is also what the IAB
proposed in "IP version 7". [IAB92] The TUBA community has not
reached consensus that this view is reasonable. While many,
including a number of the CLNP document authors, are adamant that
this is not an issue and the IETF can make modifications to the base
standards, many others are just as adamant that the standards can
only be changed through the ISO standards process. Since the
overwhelming feeling within the IETF is that the IETF must "own" the
standards on which it is basing its future, this disagreement within
the TUBA community was disquieting.
For a number of reasons, unfortunately including prejudice in a few
cases, the reviews of the TUBA proposals were much more mixed than
for SIPP or CATNIP. Clearly TUBA meets the requirements for the
ability to scale to large numbers of hosts, supports flexible
topologies, is media independent and is a datagram protocol. To the
reviewers, it was less clear that TUBA met the other IPng
requirements and these views varied widely.
There was also disagreement over the advisability of using NSAPs for
routing given the wide variety of NSAP allocation plans. The
Internet would have to restrict the use of NSAPs to those which are
allocated with the actual underlying network topology in mind if the
required degree of aggregation of routing information is to be
achieved.
8.4 Summary of Proposal Reviews
To summarize, significant problems were seen in all three of the
proposals. The feeling was that, to one degree or another, both SIPP
and TUBA would work in the Internet context but each exhibited its
own problems. Some of these problems would have to be rectified
before either one would be ready to replace IPv4, much less be the
vehicle to carry the Internet into the future. Other problems could
be addressed over time. CATNIP was felt to be too incomplete to be
considered.
9. A Revised Proposal
As mentioned above, there was considerable discussion of the
strengths and weaknesses of the various IPng proposals during the
IPng "BigTen" retreat on May 19th and 20th 1994. [Knopper94b] After
this retreat Steve Deering and Paul Francis, two of the co-chairs of
the SIPP Working Group, sent a message to the sipp mailing list
detailing the discussions at the retreat and proposing some changes
in SIPP. [Deering94a]
The message noted "The recurring (and unsurprising) concerns about
SIPP were:
(1) complexity/manageability/feasibility of IPAE, and
(2) adequacy/correctness/limitations of SIPP"s addressing and routing
model, especially the use of loose source routing to accomplish
"extended addressing"".
They "proposed to address these concerns by changing SIPP as follows:
* Change address size from 8 bytes to 16 bytes (fixed-length).
* Specify optional use of serverless autoconfiguration of the 16-byte
address by using IEEE 802 address as the low-order ("node ID")
part.
* For higher-layer protocols that use internet-layer addresses as
part of connection identifiers (e.g., TCP), require that they use
the entire 16-byte addresses.
* Do *not* use Route Header for extended addressing."
After considerable discussion on the sipp and big-internet mailing
lists about these proposed changes, the SIPP working group published
a revised version of SIPP [Deering94b], a new addressing architecture
[Francis94], and a simplified transition mechanism [Gillig94a].
These were submitted to the IPng Directorate for their consideration.
This proposal represents a synthesis of multiple IETF efforts with
much of the basic protocol coming from the SIPP effort, the
autoconfiguration and transition portions influenced by TUBA, the
addressing structure is based on the CIDR work and the routing header
evolving out of the SDRP deliberations.
10. Assumptions
10.1 Criteria Document and Timing of Recommendation
In making the following recommendations we are making two assumptions
of community consensus; that the IPng criteria document represents
the reasonable set of requirements for an IPng, and that a specific
recommendation should be made now and that from this point on the
IETF should proceed with a single IPng effort.
As described above, the IPng Technical Criteria document [Kasten94]
was developed in a open manner and was the topic of extensive
discussions on a number of mailing lists. We believe that there is a
strong consensus that this document accurately reflects the
community"s set of technical requirements which an IPng should be
able to meet.
A prime topic of discussion on the big-internet mailing list this
spring as well as during the open IPng directorate meeting in
Seattle, was the need to make a specific IPng recommendation at this
time. Some people felt that additional research would help resolve
some of the issues that are currently unresolved. While others
argued that selecting a single protocol to work on would clarify the
picture for the community, focus the resources of the IETF on
finalizing its details, and, since the argument that there were open
research items could be made at any point in history, there might
never be a "right" time.
Our reading of the community is that there is a consensus that a
specific recommendation should be made now. This is consistent with
the views expressed during the ipdecide BOF in Amsterdam [Gross94]
and in some of the RFC1550 white papers [Carpen94a].
There is no particular reason to think that the basic recommendation
would be significantly different if we waited for another six months
or a year. Clearly some details which are currently unresolved could
be filled in if the recommendation were to be delayed, but the
current fragmentation of the IETF"s energies limits the efficiency of
this type of detail resolution. Concentrating the resources of the
IETF behind a single effort seems to us to be a more efficient way to
proceed.
10.2 Address Length
One of the most hotly discussed aspects of the IPng design
possibilities was address size and format. During the IPng process
four distinct views were expressed about these issues:
1. The view that 8 bytes of address are enough to meet the current
and future needs of the Internet (squaring the size of the IP
address space). More would waste bandwidth, promote inefficient
assignment, and cause problems in some networks (such as mobiles
and other low speed links).
2. The view that 16 bytes is about right. That length supports easy
auto-configuration as well as organizations with complex internal
routing topologies in conjunction with the global routing topology
now and well into the future.
3. The view that 20 byte OSI NSAPs should be used in the interests of
global harmonization.
4. The view that variable length addresses which might be smaller or
larger than 16 bytes should be used to embrace all the above
options and more, so that the size of the address could be
adjusted to the demands of the particular environment, and to
ensure the ability to meet any future networking requirements.
Good technical and engineering arguments were made for and against
all of these views. Unanimity was not achieved, but we feel that a
clear majority view emerged that the use of 16 byte fixed length
addresses was the best compromise between efficiency, functionality,
flexibility, and global applicability. [Mankin94]
11. IPng Recommendation
After a great deal of discussion in many forums and with the
consensus of the IPng Directorate, we recommend that the protocol
described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit
ver)" [Deering94b] be adopted as the basis for IPng, the next
generation of the Internet Protocol. We also recommend that the
other documents listed in Appendix C be adopted as the basis of
specific features of this protocol.
This proposal resolves most of the perceived problems, particularly
in the areas of addressing, routing, transition and address
autoconfiguration. It includes the broad base of the SIPP proposal
effort, flexible address autoconfiguration features, and a merged
transition strategy. We believe that it meets the requirements
outlined in the IPng Criteria document and provides the framework to
fully meet the needs of the greater Internet community for the
foreseeable future.
11.1 IPng Criteria Document and IPng
A detailed review of how IPng meets the requirements set down in the
IPng Criteria document [Kasten94] will soon be published. Following
is our feelings about the extent to which IPng is responsive to the
criteria.
* complete specification - the base specifications for IPng are
complete but transition and address autoconfiguration do remain to
be finalized
* architectural simplicity - the protocol is simple, easy to explain
and uses well established paradigms
* scale - an address size of 128 bits easily meets the need to
address 10**9 networks even in the face of the inherent
inefficiency of address allocation for efficient routing
* topological flexibility - the IPng design places no constraints on
network topology except for the limit of 255 hops
* performance - the simplicity of processing, the alignment of the
fields in the headers, and the elimination of the header checksum
will allow for high performance handling of IPng data streams
* robust service - IPng includes no inhibitors to robust service and
the addition of packet-level authentication allows the securing of
control and routing protocols without having to have separate
procedures
* transition - the IPng transition plan is simple and realistically
covers the transition methods that will be present in the
marketplace
* media independence - IPng retains IPv4"s media independence, it may
be possible to make use of IPng"s Flow Label in some connection-
oriented media such as ATM
* datagram service - IPng preserves datagram service as its basic
operational mode, it is possible that the use of path MTU discovery
will complicate the use of datagrams in some cases
* configuration ease - IPng will have easy and flexible address
autoconfiguration which will support a wide variety of environments
from nodes on an isolated network to nodes deep in a complex
internet
* security - IPng includes specific mechanisms for authentication and
encryption at the internetwork layer; the security features do rely
on the presence of a yet to be defined key management system
* unique names - IPng addresses may be used as globally unique names
although they do have topological significance
* access to standards - all of the IPng standards will be published
as RFCs with unlimited distribution
* multicast support - IPng specifically includes multicast support
* extensibility - the use of extension headers and an expandable
header option feature will allow the introduction of new features
into IPng when needed in a way that minimizes the disruption of the
existing network
* service classes - the IPng header includes a Flow Label which may
be used to differentiate requested service classes
* mobility - the proposed IPv4 mobility functions will work with IPng
* control protocol - IPng includes the familiar IPv4 control protocol
features
* tunneling support - encapsulation of IPng or other protocols within
IPng is a basic capability described in the IPng specifications
11.2 IPv6
The IANA has assigned version number 6 to IPng. The protocol itself
will be called IPv6.
The remainder of this memo is used to describe IPv6 and its features.
This description is an overview snapshot. The standards documents
themselves should be referenced for definitive specifications. We
also make a number of specific recommendations concerning the details
of the proposed protocol, the procedures required to complete the
definition of the protocol, and the IETF working groups we feel are
necessary to accomplish the task.
12. IPv6 Overview
IPv6 is a new version of the Internet Protocol, it has been designed
as an evolutionary, rather than revolutionary, step from IPv4.
Functions which are generally seen as working in IPv4 were kept in
IPv6. Functions which don"t work or are infrequently used were
removed or made optional. A few new features were added where the
functionality was felt to be necessary.
The important features of IPv6 include: [Hinden94c]
* expanded addressing and routing capabilities - The IP address size
is increased from 32 bits to 128 bits providing support for a much
greater number of addressable nodes, more levels of addressing
hierarchy, and simpler auto-configuration of addresses.
The scaleability of multicast routing is improved by adding a
"scope" field to multicast addresses.
A new type of address, called a "cluster address" is defined to
identify topological regions rather than individual nodes. The use
of cluster addresses in conjunction with the IPv6 source route
capability allows nodes additional control over the path their
traffic takes.
* simplified header format - Some IPv4 header fields have been
dropped or made optional to reduce the common-case processing cost
of packet handling and to keep the bandwidth overhead of the IPv6
header as low as possible in spite of the increased size of the
addresses. Even though the IPv6 addresses are four time longer
than the IPv4 addresses, the IPv6 header is only twice the size of
the IPv4 header.
* support for extension headers and options - IPv6 options are placed
in separate headers that are located in the packet between the IPv6
header and the transport-layer header. Since most IPv6 option
headers are not examined or processed by any router along a
packet"s delivery path until it arrives at its final destination,
this organization facilitates a major improvement in router
performance for packets containing options. Another improvement is
that unlike IPv4, IPv6 options can be of arbitrary length and not
limited to 40 bytes. This feature plus the manner in which they are
processed, permits IPv6 options to be used for functions which were
not practical in IPv4.
A key extensibility feature of IPv6 is the ability to encode,
within an option, the action which a router or host should perform
if the option is unknown. This permits the incremental deployment
of additional functionality into an operational network with a
minimal danger of disruption.
* support for authentication and privacy - IPv6 includes the
definition of an extension which provides support for
authentication and data integrity. This extension is included as a
basic element of IPv6 and support for it will be required in all
implementations.
IPv6 also includes the definition of an extension to support
confidentiality by means of encryption. Support for this extension
will be strongly encouraged in all implementations.
* support for autoconfiguration - IPv6 supports multiple forms of
autoconfiguration, from "plug and play" configuration of node
addresses on an isolated network to the full-featured facilities
offered by DHCP.
* support for source routes - IPv6 includes an extended function
source routing header designed to support the Source Demand Routing
Protocol (SDRP). The purpose of SDRP is to support source-initiated
selection of routes to complement the route selection provided by
existing routing protocols for both inter-domain and intra-domain
routes. [Estrin94b]
* simple and flexible transition from IPv4 - The IPv6 transition plan
is aimed at meeting four basic requirements: [Gillig94a]
- Incremental upgrade. Existing installed IPv4 hosts and routers
may be upgraded to IPv6 at any time without being dependent on
any other hosts or routers being upgraded.
- Incremental deployment. New IPv6 hosts and routers can be
installed at any time without any prerequisites.
- Easy Addressing. When existing installed IPv4 hosts or routers
are upgraded to IPv6, they may continue to use their existing
address. They do not need to be assigned new addresses.
- Low start-up costs. Little or no preparation work is needed in
order to upgrade existing IPv4 systems to IPv6, or to deploy new
IPv6 systems.
* quality of service capabilities - A new capability is added to
enable the labeling of packets belonging to particular traffic
"flows" for which the sender has requested special handling, such
as non-default quality of service or "real-time" service.
12.1 IPv6 Header Format
The IPv6 header, although longer than the IPv4 header, is
considerably simplified. A number of functions that were in the IPv4
header have been relocated in extension headers or dropped.
[Deering94b]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version Flow Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Payload Length Next Header Hop Limit
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+ +

+ Source Address +

+ +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+ +

+ Destination Address +

+ +

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Version - Internet Protocol version number. IPng has been assigned
version number 6. (4-bit field)
* Flow Label - This field may be used by a host to label those
packets for which it is requesting special handling by routers
within a network, such as non-default quality of service or "real-
time" service. (28-bit field)
* Payload Length - Length of the remainder of the packet following
the IPv6 header, in octets. To permit payloads of greater than 64K
bytes, if the value in this field is 0 the actual packet length
will be found in an Hop-by-Hop option. (16-bit unsigned integer)
* Next Header - Identifies the type of header immediately following
the IPv6 header. The Next Header field uses the same values as the
IPv4 Protocol field (8-bit selector field)
* Hop Limit - Used to limit the impact of routing loops. The Hop
Limit field is decremented by 1 by each node that forwards the
packet. The packet is discarded if Hop Limit is decremented to
zero. (8-bit unsigned integer)
* Source Address - An address of the initial sender of the packet.
(128 bit field)
* Destination Address - An address of the intended recipient of the
packet (possibly not the ultimate recipient, if an optional Routing
Header is present). (128 bit field)
12.2 Extension Headers
In IPv6, optional internet-layer information is encoded in separate
headers that may be placed between the IPv6 header and the
transport-layer header in a packet. There are a small number of such
extension headers, each identified by a distinct Next Header value.
[From a number of the documents listed in Appendix C.]
12.2.1 Hop-by-Hop Option Header
The Hop-by-Hop Options header is used to carry optional
information that must be examined by every node along a packet"s
delivery path. The Hop-by-Hop Options header is identified by a
Next Header value of 0 in the IPv6 header, and has the following
format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Hdr Ext Len
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

. .
. Options .
. .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Hop-by-Hop Options header. Uses the same values
as the IPv4 Protocol field. (8-bit selector)
* Hdr Ext Len - Length of the Hop-by-Hop Options header in 8-octet
units, not including the first 8 octets. (8-bit unsigned
integer)
* Options - Contains one or more TLV-encoded options. (Variable-
length field, of length such that the complete Hop-by-Hop
Options header is an integer multiple of 8 octets long.)
12.2.2 IPv6 Header Options
Two of the currently-defined extension headers -- the Hop-by-Hop
Options header and the End-to-End Options header -- may carry a
variable number of Type-Length-Value (TLV) encoded "options", of
the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
Option Type Opt Data Len Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
* Option Type - identifier of the type of option (8-bit field)
* Opt Data Len - Length of the Option Data field of this option,
in octets. (8-bit unsigned integer)
* Option Data - Option-Type-specific data. (Variable-length field)
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if
the processing IPv6 node does not recognize the Option Type:
00 - skip over this option and continue processing the header
01 - discard the packet
10 - discard the packet and send an ICMP Unrecognized Type message
to the packet"s Source Address, pointing to the unrecognized
Option Type
11 - undefined.
In the case of Hop-by-Hop options only, the third-highest-order
bit of the Option Type specifies whether or not the Option Data of
this option shall be included in the integrity assurance
computation performed when an Authentication header is present.
Option data that changes en route must be excluded from that
computation.
12.2.3 Routing Header
The Routing header is used by an IPv6 source to list one or more
intermediate nodes (or topological clusters) to be "visited" on
the way to a packet"s destination. This particular form of the
Routing Header is designed to support SDRP. [Estrin94b]
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next Header Routing Type=1 MF Reserved SrcRouteLen
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NextHopPtr Strict/Loose Bit Mask
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

. .
. Source Route .
. .

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* Next Header - Identifies the type of header immediately
following the Routing Header. Uses the same values as the IPv4
Protocol field. (8-bit selector)
* Routing Type - Indicates the type of routing supported by this
header. Value must be 1.
* MRE flag - Must Report Errors. If this bit is set to 1, and a
router can not further forward a packet (with an incompletely
traversed source route), as specified in the Source Route, the
router must generate an ICMP error message. If this bit is set
to 0, and a router can not further forward a packet (wit