Technical Summary
This document defines a new IPv6 Hop-by-Hop Option that
will be used narrowly within multi-level secure network
deployments. This option is used to enable mandatory
access controls (e.g. to prevent a MOST SECRET packet
from being forwarded out an UNCLASSIFIED interface).
This option is related to prior IPv4 work in the same area,
specifically RFC-1038, RFC-1108 (IPSO), and FIPS-188 (CIPSO).
Those IPv4 options are deployed by many countries and several
financial institutions to provide mandatory access controls
for IPv4 packets. These IPv4 options are supported in some
current commercial products. For example, Cisco IOS, Sun
Trusted Solaris, and SE-Linux support RFC-1108; Sun Trusted
Solaris, SGI IRIX, and SE-Linux also support FIPS-188.
This must be an IPv6 Hop-by-Hop option because routers
that have been enhanced to recognise this option are a
critical point where mandatory access controls are applied.
Because this option should never appear on the public
global Internet, and because the option is part of a scheme
for mandatory access controls, this option ought not create
a denial-of-service issue for routers in the global Internet.
Working Group Summary
This document is an individual submission, not the product
of an IETF working group.
The document has been reviewed extensively by implementers
at several different firms. It also has been reviewed by
users at multiple operational sites in multiple countries
and organisations.
IETF Last Call highlighted some controversies. The document
was Last Called for standards track, but is now being considered
for Informational status as a result of comments on the IETF
discussion list. Using a hop-by-hop suboption has also proven
controverial.
Document Quality
There are no implementations of this specification as documented,
but there is considerable implementation experience for the related
IPv4 RFCs. There is also a proprietary solution for IPv6 that has been
in deployment for several years. This document reflects the lessons
learned from deployment experience with these solutions.
This document is acceptable to the reviewers that have provided
input to the document. No concerns about clarity have been
received by the document editor or document shepherd. This
specification is much more detailed than the previous IPv4
label option specifications were. Some Last Call comments
indicated that additional background on Multi-Level Security (MLS)
was needed, but that information was deemed out of scope by the
editor and sponsoring AD.
Personnel
Randall Atkinson is the document shepherd, and is also
the active document editor.
Tim Polk is the sponsoring Area Director.
IESG Note
This RFC specifies the use of an IPv6 hop-by-hop option. The IESG
notes that general deployment of protocols with hop-by-hop options are
problematic, and the development of such protocols is consequently
discouraged. After careful review, the IETF has determined that a
hop-by-hop option is an appropriate solution for this specific limited
environment and use case. Furthermore, the mechanism specified in this
RFC is only applicable to closed IP networks. It is unsuitable for use
and ineffective on the global public Internet.