Network Working Group M. StJohns
Request for Comments: 5570 Consultant
Category: Informational R. Atkinson
Extreme Networks
G. Thomas
US Department of Defense
July 2009
Network Working Group M. StJohns
Request for Comments: 5570 Consultant
Category: Informational R. Atkinson
Extreme Networks
G. Thomas
US Department of Defense
July 2009
Common Architecture Label IPv6 Security Option (CALIPSO)
通用体系结构标签IPv6安全选项（CALIPSO）
Abstract
摘要
This document describes an optional method for encoding explicit packet Sensitivity Labels on IPv6 packets. It is intended for use only within Multi-Level Secure (MLS) networking environments that are both trusted and trustworthy.
本文档描述了一种可选方法，用于对IPv6数据包上的显式数据包敏感标签进行编码。它仅适用于受信任和可信赖的多级安全（MLS）网络环境。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
IESG Note
IESG注释
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指定使用IPv6逐跳选项。IESG指出，采用逐跳选项的协议的一般部署存在问题，因此不鼓励开发此类协议。经过仔细审查，IETF已确定逐跳选项是适用于此特定有限环境和用例的适当解决方案。此外，本RFC中指定的机制仅适用于封闭的IP网络。它不适合在全球公共互联网上使用且无效。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. History ....................................................4
1.2. Intent and Applicability ...................................6
1.3. Deployment Examples ........................................7
2. Definitions .....................................................9
2.1. Domain of Interpretation ...................................9
2.2. Sensitivity Level .........................................10
2.3. Compartment ...............................................10
2.4. Releasability .............................................11
2.5. Sensitivity Label .........................................16
2.6. Import ....................................................17
2.7. Export ....................................................17
2.8. End System ................................................18
2.9. Intermediate System .......................................18
2.10. System Security Policy ...................................19
3. Architecture ...................................................19
4. Defaults .......................................................24
5. Format .........................................................26
5.1. Option Format .............................................27
5.2. Packet Word Alignment Considerations ......................30
6. Usage ..........................................................31
6.1. Sensitivity Label Comparisons .............................31
6.2. End System Processing .....................................34
6.3. Intermediate System Processing ............................37
6.4. Translation ...............................................40
7. Architectural and Implementation Considerations ................41
7.1. Intermediate Systems ......................................42
7.2. End Systems ...............................................43
7.3. Upper-Layer Protocols .....................................43
8. Security Considerations ........................................46
9. IANA Considerations ............................................48
9.1. IP Option Number ..........................................48
9.2. CALIPSO DOI Values Registry ...............................49
10. Acknowledgments ...............................................50
11. References ....................................................50
11.1. Normative References .....................................50
11.2. Informative References ...................................50
1. Introduction ....................................................4
1.1. History ....................................................4
1.2. Intent and Applicability ...................................6
1.3. Deployment Examples ........................................7
2. Definitions .....................................................9
2.1. Domain of Interpretation ...................................9
2.2. Sensitivity Level .........................................10
2.3. Compartment ...............................................10
2.4. Releasability .............................................11
2.5. Sensitivity Label .........................................16
2.6. Import ....................................................17
2.7. Export ....................................................17
2.8. End System ................................................18
2.9. Intermediate System .......................................18
2.10. System Security Policy ...................................19
3. Architecture ...................................................19
4. Defaults .......................................................24
5. Format .........................................................26
5.1. Option Format .............................................27
5.2. Packet Word Alignment Considerations ......................30
6. Usage ..........................................................31
6.1. Sensitivity Label Comparisons .............................31
6.2. End System Processing .....................................34
6.3. Intermediate System Processing ............................37
6.4. Translation ...............................................40
7. Architectural and Implementation Considerations ................41
7.1. Intermediate Systems ......................................42
7.2. End Systems ...............................................43
7.3. Upper-Layer Protocols .....................................43
8. Security Considerations ........................................46
9. IANA Considerations ............................................48
9.1. IP Option Number ..........................................48
9.2. CALIPSO DOI Values Registry ...............................49
10. Acknowledgments ...............................................50
11. References ....................................................50
11.1. Normative References .....................................50
11.2. Informative References ...................................50
The original IPv4 specification in RFC 791 includes an option for labeling the sensitivity of IP packets. That option was revised by RFC 1038 and later by RFC 1108 [RFC791] [RFC1038] [RFC1108]. Although the IETF later deprecated RFC 1108, that IPv4 option continues to be in active use within a number of closed Multi-Level Secure (MLS) IP networks.
RFC 791中的原始IPv4规范包括一个用于标记IP数据包敏感度的选项。该选项由RFC 1038修订，随后由RFC 1108[RFC791][RFC1038][RFC1108]修订。尽管IETF后来反对RFC1108，但该IPv4选项仍在许多封闭的多级安全（MLS）IP网络中积极使用。
One or another IP Sensitivity Label option has been in limited deployment for about two decades, most usually in governmental or military internal networks. There are also some commercial sector deployments, where corporate security policies require Mandatory Access Controls be applied to sensitive data. Some banks use MLS technology to restrict sensitive information, for example information about mergers and acquisitions. This IPv6 option, like its IPv4 predecessors, is only intended for deployment within private internetworks, disconnected from the global Internet. This document specifies the explicit packet labeling extensions for IPv6 packets.
一个或另一个IP敏感标签选项在大约二十年的时间里一直处于有限的部署中，大多数情况下是在政府或军事内部网络中。还有一些商业部门部署，公司安全策略要求对敏感数据应用强制性访问控制。一些银行使用MLS技术限制敏感信息，例如有关并购的信息。与IPv4的前身一样，此IPv6选项仅用于在与全球互联网断开连接的专用互联网内部署。本文档指定了IPv6数据包的显式数据包标签扩展。
This document is a direct descendent of RFC 1038 and RFC 1108 and is a close cousin to the work done in the Commercial IP Security Option (CIPSO) Working Group of the Trusted Systems Interoperability Group (TSIG) [FIPS-188]. The IP Security Option defined by RFC 1038 was designed with one specific purpose in mind: to support the fielding of an IPv4 packet-encryption device called a BLACKER [RFC1038]. Because of this, the definitions and assumptions in those documents were necessarily focused on the US Department of Defense and the BLACKER device. Today, IP packet Sensitivity Labeling is most commonly deployed within Multi-Level Secure (MLS) environments, often composed of Compartmented Mode Workstations (CMWs) connected via a Local Area Network (LAN). So the mechanism defined here is accordingly more general than either RFC 1038 or RFC 1108 were.
本文件是RFC 1038和RFC 1108的直接后代，与可信系统互操作性小组（TSIG）的商业IP安全选项（CIPSO）工作组的工作密切相关[FIPS-188]。RFC1038定义的IP安全选项的设计有一个特定目的：支持部署名为BLACKER[RFC1038]的IPv4数据包加密设备。正因为如此，这些文件中的定义和假设必然集中在美国国防部和BLACKER装置上。如今，IP数据包敏感标签最常用于多层安全（MLS）环境中，通常由通过局域网（LAN）连接的分区模式工作站（CMW）组成。因此，这里定义的机制相应地比RFC1038或RFC1108更一般。
Also, the deployment of Compartmented Mode Workstations ran into operational constraints caused by the limited, and relatively small, space available for IPv4 options. This caused one non-IETF specification for IPv4 packet labeling to have a large number of sub-options. A very unfortunate side effect of having sub-options within an IPv4 label option was that it became much more challenging to implement Intermediate System support for Mandatory Access Controls (e.g., in a router or MLS guard system) and still be able to forward traffic at, or near, wire-speed.
此外，由于IPv4选项可用空间有限且相对较小，分区模式工作站的部署遇到了操作限制。这导致IPv4数据包标签的一个非IETF规范具有大量子选项。在IPv4标签选项中具有子选项的一个非常不幸的副作用是，实现对强制访问控制的中间系统支持（例如，在路由器或MLS guard系统中）变得更具挑战性，并且仍然能够以或接近线速转发流量。
In the last decade or so, typical Ethernet link speeds have changed from 10 Mbps half-duplex to 1 Gbps full-duplex. The 10 Gbps full-duplex Ethernet standard is widely available today in routers, Ethernet switches, and even in some servers. The IEEE is actively developing standards for both 40 Gbps Ethernet and 100 Gbps Ethernet as of this writing. Forwarding at those speeds typically requires support from Application-Specific Integrated Circuits (ASICs); supporting more complex packet formats usually requires significantly more gates than supporting simpler packet formats. So the pressure to have a single simple option format has only increased in the past decade, and is only going to increase in the future.
在过去十年左右的时间里，典型的以太网链路速度已从10 Mbps半双工变为1 Gbps全双工。目前，10 Gbps全双工以太网标准广泛应用于路由器、以太网交换机，甚至某些服务器中。在撰写本文时，IEEE正在积极开发40 Gbps以太网和100 Gbps以太网的标准。以这些速度转发通常需要特定应用集成电路（ASIC）的支持；支持更复杂的数据包格式通常比支持更简单的数据包格式需要更多的门。因此，在过去十年中，单一简单期权格式的压力只会增加，未来也只会增加。
When IPv6 was initially being developed, it was anticipated that the availability of IP Security, in particular the Encapsulating Security Payload (ESP) and the IP Authentication Header (AH), would obviate the need for explicit packet Sensitivity Labels with IPv6 [RFC1825] [RFC4301] [RFC4302] [RFC4303]. For MLS IPv6 deployments where the use of AH or ESP is practical, the use of AH and/or ESP is recommended.
最初开发IPv6时，预计IP安全的可用性，特别是封装安全负载（ESP）和IP身份验证报头（AH），将消除使用IPv6[RFC1825][RFC4301][RFC4302][RFC4303]显式数据包敏感标签的需要。对于实际使用AH或ESP的MLS IPv6部署，建议使用AH和/或ESP。
However, some applications (e.g., distributed file systems), most often those not designed for use with Compartmented Mode Workstations or other Multi-Level Secure (MLS) computers, multiplex different transactions at different Sensitivity Levels and/or with different privileges over a single IP communications session (e.g., with the User Datagram Protocol). In order to maintain data Sensitivity Labeling for such applications, to be able to implement routing and Mandatory Access Control decisions in routers and guards on a per-IP-packet basis, and for other reasons, there is a need to have a mechanism for explicitly labeling the sensitivity information for each IPv6 packet.
但是，一些应用程序（例如，分布式文件系统），通常是那些不设计用于分隔模式工作站或其他多级安全（MLS）计算机的应用程序，在单个IP通信会话上以不同的敏感度和/或不同的权限多路传输不同的事务（例如，使用用户数据报协议）。为了维护此类应用程序的数据敏感度标签，为了能够在路由器和防护装置中基于每个IP数据包实施路由和强制访问控制决策，以及出于其他原因，需要有一种机制来明确标记每个IPv6数据包的敏感度信息。
Existing Layer 3 Virtual Private Network (VPN) technology can't solve the set of issues addressed by this specification, for several independent reasons. First, in a typical deployment, many labeled packets will flow from an MLS End System through some set of networks to a receiving MLS End System. The received per-packet label is used by the receiving MLS End System to determine which Sensitivity Label to associate with the user data carried in the packet. Existing Layer 3 VPN specifications do not specify any mechanism to carry a Sensitivity Label. Second, existing Layer 3 VPN technologies are not implemented in any MLS End Systems, nor in typical single-level End System operating systems, but instead typically are only implemented in routers. Adding a Layer 3 VPN implementation to the networking stack of an MLS End System would be a great deal more work than adding this IPv6 option to that same MLS End System. Third, existing Layer 3 VPN specifications do not support the use of Sensitivity Labels to select a VPN to use in carrying a packet, which function is
由于几个独立的原因，现有的第3层虚拟专用网（VPN）技术无法解决本规范所解决的一系列问题。首先，在典型部署中，许多标记的数据包将从MLS端系统通过一组网络流向接收MLS端系统。接收MLS终端系统使用接收到的每个分组标签来确定哪个灵敏度标签与分组中携带的用户数据相关联。现有的第3层VPN规范没有指定任何携带敏感标签的机制。其次，现有的第3层VPN技术没有在任何MLS终端系统中实现，也没有在典型的单级终端系统操作系统中实现，而是通常仅在路由器中实现。将第3层VPN实现添加到MLS端系统的网络堆栈将比将此IPv6选项添加到同一个MLS端系统要多得多。第三，现有的第3层VPN规范不支持使用敏感标签来选择用于承载数据包的VPN，该功能是
essential if one wanted to obviate this IPv6 option. Substantial new standards development, along with significant new implementation work in End Systems, would be required before a Layer 3 VPN approach to these issues could be used. Developing such specifications, and then implementing them in MLS systems, would need substantially greater effort than simply implementing this IPv6 label option in an MLS End System (or in a label-aware router). Further, both the MLS user community and the MLS implementer community prefer the approach defined in this specification.
如果要避免此IPv6选项，则必须使用此选项。在使用第3层VPN方法解决这些问题之前，需要大量的新标准开发，以及终端系统中重要的新实施工作。开发这样的规范，然后在MLS系统中实现，将需要比在MLS终端系统（或标签感知路由器）中简单实现此IPv6标签选项更大的努力。此外，MLS用户社区和MLS实现者社区都喜欢本规范中定义的方法。
Nothing in this document applies to any system that does not claim to implement this document.
本文件中的任何内容均不适用于未声明实施本文件的任何系统。
This document describes a generic way of labeling IPv6 datagrams to reflect their particular sensitivity. Provision is made for separating data based on domain of interpretation (e.g., an agency, a country, an alliance, or a coalition), the relative sensitivity (i.e., Sensitivity Levels), and need-to-know or formal access programs (i.e., compartments or categories).
本文档描述了一种标记IPv6数据报的通用方法，以反映其特定的敏感性。根据解释领域（例如，一个机构、一个国家、一个联盟或一个联盟）、相对敏感度（即敏感度水平）和需要了解或正式访问计划（即分区或类别）对数据进行分离。
A commonly used method of encoding Releasabilities as if they were Compartments is also described. This usage does not have precisely the same semantics as some formal Releasability policies, but existing Multi-Level Secure operating systems do not contain operating system support for Releasabilities as a separate concept from compartments. The semantics for this sort of Releasability encoding is close to the formal policies and has been deployed by a number of different organizations for at least a decade now.
还描述了一种将可释放性编码为分区的常用方法。这种用法与一些正式的可发布性策略的语义并不完全相同，但现有的多级安全操作系统不包含操作系统对可发布性的支持，这是一个独立于分区的概念。这种可发布性编码的语义接近于正式的策略，并且已经被许多不同的组织部署了至少十年。
In particular, the authors believe that this mechanism is suitable for deployment in United Nations (UN) peace-keeping operations, in North Atlantic Treaty Organisation (NATO) or other coalition operations, in all current US Government MLS environments, and for deployment in other similar commercial or governmental environments. This option would not normally ever be visible in an IP packet on the global public Internet.
特别是，作者认为，该机制适合部署在联合国（UN）维持和平行动、北大西洋公约组织（北约）或其他联盟行动、所有当前美国政府MLS环境中，以及其他类似商业或政府环境中。此选项通常不会在全球公共互联网上的IP数据包中可见。
Because of the unusually severe adverse consequences (e.g., loss of life, loss of very large sums of money) likely if a packet labeled with this IPv6 Option were to escape onto the global public Internet, organizations deploying this mechanism have unusually strong incentives to configure security controls to prevent labeled packets from ever appearing on the global public Internet. Indeed, a primary purpose of this mechanism is to enable deployment of Mandatory Access Controls for IPv6 packets.
由于如果标记有此IPv6选项的数据包逃逸到全球公共互联网上，可能会产生异常严重的不良后果（例如，生命损失、巨额金钱损失），部署此机制的组织有异常强烈的动机来配置安全控制，以防止标记的数据包出现在全球公共互联网上。实际上，此机制的主要目的是为IPv6数据包部署强制访问控制。
However, to ensure interoperability of both End Systems and Intermediate Systems within such a labeled deployment of IPv6, it is essential to have an open specification for this option.
然而，为了确保在这种标记的IPv6部署中终端系统和中间系统的互操作性，必须为该选项制定一个开放的规范。
This option is NOT designed to be an all-purpose label option and specifically does not include support for generic Domain Type Enforcement (DTE) mechanisms. If such a DTE label option is desired, it ought to be separately specified and have its own (i.e., different) IPv6 option number.
此选项并非设计为通用标签选项，特别是不支持通用域类型强制（DTE）机制。如果需要这样的DTE标签选项，则应单独指定该选项，并具有自己的（即不同的）IPv6选项号。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Two deployment scenarios for IP packet Sensitivity Labels are most common. We should first note that in typical deployments, all people having access to an unencrypted link are cleared for all unencrypted information traversing that link. Also, MLS system administrators normally have previously been cleared to see all of the information processed or stored by that MLS system. This specification does not seek to eliminate all potential covert channels relating to this IPv6 option.
IP数据包敏感标签的两种部署方案最常见。我们应该首先注意，在典型的部署中，所有能够访问未加密链接的人都会被清除，以获取通过该链接的所有未加密信息。此外，MLS系统管理员通常已被清除，以查看该MLS系统处理或存储的所有信息。本规范并不寻求消除与此IPv6选项相关的所有潜在隐蔽通道。
In the first scenario, all the connected nodes in a given private internetwork are trusted systems that have Multi-Level Secure (MLS) operating systems, such as Compartmented Mode Workstations (CMWs), that support per-packet Sensitivity Labels [TCSEC] [TNI] [CMW] [MLOSPP]. In this type of deployment, all IP packets carried within the private internetwork are labeled, the IP routers apply mandatory access controls (MAC) based on the packet labels and the sensitivity ranges configured into the routers, all End Systems include packet Sensitivity Labels in each originated packet, and all End Systems apply Mandatory Access Controls to each received packet. Packets received by a router or End System that have a Sensitivity Label outside the permitted range for the receiving interface (or, in the case of a router, outside the permitted range for either the incoming or the outgoing interface) are dropped because they violate the MAC policy.
在第一个场景中，给定专用互联网中的所有连接节点都是具有多级安全（MLS）操作系统的受信任系统，例如支持每包敏感标签[TCSEC][TNI][CMW][MLOSPP]的分区模式工作站（CMW）。在这种类型的部署中，专用互联网内携带的所有IP数据包都被标记，IP路由器根据数据包标签和路由器中配置的敏感度范围应用强制访问控制（MAC），所有终端系统在每个原始数据包中包括数据包敏感度标签，所有终端系统都对每个接收到的数据包应用强制访问控制。如果路由器或终端系统接收的数据包的敏感度标签超出了接收接口的允许范围（或者，对于路由器，超出了传入或传出接口的允许范围），则会丢弃这些数据包，因为它们违反了MAC策略。
The second scenario is a variation of the first, where End Systems with non-MLS operating systems are present on certain subnetworks of the private internetwork. By definition, these non-MLS End Systems operate in "system high" mode. In "system high" mode, all information on the system is considered to have the sensitivity of the most sensitive data on the system. If a system happens to contain data only at one Sensitivity Level, this would also be an
第二个场景是第一个场景的变体，其中带有非MLS操作系统的终端系统出现在专用互联网的某些子网上。根据定义，这些非MLS终端系统在“系统高”模式下运行。在“系统高”模式下，系统上的所有信息被视为具有系统上最敏感数据的灵敏度。如果一个系统碰巧只包含一个敏感度级别的数据，这也将是一个错误
example of "system high" operation. In this scenario, each subnetwork that contains any single-level End Systems has one single "default" Sensitivity Label that applies to all single-level systems on that IP subnetwork. Because those non-MLS End Systems are unable to create packets containing Sensitivity Labels and are also unable to apply MAC enforcement on received packets, security gateways (which might, for example, be label-aware IP routers) connected to such subnetworks need to insert sensitivity labels to packets originated by the "system high" End Systems that are to be forwarded off subnet. While the CALIPSO IPv6 option is marked as "ignore if unrecognized", there are some deployed IPv6 End Systems with bugs. Users can't fix these operating system bugs; some users need to be able to integrate their existing IPv6 single-level End Systems to have a useful overall MLS deployment. So, for packets destined for IP subnetworks containing single-level End Systems, those last-hop security gateways also apply Mandatory Access Controls (MAC) and then either drop (if the packet is not permitted on that destination subnet) exclusive-or remove Sensitivity Labels and forward packets onto those "system high" subnetworks (if the packet is permitted on that destination subnetwork).
“系统高”操作示例。在这种情况下，包含任何单级终端系统的每个子网都有一个“默认”灵敏度标签，适用于该IP子网上的所有单级系统。由于这些非MLS终端系统无法创建包含敏感标签的数据包，也无法对接收到的数据包应用MAC强制，因此连接到此类子网的安全网关（例如，可能是标签感知IP路由器）需要将敏感标签插入“系统高”发起的数据包要转发到子网之外的终端系统。虽然CALIPSO IPv6选项标记为“如果无法识别，则忽略”，但有些已部署的IPv6终端系统存在漏洞。用户无法修复这些操作系统错误；一些用户需要能够集成其现有的IPv6单级终端系统，以便进行有用的总体MLS部署。因此，对于发送到包含单级终端系统的IP子网的数据包，这些最后一跳安全网关也应用强制访问控制（MAC），然后要么丢弃（如果目标子网不允许该数据包），要么移除敏感标签，并将数据包转发到这些“系统高”子网（如果目标子网上允许该数据包）。
The authors are not aware of any existing MLS network deployments that use a commercial Network Address Translation (NAT), Network Address and Port Translation (NAPT), or any other commercial "middlebox" device. For example, NAT boxes aren't used, unlike practices in some segments of the public Internet.
作者不知道任何现有的MLS网络部署使用商业网络地址转换（NAT）、网络地址和端口转换（NAPT）或任何其他商业“中间盒”设备。例如，NAT盒不被使用，这与公共互联网某些部分的做法不同。
Similarly, the authors are not aware of any existing MLS network deployments that use a commercial firewall. MLS networks normally are both physically and electronically isolated from the global Internet, so operators of MLS networks are not concerned about external penetration (e.g., by worms, viruses, or the like). Similarly, all users of the MLS network have been cleared using some process specific to that organization, and hence are believe to be trustworthy. In a typical deployment, all computers connected to the MLS network are in a physically secure room or building (e.g., protected by guards with guns). Electronic equipment that enters such a space typically does not leave. Items such as USB memory sticks are generally not permitted; in fact, often the USB ports on MLS computers have been removed or otherwise made inoperable to prevent people from adding or removing information.
同样，作者不知道任何现有的使用商业防火墙的MLS网络部署。MLS网络通常在物理上和电子上与全球互联网隔离，因此MLS网络的运营商不担心外部渗透（例如蠕虫、病毒等）。类似地，MLS网络的所有用户都已通过特定于该组织的某些流程获得许可，因此被认为是可信的。在典型部署中，连接到MLS网络的所有计算机都位于物理安全的房间或建筑物中（例如，由持枪警卫保护）。进入这种空间的电子设备通常不会离开。一般不允许使用USB记忆棒等物品；事实上，MLS计算机上的USB端口通常已被移除或无法操作，以防止人们添加或移除信息。
Also, for security reasons, content transformation in the middle of an MLS network is widely considered undesirable, and so is not typically undertaken. Hypothetically, if such content transformation were undertaken, it would be performed by a certified MLS system that has been suitably accredited for that particular purpose in that particular deployment.
此外，出于安全原因，MLS网络中间的内容转换被普遍认为是不希望的，因此通常不进行。假设，如果进行了此类内容转换，则该转换将由经过认证的MLS系统执行，该系统已在该特定部署中针对该特定目的获得适当认证。
This section defines several terms that are important to understanding and correctly implementing this specification. Because of historical variations in terminology in different user communities, several terms have defined synonyms.
本节定义了对理解和正确实施本规范非常重要的几个术语。由于不同用户群体中术语的历史差异，有几个术语定义了同义词。
The verb "dominate" is used in this document to describe comparison of two Sensitivity Labels within a given Domain of Interpretation. Sensitivity Label A dominates Sensitivity Label B if the Sensitivity Level of A is greater than or equal to the Sensitivity Level of B AND the Compartment Set of A is a superset (proper or improper) of the Compartment Set of B. This term has been used in Multi-Level Secure circles with this meaning for at least two decades.
本文件中使用动词“支配”来描述给定解释范围内两个敏感度标签的比较。如果A的灵敏度水平大于或等于B的灵敏度水平，且A的隔室集是B的隔室集的超集（正确或不正确），则灵敏度标签A支配灵敏度标签B。该术语已在具有此含义的多级安全圈中使用至少二十年。
A Domain of Interpretation (DOI) is a shorthand way of identifying the use of a particular labeling, classification, and handling system with respect to data, the computers and people who process it, and the networks that carry it. The DOI policies, combined with a particular Sensitivity Label (which is defined to have meaning within that DOI) applied to a datum or collection of data, dictates which systems, and ultimately which persons may receive that data.
解释域（DOI）是识别特定标签、分类和处理系统对数据、处理数据的计算机和人员以及承载数据的网络的使用的一种简写方法。内政部政策与适用于数据或数据集合的特定敏感性标签（定义为在内政部内具有含义）相结合，规定了哪些系统，以及最终哪些人可以接收该数据。
In other words, a label of "SECRET" by itself is not meaningful; one also must know that the document or data belongs to some specific organization (e.g., US Department of Defense (DoD), US Department of Energy (DoE), UK Ministry of Defence (MoD), North Atlantic Treaty Organisation (NATO), United Nations (UN), a specific commercial firm) before one can decide on who is allowed to receive the data.
换言之，“秘密”的标签本身是没有意义的；还必须知道文件或数据属于某个特定组织（如美国国防部（DoD）、美国能源部（DoE）、英国国防部（MoD）、北大西洋公约组织（北约）、联合国（UN）、特定商业公司），然后才能决定允许谁接收数据。
A CALIPSO DOI is an opaque identifier that is used as a pointer to a particular set of policies, which define the Sensitivity Levels and Compartments present within the DOI, and by inference, to the "real-world" (e.g., used on paper documents) equivalent labels (See "Sensitivity Label" below). Registering or defining a set of real-world security policies as a CALIPSO DOI results in a standard way of labeling IP data originating from End Systems "accredited" or "approved" to operate within that DOI and the constraints of those security policies. For example, if one did this for the US Department of Defense, one would list all the acceptable labels such as "SECRET" and "TOP SECRET", and one would link the CALIPSO DOI to the [DoD5200.28] and [DoD5200.1-R] documents, which define how to mark and protect data with the US Department of Defense (DoD) [DoD5200.28] [DoD5200.1-R].
CALIPSO DOI是一种不透明标识符，用作指向一组特定策略的指针，这些策略定义了DOI中存在的敏感度级别和分区，并通过推断指向“真实世界”（例如，用于纸质文档）等效标签（见下文的“敏感度标签”）。将一组真实世界的安全策略注册或定义为CALIPSO DOI会导致以标准方式标记源于终端系统的IP数据，以“认证”或“批准”在该DOI内运行，以及这些安全策略的约束。例如，如果为美国国防部这样做，将列出所有可接受的标签，如“机密”和“绝密”，并将CALIPSO DOI链接到[DoD5200.28]和[DoD5200.1-R]文件，这些文件定义了如何与美国国防部（DoD）[DoD5200.28][DoD5200.1-R]标记和保护数据。
The scope of the DOI is dependent on the organization creating it. In some cases, the creator of the DOI might not be identical to a given user of the DOI. For example, a multi-national organization (e.g., NATO) might create a DOI, while a given member nation or organization (e.g., UK MoD) might be using that multi-national DOI (possibly along with other DOIs created by others) within its private networks. To provide a different example, the United States might establish a DOI with specific meanings, which correspond to the normal way it labels classified documents and which would apply primarily to the US DoD, but those specific meanings might also apply to other associated agencies. A company or other organization also might establish a DOI, which applies only to itself.
内政部的范围取决于创建它的组织。在某些情况下，DOI的创建者可能与给定的DOI用户不同。例如，一个多国组织（如北约）可能创建一个内政部，而一个给定的成员国或组织（如英国国防部）可能在其私有网络内使用该多国内政部（可能与其他人创建的其他内政部一起）。为了提供一个不同的例子，美国可能会建立一个具有特定含义的内政部，其对应于其标记机密文件的正常方式，主要适用于美国国防部，但这些特定含义也可能适用于其他相关机构。公司或其他组织也可以设立一个DOI，该DOI仅适用于其自身。
NOTE WELL: A CALIPSO Domain of Interpretation is different from, and is disjoint from, an Internet Security Association and Key Management Protocol (ISAKMP) / Internet Key Exchange (IKE) Domain of Interpretation. It is important not to confuse the two different concepts, even though the terms might superficially appear to be similar.
请注意：CALIPSO解释域与Internet安全关联和密钥管理协议（ISAKMP）/Internet密钥交换（IKE）解释域不同，并且不相交。重要的是不要混淆这两个不同的概念，即使这些术语表面上看起来很相似。
A Sensitivity Level represents a mandatory separation of data based on relative sensitivity. Sensitivity Levels ALWAYS have a specific ordering within a DOI. Clearance to access a specific level of data also implies access to all levels whose sensitivity is less than that level. For example, if the A, B, and C are levels, and A is more sensitive than B, which is in turn more sensitive than C (A > B > C), access to data at the B level implies access to C as well. As an example, common UK terms for a Sensitivity Level include (from low to high) "UNCLASSIFIED", "RESTRICTED", "CONFIDENTIAL", "SECRET", and "MOST SECRET".
灵敏度级别表示基于相对灵敏度的强制数据分离。敏感度级别在DOI中始终具有特定的顺序。允许访问特定级别的数据还意味着访问敏感度低于该级别的所有级别。例如，如果A、B和C是级别，并且A比B更敏感，而B又比C更敏感（A>B>C），那么在B级别访问数据也意味着访问C。例如，英国对敏感度级别的常用术语包括（从低到高）“未分类”、“受限”、“机密”、“机密”和“最机密”。
NOTE WELL: A Sensitivity Level is only one component of a Sensitivity Label. It is important not to confuse the two terms. The term "Sensitivity Level" has the same meaning as the term "Security Level".
注：灵敏度水平只是灵敏度标签的一个组成部分。重要的是不要混淆这两个术语。术语“敏感度水平”与术语“安全性水平”具有相同的含义。
A Compartment represents a mandatory segregation of data based on formal information categories, formal information compartments, or formal access programs for specific types of data. For example, a small startup company creates "FINANCE" and "R&D" compartments to protect data critical to its success -- only employees with a specific need to know (e.g., the accountants and controller for "FINANCE", specific engineers for "R&D") are given access to each compartment. Each Compartment is separate and distinct. Access to
分区表示基于正式信息类别、正式信息分区或特定类型数据的正式访问程序的强制数据隔离。例如，一家小型初创公司创建了“财务”和“研发”隔间，以保护对其成功至关重要的数据——只有特定需要了解的员工（例如，“财务”的会计和控制员、“研发”的特定工程师）才能访问每个隔间。每个隔间都是独立的。访问
one Compartment does not imply access to any other Compartment. Data may be protected in multiple compartments (e.g., "FINANCE" data about a new "R&D" project) at the same time, in which case access to ALL of those compartments is required to access the data. Employees only possessing clearance for a given Sensitivity Level (i.e., without having clearance for any specific compartments at that Sensitivity Level) do not have access to any data classified in any compartments (e.g., "SECRET FINANCE" dominates "SECRET").
一个隔间并不意味着可以进入任何其他隔间。数据可能同时在多个分区中受到保护（例如，关于新“研发”项目的“财务”数据），在这种情况下，访问数据需要访问所有这些分区。仅拥有给定敏感度级别许可的员工（即，没有该敏感度级别的任何特定隔间的许可）无权访问任何隔间中分类的任何数据（例如，“秘密金融”主导“秘密”）。
NOTE WELL: The term "category" has the same meaning as "compartment". Some user communities have used the term "category", while other user communities have used the term "compartment", but the terms have identical meaning.
注：术语“类别”与“隔间”的含义相同。一些用户社区使用了术语“类别”，而其他用户社区使用了术语“隔间”，但这些术语具有相同的含义。
A Releasability represents a mandatory segregation of data, based on a formal decision to release information to others.
可发布性表示基于向其他人发布信息的正式决定，强制隔离数据。
Historically, most MLS deployments handled Releasability as if it were an inverted Compartment. Strictly speaking, this provides slightly different semantics and behavior than a paper marked with the same Releasabilities would obtain, because the formal semantics of Compartments are different from the formal semantics of Releasability. The differences in behavior are discussed in more detail later in this sub-section.
从历史上看，大多数MLS部署都将可发布性当作一个倒置的隔间来处理。严格地说，这提供的语义和行为与标记有相同可发布性的文章略有不同，因为分区的形式语义不同于可发布性的形式语义。本小节后面将更详细地讨论行为上的差异。
In practice, for some years now some relatively large MLS deployments have been encoding Releasabilities as if they were inverted Compartments. The results have been tolerable and those deployments are generally considered successful by their respective user communities. This description is consistent with these MLS deployments, so has significant operational experience behind it.
在实践中，几年来，一些相对较大的MLS部署一直在编码可释放性，就好像它们是倒置的隔间一样。结果是可以接受的，这些部署通常被各自的用户社区认为是成功的。此描述与这些MLS部署一致，因此具有丰富的操作经验。
For example, two companies (ABC and XYZ) are engaging in a technical alliance. ABC labels all information present within its enterprise that is to be shared as part of the alliance as REL XYZ (e.g., COMPANY CONFIDENTIAL REL XYZ).
例如，两家公司（ABC和XYZ）正在进行技术联盟。ABC将其企业内所有作为联盟一部分共享的信息标记为REL XYZ（例如，公司机密REL XYZ）。
However, unlike the compartment example above, COMPANY CONFIDENTIAL dominates COMPANY CONFIDENTIAL REL XYZ. This means that XYZ employees granted a COMPANY CONFIDENTIAL REL XYZ clearance can only access releasable material, while ABC employees with a COMPANY CONFIDENTIAL clearance can access all information.
然而，与上面的隔间示例不同，公司机密在公司机密REL XYZ中占主导地位。这意味着，获得公司机密相对XYZ许可的XYZ员工只能访问可发布的材料，而获得公司机密许可的ABC员工可以访问所有信息。
If REL XYZ were managed as a compartment, then users granted a COMPANY CONFIDENTIAL REL XYZ clearance would have access to all of ABC's COMPANY CONFIDENTIAL material, which is undesirable.
如果将REL XYZ作为一个隔间进行管理，那么获得公司机密REL XYZ许可的用户将有权访问ABC公司的所有机密材料，这是不可取的。
Releasabilities can be combined (e.g., COMPANY CONFIDENTIAL REL XYZ/ABLE). In this case, users possessing a clearance of either COMPANY CONFIDENTIAL, COMPANY CONFIDENTIAL REL XYZ, COMPANY CONFIDENTIAL REL ABLE, or COMPANY CONFIDENTIAL REL XYZ/ABLE can access this information.
可发布性可以组合（例如，公司机密相关XYZ/ABLE）。在这种情况下，拥有公司机密、公司机密相关XYZ、公司机密相关表格或公司机密相关XYZ/表格许可的用户可以访问此信息。
Individual bits in this option's Compartment Bitmap field MAY be used to encode "releasability" information. The process for making this work properly is described below.
此选项隔间位图字段中的单个位可用于编码“可发布性”信息。使其正常工作的过程如下所述。
This scheme is carefully designed so that intermediate systems need not know whether a given bit in the Compartment Bitmap field represents a compartment or a Releasability. All that an Intermediate System needs to do is apply the usual comparison (described in Section 2.5.1 and 2.5.2) to determine whether or not a packet's label is in-range for an interface. This simplifies both the configuration and implementation of a label-aware Intermediate System.
该方案经过精心设计，因此中间系统不需要知道隔间位图字段中的给定位是表示隔间还是可发布性。中间系统需要做的只是应用通常的比较（如第2.5.1节和第2.5.2节所述），以确定数据包的标签是否在接口的范围内。这简化了标签感知中间系统的配置和实现。
Unlike bits that represent compartments, bits that represent a Releasability are "active low".
与表示隔室的位不同，表示可释放性的位是“低激活”。
If a given Releasability bit in the Compartment Bitmap field is "0", the information may be released to that community. If the compartment bit is "1", the information may not be released to that community.
如果隔间位图字段中的给定可发布位为“0”，则信息可能会发布到该社区。如果隔间位为“1”，则信息可能不会发布到该社区。
Only administrative interfaces used to present or construct binary labels in human-readable form need to understand the distinction between Releasability bits and non-Releasability bits. Implementers are encouraged to describe Releasability encoding in the documentation supplied to users of systems that implement this specification.
只有用于以人类可读的形式呈现或构造二进制标签的管理接口需要理解可发布位和不可发布位之间的区别。鼓励实现者在提供给实现本规范的系统用户的文档中描述可发布性编码。
For objects, such as IP packets, let bits 0-3 of the Compartment Bitmap field be dedicated to controlling Releasability to the communities A, B, C, and D, respectively.
对于对象，例如IP分组，让隔间位图字段的位0-3分别专用于控制社区A、B、C和D的可发布性。
Example 1: Not releasable to any community: This is usually how handling restrictions such as "No Foreigners (NO FORN)" are encoded. ABCD == 1111
示例1：不可发布到任何社区：这通常是处理诸如“无外国人（无FORN）”等限制的编码方式。ABCD==1111
Example 2: Releasable only to community A and community C:
ABCD == 0101
Example 2: Releasable only to community A and community C:
ABCD == 0101
Example 3: Releasable only to community B:
ABCD == 1011
Example 3: Releasable only to community B:
ABCD == 1011
Example 4: Releasable to communities A,B,C, & D:
ABCD == 0000
Example 4: Releasable to communities A,B,C, & D:
ABCD == 0000
For subjects, such as clearances of users, the same bit encodings are used for Releasabilities as are used for objects (see above).
对于主题（如用户许可），可发布性使用与对象相同的位编码（见上文）。
Example 1: Clearance not belonging to any community: This user can see information belonging to any Releasability community, since s/he is not in any Releasability community. ABCD = 1111
示例1：不属于任何社区的许可：该用户可以查看属于任何可发布社区的信息，因为他/她不在任何可发布社区中。ABCD=1111
Example 2: Clearance belonging to community A and C: This user can only see Releasable AC information, and cannot see Releasable A information. ABCD == 0101
示例2：属于社区A和社区C的许可：该用户只能看到可发布的AC信息，而不能看到可发布的A信息。ABCD==0101
Example 3: Clearance belonging to community B: This user can only see Releasable B information. ABCD == 1011
示例3：属于社区B的许可：此用户只能看到可发布的B信息。ABCD==1011
Example 4: Clearance belongs to communities A,B,C, and D: This user can only see Releasable ABCD information, and cannot (for example) see Releasable AB or Releasable BD information. ABCD == 0000
示例4：清除属于社区A、B、C和D：此用户只能看到可发布的ABCD信息，而不能（例如）看到可发布的AB或可发布的BD信息。ABCD==0000
Now we consider example comparisons for an IP router that is enforcing MAC by using CALIPSO labels on some interface:
现在我们考虑一个IP路由器的例子比较，它是通过在一些接口上使用CALIPSO标签来执行MAC的：
Let the MINIMUM label for that router interface be: CONFIDENTIAL RELEASABLE AC
让路由器接口的最小标签为：机密可发布AC
Therefore, this interface has a minimum Releasability of 0101.
因此，该接口的最小可发布性为0101。
Let the MAXIMUM label for that router interface be: TOP SECRET NOT RELEASABLE
让该路由器接口的最大标签为：绝密不可发布
Therefore, this interface has a maximum Releasability of 1111.
因此，该接口的最大可发布性为1111。
For the range comparisons, the bit values for the current packet need to be "greater than or equal to" the minimum value for the interface AND also the bit values for the current packet need to be "less than or equal to" the maximum value for the interface, just as with compartment comparisons. The inverted encoding scheme outlined above ensures that the proper results occur.
对于范围比较，当前数据包的位值需要“大于或等于”接口的最小值，并且当前数据包的位值也需要“小于或等于”接口的最大值，就像隔室比较一样。上面概述的反向编码方案确保产生正确的结果。
Consider a packet with label CONFIDENTIAL RELEASABLE AC: 1) Sensitivity Level comparison: (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET) so the Sensitivity Level is "within range" for that router interface. 2) Compartment bitmap comparison: The test is [(0101 >= 0101) AND (0101 <= 1111)], so the Compartment bitmap is "within range" for that router interface.
考虑一个带有标签机密可释放AC的包：1）灵敏度等级比较：（机密<＝机密>最高机密），因此该路由器接口的灵敏度水平在“范围内”。2） 隔间位图比较：测试为[（0101>=0101）和（0101<=1111）]，因此隔间位图在该路由器接口的“范围内”。
Consider a packet with label CONFIDENTIAL RELEASABLE ABCD: 1) Sensitivity Label comparison: (CONFIDENTIAL <= CONFIDENTIAL <= TOP SECRET) so the Sensitivity Level is "within range" for that router interface. 2) Compartment bitmap comparison: The test is [(0000 >= 0101) AND (0000 <= 1111)], so the Compartment Bitmap is NOT "within range" for that router interface.
考虑一个带有标签机密可释放ABCD：1）敏感标签比较：（机密<＝机密>最高机密），因此该路由器接口的灵敏度水平在“范围内”。2） 隔间位图比较：测试为[（0000>=0101）和（0000<=1111）]，因此隔间位图不在该路由器接口的“范围内”。
Consider a packet with label SECRET NOT RELEASABLE: 1) Sensitivity Label comparison: (CONFIDENTIAL <= SECRET <= TOP SECRET) so the Sensitivity Level is "within range" for that router interface. 2) Compartment bitmap comparison: The test is [(1111 >= 0101) AND (1111 <= 1111)], so the Compartment bitmap is "within range" for that router interface.
考虑一个带有标签秘密的包不能释放：1）敏感标签比较：（机密< =机密>最高机密），因此该路由器接口的灵敏度水平在“范围内”。2） 隔间位图比较：测试为[（1111>=0101）和（1111<=1111）]，因此隔间位图在该路由器接口的“范围内”。
For example, if one considers a person "Jane Doe" who is a member of two Releasability communities (A and also B), she is permitted to see a paper document that is marked "Releasable A", "Releasable B", or "Releasable AB" -- provided that her Clearance and Compartments are in-range for the Sensitivity Level and Compartments (respectively) of the paper document.
例如，如果一个人是“Jane Doe”，他是两个可发布社区（a和B）的成员，她被允许查看标记为“可发布a”、“可发布B”或“可发布AB”的纸质文档，前提是她的许可和隔间分别在敏感度和隔间的范围内这是一份纸质文件。
Now, let us consider an equivalent electronic example implemented and deployed as outlined above. In this, we consider two Releasability communities (A and B). Those bits will be set to 00 for the electronic user ID used by user "Jane Doe".
现在，让我们考虑一个等效的电子例子，如上所述实现和部署。在本文中，我们考虑两个可释放社区（A和B）。对于用户“Jane Doe”使用的电子用户ID，这些位将设置为00。
However, the electronic Releasability approach above will ONLY permit her to see information marked as "Releasable AB". The above electronic approach will deny her the ability to read documents marked "Releasable A" or "Releasable B". This is because "Releasable A" is encoded as "01", "Releasable B" is encoded as "10", while "Releasable AB" is encoded as "00". If one looks at the compartment dominance computation, "00" dominates "00", but "00" does NOT dominate "01", and "00" also does NOT dominate "10".
然而，上述电子可发布性方法仅允许她查看标记为“可发布AB”的信息。上述电子方式将使她无法阅读标有“可发布A”或“可发布B”的文件。这是因为“可释放A”编码为“01”，“可释放B”编码为“10”，而“可释放AB”编码为“00”。如果我们看一下舱室优势计算，“00”支配“00”，但“00”不支配“01”，“00”也不支配“10”。
Users report that the current situation is tolerable, but not ideal. Users also report that various operational complexities can arise from this approach.
用户报告说，目前的情况可以接受，但并不理想。用户还报告说，这种方法可能会导致各种操作复杂性。
Several deployments work around this limitation by assigning an electronic user several parallel clearances. Referring to the (fictitious) example above, the user "Jane Doe" might have one clearance without any Releasability, another separate clearance with Releasability A, and a third separate clearance with Releasability B. While this has implications (e.g., a need to be able to associate multiple separate parallel clearances with a single user ID) for implementers of MLS systems, this specification cannot (and does not) levy any requirements that an implementation be able to associate multiple clearances with each given user ID because that level of detail is beyond the scope of an IP labeling option.
一些部署通过为电子用户分配多个平行间隙来解决此限制。参考上面的（虚构的）示例，用户“Jane Doe”可能有一个没有任何可发布性的许可证，另一个单独的许可证具有可发布性A，第三个单独的许可证具有可发布性B。尽管这有影响（例如，需要能够将多个单独的平行许可证与单个用户ID关联）对于MLS系统的实施者，本规范不能（也不会）提出任何要求，要求实施者能够将多个许可与每个给定的用户ID相关联，因为该详细程度超出了IP标签选项的范围。
Separating the Releasability bits into a separate bitmap within the CALIPSO option was seriously considered. However, existing MLS implementations lack operating system support for Releasability. So even if CALIPSO had a separate bitmap field, those bits would have been mapped to Compartment bits by the sending/receiving nodes, so the operational results would not have been different than those described here.
在CALIPSO选项中将可发布性位分离为单独的位图是经过认真考虑的。然而，现有的MLS实现缺乏操作系统对可发布性的支持。因此，即使CALIPSO有一个单独的位图字段，这些位也会被发送/接收节点映射到隔间位，因此操作结果不会与这里描述的不同。
Several MLS network deployments connect MLS End Systems both to a labeled national network and also to a labeled coalition network simultaneously. Depending on whether the data is labeled according to national rules or according to coalition rules, the set of Releasability marks will vary. Some choices are likely to lead to more (or fewer) incorrect Releasability decisions (although the results of the above Releasability encodings are believed to be fail-safe).
多个MLS网络部署将MLS终端系统同时连接到标记的国家网络和标记的联盟网络。根据数据是根据国家规则还是根据联盟规则进行标记，可发布性标记集将有所不同。一些选择可能导致更多（或更少）错误的可发布性决策（尽管上述可发布性编码的结果被认为是故障安全的）。
A Sensitivity Label is a quadruple consisting of a DOI, a Sensitivity Level, a Compartment Set, and a Releasability Set. The Compartment Set may be the empty set if and only if no compartments apply. A Releasability Set may be the empty set if and only if no Releasabilities apply. A DOI used within an End System may be implicit or explicit depending on its use. CALIPSO Sensitivity Labels always have an explicit DOI. A CALIPSO Sensitivity Label consists of a Sensitivity Label in a particular format (defined below). A CALIPSO Sensitivity Label ALWAYS contains an explicit DOI value. In a CALIPSO Sensitivity Label, the Compartment Bitmap field is used to encode both the logical Compartment Set and also the logical Releasability Set.
灵敏度标签是由DOI、灵敏度等级、隔室集和可释放性集组成的四重标签。当且仅当无隔室适用时，隔室组可为空组。当且仅当不适用可发布性时，可发布性集可以是空集。终端系统中使用的DOI可能是隐式的，也可能是显式的，具体取决于其用途。CALIPSO灵敏度标签始终具有显式DOI。CALIPSO灵敏度标签由特定格式（定义见下文）的灵敏度标签组成。CALIPSO敏感度标签始终包含显式DOI值。在CALIPSO灵敏度标签中，隔间位图字段用于对逻辑隔间集和逻辑可发布性集进行编码。
End Systems using operating systems with MLS capabilities that also implement IPv6 normally will be able to include CALIPSO labels in packets they originate and will be able to enforce MAC policy on the CALIPSO labels in any packets they receive.
使用具有MLS功能且通常也实施IPv6的操作系统的终端系统将能够在其发起的数据包中包含CALIPSO标签，并且能够在其接收的任何数据包中对CALIPSO标签实施MAC策略。
End Systems using an operating system that lacks Multi-Level Secure capabilities operate in "system high" mode. This means that all data on the system is considered to have the Sensitivity Label of the most sensitive data on the system. Such a system normally is neither capable of including CALIPSO labels in packets that it originates nor of enforcing CALIPSO labels in packets that it receives.
使用缺乏多级安全功能的操作系统的终端系统在“系统高”模式下运行。这意味着系统上的所有数据都被视为具有系统上最敏感数据的敏感标签。这种系统通常既不能在其发起的数据包中包含CALIPSO标签，也不能在其接收的数据包中强制使用CALIPSO标签。
NOTE WELL: The term "Security Marking" has the same meaning as "Sensitivity Label".
注：术语“安全标记”与“敏感标签”的含义相同。
Two Sensitivity Labels (A and B) can be compared. Indeed, Sensitivity Labels exist primarily so they can be compared as part of a Mandatory Access Control decision. Comparison is critical to determining if a subject (a person, network, etc.) operating at one Sensitivity Label (A) should be allowed to access an object (file, packet, route, etc.) classified at another Sensitivity Label (B). The comparison of two labels (A and B) can return one (and only one) of the following results:
可以比较两个灵敏度标签（A和B）。事实上，敏感度标签的存在主要是为了将它们作为强制访问控制决策的一部分进行比较。比较对于确定在一个敏感度标签（a）处操作的受试者（个人、网络等）是否应允许访问在另一个敏感度标签（B）处分类的对象（文件、数据包、路由等）至关重要。比较两个标签（A和B）可以返回以下结果中的一个（且仅返回一个）：
1) A dominates B (e.g., A=SECRET, B=UNCLASSIFIED); A can read B,
1) A支配B（例如，A=秘密，B=未分类）；A可以读B，
2) B dominates A (e.g., A=UNCLASSIFIED, B=SECRET); A cannot access B,
2) B支配A（例如，A=未分类，B=秘密）；A无法访问B，
3) A equals B (e.g., A=SECRET, B=SECRET); A can read/write B,
3) A等于B（例如，A=秘密，B=秘密）；A可以读/写B，
exclusive-or
排他或
4) A is incomparable to B (e.g., A=SECRET R&D, B=SECRET FINANCE); A cannot access B, and also, B cannot access A.
4) A是B所无法比拟的（例如，A=秘密研发，B=秘密金融）；A不能访问B，B也不能访问A。
By definition, if A and B are members of different DOIs, the result of comparison is always incomparable. It is possible to overcome this if and only if A and/or B can be translated into some common DOI, such that the labels are then interpretable.
根据定义，如果A和B是不同DOI的成员，比较的结果总是不可比较的。当且仅当A和/或B可以翻译成一些公共DOI，这样标签就可以解释时，才有可能克服这个问题。
A range is a pair of Sensitivity Labels, which indicate both a minimum and a maximum acceptable Sensitivity Label for objects compared against it. A range is usually expressed as "<minimum> : <maximum>" and always has the property that the maximum Sensitivity Label dominates the minimum Sensitivity Label. In turn, this requires that the two Sensitivity Labels MUST be comparable.
一个范围是一对灵敏度标签，表示与之比较的对象的最小和最大可接受灵敏度标签。范围通常表示为“<minimum>：<maximum>”，并且始终具有最大灵敏度标签支配最小灵敏度标签的特性。反过来，这要求两个灵敏度标签必须具有可比性。
A range where <minimum> equals <maximum> may be expressed simply as "<minimum>"; in this case, the only acceptable Sensitivity Label is <minimum>.
<minimum>等于<maximum>的范围可以简单地表示为“<minimum>”；在这种情况下，唯一可接受的灵敏度标签是<最小值>。
The act of receiving a datagram and translating the CALIPSO Sensitivity Label of that packet into the appropriate internal (i.e., end-system-specific) Sensitivity Label.
接收数据报并将该数据包的CALIPSO灵敏度标签转换为适当的内部（即终端系统特定）灵敏度标签的行为。
The act of selecting an appropriate DOI for an outbound datagram, translating the internal (end-system-specific) label into an CALIPSO Sensitivity Label based on that DOI, and sending the datagram. The selection of the appropriate DOI may be based on many factors including, but not necessarily limited to:
为出站数据报选择适当的DOI，基于该DOI将内部（终端系统特定）标签转换为CALIPSO敏感标签，并发送数据报的行为。适当DOI的选择可能基于许多因素，包括但不一定限于：
Source Port Destination Port Transport Protocol Application Protocol Application Information End System Subnetwork Network Sending Interface System Implicit/Default DOI
源端口目标端口传输协议应用协议应用信息终端系统子网网络发送接口系统隐式/默认DOI
Regardless of the DOI selected, the Sensitivity Label of the outbound datagram must be consistent with the security policy monitor of the originating system and also with the DOI definition used by all other devices cognizant of that DOI.
无论选择哪个DOI，出站数据报的敏感度标签必须与发起系统的安全策略监视器一致，并且与所有其他识别该DOI的设备使用的DOI定义一致。
An End System is a host or router from which a datagram originates or to which a datagram is ultimately delivered.
终端系统是一台主机或路由器，数据报从该主机或路由器发出，或数据报最终传送到该主机或路由器。
The IPv6 community has defined the term Node to include both Intermediate Systems and End Systems [RFC2460].
IPv6社区已将术语节点定义为包括中间系统和终端系统[RFC2460]。
An Intermediate System (IS) is a node that receives and transmits a particular datagram without being either the source or destination of that datagram. An Intermediate System might also be called a "gateway", "guard", or "router" in some user communities.
中间系统（IS）是接收和发送特定数据报的节点，而不是该数据报的源或目标。在某些用户社区中，中间系统也可以称为“网关”、“守卫”或“路由器”。
So an IPv6 router is one example of an Intermediate System. A firewall or security guard device that applies security policies and forwards IPv6 packets that comply with those security policies is another example of an Intermediate System.
所以IPv6路由器就是中间系统的一个例子。应用安全策略并转发符合这些安全策略的IPv6数据包的防火墙或安全防护设备是中间系统的另一个示例。
An Intermediate System may handle ("forward") a datagram destined for some other node without necessarily importing or exporting the datagram to/from itself.
中间系统可以处理（“转发”）目的地为某个其他节点的数据报，而不必向自身导入或导出数据报。
NOTE WELL: Any given system can be both an End System and an Intermediate System -- which role the system assumes at any given time depends on the address(es) of the datagram being considered and the address(es) associated with that system.
请注意：任何给定的系统都可以是终端系统和中间系统——系统在任何给定时间所扮演的角色取决于所考虑的数据报的地址以及与该系统关联的地址。
A System Security Policy (SSP) consists of a Sensitivity Label and the organizational security policies associated with content labeled with a given security policy. The SSP acts as a bridge between how the organization's Mandatory Access Control (MAC) policy is stated and managed and how the network implements that policy. Typically, the SSP is a document created by the Information Systems Security Officer (ISSO) of the site or organization covered by that SSP.
系统安全策略（SSP）由敏感度标签和与使用给定安全策略标记的内容相关联的组织安全策略组成。SSP在组织的强制访问控制（MAC）策略的制定和管理以及网络如何实施该策略之间起着桥梁作用。通常，SSP是由该SSP覆盖的站点或组织的信息系统安全官员（ISSO）创建的文件。
This document describes a convention for labeling an IPv6 datagram within a particular system security policy. The labels are designed for use within a Mandatory Access Control (MAC) system. A real-world example is the security classification system in use within the UK Government. Some data held by the government is "classified", and is therefore restricted by law to those people who have the appropriate "clearances".
本文档描述了在特定系统安全策略中标记IPv6数据报的约定。标签设计用于强制访问控制（MAC）系统。一个真实的例子是英国政府内部使用的安全分类系统。政府持有的一些数据是“机密”的，因此，法律将其限制为拥有适当“许可”的人。
Commercial examples of information labeling schemes also exist [CW87]. For example, one global electrical equipment company has a formal security policy that defines six different Sensitivity Levels for its internal data, ranging from "Class 1" to "Class 6" information. Some financial institutions use multiple compartments to restrict access to certain information (e.g., "mergers and acquisitions", "trading") to those working directly on those projects and to deny access to other groups within the company (e.g., equity trading). A CALIPSO Sensitivity Label is the network instantiation of a particular information security policy, and the policy's related labels, classifications, compartments, and Releasabilities.
信息标签方案的商业示例也存在[CW87]。例如，一家全球电气设备公司有一个正式的安全政策，为其内部数据定义了六种不同的敏感度级别，从“1级”到“6级”信息。一些金融机构使用多个部门限制直接从事这些项目的人员访问某些信息（如“并购”、“交易”），并拒绝访问公司内的其他群体（如股权交易）。CALIPSO敏感标签是特定信息安全策略的网络实例，以及该策略的相关标签、分类、分区和可发布性。
Some years ago, the Mandatory Access Control (MAC) policy for US Government classified information was specified formally in mathematical notation [BL73]. As it happens, many other organizations or governments have the same basic Mandatory Access Control (MAC) policy for information with differing ("vertical") Sensitivity Levels. This document builds upon the formal definitions of Bell-LaPadula [BL73]. There are two basic principles: "no write down" and "no read up".
几年前，美国政府机密信息的强制访问控制（MAC）政策在数学符号[BL73]中正式规定。事实上，许多其他组织或政府对不同（“垂直”）敏感度级别的信息都有相同的基本强制访问控制（MAC）策略。本文件以Bell LaPadula[BL73]的正式定义为基础。有两个基本原则：“不写”和“不读”。
The first rule means that an entity having minimum Sensitivity Level X must not be able to write information that is marked with a Sensitivity Level below X. The second rule means that an entity having maximum Sensitivity Level X must not be able to read information having a Sensitivity Level above X. In a normal deployment, information downgrading ("write down") must not occur automatically, and is permitted if and only if a person with
第一条规则意味着具有最低灵敏度级别X的实体不能写入灵敏度级别低于X的信息。第二条规则意味着具有最高灵敏度级别X的实体不能读取灵敏度级别高于X的信息。在正常部署中，信息降级（“减记”）不得自动发生，且仅当
appropriate "downgrade" privilege manually verifies the information is permitted to be downgraded before s/he manually relabels (i.e., "downgrades") the information. Subsequent to the original work by Bell and LaPadula in this area, this formal model was extended to also support ("horizontal") Compartments of information.
适当的“降级”权限在s/he手动重新标记（即“降级”）信息之前，手动验证允许降级的信息。继贝尔和拉帕杜拉在这一领域的原始工作之后，这个正式模型也被扩展到支持信息的（“水平”）隔间。
This document extends Bell-LaPadula to accommodate the notion of separate Domains of Interpretation (DOI) [BL73]. Each DOI constitutes a single comparable domain of Sensitivity Labels as stated by Bell-LaPadula. Sensitivity Labels from different domains cannot be directly compared using Bell-LaPadula semantics.
本文件扩展了Bell-LaPadula，以适应不同解释领域（DOI）的概念[BL73]。如Bell LaPadula所述，每个DOI构成一个单一的可比较敏感度标签域。使用Bell-LaPadula语义无法直接比较来自不同领域的敏感度标签。
This document is focused on providing specifications for (1) encoding Sensitivity Labels in packets, and (2) how such Sensitivity Labels are to be interpreted and enforced at the IP layer. This document recognizes that there are several kinds of application processing that occur above the IP layer that significantly impact end-to-end system security policy enforcement, but are out of scope for this document. In particular, how the network labeling policy is enforced within processing in an End System is critical, but is beyond the scope of a network (IP) layer Sensitivity Label encoding standard. Other specifications exist, which discuss such details [TCSEC] [TNI] [CMW] [ISO-15408] [CC] [MLOSPP].
本文档的重点是提供（1）在数据包中编码敏感标签的规范，以及（2）如何在IP层解释和实施此类敏感标签的规范。本文档认识到，IP层上发生的几种应用程序处理会对端到端系统安全策略的实施产生重大影响，但超出了本文档的范围。特别是，如何在终端系统中的处理中实施网络标签策略至关重要，但超出了网络（IP）层敏感标签编码标准的范围。还有其他规范讨论了此类细节[TCSEC][TNI][CMW][ISO-15408][CC][MLOSPP]。
This specification does not preclude an End System capable of providing labeled packets across some range of Sensitivity Labels. A Compartmented Mode Workstation (CMW) is an example of such an End System [CMW]. This is useful if the End System is capable of, and accredited to, separate processing across some range of Sensitivity Labels. Such a node would have a range associated with it within the network interface connecting the node to the network. As an example, an End System has the range "SECRET: TOP SECRET" associated with it in the Intermediate System to which the node is attached. SECRET processing on the node is allowed to traverse the network to other "SECRET : SECRET" segments of the network, ultimately to a "SECRET : SECRET" node. Likewise, TOP SECRET processing on the node is allowed to traverse a network through "TOP SECRET: TOP SECRET" segments, ultimately to some "TOP SECRET: TOP SECRET" node. The node in this case can allow a user on this node to access SECRET and TOP SECRET resources, provided the user holds the appropriate clearances and has been correctly configured.
本规范不排除终端系统能够提供一些灵敏度标签范围内的标签数据包。分隔式工作站（CMW）就是这种终端系统[CMW]的一个例子。如果终端系统能够并认可在某些灵敏度标签范围内进行单独处理，则此功能非常有用。这样的节点将在连接节点到网络的网络接口内具有与其相关联的范围。例如，终端系统在节点所连接的中间系统中具有与其关联的范围“SECRET:TOP SECRET”。允许节点上的秘密处理穿过网络到达网络的其他“SECRET:SECRET”段，最终到达“SECRET:SECRET”节点。同样，允许节点上的绝密处理通过“绝密：绝密”段穿越网络，最终到达某个“绝密：绝密”节点。本例中的节点可以允许该节点上的用户访问机密和绝密资源，前提是该用户持有适当的许可证并已正确配置。
With respect to a given network, each distinct Sensitivity Label represents a separate virtual network, which shares the same physical network. There are rules for moving information between the various virtual networks. The model we use within this document is based on
对于给定的网络，每个不同的敏感度标签表示一个单独的虚拟网络，该虚拟网络共享相同的物理网络。在各种虚拟网络之间移动信息有一些规则。我们在本文档中使用的模型基于
the Bell-LaPadula model, but is extended to cover the concept of differing Domains of Interpretation. Nodes that implement this protocol MUST enforce this mandatory separation of data.
Bell-LaPadula模型，但扩展到涵盖不同解释领域的概念。实现此协议的节点必须强制执行此强制数据分离。
CALIPSO provides for both horizontal ("Compartment") and vertical ("Sensitivity Level") separation of information, as well as separation based on DOI. The basic rule is that data MUST NOT be delivered to a user or system that is not approved to receive it.
CALIPSO提供了信息的水平（“隔室”）和垂直（“敏感度级别”）分离，以及基于DOI的分离。基本规则是，不得将数据交付给未经批准接收数据的用户或系统。
NOTE WELL: Wherever we say "not approved", we also mean "not cleared", "not certified", and/or "not accredited" as applicable in one's operational community.
注：无论我们说“未批准”，我们也指“未批准”、“未认证”和/或“未认证”，适用于运营社区。
This specification does not enable AUTOMATIC relabeling of information, within a DOI or to a different DOI. That is, neither automatic "upgrading" nor automatic "downgrading" of information are enabled by this specification. Local security policies might allow some limited downgrading, but this normally requires the intervention of some human entity and is usually done within an End System with respect to the internal Sensitivity Label, rather than on a network or in an intermediate-system (e.g., router, guard). Automatic downgrading is not suggested operational practice; further discussion of downgrading is outside the scope of this protocol specification.
本规范不允许在DOI内或向不同DOI自动重新标记信息。也就是说，此规范既不启用信息的自动“升级”，也不启用信息的自动“降级”。本地安全策略可能允许一些有限的降级，但这通常需要一些人的实体的干预，并且通常在终端系统内就内部敏感度标签进行，而不是在网络或中间系统（例如路由器、警卫）上进行。操作实践中不建议自动降级；降级的进一步讨论不在本协议规范的范围内。
Implementers of this specification MUST NOT permit automatic upgrading or downgrading of information in the default configuration of their implementation. Implementers MAY add a configuration knob that would permit a System Security Officer holding appropriate privilege to enable automatic upgrading or downgrading of information. If an implementation supports such a knob, the existence of the configuration knob must be clearly documented and the default knob setting MUST be that automatic upgrading or downgrading is DISABLED. Automatic information upgrading and downgrading is not recommended operational practice.
本规范的实现者不得允许在其实现的默认配置中自动升级或降级信息。实施者可以添加一个配置旋钮，允许持有适当权限的系统安全官员自动升级或降级信息。如果实施支持此类旋钮，则必须清楚记录配置旋钮的存在，并且默认旋钮设置必须为禁用自动升级或降级。不建议在操作实践中自动升级和降级信息。
Many existing MLS deployments already use (and operationally need to use) more than one DOI concurrently. User feedback from early versions of this specification indicates that it is common at present for a single network link (i.e., IP subnetwork) to carry traffic for both a particular coalition (or joint-venture) activity and also for the government (or other organization) that owns and operates that particular network link. On such a link, one CALIPSO DOI would typically be used for the coalition traffic and some different CALIPSO DOI would typically be used for non-coalition traffic (i.e., traffic that is specific to the government that owns and operates that particular network link). For example, a UK military network that is part of a NATO deployment might have and use a UK MoD DOI for
许多现有MLS部署已经同时使用（并且在操作上需要使用）多个DOI。本规范早期版本的用户反馈表明，目前单个网络链路（即IP子网）承载特定联盟（或合资企业）活动以及拥有和运营该特定网络链路的政府（或其他组织）的流量是很常见的。在这种链路上，一个CALIPSO DOI通常用于联盟流量，而一些不同的CALIPSO DOI通常用于非联盟流量（即，特定于拥有和运营该特定网络链路的政府的流量）。例如，作为北约部署一部分的英国军事网络可能拥有并使用英国国防部DOI进行部署
information originating/terminating on another UK system, while concurrently using a different NATO DOI for information originating/terminating on a non-UK NATO system.
在另一个英国系统上发起/终止的信息，同时对非英国北约系统上发起/终止的信息使用不同的北约DOI。
Additionally, operational experience with existing MLS systems has shown that if a system only supports a single DOI at a given time, then it is impossible for a deployment to migrate from using one DOI value to a different DOI value in a smooth, lossless, zero downtime, manner.
此外，现有MLS系统的运行经验表明，如果一个系统在给定时间只支持一个DOI，那么部署就不可能以平稳、无损、零停机的方式从使用一个DOI值迁移到另一个DOI值。
Therefore, a node that implements this specification MUST be able to support at least two CALIPSO DOIs concurrently. Support for more than two concurrent CALIPSO DOIs is encouraged. This requirement to support at least two CALIPSO DOIs concurrently is not necessarily an implementation constraint upon MLS operating system internals that are unrelated to the network.
因此，实现此规范的节点必须能够同时支持至少两个CALIPSO DOI。鼓励支持两个以上的并发CALIPSO DOI。同时支持至少两个CALIPSO DOI的要求不一定是对与网络无关的MLS操作系统内部的实现约束。
Indeed, use of multiple DOIs is also operationally useful in deployments having a single administration that also have very large numbers of compartments. For example, such a deployment might have one set of related compartments in one CALIPSO DOI and a different set of compartments in a different CALIPSO DOI. Some compartments might be present in both DOIs, possibly at different bit positions of the compartment bitmap in different DOIs. While this might make some implementations more complex, it might also be used to reduce the typical size of the IPv6 CALIPSO option in data packets.
事实上，使用多个DOI在部署具有单一管理且具有大量隔间的部署中也非常有用。例如，这样的部署可能在一个CALIPSO DOI中有一组相关的隔室，在另一个CALIPSO DOI中有一组不同的隔室。两个DOI中可能都存在一些隔室，可能位于不同DOI中隔室位图的不同位位置。虽然这可能使某些实现更加复杂，但也可能用于减少数据包中IPv6 CALIPSO选项的典型大小。
Moving information between any two DOIs is permitted -- if and only if -- the owners of the DOIs:
允许在任意两个DOI之间移动信息——当且仅当——DOI的所有者：
1) Agree to the exchange,
1) 同意交换，
AND
和
2) Publish a document with a table of equivalencies that maps the CALIPSO values of one DOI into the other and make that document available to security administrators of MLS systems within the deployment scope of those two DOIs.
2) 发布一份带有等效表的文档，该表将一个DOI的CALIPSO值映射到另一个DOI，并将该文档提供给这两个DOI部署范围内MLS系统的安全管理员。
The owners of two DOIs may choose to permit the exchange on or between any of their systems, or may restrict exchange to a small subset of the systems they own/accredit. One-way agreements are permissible, as are agreements that are a subset of the full table of equivalences. Actual administration of inter-DOI agreements is outside the scope of this document.
两个内政部的所有者可选择允许在其任何系统上或在其系统之间进行交换，或将交换限制在其拥有/授权的系统的一小部分。单向协议是允许的，作为完整等效表子集的协议也是允许的。内政部间协定的实际管理不在本文件的范围之内。
When data leaves an End System it is exported to the network, and marked with a particular DOI, Sensitivity Level, and Compartment Set. (This triple is collectively termed a Sensitivity Label.) This Sensitivity Label is derived from the internal Sensitivity Label (the end-system-specific implementation of a given Sensitivity Label), and the Export DOI. Selection of the Export DOI is described in detail in Section 6.2.1.
当数据离开终端系统时，它被导出到网络，并用特定的DOI、灵敏度级别和隔室集进行标记。（此三元组统称为灵敏度标签。）此灵敏度标签源自内部灵敏度标签（给定灵敏度标签的终端系统特定实现）和导出DOI。第6.2.1节详细描述了导出DOI的选择。
When data arrives at an End System, it is imported from the network to the End System. The data from the datagram takes on an internal Sensitivity Label based on the Sensitivity Label contained in the datagram. This assumes the datagram is marked with a recognizable DOI, there is a corresponding internal Sensitivity Label equivalent to the CALIPSO Sensitivity Label, and the datagram is "within range" for the receiving logical interface.
当数据到达终端系统时，它将从网络导入终端系统。数据报中的数据采用基于数据报中包含的灵敏度标签的内部灵敏度标签。这假设数据报标记有可识别的DOI，存在与CALIPSO灵敏度标签等效的相应内部灵敏度标签，并且数据报在接收逻辑接口的“范围内”。
A node has one or more physical interfaces. Each physical interface is associated with a physical network segment used to connect the node, router, LAN, or WAN. One or more Sensitivity Label ranges are associated with each physical network interface. Sensitivity Label ranges from multiple DOIs must be enumerated separately. Multiple ranges from the same DOI are permissible.
节点具有一个或多个物理接口。每个物理接口都与用于连接节点、路由器、LAN或WAN的物理网段相关联。一个或多个灵敏度标签范围与每个物理网络接口相关联。必须单独枚举来自多个DOI的灵敏度标签范围。允许来自同一DOI的多个范围。
Each node also might have one or more logical network interfaces.
每个节点还可能有一个或多个逻辑网络接口。
A given logical network interface might be associated with more than one physical interface. For example, a switch/router might have two separate Ethernet ports that are associated with the same Virtual Local Area Network (VLAN), where that one VLAN mapped to a single IPv6 subnetwork [IEEE802.1Q].
给定的逻辑网络接口可能与多个物理接口关联。例如，交换机/路由器可能有两个与同一虚拟局域网（VLAN）关联的独立以太网端口，其中一个VLAN映射到单个IPv6子网[IEEE802.1Q]。
A given physical network interface might have more than one associated logical interface. For example, a node might have 2 logical network interfaces, each for a different IP subnetwork ("super-netting"), on a single physical network interface (e.g., on a single Network Interface Card of a personal computer). Alternatively, also as an example, a single Ethernet port might have multiple Virtual LANs (VLANs) associated with it, where each VLAN could be a separate logical network interface.
给定的物理网络接口可能有多个关联的逻辑接口。例如，在单个物理网络接口上（例如，在个人计算机的单个网络接口卡上），节点可能有2个逻辑网络接口，每个逻辑网络接口用于不同的IP子网（“超级网络”）。或者，作为一个示例，单个以太网端口可能有多个与其关联的虚拟LAN（VLAN），其中每个VLAN都可以是一个单独的逻辑网络接口。
One or more Sensitivity Label ranges are associated with each logical network interface. Sensitivity Label ranges from multiple DOIs must be enumerated separately. Multiple ranges from the same DOI are permissible. Each range associated with a logical interface must fall within a range separately defined for the corresponding physical interface.
一个或多个灵敏度标签范围与每个逻辑网络接口相关联。必须单独枚举来自多个DOI的灵敏度标签范围。允许来自同一DOI的多个范围。与逻辑接口关联的每个范围必须位于为相应物理接口单独定义的范围内。
There is specific user interest in having IPv6 routers that can apply per-logical-interface mandatory access controls based on the contents of the CALIPSO Sensitivity Labels in IPv6 packets. The authors note that since the early 1990s, and continuing through today, some commercial IPv4 router products provide MAC enforcement for the RFC 1108 IP Security Option.
用户特别感兴趣的是，IPv6路由器可以根据IPv6数据包中CALIPSO敏感标签的内容对每个逻辑接口应用强制访问控制。作者们注意到，自20世纪90年代初至今，一些商用IPv4路由器产品为RFC1108 IP安全选项提供MAC强制。
In transit, a datagram is handled based on its CALIPSO Sensitivity Label, and is usually neither imported to or exported from the various Intermediate Systems it transits. There also is the concept of "CALIPSO Gateways", which import data from one DOI and export it to another DOI such that the effective Sensitivity Label is NOT changed, but is merely represented using a different DOI. In other words, such devices would be trustworthy, trusted, and authorized to provide on-the-fly relabeling of packets at the boundaries between complete systems of End Systems within a single DOI. Typically, such systems require specific certification(s) and accreditation(s) before deployment or use.
在传输过程中，数据报根据其CALIPSO敏感标签进行处理，通常既不导入也不从其传输的各种中间系统导出。还有“CALIPSO网关”的概念，它从一个DOI导入数据并导出到另一个DOI，这样有效灵敏度标签不会改变，而只是使用不同的DOI表示。换句话说，这样的设备将是可信的、可信的，并且被授权在单个DOI内的终端系统的完整系统之间的边界处提供数据包的动态重新标记。通常，此类系统在部署或使用前需要特定的认证和认可。
This Section describes the default behavior of CALIPSO-compliant End Systems and Intermediate Systems. Implementers MAY implement configuration knobs to vary from this behavior, provided that the default behavior (i.e., if the system administrator does not explicitly change the configured behavior of the device) is as described below. If implementers choose to implement such configuration knobs, the configuration parameters and the behaviors that they enable and disable SHOULD be documented for the benefit of system administrators of those devices.
本节介绍与CALIPSO兼容的终端系统和中间系统的默认行为。如果默认行为（即，如果系统管理员未明确更改设备的配置行为）如下所述，则实施者可以实施配置旋钮以改变此行为。如果实现者选择实现此类配置旋钮，则应记录配置参数及其启用和禁用的行为，以便于这些设备的系统管理员。
Each Intermediate System or End System is responsible for properly interpreting and enforcing the MLS Mandatory Access Control policy. Practically, this means that each node must evaluate the label on the inbound packet, ensure that this Sensitivity Label is valid (i.e., within range) for the receiving interface, and at a minimum only forward the packet to an interface and node where the Sensitivity Label of the packet falls within the assigned range of that node's receiving interface.
每个中间系统或终端系统负责正确解释和实施MLS强制访问控制策略。实际上，这意味着每个节点必须评估入站数据包上的标签，确保该敏感标签对接收接口有效（即在范围内），并且至少仅将分组转发到接口和节点，其中分组的灵敏度标签落在该节点的接收接口的分配范围内。
Packets with an invalid (e.g., out-of-range) Sensitivity Label for the receiving interface MUST be dropped upon receipt. A Sensitivity Label is valid if and only if the Sensitivity Label falls within the range assigned to the transmitting interface on the sending system and within the range assigned to the receiving interface on the receiving system. These rules also need to be applied by Intermediate Systems on each hop that a CALIPSO-labeled packet traverses, not merely at the end points of a labeled IP session. As
接收接口灵敏度标签无效（例如超出范围）的数据包必须在接收时丢弃。当且仅当灵敏度标签在发送系统上分配给发送接口的范围内以及在接收系统上分配给接收接口的范围内时，灵敏度标签才有效。这些规则还需要由中间系统在CALIPSO标记的数据包经过的每个跃点上应用，而不仅仅是在标记的IP会话的端点。像
an example, it is a violation of the default MLS MAC policy for a packet with a higher Sensitivity Level (e.g., "MOST SECRET") to transit a link whose maximum Sensitivity Level is less than that first Sensitivity Level (e.g., "SECRET").
例如，对于具有较高灵敏度级别（例如，“最机密”）的分组来说，传输其最大灵敏度级别小于该第一灵敏度级别（例如，“机密”）的链路是违反缺省MLS MAC策略的。
If an unlabeled packet is received from a node that does not support CALIPSO Sensitivity Labels (i.e., unable to assign Sensitivity Labels itself) and the packet is destined for a node that supports CALIPSO Sensitivity Labels, then the receiving intermediate system needs to insert a Sensitivity Label. This Sensitivity Label MUST be equal to the maximum Sensitivity Label assigned to the originating node if and only if that is known to the receiving node. If this receiving Intermediate System does not know which Sensitivity Label is assigned to the originating node, then the maximum Sensitivity Label of the interface that received the unlabeled packet MUST be inserted.
如果从不支持CALIPSO敏感标签的节点接收到未标记的数据包（即，无法分配敏感标签本身），并且该数据包的目的地是支持CALIPSO敏感标签的节点，则接收中间系统需要插入敏感标签。当且仅当接收节点已知时，此灵敏度标签必须等于分配给发起节点的最大灵敏度标签。如果该接收中间系统不知道将哪个灵敏度标签分配给发起节点，则必须插入接收未标记数据包的接口的最大灵敏度标签。
NOTE WELL: The procedure in the preceding paragraph is NOT a label upgrade -- because it is not changing an existing label; instead, it is simply inserting a Sensitivity Label that has the only "safe" value, given that no other information is known to the receiving node. In large-scale deployments, it is very unlikely that a given node will have any authoritative a priori information about the security configuration of any node that is NOT on a directly attached link.
请注意：上一段中的过程不是标签升级——因为它不是更改现有标签；相反，它只是插入一个灵敏度标签，该标签具有唯一的“安全”值，因为接收节点不知道其他信息。在大规模部署中，给定节点不太可能具有任何关于不在直接连接链路上的任何节点的安全配置的权威先验信息。
If a packet is to be sent to a node that is defined to not be Sensitivity Label aware, from a node that is label aware, then the Sensitivity Label MAY be removed upon transmission if and only if local security policy explicitly permits this. The originating node is still responsible for ensuring that the Sensitivity Label on the packet falls within the Sensitivity Label range associated with the receiving node. If the packet will traverse more than one subnetwork between origin and destination, and those subnetworks are labeled, then the packet SHOULD normally contain a Sensitivity Label so that the packet will be able to reach the destination and the Intermediate Systems will be able to apply the requisite MAC policy to the packet.
如果要将数据包从具有标签意识的节点发送到定义为不具有敏感标签意识的节点，则只有在本地安全策略明确允许的情况下，才能在传输时删除敏感标签。发起节点仍然负责确保分组上的灵敏度标签落在与接收节点相关联的灵敏度标签范围内。如果数据包将在始发站和目的地之间穿过多个子网，并且这些子网已标记，则数据包通常应包含敏感度标签，以便数据包能够到达目的地，并且中间系统将能够对数据包应用必要的MAC策略。
NOTE WELL: In some IPv4 MLS network deployments that exist as of the publication date, if a first-hop router receives an unlabeled IPv4 packet, the router inserts an appropriate Sensitivity Label into that IPv4 packet, in the manner described above. So sending a packet without a label across a multiple subnetwork path to a destination does not guarantee that the packet will arrive containing no Sensitivity Label.
请注意：在一些截至发布日期的IPv4 MLS网络部署中，如果第一跳路由器接收到未标记的IPv4数据包，则路由器将以上述方式向该IPv4数据包中插入适当的敏感度标签。因此，通过多个子网路径将没有标签的数据包发送到目的地并不保证数据包到达时不包含敏感标签。
This section describes the format of the CALIPSO option for use with IPv6 datagrams. CALIPSO is an IPv6 Hop-By-Hop Option, rather than an IPv6 Destination Option, to ensure that a security gateway or router can apply access controls to IPv6 packets based on the CALIPSO label carried by the packet.
本节介绍用于IPv6数据报的CALIPSO选项的格式。CALIPSO是IPv6逐跳选项，而不是IPv6目标选项，以确保安全网关或路由器可以基于数据包携带的CALIPSO标签对IPv6数据包应用访问控制。
An IPv6 datagram that has not been tunneled contains at most one CALIPSO label. In the special case where (1) a labeled IPv6 datagram is tunneled inside another labeled IPv6 datagram AND (2) IP Security is NOT providing confidentiality protection for the inner packet, the outer CALIPSO Sensitivity Label must have the same meaning as the inner CALIPSO Sensitivity Label. For example, it would be invalid to encapsulate an unencrypted IPv6 packet with a Sensitivity Label of (SECRET, no compartments) inside a packet with an outer Sensitivity Label of (UNCLASSIFIED).
未通过隧道传输的IPv6数据报最多包含一个CALIPSO标签。在特殊情况下，（1）标记的IPv6数据报被隧道传输到另一个标记的IPv6数据报中，（2）IP安全未为内部数据包提供保密保护，外部CALIPSO敏感标签必须与内部CALIPSO敏感标签具有相同的含义。例如，将敏感度标签为（机密，无隔室）的未加密IPv6数据包封装在外部敏感度标签为（未分类）的数据包中是无效的。
If the inner IPv6 packet is tunneled inside the Encapsulating Security Payload (ESP) and confidentiality is being provided to that inner packet, then the outer packet MAY have a different CALIPSO Sensitivity Label -- subject to local security policy.
如果内部IPv6数据包在封装安全有效负载（ESP）内进行隧道传输，并且为该内部数据包提供了机密性，则外部数据包可能具有不同的CALIPSO敏感标签——取决于本地安全策略。
As a general principle, the meaning of the Sensitivity Labels must be identical when one has a labeled cleartext IP packet that has been encapsulated (tunneled) inside another labeled IP packet. This is true whether one has IPv6 tunneled in IPv6, IPv4 tunneled in IPv6, or IPv6 tunneled in IPv4. This is essential to maintaining proper Mandatory Access Controls.
作为一般原则，当一个有标签的明文IP包被封装（隧道）在另一个有标签的IP包中时，灵敏度标签的含义必须相同。无论是在IPv6中隧道IPv6、在IPv6中隧道IPv4还是在IPv4中隧道IPv6，都是如此。这对于维持适当的强制性访问控制至关重要。
This option's syntax has been designed with intermediate systems in mind. It is now common for an MLS network deployment to contain an Intermediate Systems acting as a guard (sometimes several acting as guards). Such a guard device needs to be able to very rapidly parse the Sensitivity Label in each packet, apply ingress interface MAC policy, forward the packet while aware of the packet's Sensitivity Label, and then apply egress interface MAC policy.
此选项的语法设计时考虑了中间系统。现在，MLS网络部署通常包含一个充当警卫的中间系统（有时几个充当警卫）。这样的保护设备需要能够非常快速地解析每个分组中的敏感标签，应用入口接口MAC策略，在知道分组的敏感标签的同时转发分组，然后应用出口接口MAC策略。
At least one prior IP Sensitivity Label option [FIPS-188] used a syntax that was unduly complex to parse in IP routers, hence that option never was implemented in an IP router. So there is a deliberate effort here to choose a streamlined option syntax that is easy to parse, encode, and implement in more general terms.
至少有一个先前的IP敏感标签选项[FIPS-188]使用的语法过于复杂，无法在IP路由器中解析，因此该选项从未在IP路由器中实现。因此，我们特意选择了一种简化的选项语法，这种语法很容易用更一般的术语进行解析、编码和实现。
The CALIPSO option is an IPv6 Hop-by-Hop Option and is designed to comply with IPv6 optional header rules. Following the nomenclature of Section 4.2 of RFC 2460, the Option Type field of this option must have 4n+2 alignment [RFC2460].
CALIPSO选项是一个IPv6逐跳选项，旨在遵守IPv6可选标头规则。按照RFC 2460第4.2节的命名法，该选项的选项类型字段必须具有4n+2对齐[RFC2460]。
The CALIPSO Option Data MUST NOT change en route, except when (1) "DOI translation" is performed by a trusted Intermediate System, (2) a CALIPSO Option is inserted by a trusted Intermediate System upon receipt of an unlabeled IPv6 packet, or (3) a CALIPSO Option is removed by a last-hop trusted Intermediate System immediately prior to forwarding the packet to a destination node that does not implement support for CALIPSO labels. The details of these three exceptions are described elsewhere in this document.
CALIPSO选项数据不得在路由过程中更改，除非（1）受信任的中间系统执行“DOI转换”，（2）受信任的中间系统在收到未标记的IPv6数据包时插入CALIPSO选项，或（3）在将数据包转发到不支持CALIPSO标签的目标节点之前，最后一跳可信中间系统将删除CALIPSO选项。这三种例外情况的详细信息在本文件的其他部分进行了说明。
If the option type is not recognized by a node examining the packet, the option is ignored. However, all implementations of this specification MUST be able to recognize this option and therefore MUST NOT ignore this option if it is present in an IPv6 packet.
如果检查数据包的节点无法识别选项类型，则忽略该选项。但是，本规范的所有实现必须能够识别此选项，因此，如果IPv6数据包中存在此选项，则不得忽略此选项。
This option is designed to comply with the IPv6 optional header rules [RFC2460]. The CALIPSO option is always carried in a Hop-By-Hop Option Header, never in any other part of an IPv6 packet. This rule exists because IPv6 routers need to be able to see the CALIPSO label so that those routers are able to apply MLS Mandatory Access Controls to those packets.
此选项设计为符合IPv6可选标头规则[RFC2460]。CALIPSO选项始终包含在逐跳选项标头中，而不包含在IPv6数据包的任何其他部分中。此规则的存在是因为IPv6路由器需要能够看到CALIPSO标签，以便这些路由器能够对这些数据包应用MLS强制访问控制。
The diagram below shows the CALIPSO option along with the required (first) two fields of the Hop-By-Hop Option Header that envelops the CALIPSO option. The design of the CALIPSO option is arranged to avoid the need for 16 bits of padding between the HDR EXT LEN field and the start of the CALIPSO option. Also, the CALIPSO Domain of Interpretation field is laid out so that it normally will be 32-bit aligned.
下图显示了CALIPSO选项以及封装CALIPSO选项的逐跳选项标头的必需（前）两个字段。CALIPSO选项的设计旨在避免HDR EXT LEN字段和CALIPSO选项开始之间需要16位填充。此外，解释字段的CALIPSO域被布置为通常32位对齐。
------------------------------------------------------------
| Next Header | Hdr Ext Len | Option Type | Option Length|
+-------------+---------------+-------------+--------------+
| CALIPSO Domain of Interpretation |
+-------------+---------------+-------------+--------------+
| Cmpt Length | Sens Level | Checksum (CRC-16) |
+-------------+---------------+-------------+--------------+
| Compartment Bitmap (Optional; variable length) |
+-------------+---------------+-------------+--------------+
------------------------------------------------------------
| Next Header | Hdr Ext Len | Option Type | Option Length|
+-------------+---------------+-------------+--------------+
| CALIPSO Domain of Interpretation |
+-------------+---------------+-------------+--------------+
| Cmpt Length | Sens Level | Checksum (CRC-16) |
+-------------+---------------+-------------+--------------+
| Compartment Bitmap (Optional; variable length) |
+-------------+---------------+-------------+--------------+
This field contains an unsigned 8-bit value. Its value is 00000111 (binary).
此字段包含一个无符号8位值。其值为00000111（二进制）。
Nodes that do not recognize this option should ignore it. In many cases, not all routers in a given MLS deployment will contain support for this CALIPSO option. For interoperability reasons, it is important that routers that do not support the CALIPSO forward this packet normally, even though those routers do not recognize the CALIPSO option.
不识别此选项的节点应忽略它。在许多情况下，并非给定MLS部署中的所有路由器都支持此CALIPSO选项。出于互操作性原因，不支持CALIPSO的路由器必须正常转发此数据包，即使这些路由器不识别CALIPSO选项。
In the event the IPv6 packet is fragmented, this option MUST be copied on fragmentation. Virtually all users want the choice of using the IP Authentication Header (a) to authenticate this option and (b) to bind this option to the associated IPv6 packet.
如果IPv6数据包被分段，则必须在分段时复制此选项。实际上，所有用户都希望选择使用IP身份验证标头（a）来验证此选项，以及（b）将此选项绑定到关联的IPv6数据包。
This field contains an unsigned integer one octet in size. Its minimum value is eight (e.g., when the Compartment Bitmap field is absent). This field specifies the Length of the option data field of this option in octets. The Option Type and Option Length fields are not included in the length calculation.
此字段包含一个大小为一个八位字节的无符号整数。其最小值为8（例如，当缺少隔间位图字段时）。此字段指定此选项的选项数据字段的长度（以八位字节为单位）。长度计算中不包括选项类型和选项长度字段。
This field contains an unsigned 8-bit integer. The field specifies the size of the Compartment Bitmap field in 32-bit words. The minimum value is zero, which is used only when the information in this packet is not in any compartment. (In that situation, the CALIPSO Sensitivity Label has no need for a Compartment Bitmap). Note that measuring the Compartment Bitmap field length in 32-bit words permits the header to be 64-bit aligned, following IPv6 guidelines, without wasting 32 bits. Using 64-bit words for the size of the Compartment Bitmap field length would force 32 bits of padding with every option in order to maintain 64-bit alignment; wasting those bits in every CALIPSO option is undesirable.
此字段包含一个无符号8位整数。该字段以32位字指定隔间位图字段的大小。最小值为零，仅当此数据包中的信息不在任何隔室中时使用。（在这种情况下，CALIPSO灵敏度标签不需要隔间位图）。请注意，测量32位字中的隔间位图字段长度允许标头按照IPv6准则进行64位对齐，而不会浪费32位。使用64位字作为隔间位图字段长度的大小将强制每个选项填充32位，以保持64位对齐；在每个CALIPSO选项中浪费这些比特是不可取的。
Because this specification represents Releasabilities on the wire as inverted Compartments, the size of the Compartment Bitmap field needs to be large enough to hold not only the set of logical Compartments, but instead to hold both the set of logical Compartments and the set of logical Releasabilities.
由于此规范将线路上的可释放性表示为反向隔室，因此隔室位图字段的大小需要足够大，以便不仅容纳逻辑隔室集，而且容纳逻辑隔室集和逻辑可释放性集。
Recall that the overall length of this option MUST follow IPv6 optional header rules, including the word alignment rules. This has implications for the valid values for this field. In some cases, the
回想一下，此选项的总长度必须遵循IPv6可选标头规则，包括单词对齐规则。这会影响此字段的有效值。在某些情况下
length of the Compartment Bitmap field might need to exceed the number of bits required to hold the sum of the logical Compartments and the logical Releasabilities, in order to comply with IPv6 alignment rules.
隔间位图字段的长度可能需要超过保存逻辑隔间和逻辑可释放性总和所需的位数，以符合IPv6对齐规则。
This field contains an unsigned 32-bit integer. IANA maintains a registry with assignments of the DOI values used in this field. The DOI identifies the rules under which this datagram must be handled and protected. The NULL DOI, in which this field is all zeros, MUST NOT appear in any IPv6 packet on any network.
此字段包含一个无符号32位整数。IANA维护一个注册表，其中包含该字段中使用的DOI值的分配。DOI确定必须根据哪些规则处理和保护此数据报。任何网络上的任何IPv6数据包中都不得出现空DOI，其中该字段为全零。
NOTE WELL: The Domain Of Interpretation value where all 4 octets contain zero is defined to be the NULL DOI. The NULL DOI has no compartments and has a single level whose value and CALIPSO representation are each zero. The NULL DOI MUST NOT ever appear on the wire. If a packet is received containing the NULL DOI, that packet MUST be dropped and the event SHOULD be logged as a security fault.
注：所有4个八位字节都包含零的解释值域被定义为空DOI。空DOI没有隔间，只有一个级别，其值和CALIPSO表示均为零。空DOI不得出现在导线上。如果接收到包含空DOI的数据包，则必须丢弃该数据包，并将该事件记录为安全故障。
This contains an unsigned 8-bit value. This field contains an opaque octet whose value indicates the relative sensitivity of the data contained in this datagram in the context of the indicated DOI. The values of this field MUST be ordered, with 00000000 being the lowest Sensitivity Level and 11111111 being the highest Sensitivity Level.
它包含一个无符号8位值。此字段包含一个不透明的八位字节，其值表示此数据报中包含的数据在所示DOI上下文中的相对敏感性。必须对该字段的值进行排序，00000000为最低灵敏度级别，11111111为最高灵敏度级别。
However, in a typical deployment, not all 256 Sensitivity Levels will be in use. So the set of valid Sensitivity Level values depends upon the CALIPSO DOI in use. This sensitivity ordering rule is necessary so that Intermediate Systems (e.g., routers or MLS guards) will be able to apply MAC policy with minimal per-packet computation and minimal configuration.
但是，在典型部署中，并非所有256个敏感度级别都将使用。因此，有效的灵敏度级别值集取决于使用的CALIPSO DOI。这种敏感性排序规则是必要的，以便中间系统（例如路由器或MLS警卫）能够以最小的每包计算和最小的配置应用MAC策略。
This 16-bit field contains the a CRC-16 checksum as defined in Appendix C of RFC 1662 [RFC1662]. The checksum is calculated over the entire CALIPSO option in this packet, including option header, zeroed-out checksum field, option contents, and any required padding zero bits.
该16位字段包含RFC 1662[RFC1662]附录C中定义的CRC-16校验和。校验和是在该数据包中的整个CALIPSO选项上计算的，包括选项头、清零校验和字段、选项内容和任何所需的填充零位。
The checksum MUST always be computed on transmission and MUST always be verified on reception. This checksum only provides protection against accidental corruption of the CALIPSO option in cases where
必须始终在传输时计算校验和，并且必须始终在接收时验证校验和。此校验和仅在以下情况下提供防止CALIPSO选项意外损坏的保护：
neither the underlying medium nor other mechanisms, such as the IP Authentication Header (AH), are available to protect the integrity of this option.
基础介质或其他机制（如IP身份验证标头（AH））都不可用于保护此选项的完整性。
Note that the checksum field is always required, even when other integrity protection mechanisms (e.g., AH) are used. This method is chosen for its reliability and simplicity in both hardware and software implementations, and because many implementations already support this checksum due to its existing use in various IETF specifications.
请注意，即使使用了其他完整性保护机制（如AH），也始终需要校验和字段。选择此方法是因为其在硬件和软件实现中的可靠性和简单性，并且由于其在各种IETF规范中的现有使用，许多实现已经支持此校验和。
This contains a variable number of 64-bit words. Each bit represents one compartment within the DOI. Each "1" bit within an octet in the Compartment Bitmap field represents a separate compartment under whose rules the data in this packet must be protected. Hence, each "0" bit indicates that the compartment corresponding with that bit is not applicable to the data in this packet. The assignment of identity to individual bits within a Compartment Bitmap for a given DOI is left to the owner of that DOI.
它包含可变数量的64位字。每个位代表DOI中的一个隔间。隔间位图字段中八位字节内的每个“1”位表示一个单独的隔间，根据该隔间的规则，必须保护此数据包中的数据。因此，每个“0”位指示与该位对应的隔室不适用于该分组中的数据。为给定DOI的分区位图中的各个位分配标识留给该DOI的所有者。
This specification represents a Releasability on the wire as if it were an inverted Compartment. So the Compartment Bitmap holds the sum of both logical Releasabilities and also logical Compartments for a given DOI value. The encoding of the Releasabilities in this field is described elsewhere in this document. The Releasability encoding is designed to permit the Compartment Bitmap evaluation to occur without the evaluator necessarily knowing the human semantic associated with each bit in the Compartment Bitmap. In turn, this facilitates the implementation and configuration of Mandatory Access Controls based on the Compartment Bitmap within IPv6 routers or guard devices.
此规范表示电线上的可释放性，就像它是一个倒置的隔间一样。因此，分区位图保存给定DOI值的逻辑可发布性和逻辑分区的总和。此字段中可发布性的编码在本文档的其他地方进行了描述。可释放性编码旨在允许隔室位图评估发生，而评估者不必知道与隔室位图中的每个位相关联的人类语义。反过来，这有助于基于IPv6路由器或保护设备内的隔间位图实施和配置强制访问控制。
The basic option is variable length, due to the variable length Compartment Bitmap field.
由于可变长度隔间位图字段，基本选项为可变长度。
Intermediate Systems that lack custom silicon processing capabilities and most End Systems perform best when processing fixed-length, fixed-location items. So the IPv6 base specification levies certain requirements on all IPv6 optional headers.
缺乏定制硅处理能力的中间系统和大多数终端系统在处理固定长度、固定位置的项目时表现最佳。因此，IPv6基本规范对所有IPv6可选头都提出了某些要求。
The CALIPSO option must maintain this IPv6 64-bit alignment rule for the option overall. Please note that the Compartment Bitmap field has a length in quanta of 32-bit words (e.g., 0 bits, 32 bits, 64 bits, 96 bits), which permits the overall CALIPSO option length to be 64-bit aligned -- without requiring 32 bits of NULL padding with every CALIPSO option.
CALIPSO选项必须为整个选项维护此IPv6 64位对齐规则。请注意，隔间位图字段的长度以32位字（例如，0位、32位、64位、96位）为单位，这允许整个CALIPSO选项长度为64位对齐，而不需要每个CALIPSO选项使用32位空填充。
This section describes specific protocol processing steps required for systems that claim to implement or conform with this specification.
本节描述声称实施或符合本规范的系统所需的特定协议处理步骤。
This section describes how comparisons are made between two Sensitivity Labels. Implementing this comparison correctly is critical to the MLS system providing the intended Mandatory Access Controls (MACs) to network traffic entering or leaving the system.
本节介绍如何在两个灵敏度标签之间进行比较。正确执行此比较对于MLS系统至关重要，因为MLS系统为进入或离开系统的网络流量提供了预期的强制访问控制（MAC）。
A Sensitivity Label consists of a DOI, a Sensitivity Level, and zero or more Compartments. The following notation will be used:
灵敏度标签由DOI、灵敏度等级和零个或多个隔室组成。将使用以下符号：
A.DOI = the DOI portion of Sensitivity Label A A.LEV = the Sensitivity Level portion of Sensitivity Label A A.COMP = the Compartments portion of Sensitivity Label A
A.DOI=灵敏度标签A的DOI部分A.LEV=灵敏度标签A的灵敏度水平部分A.COMP=灵敏度标签A的隔室部分
A Sensitivity Label "M" is "within range" for a particular range "LO:HI" if and only if:
灵敏度标签“M”在特定范围“LO:HI”的“范围内”，当且仅当：
1. M, LO, and HI are members of the same DOI.
1. M、 LO和HI是同一DOI的成员。
(M.DOI == LO.DOI == HI.DOI)
(M.DOI == LO.DOI == HI.DOI)
2. The range is a valid range. A given range LO:HI is valid if and only if HI dominates LO.
2. 该范围是一个有效范围。给定的LO:HI范围当且仅当HI支配LO时有效。
((LO.LEV <= HI.LEV) && (LO.COMP <= HI.COMP))
((LO.LEV <= HI.LEV) && (LO.COMP <= HI.COMP))
3. The Sensitivity Level of M dominates the low-end (LO) Sensitivity Level AND the Sensitivity Level of M is dominated by the high-end (HI) Sensitivity Level.
3. M的灵敏度水平主导低端（LO）灵敏度水平，M的灵敏度水平主导高端（HI）灵敏度水平。
(LO.LEV <= M.LEV <= HI.LEV)
(LO.LEV <= M.LEV <= HI.LEV)
AND
和
4. The Sensitivity Label M has a Compartment Set that dominates the Compartment Set contained in the Sensitivity Label from the low-end range (LO), and that is dominated by the Compartment Set contained in the high-end Sensitivity Label (HI) from the range.
4. 灵敏度标签M具有一个隔室集，该隔室集控制低端范围（LO）的灵敏度标签中包含的隔室集，并由高端范围的灵敏度标签（HI）中包含的隔室集控制。
(LO.COMP <= M.COMP <= HI.COMP)
(LO.COMP <= M.COMP <= HI.COMP)
A Sensitivity Label "M" is "less than" some other Sensitivity Label "LO" if and only if:
灵敏度标签“M”小于其他一些灵敏度标签“LO”，当且仅当：
1. The DOI for the Sensitivity Label M is identical to the DOI for both the low-end and high-end of the range.
1. 灵敏度标签M的DOI与该范围低端和高端的DOI相同。
(M.DOI == LO.DOI == HI.DOI)
(M.DOI == LO.DOI == HI.DOI)
AND EITHER
或者
2. The Sensitivity Level of M is less than the Sensitivity Level of LO.
2. M的灵敏度水平小于LO的灵敏度水平。
(M.LEV < LO.LEV)
（米列弗<低列弗）
OR
或
3. The Compartment Set of Sensitivity Label M is dominated by the Compartment Set of Sensitivity Label LO.
3. 灵敏度标签M的隔室组主要由灵敏度标签LO的隔室组控制。
(M.COMP <= LO.COMP)
（M.COMP<=低COMP）
A Sensitivity Label "M" is "below range" for a Sensitivity Label "LO:HI", if LO dominates M and LO is not equal to M.
如果LO支配M且LO不等于M，则灵敏度标签“M”为灵敏度标签“LO:HI”的“低于范围”。
A Sensitivity Label "M" is "greater than" some Sensitivity Label "HI" if and only if:
灵敏度标签“M”大于某些灵敏度标签“HI”，当且仅当：
1. Their DOI's are identical.
1. 他们的内政部是一样的。
(M.DOI == HI.DOI)
（M.DOI==HI.DOI）
AND EITHER
或者
2A. M's Sensitivity Level is above HI's Sensitivity Level.
2A。M的灵敏度水平高于HI的灵敏度水平。
(M.LEV > HI.LEV)
（M.LEV>HI.LEV）
OR
或
2B. M's Compartment Set is greater than HI's Compartment Set.
2B。M的隔间设置大于HI的隔间设置。
(M.COMP > HI.COMP)
（M.COMP>HI.COMP）
A Sensitivity Label "M" is "above range" for a Sensitivity Label, "LO:HI", if M dominates HI and M is not equal to HI.
如果M支配HI且M不等于HI，则灵敏度标签“M”是灵敏度标签“LO:HI”的“高于范围”。
A Sensitivity Label "A" is "equal to" another Sensitivity Label "B" if and only if:
一个灵敏度标签“A”等于另一个灵敏度标签“B”，当且仅当：
1. They have the exact same DOI.
1. 他们有完全相同的DOI。
(A.DOI == B.DOI)
（A.DOI==B.DOI）
2. They have identical Sensitivity Levels.
2. 它们具有相同的灵敏度水平。
(A.LEV == B.LEV)
（A.LEV==B.LEV）
3. Their Compartment Sets are identical.
3. 他们的隔间是相同的。
(A.COMP == B.COMP)
（A.COMP==B.COMP）
A Sensitivity Label "A" is disjoint from another Sensitivity Label "B" if any of these conditions are true:
如果以下任一条件成立，则灵敏度标签“A”与另一灵敏度标签“B”不相交：
1. Their DOI's differ.
1. 他们的内政部不同。
(A.DOI <> B.DOI)
（A.DOI<>B.DOI）
2. B does not dominate A, A does not dominate B, and A is not equal to B.
2. B不支配A，A不支配B，A不等于B。
(^( (A < B) || (A > B) || (A == B) ))
(^( (A < B) || (A > B) || (A == B) ))
3. Their Compartment Sets are disjoint from each other; A's Compartment Set does not dominate B's Compartment Set AND B's Compartment Set does not dominate A's Compartment Set.
3. 它们的隔室组彼此不相交；A的隔间集不支配B的隔间集，B的隔间集不支配A的隔间集。
(^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) ))
(^( (A.COMP >= B.COMP) || (A.COMP <= B.COMP) ))
This section describes CALIPSO-related processing for IPv6 packets imported or exported from an End System claiming to implement or conform with this specification. This document places no additional requirements on IPv6 nodes that do not claim to implement or conform with this document.
本节描述从声称实现或符合本规范的终端系统导入或导出的IPv6数据包的CALIPSO相关处理。本文档对未声明实施或符合本文档要求的IPv6节点没有其他要求。
An End System that sends data to the network is said to "export" it to the network. Before a datagram can leave an end system and be transmitted over a network, the following ordered steps must occur:
向网络发送数据的终端系统被称为将数据“导出”到网络。在数据报可以离开终端系统并通过网络传输之前，必须执行以下顺序步骤：
1. Selection of the export DOI:
1. 选择导出DOI：
a) If the upper-level protocol selects a DOI, then that DOI is selected.
a) 如果上层协议选择一个DOI，则选择该DOI。
b) Else, if there are tables defining a specific default DOI for the specific destination End System address or for the network address, then that DOI is selected.
b) 否则，如果有表定义了特定目标端系统地址或网络地址的特定默认DOI，则选择该DOI。
c) Else, if there is a specific DOI associated with the sending logical interface (i.e., IP address), then that DOI is selected.
c) 否则，如果存在与发送逻辑接口（即IP地址）关联的特定DOI，则选择该DOI。
d) Else the default DOI for the system is selected.
d) 否则将选择系统的默认DOI。
NOTE WELL: A connection-oriented transport-layer protocol session (e.g., Transmission Control Protocol (TCP) session, Stream Control Transmission Protocol (SCTP) session) MUST have the same DOI and same Sensitivity Label for the life of that connection. The DOI is selected at connection initiation and MUST NOT change during the session.
请注意：面向连接的传输层协议会话（例如，传输控制协议（TCP）会话、流控制传输协议（SCTP）会话）在该连接的生命周期内必须具有相同的DOI和相同的灵敏度标签。DOI是在连接启动时选择的，在会话期间不得更改。
A trusted multi-level application that possesses appropriate privilege MAY use multiple connection-oriented transport-layer protocol sessions with differing Sensitivity Labels concurrently.
具有适当权限的受信任多级应用程序可以同时使用具有不同敏感度标签的多个面向连接的传输层协议会话。
Some trusted UDP-based applications (e.g., remote procedure call service) multiplex different transactions having different Sensitivity Levels in different packets for the same IP session (e.g., IP addresses and UDP ports are constant for a given UDP session). In such cases, the Trusted Computing Base MUST ensure that each packet is labeled with the correct Sensitivity Label for the information carried in that particular packet.
一些基于UDP的可信应用程序（例如，远程过程调用服务）在同一IP会话的不同数据包中多路传输具有不同灵敏度级别的不同事务（例如，给定UDP会话的IP地址和UDP端口是恒定的）。在这种情况下，可信计算基础必须确保每个数据包都标有该特定数据包中所携带信息的正确敏感度标签。
In the event the End System selects and uses a specific DOI and that DOI is not recognized by the originating node's first-hop router, the packet MUST be dropped by the first-hop router. In such a case, the networking API should indicate the connection failure (e.g., with some appropriate error, such as ENOTREACH). This fault represents (1) incorrect configuration of either the Intermediate System or of the End System or (2) correct operation for a node that is not permitted to send IPv6 packets with that DOI through that Intermediate System.
如果终端系统选择并使用特定的DOI，并且发起节点的第一跳路由器无法识别该DOI，则第一跳路由器必须丢弃该数据包。在这种情况下，网络API应该指示连接失败（例如，带有一些适当的错误，例如ENOTREACH）。此故障表示（1）中间系统或终端系统的配置不正确，或（2）不允许通过该中间系统使用该DOI发送IPv6数据包的节点的操作正确。
When an MLS End System is connected to an MLS LAN, it is possible that there would be more than one first-hop Intermediate System concurrently, with different Intermediate Systems having different valid Sensitivity Label ranges. Thoughtful use of the IEEE 802 Virtual LAN (VLAN) standard (e.g., with different VLAN IDs corresponding to different sensitivity ranges) might ease proper system configuration in such deployments.
当MLS终端系统连接到MLS LAN时，可能会同时存在多个第一跳中间系统，不同的中间系统具有不同的有效灵敏度标签范围。深思熟虑地使用IEEE 802虚拟局域网（VLAN）标准（例如，不同的VLAN ID对应不同的敏感度范围）可能会简化此类部署中的适当系统配置。
2. Export Labeling:
2. 出口标签：
Once the DOI is selected, the CALIPSO Sensitivity Label and values are determined based on the internal Sensitivity Label and the DOI. In the event the internal Sensitivity Level does not map to a valid CALIPSO Sensitivity Label, then an error SHOULD be returned to the upper-level protocol and that error MAY be logged. No further attempt to send this datagram should be made.
选择DOI后，CALIPSO灵敏度标签和值将根据内部灵敏度标签和DOI确定。如果内部灵敏度级别未映射到有效的CALIPSO灵敏度标签，则应将错误返回到上层协议，并记录该错误。不应再尝试发送此数据报。
3. Access Control:
3. 访问控制：
Once the datagram is marked and the sending logical interface is selected (by the routing code), the datagram's Sensitivity Label is compared against the Sensitivity Label range(s) associated with that logical interface. For the datagram to be sent, the interface MUST list the DOI of the datagram Sensitivity Label as one of the permissible DOI's and the datagram Sensitivity Label must be within range for the range associated with that DOI. If the datagram fails this access test, then
标记数据报并选择发送逻辑接口（通过路由代码）后，将数据报的灵敏度标签与与该逻辑接口相关联的灵敏度标签范围进行比较。对于要发送的数据报，接口必须将数据报敏感标签的DOI列为允许的DOI之一，并且数据报敏感标签必须在与该DOI关联的范围内。如果数据报未通过此访问测试，则
an error SHOULD be returned to the upper-level protocol and MAY be logged. No further attempt to send this datagram should be made.
错误应返回到上层协议，并可能被记录。不应再尝试发送此数据报。
When a datagram arrives at an interface on an End System, the receiving End System MUST:
当数据报到达终端系统上的接口时，接收端系统必须：
1. Verify the CALIPSO checksum. Datagrams with invalid checksums MUST be silently dropped. Such a drop event SHOULD be logged as a security fault with an indication of what happened.
1. 验证CALIPSO校验和。必须以静默方式删除具有无效校验和的数据报。此类丢弃事件应记录为安全故障，并指示发生了什么。
2. Verify the CALIPSO has a known and valid DOI. Datagrams with unrecognized or illegal DOIs MUST be silently dropped. Such an event SHOULD be logged as a security fault with an indication of what happened.
2. 验证CALIPSO是否具有已知且有效的DOI。具有无法识别或非法DOI的数据报必须静默删除。此类事件应记录为安全故障，并指示发生了什么。
3. Verify the DOI is a permitted one for the receiving interface. Datagrams with prohibited DOI values MUST be silently dropped. Such an event SHOULD be logged as a security fault with an indication of what happened.
3. 验证DOI是否为接收接口允许的DOI。具有禁止的DOI值的数据报必须以静默方式删除。此类事件应记录为安全故障，并指示发生了什么。
4. Verify the CALIPSO Sensitivity Label is within the permitted range for the receiving interface:
4. 验证CALIPSO灵敏度标签是否在接收接口的允许范围内：
NOTE WELL: EACH permitted DOI on an interface has a separate table describing the permitted range for that DOI.
请注意：接口上每个允许的DOI都有一个单独的表，描述该DOI的允许范围。
A datagram with a Sensitivity Label within the permitted range is accepted for further processing.
灵敏度标签在允许范围内的数据报可接受进一步处理。
A datagram with a Sensitivity Label disjoint with the permitted range MUST be silently dropped. Such an event SHOULD be logged as a security fault, with an indication that the packet was dropped because of a disjoint Sensitivity Label. An ICMP error message MUST NOT be sent in this case.
灵敏度标签与允许范围不相交的数据报必须静默删除。此类事件应记录为安全故障，并指示数据包由于不相交的敏感标签而被丢弃。在这种情况下，不得发送ICMP错误消息。
A datagram with a Sensitivity Label below the permitted range MUST be dropped. This event SHOULD be logged as a security fault, with an indication that the packet was below range. An ICMP error message MUST NOT be sent in this case.
灵敏度标签低于允许范围的数据报必须删除。此事件应记录为安全故障，并指示数据包低于范围。在这种情况下，不得发送ICMP错误消息。
A datagram with a Sensitivity Label above the permitted range MUST be dropped. This event SHOULD be logged as a security fault, with an indication that the packet was above range. An ICMP error message MUST NOT be sent in this case.
灵敏度标签高于允许范围的数据报必须丢弃。此事件应记录为安全故障，并指示数据包超出范围。在这种情况下，不得发送ICMP错误消息。
5. Once the datagram has been accepted, the receiving system MUST use the import Sensitivity Label and DOI to associate the appropriate internal Sensitivity Label with the data in the received datagram. This label information MUST be carried as part of the information returned to the upper-layer protocol.
5. 一旦数据报被接受，接收系统必须使用导入灵敏度标签和DOI将适当的内部灵敏度标签与接收到的数据报中的数据相关联。该标签信息必须作为返回上层协议的信息的一部分携带。
This section describes CALIPSO-related processing for IPv6 packets transiting an IPv6 Intermediate System that claims to implement and comply with this specification. This document places no additional requirements on IPv6 Intermediate Systems that do not claim to comply or conform with this document.
本节描述了在声称实现并遵守本规范的IPv6中间系统中传输IPv6数据包的CALIPSO相关处理。本文件对声称不符合或不符合本文件要求的IPv6中间系统没有附加要求。
The CALIPSO packet format has been designed so that one can configure an Intermediate System with the minimum sensitivity level, maximum Sensitivity Level, minimum compartment bitmap, and maximum compartment bitmap -- and then deploy that system without forcing the system to know the detailed human meaning of each Sensitivity Level or compartment bit value. Instead, once the minimum and maximum labels have been configured, the Intermediate System can apply a simple algorithm to determine whether or not a packet is within range for a given interface. This design should be straight-forward to implement in Application-Specific Integrated Circuit (ASIC) or Field Programmable Gate Array (FPGA) hardware, because the option format is simple and easy to parse, and because only a single comparison algorithm (defined in this RFC, hence known in advance) is needed.
CALIPSO数据包格式的设计使您可以配置具有最小灵敏度级别、最大灵敏度级别、最小隔间位图、，和最大隔间位图——然后部署该系统，而不强制系统了解每个灵敏度级别或隔间位值的详细人类含义。相反，一旦配置了最小和最大标签，中间系统就可以应用简单的算法来确定数据包是否在给定接口的范围内。该设计应直接在专用集成电路（ASIC）或现场可编程门阵列（FPGA）硬件中实现，因为选项格式简单且易于解析，并且只需要一个比较算法（在本RFC中定义，因此提前知道）。
Intermediate Systems have slightly different rules for processing marked datagrams than do End Systems. Primarily, Intermediate Systems do not IMPORT or EXPORT transit datagrams, they just forward them. Also, in most deployments intermediate systems are used to provide Mandatory Access Controls to packets traversing more than one subnetwork.
中间系统处理标记数据报的规则与终端系统略有不同。基本上，中间系统不导入或导出传输数据报，它们只是转发它们。此外，在大多数部署中，中间系统用于对穿越多个子网的数据包提供强制访问控制。
The following checks MUST occur before any other processing. Upon receiving a CALIPSO-labeled packet, an Intermediate System must:
在进行任何其他处理之前，必须进行以下检查。收到CALIPSO标记的数据包后，中间系统必须：
1. Determine whether or not this datagram is destined for (addressed to) this Intermediate System. If so, then the Intermediate System becomes an End System for the purposes of receiving this particular datagram and the rules for IMPORTing described above are followed.
1. 确定此数据报是否发往（发往）此中间系统。如果是这样，则中间系统就成为接收该特定数据报的终端系统，并且遵循上述导入规则。
2. Verify the CALIPSO checksum. Datagrams with invalid checksums MUST be silently dropped. The drop event SHOULD be logged as a security fault with an indication of what happened and MAY additionally be logged as a network fault.
2. 验证CALIPSO校验和。必须以静默方式删除具有无效校验和的数据报。丢弃事件应记录为安全故障，并指示发生了什么，还可记录为网络故障。
NOTE WELL: A checksum failure could indicate a general network problem (e.g., noise on a radio link) that is unrelated to the presence of a CALIPSO option, but it also could indicate an attempt by an adversary to tamper with the value of a CALIPSO label.
请注意：校验和故障可能表示与CALIPSO选项的存在无关的一般网络问题（例如，无线电链路上的噪声），但也可能表示对手试图篡改CALIPSO标签的值。
3. Verify the CALIPSO has a known and valid DOI. Datagrams with unrecognized or illegal DOIs MUST be silently dropped. Such an event SHOULD be logged as a security fault with an indication of what happened.
3. 验证CALIPSO是否具有已知且有效的DOI。具有无法识别或非法DOI的数据报必须静默删除。此类事件应记录为安全故障，并指示发生了什么。
4. Verify the DOI is a permitted one for the receiving interface. Datagrams with prohibited DOIs MUST be silently dropped. Such a drop SHOULD be logged as a security fault with an indication of what happened.
4. 验证DOI是否为接收接口允许的DOI。具有禁止的DOI的数据报必须以静默方式丢弃。这种下降应记录为安全故障，并指示发生了什么。
5. Verify the Sensitivity Label within the CALIPSO is within the permitted range for the receiving interface:
5. 验证CALIPSO内的灵敏度标签是否在接收接口的允许范围内：
NOTE WELL: Each permitted DOI on an interface has a separate table describing the permitted range for that DOI.
请注意：接口上每个允许的DOI都有一个单独的表，描述该DOI的允许范围。
A rejected datagram with a Sensitivity Label below or disjoint with the permitted range MUST be silently dropped. Such an event SHOULD be logged as a security fault with an indication of what happened. An ICMP error message MUST NOT be sent in this case.
灵敏度标签低于允许范围或与允许范围不相交的被拒绝数据报必须静默删除。此类事件应记录为安全故障，并指示发生了什么。在这种情况下，不得发送ICMP错误消息。
A rejected datagram with a Sensitivity Label above the permitted range MUST be dropped. The drop event SHOULD be logged as a security fault with an indication of what happened. An ICMP error message MUST NOT be sent in this case.
必须删除灵敏度标签高于允许范围的被拒绝数据报。跌落事件应记录为安全故障，并指示发生了什么。在这种情况下，不得发送ICMP错误消息。
If and only if all the above conditions are met is the datagram accepted by the IPv6 Intermediate System for further processing and forwarding.
当且仅当满足上述所有条件时，IPv6中间系统才会接受数据报以进行进一步处理和转发。
At this point, the datagram is within the permitted range for the Intermediate System, so appropriate ICMP error messages MAY be created by the IP module back to the originating End System regarding the forwarding of the datagram. These ICMP messages MUST be created with the exact same Sensitivity Label as the datagram causing the error. Standard rules about generating ICMP error messages (e.g., never generate an ICMP error message in response to a received ICMP error message) continue to apply. Note that these locally generated ICMP messages must go through the same outbound checks (including MAC checks) as any other forwarded datagram as described in the following paragraphs.
此时，数据报在中间系统的允许范围内，因此IP模块可能会创建适当的ICMP错误消息，返回到发起端系统，以转发数据报。创建这些ICMP消息时，必须使用与导致错误的数据报完全相同的敏感度标签。有关生成ICMP错误消息的标准规则（例如，决不生成ICMP错误消息以响应收到的ICMP错误消息）继续适用。请注意，这些本地生成的ICMP消息必须经过与任何其他转发数据报相同的出站检查（包括MAC检查），如以下段落所述。
It is at this point, after input processing and before output processing, that translation of the CALIPSO from one DOI to another DOI takes place in an Intermediate System, if at all. Section 6.4 describes the two possible approaches to translation.
正是在这一点上，在输入处理之后和输出处理之前，CALIPSO从一个DOI到另一个DOI的转换发生在一个中间系统中（如果有的话）。第6.4节描述了两种可能的翻译方法。
Once the forwarding code has selected the interface through which the datagram will be transmitted, the following takes place:
一旦转发代码选择了传输数据报的接口，就会发生以下情况：
1. If the output interface requires that all packets contain a CALIPSO label, then verify that the packet contains a CALIPSO label.
1. 如果输出接口要求所有数据包都包含CALIPSO标签，则验证该数据包是否包含CALIPSO标签。
2. Verify the DOI is a permitted one for the sending interface and that the datagram is within the permitted range for the DOI and for the interface.
2. 验证DOI是发送接口允许的，并且数据报在DOI和接口允许的范围内。
3. Datagrams with prohibited DOIs or with out-of-range Sensitivity Labels MUST be dropped. Any drop event SHOULD be logged as a security fault, including appropriate details about which datagram was dropped and why.
3. 必须删除带有禁止DOI或超出范围敏感标签的数据报。任何丢弃事件都应记录为安全故障，包括关于丢弃哪个数据报以及为什么丢弃的适当详细信息。
4. Datagrams with prohibited DOIs or out-of-range Sensitivity Labels MAY result in an ICMP "Destination Unreachable" error message, depending upon the security configuration of the system.
4. 根据系统的安全配置，带有禁止DOI或超出范围敏感标签的数据报可能会导致ICMP“Destination Unreachable”错误消息。
If the cause of the dropped packet is that the DOI is prohibited or unrecognized, then a reason code of "No Route to Host" is used. If the dropped packet's DOI is valid, but the Sensitivity Label is out of range, then a reason code of "Administratively Prohibited" is used. If an unlabeled packet has been dropped because the packet is required to be labeled, then a reason code of "Administratively Prohibited" is used.
如果丢弃数据包的原因是DOI被禁止或无法识别，则使用“无主机路由”的原因码。如果丢弃的数据包的DOI有效，但敏感度标签超出范围，则使用“管理禁止”的原因码。如果未标记的数据包因需要标记而被丢弃，则使用“管理禁止”的原因码。
In all cases, if an ICMP Error Message is sent, then it MUST be sent with the same Sensitivity Label as the rejected datagram.
在所有情况下，如果发送ICMP错误消息，则必须使用与被拒绝数据报相同的灵敏度标签发送该消息。
The choice of whether or not to send an ICMP message, if sending an ICMP message for this case is implemented, MUST be configurable, and SHOULD default to not sending an ICMP message. Standard conditions about generating ICMP error messages (e.g., never send an ICMP error message about a received ICMP error message) continue to apply.
如果在这种情况下发送ICMP消息，则是否发送ICMP消息的选择必须是可配置的，并且应默认为不发送ICMP消息。有关生成ICMP错误消息的标准条件（例如，决不发送有关接收到的ICMP错误消息的ICMP错误消息）继续适用。
A system that provides on-the-fly relabeling is said to "translate" from one DOI to another. There are basically two ways a datagram can be relabeled:
提供即时重新标记的系统被称为从一个DOI“翻译”到另一个DOI。基本上有两种方法可以重新标记数据报：
Either the Sensitivity Label can be converted from a CALIPSO Sensitivity Label, to an internal Sensitivity Label, and then back to a new CALIPSO Sensitivity Label, exclusive-or a CALIPSO Sensitivity Label can be directly remapped into a new CALIPSO Sensitivity Label.
灵敏度标签可以从CALIPSO灵敏度标签转换为内部灵敏度标签，然后再转换回新的CALIPSO灵敏度标签，或者CALIPSO灵敏度标签可以直接重新映射到新的CALIPSO灵敏度标签。
The first of these methods is the functional equivalent of "importing" the datagram then "exporting" it and is covered in detail in the "Import" (Section 6.2.2) and "Export" (Section 6.2.1) sections above.
第一种方法的功能相当于“导入”数据报，然后“导出”数据报，并在上述“导入”（第6.2.2节）和“导出”（第6.2.1节）章节中详细介绍。
The remainder of this section describes the second method, which is direct relabeling. The choice of which method to use for relabeling is an implementation decision outside the scope of this document.
本节剩余部分将介绍第二种方法，即直接重新标记。选择用于重新标记的方法是本文件范围之外的实施决策。
A system that provides on-the-fly relabeling without importing or exporting is basically a special case of the Intermediate System rules listed above. Translation or relabeling takes place AFTER all input checks take place, but before any output checks are done.
在不导入或导出的情况下提供动态重新标记的系统基本上是上述中间系统规则的特例。翻译或重新标记发生在所有输入检查发生之后，但在任何输出检查完成之前。
Once a datagram has passed the Intermediate System input processing and input validation described in Section 6.3.1, and has been accepted as valid, the CALIPSO in that datagram may be relabeled. To determine the new Sensitivity Label, first determine the new output DOI.
一旦数据报通过了第6.3.1节所述的中间系统输入处理和输入验证，并被视为有效，则可重新标记该数据报中的CALIPSO。要确定新的灵敏度标签，首先确定新的输出DOI。
The selection of the output DOI may be based on any of Incoming DOI, Incoming Sensitivity Label, Destination End System, Destination Network, Destination Subnetwork, Sending Interface, or Receiving Interface, or combinations thereof. Exact details on how the output DOI is selected are implementation dependent, with the caveat that it should be consistent and reversible. If a datagram from End System A to End System B with DOI X maps into DOI Y, then a datagram from B to A with DOI Y should map into DOI X.
输出DOI的选择可以基于传入DOI、传入灵敏度标签、目的地端系统、目的地网络、目的地子网络、发送接口或接收接口中的任何一个，或其组合。关于如何选择输出DOI的确切细节取决于实现，需要注意的是，它应该是一致的和可逆的。如果从端系统a到端系统B的带有DOI X的数据报映射到DOI Y，那么从B到a的带有DOI Y的数据报应该映射到DOI X。
Once the output DOI is selected, the output Sensitivity Label is determined based on (1) the input DOI and input Sensitivity Label and (2) the output DOI. In the event the input Sensitivity Label does not map to a valid output Sensitivity Label for the output DOI, then the datagram MUST be silently dropped and the drop event SHOULD be logged as a security fault.
一旦选择了输出DOI，则根据（1）输入DOI和输入灵敏度标签以及（2）输出DOI来确定输出灵敏度标签。如果输入灵敏度标签未映射到输出DOI的有效输出灵敏度标签，则必须静默删除数据报，并且删除事件应记录为安全故障。
Once the datagram has been relabeled, the Intermediate System output procedures described in Section 6.3.3 are followed, with the exception that any error that would cause an ICMP error message to be generated back to the originating End System instead MUST silently drop the datagram without sending an ICMP error message. Such a drop SHOULD be logged as a security fault.
重新标记数据报后，将遵循第6.3.3节中所述的中间系统输出程序，但会导致ICMP错误消息生成回原始端系统的任何错误必须在不发送ICMP错误消息的情况下自动删除数据报。此类下降应记录为安全故障。
This section contains "implementation considerations"; it does not contain "requirements". Implementation experience might eventually turn some of them into implementation requirements in some future version of this specification.
本节包含“实施注意事项”；它不包含“要求”。在本规范的未来版本中，实现经验可能最终会将其中一些转化为实现需求。
This IPv6 option specification is only a small part of an overall distributed Multi-Level Secure (MLS) deployment. Detailed instructions on how to build a Multi-Level Secure (MLS) device are well beyond the scope of this specification. Additional information on implementing a Multi-Level Secure operating system, for example implementing an MLS End System, is available from a range of sources [TCSEC] [TNI] [CMW] [CC] [ISO-15408] [MLOSPP].
此IPv6选项规范只是整个分布式多级安全（MLS）部署的一小部分。关于如何构建多级安全（MLS）设备的详细说明远远超出了本规范的范围。有关实施多级安全操作系统的更多信息，例如实施MLS终端系统，可从多种来源获得[TCSEC][TNI][CMW][CC][ISO-15408][MLOSPP]。
Because the usual 5-tuple (i.e., Source IP address, Destination IP address, Transport protocol, Source Port, and Destination Port) do not necessarily uniquely identify a flow within a labeled MLS network deployment, some applications or services might be impacted by multiple flows mapping to a single 5-tuple. This might have unexpected impacts in a labeled MLS network deployment using such application protocols. For example, Resource Reservation Protocol (RSVP), Session Initiation Protocol (SIP), and Session Description Protocol (SDP) might be impacted by this.
由于通常的5元组（即，源IP地址、目标IP地址、传输协议、源端口和目标端口）不一定唯一地标识标记的MLS网络部署中的流，因此一些应用程序或服务可能会受到映射到单个5元组的多个流的影响。这可能会对使用此类应用程序协议的标记MLS网络部署产生意外影响。例如，资源预留协议（RSVP）、会话启动协议（SIP）和会话描述协议（SDP）可能会受到此影响。
A number of Commercial-Off-The-Shelf (COTS) applications (e.g., Remote Access Dial-In User Service (RADIUS), Hyper-Text Transfer Protocol (HTTP), and Transport-Layer Security (TLS) web content access) have been included in MLS network deployments for about two decades, without operational difficulties or a need for special modifications. The ability to use these common applications demonstrates that the basic Internet architecture remains unchanged in an MLS deployment, although certain details (e.g., adding labels to IP datagrams) do change.
MLS网络部署中包含了许多商用现货（COTS）应用程序（例如，远程访问拨入用户服务（RADIUS）、超文本传输协议（HTTP）和传输层安全（TLS）web内容访问）大约20年，没有操作困难或需要特殊修改。使用这些通用应用程序的能力表明，MLS部署中的基本Internet架构保持不变，尽管某些细节（例如，向IP数据报添加标签）确实发生了变化。
Historically, RFC 1108 was supported by one commercial label-aware IP router. Neither RFC 1038 nor FIPS-188 were supported in any commercial IP router, so far as the authors are aware. A label-aware router does not necessarily use an MLS operating system. Instead, a label-aware router might use a conventional router operating system, adding extensions to permit application of per-logical-interface label-oriented Access Control Lists (ACLs) to IP packets entering and leaving that router's network interface(s).
过去，RFC1108由一个商业标签感知IP路由器支持。据作者所知，任何商用IP路由器都不支持RFC1038或FIPS-188。标签感知路由器不一定使用MLS操作系统。相反，标签感知路由器可能使用传统的路由器操作系统，添加扩展以允许对进出路由器网络接口的IP数据包应用每逻辑接口面向标签的访问控制列表（ACL）。
This proposal does not change IP routing in any way. Existing label-aware routers do not use Sensitivity Labels in path calculations, Routing Information Base (RIB) or Forwarding Information Base (FIB) calculations, their routing protocols, or their packet forwarding decisions.
此建议不会以任何方式更改IP路由。现有的标签感知路由器在路径计算、路由信息库（RIB）或转发信息库（FIB）计算、路由协议或数据包转发决策中不使用敏感标签。
Similarly, existing MLS network deployments use many protocols or specifications, for example, Differentiated Services, without modification. For Differentiated Services, this might mean that multiple IP flows (i.e., flows differing only in their CALIPSO label value) would be categorized and handled by Intermediate Systems as if they were a single flow.
类似地，现有的MLS网络部署使用许多协议或规范，例如，区分服务，无需修改。对于差异化服务，这可能意味着多个IP流（即仅在CALIPSO标签值上不同的流）将由中间系统进行分类和处理，就像它们是单个流一样。
Router performance is optimized if there is hardware support for applying the Mandatory Access Controls based on this label option. An issue with CIPSO is that the option syntax is remarkably complex [FIPS-188]. So this label option uses a simplified syntax. This
如果有基于此标签选项应用强制访问控制的硬件支持，路由器性能将得到优化。CIPSO的一个问题是选项语法非常复杂[FIPS-188]。所以这个标签选项使用了简化的语法。这
should make it more practical to create custom logic (e.g., in Verilog) with support for this option and the associated Mandatory Access Controls.
应使创建自定义逻辑（例如，在Verilog中）更加实用，并支持此选项和相关的强制访问控制。
It is possible for a system administrator to create two DOIs with different overlapping compartment ranges. This can be used to reduce the size of the IPv6 Sensitivity Label option in some deployments.
系统管理员可以创建两个具有不同重叠隔室范围的DOI。这可用于减少某些部署中IPv6敏感标签选项的大小。
As CALIPSO is an IP option, this document focuses upon the network-layer handling of IP packets containing CALIPSO options. This section provides some discussion of some upper-layer protocol issues.
由于CALIPSO是一个IP选项，本文档重点介绍包含CALIPSO选项的IP数据包的网络层处理。本节讨论了一些上层协议问题。
This section is not a complete specification for how an MLS End System handles information internally after the decision has been made to accept a received IPv6 packet containing a CALIPSO option. Implementers of MLS systems might wish also to consult [TCSEC], [TNI], [CMW], [CC], [ISO-15408], and [MLOSPP].
本节不是MLS终端系统在决定接受包含CALIPSO选项的接收IPv6数据包后如何在内部处理信息的完整规范。MLS系统的实施者可能还希望咨询[TCSEC]、[TNI]、[CMW]、[CC]、[ISO-15408]和[MLOSPP]。
In a typical MLS End System, the information received from the network (i.e., information not dropped by the network layer as a result of the CALIPSO processing described in this document) is assigned an internal Sensitivity Label while inside the End System operating system. The MLS End System uses the Bell-LaPadula Mandatory Access Control policy [BL73] to determine how that information is processed, including to which transport-layer sessions or to which applications the information is delivered.
在典型的MLS终端系统中，从网络接收的信息（即，由于本文件中描述的CALIPSO处理而未被网络层丢弃的信息）在终端系统操作系统内被分配一个内部灵敏度标签。MLS终端系统使用Bell-LaPadula强制访问控制策略[BL73]来确定如何处理该信息，包括将该信息传递到哪个传输层会话或哪个应用程序。
Within this section, we use one additional notation, in an attempt to be both clear and concise. Here, the string "W:XY" defines a Sensitivity Label where the Sensitivity Level is W and where X and Y are the only compartments enabled, while the string "W::" defines a Sensitivity Label where the Sensitivity Level is W and there are no compartments enabled.
在本节中，我们使用了一个额外的符号，试图做到既清晰又简洁。这里，字符串“W:XY”定义了灵敏度标签，其中灵敏度级别为W，X和Y是唯一启用的隔室，而字符串“W:：”定义了灵敏度标签，其中灵敏度级别为W，没有启用的隔室。
With respect to a network, each distinct Sensitivity Label represents a separate virtual network, which shares the same physical network.
对于网络，每个不同的敏感度标签表示一个单独的虚拟网络，该虚拟网络共享同一物理网络。
The above statement, taken from Section 3, has a non-obvious, but critical, corollary. If there are separate virtual networks, then it is possible for a system that exists in multiple virtual networks to have identical TCP connections, each one existing in a different virtual network.
上述来自第3节的陈述有一个不明显但关键的推论。如果存在独立的虚拟网络，则存在于多个虚拟网络中的系统可能具有相同的TCP连接，每个TCP连接存在于不同的虚拟网络中。
TCP connections are normally identified by source and destination port, and source and destination address. If a system labels datagrams with the CALIPSO option (which it must do if it exists in multiple virtual networks - e.g., a "Multi-Level Secure" system), then TCP connections are identified by source and destination port, source and destination address, and an internal Sensitivity Label (optionally, a Sensitivity Label range). This corrects a technical error in RFC 793, and is consistent with all known MLS operating system implementations [TNI] [RFC793]. There are no known currently deployed TCP instances that actually comply with this specific detail of RFC 793.
TCP连接通常由源和目标端口以及源和目标地址标识。如果系统使用CALIPSO选项标记数据报（如果存在于多个虚拟网络中，则必须这样做-例如，“多级安全”系统），则TCP连接通过源和目标端口、源和目标地址以及内部敏感标签（可选，敏感标签范围）进行标识。这纠正了RFC 793中的一个技术错误，并且与所有已知的MLS操作系统实现[TNI][RFC793]一致。目前没有已知部署的TCP实例真正符合RFC 793的这一特定细节。
Unlike TCP or SCTP, UDP is a stateless protocol, at least conceptually. However, many implementations of UDP have some session state (e.g., Protocol Control Blocks in 4.4 BSD), although the UDP protocol specifications do not require any state.
与TCP或SCTP不同，UDP是一种无状态协议，至少在概念上是这样。然而，UDP的许多实现都有一些会话状态（例如，4.4 BSD中的协议控制块），尽管UDP协议规范不需要任何状态。
One consequence of this is that in widely used End System implementations of UDP and IPv6, a UDP listener might be bound only to a particular UDP port on its End System -- without binding to a particular remote IP address or local IP address.
这样做的一个结果是，在广泛使用的UDP和IPv6终端系统实现中，UDP侦听器可能只绑定到其终端系统上的特定UDP端口，而不绑定到特定的远程IP地址或本地IP地址。
UDP can be used with unicast or with multicast. Some existing UDP End System implementations permit a single UDP packet to be delivered to more than one listener at the same time. Except for the application of Mandatory Access Controls, the behavior of a given system should remain the same (so that application behavior does not change in some unexpected way) with respect to delivery of UDP datagrams to listeners.
UDP可用于单播或多播。一些现有的UDP终端系统实现允许将单个UDP数据包同时传递给多个侦听器。除了强制访问控制的应用外，给定系统的行为在向侦听器传递UDP数据报时应保持不变（以便应用程序行为不会以某种意外的方式改变）。
For example, if a listener on UDP port X has a Sensitivity Label range with a minimum of "S:AB" and a maximum of "S:AB", then only datagrams with a destination of UDP port X and a Sensitivity Label of "S:AB" will be delivered to that listener.
例如，如果UDP端口X上的侦听器的敏感标签范围最小为“S:AB”，最大为“S:AB”，则只有目标为UDP端口X且敏感标签为“S:AB”的数据报才会传递给该侦听器。
For example, if a listener on UDP port Y has a Sensitivity Label range with a minimum of "W::" and a maximum of "X:ABC" (where X dominates W), then a datagram addressed to UDP port Y with a Sensitivity Label of "W:A" normally would be delivered to that listener.
例如，如果UDP端口Y上的侦听器的敏感标签范围最小为“W:：”，最大为“X:ABC”（其中X支配W），则通常会向该侦听器发送一个寻址到UDP端口Y且敏感标签为“W:a”的数据报。
With respect to a network, each distinct Sensitivity Label represents a separate virtual network, which shares the same physical network.
对于网络，每个不同的敏感度标签表示一个单独的虚拟网络，该虚拟网络共享同一物理网络。
The above statement, taken from Section 3, has a non-obvious, but critical, corollary. If there are separate virtual networks, then it is possible for a system that exists in multiple virtual networks to have identical SCTP connections, each one existing in a different virtual network.
上述来自第3节的陈述有一个不明显但关键的推论。如果存在独立的虚拟网络，则存在于多个虚拟网络中的系统可能具有相同的SCTP连接，每个SCTP连接存在于不同的虚拟网络中。
As with TCP, SCTP is a connection-oriented transport protocol and has substantial session state. Unlike TCP, SCTP can support session-endpoint migration among IP addresses at the same end node(s), and SCTP can also support both one-to-one and one-to-many communication sessions.
与TCP一样，SCTP是一种面向连接的传输协议，具有大量的会话状态。与TCP不同，SCTP可以支持同一终端节点的IP地址之间的会话端点迁移，并且SCTP还可以支持一对一和一对多通信会话。
In single-level End Systems, in the one-to-one mode, the SCTP session state for a single local SCTP session includes the set of remote IP addresses for the single remote SCTP instance, the set of local IP addresses, the remote SCTP port number, and the local SCTP port number.
在单级终端系统中，在一对一模式下，单个本地SCTP会话的SCTP会话状态包括单个远程SCTP实例的远程IP地址集、本地IP地址集、远程SCTP端口号和本地SCTP端口号。
In single-level End Systems, in the one-to-many mode, the SCTP session state for a single local SCTP instance can have multiple concurrent connections to several different remote SCTP peers. There cannot be more than one connection from a single SCTP instance to any given remote SCTP instance. Thus, in single-level End Systems, in the one-to-many mode, the local SCTP session state includes the set of remote IP addresses, the set of local IP addresses, the remote SCTP port number for each remote SCTP instance, and the (single) local SCTP port number.
在单级终端系统中，在一对多模式下，单个本地SCTP实例的SCTP会话状态可以具有多个到多个不同远程SCTP对等方的并发连接。从单个SCTP实例到任何给定远程SCTP实例的连接不能超过一个。因此，在单级终端系统中，在一对多模式下，本地SCTP会话状态包括远程IP地址集、本地IP地址集、每个远程SCTP实例的远程SCTP端口号和（单个）本地SCTP端口号。
In MLS End Systems, for either SCTP mode, the SCTP session state additionally includes the Sensitivity Label for each SCTP session. A single SCTP session, whether in the one-to-one mode or in the one-to-many mode, MUST have a single Sensitivity Label, rather than a Sensitivity Label range.
在MLS终端系统中，对于任一SCTP模式，SCTP会话状态还包括每个SCTP会话的灵敏度标签。单个SCTP会话，无论是在一对一模式下还是在一对多模式下，都必须具有单个灵敏度标签，而不是灵敏度标签范围。
Unlike TCP, SCTP has the ability to shift an existing SCTP session from one endpoint IP address to a different IP address that belongs to the same endpoint, when one or more endpoints have multiple IP addresses. If such shifting occurs within an MLS deployment, it is important that it only move to an IP address with a Sensitivity Label range that includes that SCTP session's own Sensitivity Label.
与TCP不同，当一个或多个端点具有多个IP地址时，SCTP能够将现有SCTP会话从一个端点IP地址转移到属于同一端点的不同IP地址。如果这种转移发生在MLS部署中，则重要的是它只能移动到具有敏感标签范围的IP地址，该敏感标签范围包括该SCTP会话自己的敏感标签。
Further, although a node might be multi-homed, it is entirely possible that only one of those interfaces is reachable for a given Sensitivity Label value. For example, one network interface on a node might have a Sensitivity Label range from "A::" to "B:XY" (where B dominates A), while a different network interface on the same node might have a Sensitivity Label range from "U::" "U::" (where A dominates U). In that example, if a packet has a CALIPSO label of
此外，尽管节点可能是多宿主的，但对于给定的灵敏度标签值，完全可能只有一个接口是可访问的。例如，节点上的一个网络接口可能具有从“a:：”到“B:XY”（其中B支配a）的灵敏度标签范围，而同一节点上的不同网络接口可能具有从“U:：”到“U:”（其中a支配U）的灵敏度标签范围。在该示例中，如果数据包的CALIPSO标签为
"A:X", then that packet will not be able to use the "U"-only network interface. Hence, an SCTP implementation needs to consider the Sensitivity Label of each SCTP instance on the local system when deciding which of its own IP addresses to communicate to the remote SCTP instance(s) for that SCTP instance. This issue might lead to novel operational issues with SCTP sessions. Implementers ought to give special attention to this SCTP-specific issue.
“A:X”，则该数据包将无法使用仅“U”的网络接口。因此，SCTP实现需要考虑本地系统上的每个SCTP实例的敏感标签，当决定其自己的IP地址与该SCTP实例的远程SCTP实例通信时。此问题可能导致SCTP会话出现新的操作问题。实施者应该特别注意这个SCTP特定的问题。
This option is recommended for deployment only in well-protected private networks that are NOT connected to the global Internet. By definition, such private networks are also composed only of trusted systems that are believed to be trustworthy. So the risk of a denial-of-service attack upon the logging implementation is much lower in the intended deployment environment than it would have been for general Internet deployments.
建议仅在未连接到全球Internet的受良好保护的专用网络中部署此选项。根据定义，此类专用网络也仅由被认为是可信的可信系统组成。因此，在预期的部署环境中，日志实现遭受拒绝服务攻击的风险比一般Internet部署要低得多。
This document describes a mechanism for adding explicit Sensitivity Labels to IPv6 datagrams. The primary purpose of these labels is to facilitate application of Mandatory Access Controls (MAC) in End Systems or Intermediate Systems that implement this specification.
本文档描述了向IPv6数据报添加显式敏感度标签的机制。这些标签的主要目的是促进强制访问控制（MAC）在实施本规范的终端系统或中间系统中的应用。
As such, correct implementation of this mechanism is very critical to the overall security of the systems and networks where this mechanisms is deployed. Use of high-assurance development techniques is encouraged. End users should carefully consider the assurance requirements of their particular deployment, in the context of that deployment's prospective threats.
因此，此机制的正确实现对于部署此机制的系统和网络的总体安全非常关键。鼓励使用高保证开发技术。最终用户应该仔细考虑其特定部署的保证要求，在该部署的未来威胁的背景下。
A concern is that since this label is used for Mandatory Access Controls, some method of binding the Sensitivity Label option to the rest of the packet is needed. Without such binding, malicious modification of the Sensitivity Label in a packet would go undetected. So, implementations of this Sensitivity Label option MUST also implement support for the IP Authentication Header (AH). Implementations MUST permit the system administrator to configure whether or not AH is used.
一个问题是，由于此标签用于强制访问控制，因此需要某种方法将敏感标签选项绑定到数据包的其余部分。如果没有这种绑定，恶意修改数据包中的敏感度标签将无法被检测到。因此，此敏感标签选项的实现还必须实现对IP身份验证头（AH）的支持。实施必须允许系统管理员配置是否使用AH。
ESP with null encryption mechanism can only protect the payload of an IPv6 packet, not any Hop-by-Hop Options. By contrast, AH protects all invariant headers and data of an IPv6 packet, including the CALIPSO Hop-by-Hop Option. The CALIPSO option defined in this document is always an IPv6 Hop-by-Hop Option, because the CALIPSO option needs to be visible to, and parsable by, IPv6 routers and security gateways so that they can apply MAC policy to packets.
带有空加密机制的ESP只能保护IPv6数据包的有效负载，而不能保护任何逐跳选项。相比之下，AH保护IPv6数据包的所有不变头和数据，包括CALIPSO逐跳选项。本文档中定义的CALIPSO选项始终是一个IPv6逐跳选项，因为CALIPSO选项需要对IPv6路由器和安全网关可见并可解析，以便它们可以将MAC策略应用于数据包。
It is anticipated that if AH is being used with a symmetric authentication algorithm, then not only the recipient End System, but also one or more security gateways along the path, will have knowledge of the symmetric key -- so that AH can be used to authenticate the packet, including the CALIPSO label. In this case, all devices knowing that symmetric authentication key would need to be trusted. Alternatively, AH may be used with an asymmetric authentication algorithm, so that the recipient and any security gateways with knowledge of the authentication key can authenticate the packet, including the CALIPSO label.
预计如果AH与对称身份验证算法一起使用，那么不仅接收方端系统，而且路径上的一个或多个安全网关都将知道对称密钥——因此AH可用于验证数据包，包括CALIPSO标签。在这种情况下，所有知道对称身份验证密钥的设备都需要被信任。或者，AH可与非对称认证算法一起使用，以便接收方和任何知道认证密钥的安全网关可以认证分组，包括CALIPSO标签。
If AH or ESP are employed to provide "labeled IP Security" within some CALIPSO deployment, then the Sensitivity Label of the IP Security Association used for a given packet MUST have the same meaning as the Sensitivity Label carried in the CALIPSO option of that packet, in order that MAC policy can and will be correctly applied.
如果AH或ESP用于在某些CALIPSO部署中提供“标记的IP安全”，则用于给定数据包的IP安全关联的敏感标签必须与该数据包的CALIPSO选项中携带的敏感标签具有相同的含义，以便能够并将正确应用MAC策略。
Because the IP Authentication Header will include the CALIPSO option among the protected IPv6 header fields, modification of a CALIPSO-labeled packet that also contains an IP Authentication Header will cause the resulting packet to fail authentication at the destination node for the AH security session. Therefore, CALIPSO labels cannot be inserted, deleted, or translated for IPv6 packets that contain an IP Authentication Header.
由于IP认证报头将在受保护的IPv6报头字段中包括CALIPSO选项，因此修改也包含IP认证报头的CALIPSO标记的数据包将导致生成的数据包在AH安全会话的目标节点的认证失败。因此，对于包含IP身份验证标头的IPv6数据包，无法插入、删除或翻译CALIPSO标签。
NOTE WELL: The "not modified during transit" bit for IPv6 option types was really created to be the "include in AH calculations" signal. There was no other reason to define that bit in IPv6.
请注意：IPv6选项类型的“传输期间未修改”位实际上被创建为“包含在AH计算中”信号。没有其他理由在IPv6中定义该位。
In situations where a modification by an Intermediate System is required by policy, but is not possible due to AH, then the packet MUST be dropped instead. If the packet must be dropped for this reason, then an ICMP "Destination Unreachable" error message SHOULD be sent back to the originator of the dropped packet with a reason code of "Administratively Prohibited". If the packet can be forwarded properly without violating the MLS MAC policy of the Intermediate System, then (by definition) such a packet modification is not required.
如果策略要求中间系统进行修改，但由于AH而无法进行修改，则必须丢弃数据包。如果出于此原因必须丢弃数据包，则应将ICMP“Destination Unreachable”（目的地不可到达）错误消息发送回丢弃数据包的发起人，原因代码为“管理禁止”。如果可以在不违反中间系统的MLS MAC策略的情况下正确地转发分组，则（根据定义）不需要这样的分组修改。
Note that in a number of error situations with labeled networking, an ICMP error message MUST NOT be sent in order to avoid creating security problems. In certain other error situations, an ICMP error message might be sent. Such ICMP handling details have been described earlier in this document. Even if an ICMP error message is sent, it might be dropped along the way before reaching its intended destination -- due to MAC rules, DOI differences, or other configured security policies along the way from the node creating the ICMP error
请注意，在标记为networking的许多错误情况下，不得发送ICMP错误消息，以避免产生安全问题。在某些其他错误情况下，可能会发送ICMP错误消息。此类ICMP处理细节已在本文件前面描述。即使发送了ICMP错误消息，由于MAC规则、DOI差异或从创建ICMP错误的节点沿途配置的其他安全策略，它也可能在到达预期目的地之前被丢弃
message to the intended destination node. In turn, this can mean operational faults (e.g., fibre cut, misconfiguration) in a labeled network deployment might be more difficult to identify and resolve.
将消息发送到预期的目标节点。反过来，这可能意味着标记的网络部署中的操作故障（例如，光纤切断、配置错误）可能更难识别和解决。
This mechanism is only intended for deployment in very limited circumstances where a set of systems and networks are in a well-protected operating environment and the threat of external or internal attack on this mechanism is considered acceptable to the accreditor of those systems and networks. IP packets containing visible packet labels ought never traverse the public Internet.
此机制仅适用于在非常有限的情况下部署，其中一组系统和网络处于受良好保护的操作环境中，且这些系统和网络的认证机构可接受对该机制的外部或内部攻击威胁。包含可见数据包标签的IP数据包不应穿越公共互联网。
This specification does not seek to eliminate all possible covert channels. The TCP specification clarification in Section 7.3.1 happens to reduce the bandwidth of a particular known covert channel, but is present primarily to clarify how networked MLS systems have always been implemented [TNI] [MLOSPP].
本规范并不试图消除所有可能的隐蔽通道。第7.3.1节中的TCP规范说明恰好减少了特定已知隐蔽信道的带宽，但主要是为了说明网络化MLS系统始终是如何实现的[TNI][MLOSPP]。
Of course, subject to local security policies, encrypted IPv6 packets with CALIPSO labels might well traverse the public Internet after receiving suitable cryptographic protection. For example, a CALIPSO-labeled packet might travel either through a Tunnel-mode ESP (with encryption) VPN tunnel that connects two or more MLS-labeled network segments. Alternatively, a CALIPSO-labeled IPv6 packet might travel over some external link that has been protected by the deployment of evaluated, certified, and accredited bulk encryptors that would encrypt the labeled packet before transmission onto the link and decrypt the labeled packet after reception from the link.
当然，根据本地安全策略，带有CALIPSO标签的加密IPv6数据包在接受适当的加密保护后很可能会穿越公共互联网。例如，CALIPSO标记的数据包可能通过隧道模式ESP（带加密）VPN隧道传输，该隧道连接两个或多个MLS标记的网段。或者，CALIPSO标记的IPv6数据包可能会在某个外部链路上传输，该链路已通过部署经评估、认证和认可的批量加密机进行保护，该批量加密机将在传输到链路上之前对标记的数据包进行加密，并在从链路接收到标记的数据包后对其进行解密。
Accreditors of a given CALIPSO deployment should consider not only personnel clearances and physical security issues, but also electronic security (e.g., TEMPEST), network security (NETSEC), communications security (COMSEC), and other issues. This specification is only a small component of an overall MLS network deployment.
一个给定的CALIPSO部署的认证人员不仅要考虑人员间隙和物理安全问题，还要考虑电子安全（例如，TEMPEST）、网络安全（NETSEC）、通信安全（COMSEC）等问题。本规范只是整个MLS网络部署的一小部分。
An IPv6 Option Number [RFC2460] has been registered for CALIPSO.
已为CALIPSO注册IPv6选项号[RFC2460]。
HEX BINARY
act chg rest
--- --- --- -----
7 00 0 00111 CALIPSO
HEX BINARY
act chg rest
--- --- --- -----
7 00 0 00111 CALIPSO
For the IPv6 Option Number, the first two bits indicate that the IPv6 node skip over this option and continue processing the header if it does not recognize the option type. The third bit indicates that the Option Data must not change en route.
对于IPv6选项编号，前两位表示IPv6节点跳过此选项，如果无法识别选项类型，则继续处理标头。第三位表示选项数据不得在途中更改。
This document is listed as the reference document.
本文件列为参考文件。
IANA has created a registry for CALIPSO DOI values. The initial values for the CALIPSO DOI registry, shown in colon-separated quad format, are as follows:
IANA已经为CALIPSO DOI值创建了一个注册表。CALIPSO DOI注册表的初始值以冒号分隔的四元格式显示，如下所示：
DOI Value Organization or Use
======================= ============================
0:0:0:0 NULL DOI. This ought not
be used on any network.
DOI Value Organization or Use
======================= ============================
0:0:0:0 NULL DOI. This ought not
be used on any network.
0:0:0:1 to 0:255:255:255 For private use among consenting parties within private networks.
0:0:0:1至0:255:255:255，供私人网络内同意方之间的私人使用。
1:0:0:0 to 254:255:255:255 For assignment by IANA to organizations following the Expert Review procedure [RFC5226].
1:0:0:0至254:255:255:255，供IANA按照专家评审程序分配给组织[RFC5226]。
255:0:0:0 to 255:255:255:255 Reserved to the IETF for future use by possible revisions of this specification.
255:0:0:0至255:255:255:255保留给IETF，以供本规范可能的修订版将来使用。
The CALIPSO DOI value 0:0:0:0 is the NULL DOI and is not to be used on any network or in any deployment.
CALIPSO DOI值0:0:0:0是空DOI，不能在任何网络或任何部署中使用。
All other CALIPSO DOI values beginning with decimal 0: are reserved for private use amongst consenting parties; values in this range will not be allocated by IANA to any particular user or user community.
以小数点0:开头的所有其他CALIPSO DOI值保留给同意方私人使用；IANA不会将此范围内的值分配给任何特定用户或用户社区。
For the CALIPSO DOI values 1:0:0:0 through 254:255:255:255 (inclusive), IANA should follow the Expert Review procedure when DOI Allocation requests are received.
对于CALIPSO DOI值1:0:0:0至254:255:255:255（含），IANA在收到DOI分配请求时应遵循专家评审程序。
CALIPSO DOI values beginning with decimal 255 are reserved to the IETF for potential future use in revisions of this specification. IESG approval is required for allocation of DOI values within that range.
以十进制255开头的CALIPSO DOI值保留给IETF，以备将来在本规范修订版中使用。在该范围内分配DOI值需要IESG批准。
This document is directly derived from an Internet-Draft titled "Son of IPSO (SIPSO)" written by Mike StJohns circa 1992. Various changes have been made since then, primarily to support IPv6 instead of IPv4. The concepts, most definitions, and nearly all of the processing rules here are identical to those in that earlier document.
本文件直接来源于Mike StJohns大约于1992年撰写的题为“IPSO之子（SIPSO）”的互联网草案。从那时起，已经进行了各种更改，主要是为了支持IPv6而不是IPv4。这里的概念、大多数定义和几乎所有的处理规则都与前面文档中的相同。
Steve Brenneman, L.C. Bruzenak, James Carlson, Pasi Eronen, Michael Fidler, Bob Hinden, Alfred Hoenes, Russ Housley, Suresh Krishnan, Jarrett Lu, Dan McDonald, Paul Moore, Joe Nall, Dave Parker, Tim Polk, Ken Powell, Randall Stewart, Bill Sommerfeld, and Joe Touch (listed in alphabetical order by family name) provided specific feedback on earlier versions of this document.
Steve Brenneman、L.C.Bruzenak、James Carlson、Pasi Eronen、Michael Fidler、Bob Hinden、Alfred Hoenes、Russ Housley、Suresh Krishnan、Jarrett Lu、Dan McDonald、Paul Moore、Joe Nall、Dave Parker、Tim Polk、Ken Powell、Randall Stewart、Bill Sommerfeld和Joe Touch（按姓氏字母顺序排列）提供了有关本文档早期版本的具体反馈。
The authors also would like to thank the several anonymous reviewers for their feedback, and particularly for sharing their insights into operational considerations with MLS networking.
作者还想感谢几位匿名评论员的反馈，特别是感谢他们与MLS网络分享他们对运营考虑的见解。
The authors would like to thank the IESG as a whole for providing feedback on earlier versions of this document.
作者要感谢IESG作为一个整体提供了对本文件早期版本的反馈。
[RFC1662] Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994.
[RFC1662]辛普森，W.，编辑，“HDLC类框架中的PPP”，标准51，RFC1662，1994年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[BL73] Bell, D.E. and LaPadula, L.J., "Secure Computer Systems: Mathematical Foundations and Model", Technical Report M74-244, MITRE Corporation, Bedford, MA, May 1973.
[BL73]Bell，D.E.和LaPadula，L.J.，“安全计算机系统：数学基础和模型”，技术报告M74-244，麻省贝德福德米特尔公司，1973年5月。
[CW87] D.D. Clark and D.R. Wilson, "A Comparison of Commercial and Military Computer Security Policies", in Proceedings of the IEEE Symposium on Security and Privacy, pp. 184-194, IEEE Computer Society, Oakland, CA, May 1987.
[CW87]D.D.Clark和D.R.Wilson，“商用和军用计算机安全政策的比较”，《IEEE安全和隐私研讨会论文集》，第184-194页，IEEE计算机学会，加利福尼亚州奥克兰，1987年5月。
[CMW] US Defense Intelligence Agency, "Compartmented Mode Workstation Evaluation Criteria", Technical Report DDS-2600-6243-91, Washington, DC, November 1991.
[CMW]美国国防情报局，“分隔式工作站评估标准”，技术报告DDS-2600-6243-91，华盛顿特区，1991年11月。
[DoD5200.1-R] US Department of Defense, "Information Security Program Regulation", DoD 5200.1-R, 17 January 1997.
[DoD5200.1-R]美国国防部，“信息安全计划条例”，国防部5200.1-R，1997年1月17日。
[DoD5200.28] US Department of Defense, "Security Requirements for Automated Information Systems," Directive 5200.28, 21 March 1988.
[DoD5200.28]美国国防部，“自动化信息系统的安全要求”，指令5200.281988年3月21日。
[MLOSPP] US Department of Defense, "Protection Profile for Multi-level Operating Systems in Environments requiring Medium Robustness", Version 1.22, 23 May 2001.
[MLOSPP]美国国防部，“需要中等健壮性的环境中多级操作系统的保护配置文件”，版本1.22，2001年5月23日。
[ISO-15408] International Standards Organisation, "Evaluation Criteria for IT Security", ISO/IEC 15408, 2005.
[ISO-15408]国际标准组织，“IT安全评估标准”，ISO/IEC 154082005。
[CC] "Common Criteria for Information Technology Security Evaluation", Version 3.1, Revision 1, CCMB-2006-09-001, September 2006.
[CC]“信息技术安全评估通用标准”，3.1版，第1版，CCMB-2006-09-001，2006年9月。
[TCSEC] US Department of Defense, "Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, 26 December 1985.
[TCSEC]美国国防部，“可信计算机系统评估标准”，国防部5200.28-STD，1985年12月26日。
[TNI] (US) National Computer Security Center, "Trusted Network Interpretation (TNI) of the Trusted Computer System Evaluation Criteria", NCSC-TG-005, Version 1, 31 July 1987.
[TNI]（美国）国家计算机安全中心，“可信计算机系统评估标准的可信网络解释（TNI）”，NCSC-TG-005，版本1，1987年7月31日。
[FIPS-188] US National Institute of Standards and Technology, "Standard Security Labels for Information Transfer", Federal Information Processing Standard (FIPS) 188, September 1994.
[FIPS-188]美国国家标准与技术研究所，“信息传输的标准安全标签”，联邦信息处理标准（FIPS）188，1994年9月。
[IEEE802.1Q] IEEE, "Virtual Bridged Local Area Networks", IEEE Standard for Local and metropolitan area networks, 802.1Q - 2005, ISBN 0-7381-4876-6, IEEE, New York, NY, USA, 19 May 2006.
[IEEE802.1Q]IEEE，“虚拟桥接局域网”，IEEE局域网和城域网标准，802.1Q-2005，ISBN 0-7381-4876-6，IEEE，纽约，纽约，美国，2006年5月19日。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1038] St. Johns, M., "Draft revised IP security option", RFC 1038, January 1988.
[RFC1038]圣约翰，M.，“修订后的IP安全选项草案”，RFC 1038，1988年1月。
[RFC1108] Kent, S., "U.S. Department of Defense Security Options for the Internet Protocol", RFC 1108, November 1991.
[RFC1108]Kent，S.，“美国国防部互联网协议的安全选项”，RFC1108，1991年11月。
[RFC1825] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[RFC1825]阿特金森，R.，“互联网协议的安全架构”，RFC18251995年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
Authors' Addresses
作者地址
Michael StJohns Germantown, MD USA
Michael StJohns Germantown，美国医学博士
EMail: mstjohns@comcast.net
EMail: mstjohns@comcast.net
Randall Atkinson Extreme Networks 3585 Monroe Street Santa Clara, CA USA 95051
美国加利福尼亚州圣克拉拉门罗街3585号Randall Atkinson极端网络公司95051
EMail: rja@extremenetworks.com
Phone: +1 (408)579-2800
EMail: rja@extremenetworks.com
Phone: +1 (408)579-2800
Georg Thomas US Department of Defense Washington, DC USA
乔治托马斯美国国防部华盛顿特区美国