Skip to main content

Common Architecture Label IPv6 Security Option (CALIPSO)

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>
Subject: Document Action: 'Common Architecture Label IPv6 
         Security Option (CALIPSO)' to Informational RFC 

The IESG has approved the following document:

- 'Common Architecture Label IPv6 Security Option (CALIPSO) '
   <draft-stjohns-sipso-11.txt> as an Informational RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Tim Polk.

A URL of this Internet-Draft is:

Ballot Text

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

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.


  Randall Atkinson is the document shepherd, and is also
  the active document editor.
  Tim Polk is the sponsoring Area Director.


   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.

RFC Editor Note