Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7371 France Telecom
Updates: 3306, 3956, 4291 S. Venaas
Category: Standards Track Cisco
ISSN: 2070-1721 September 2014
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 7371 France Telecom
Updates: 3306, 3956, 4291 S. Venaas
Category: Standards Track Cisco
ISSN: 2070-1721 September 2014
Updates to the IPv6 Multicast Addressing Architecture
IPv6多播寻址体系结构的更新
Abstract
摘要
This document updates the IPv6 multicast addressing architecture by redefining the reserved bits as generic flag bits. The document also provides some clarifications related to the use of these flag bits.
本文档通过将保留位重新定义为通用标志位来更新IPv6多播寻址体系结构。本文件还对这些标志位的使用进行了一些澄清。
This document updates RFCs 3956, 3306, and 4291.
本文档更新了RFCs 3956、3306和4291。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7371.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7371.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 ....................................................3
1.1. Requirements Language ......................................3
2. Addressing Architecture Update ..................................3
3. Flag Bits: New Processing Rules .................................4
4. RFC Updates .....................................................4
4.1. Updates to RFC 3306 ........................................4
4.1.1. Update #1 ...........................................4
4.1.2. Update #2 ...........................................6
4.2. Updates to RFC 3956 ........................................6
4.2.1. Update #1 ...........................................6
4.2.2. Update #2 ...........................................7
4.2.3. Update #3 ...........................................8
4.2.4. Update #4 ...........................................9
5. Security Considerations .........................................9
6. Acknowledgements ................................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
1. Introduction ....................................................3
1.1. Requirements Language ......................................3
2. Addressing Architecture Update ..................................3
3. Flag Bits: New Processing Rules .................................4
4. RFC Updates .....................................................4
4.1. Updates to RFC 3306 ........................................4
4.1.1. Update #1 ...........................................4
4.1.2. Update #2 ...........................................6
4.2. Updates to RFC 3956 ........................................6
4.2.1. Update #1 ...........................................6
4.2.2. Update #2 ...........................................7
4.2.3. Update #3 ...........................................8
4.2.4. Update #4 ...........................................9
5. Security Considerations .........................................9
6. Acknowledgements ................................................9
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References ....................................10
This document updates the IPv6 addressing architecture [RFC4291] by redefining reserved bits as generic flag bits (Section 2). The document also provides some clarifications related to the use of these flag bits (Section 3).
本文档通过将保留位重新定义为通用标志位（第2节），更新了IPv6寻址体系结构[RFC4291]。本文件还对这些标志位的使用进行了一些澄清（第3节）。
This document updates [RFC3956], [RFC3306], and [RFC4291]. These updates are logical consequences of the new processing rules in Section 3.
本文件更新了[RFC3956]、[RFC3306]和[RFC4291]。这些更新是第3节中新处理规则的逻辑结果。
Textual representation of IPv6 addresses included in the RFC updates follows the recommendation in [RFC5952].
RFC更新中包含的IPv6地址的文本表示遵循[RFC5952]中的建议。
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]中所述进行解释。
Bits 17-20 of a multicast address, where bit 1 is the most significant bit, are defined in [RFC3956] and [RFC3306] as reserved bits. This document defines these bits as generic flag bits so that they apply to any multicast address. These bits are referred to as "ff2" (flag field 2), while the "flgs" bits in [RFC4291] [RFC3956] are renamed to "ff1" (flag field 1).
[RFC3956]和[RFC3306]将多播地址的位17-20定义为保留位，其中位1是最高有效位。本文档将这些位定义为通用标志位，以便它们应用于任何多播地址。这些位被称为“ff2”（标志字段2），而[RFC4291][RFC3956]中的“flgs”位被重命名为“ff1”（标志字段1）。
Within this document, flag bits denote both ff1 and ff2.
在此文档中，标志位表示ff1和ff2。
Defining the bits 17-20 as flags for all IPv6 multicast addresses allows addresses to be treated in a more uniform and generic way, and allows for these bits to be defined in the future for different purposes, irrespective of the specific type of multicast address. For the record, this design choice was initially triggered by the specification in [ADDR-FORMAT], which proposed associating a meaning with one of the reserved bits. Moreover, [ADDR-FORMAT] also considered the use of the last remaining flag in ff1, but that approach was abandoned because it is not clear at this stage whether there are other usage scenarios of the flag.
将位17-20定义为所有IPv6多播地址的标志允许以更统一和通用的方式处理地址，并允许将来为不同目的定义这些位，而不管多播地址的具体类型。作为记录，这种设计选择最初是由[ADDR-FORMAT]中的规范触发的，该规范建议将一个含义与一个保留位相关联。此外，[ADDR-FORMAT]还考虑了ff1中最后一个剩余标志的使用，但该方法已被放弃，因为目前尚不清楚该标志是否存在其他使用场景。
Section 4 specifies the updated structure of the addressing architecture.
第4节规定了寻址体系结构的更新结构。
Further specification documents may define a meaning for these flag bits.
进一步的规范文档可以定义这些标志位的含义。
Some implementations and specification documents do not treat the flag bits as separate bits but tend to use their combined value as a 4-bit integer. This practice is a hurdle for assigning a meaning to the remaining flag bits. Below are listed some examples for illustration purposes:
一些实现和规范文档不将标志位视为单独的位，而是倾向于将其组合值作为4位整数。这种做法是为剩余标志位分配意义的障碍。以下列出了一些示例，以供说明：
o The reading of [RFC3306] may lead one to conclude that ff3x::/32 is the only allowed Source-Specific Multicast (SSM) IPv6 prefix block.
o 读取[RFC3306]可能会得出结论，ff3x:：/32是唯一允许的源特定多播（SSM）IPv6前缀块。
o [RFC3956] states that only ff70::/12 applies to Embedded-RP. Particularly, implementations should not treat the fff0::/12 range as Embedded-RP.
o [RFC3956]指出只有ff70:：/12适用于嵌入式RP。特别是，实现不应将fff0:：/12范围视为嵌入式RP。
To avoid such confusion and to unambiguously associate a meaning with the remaining flags, the following requirement is made:
为避免此类混淆，并将含义与剩余标志明确关联，提出以下要求：
Implementations MUST treat flag bits as separate bits.
实现必须将标志位视为单独的位。
This document changes Section 4 of [RFC3306] as follows:
本文件将[RFC3306]第4节更改如下：
OLD:
旧的：
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+
+-+-+-+-+
flgs is a set of 4 flags: |0|0|P|T|
+-+-+-+-+
+-+-+-+-+
flgs is a set of 4 flags: |0|0|P|T|
+-+-+-+-+
o P = 0 indicates a multicast address that is not assigned based on the network prefix. This indicates a multicast address as defined in [ADDRARCH].
o P=0表示未根据网络前缀分配的多播地址。这表示[ADDRARCH]中定义的多播地址。
o P = 1 indicates a multicast address that is assigned based on the network prefix.
o P=1表示根据网络前缀分配的多播地址。
o If P = 1, T MUST be set to 1, otherwise the setting of the T bit is defined in Section 2.7 of [ADDRARCH].
o 如果P=1，T必须设置为1，否则T位的设置在[ADDRARCH]第2.7节中定义。
The reserved field MUST be zero.
保留字段必须为零。
Note: [ADDRARCH] is a reference listed in [RFC3306]. [ADDRARCH] has been since obsoleted by [RFC4291].
注：[ADDRARCH]是[RFC3306]中列出的参考。[ADDRARCH]已被[RFC4291]淘汰。
NEW:
新的：
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+--------+----------------+----------+
|11111111|ff1 |scop|ff2 |rsvd| plen | network prefix | group ID |
+--------+----+----+----+----+--------+----------------+----------+
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+--------+----------------+----------+
|11111111|ff1 |scop|ff2 |rsvd| plen | network prefix | group ID |
+--------+----+----+----+----+--------+----------------+----------+
+-+-+-+-+
ff1 (flag field 1) is a set of 4 flags: |X|Y|P|T|
+-+-+-+-+
+-+-+-+-+
ff1 (flag field 1) is a set of 4 flags: |X|Y|P|T|
+-+-+-+-+
X and Y may each be set to 0 or 1. Note that X is for future assignment, while a meaning is associated with Y in RFC 3956.
X和Y可以分别设置为0或1。请注意，X代表未来的赋值，而RFC 3956中的含义与Y相关。
o P = 0 indicates a multicast address that is not assigned based on the network prefix. This indicates a multicast address as defined in [RFC4291].
o P=0表示未根据网络前缀分配的多播地址。这表示[RFC4291]中定义的多播地址。
o P = 1 indicates a multicast address that is assigned based on the network prefix.
o P=1表示根据网络前缀分配的多播地址。
o If P = 1, T MUST be set to 1; otherwise, the setting of the T bit is defined in Section 2.7 of [RFC4291].
o 如果P=1，则T必须设置为1；否则，T位的设置在[RFC4291]第2.7节中定义。
+-+-+-+-+
ff2 (flag field 2) is a set of 4 flags: |r|r|r|r|
+-+-+-+-+
+-+-+-+-+
ff2 (flag field 2) is a set of 4 flags: |r|r|r|r|
+-+-+-+-+
where "rrrr" are for future assignment as additional flag bits. r bits MUST each be sent as zero and MUST be ignored on receipt.
其中“rrrr”作为附加标志位用于将来的分配。r位必须以零的形式发送，并且在接收时必须忽略。
Flag bits denote both ff1 and ff2.
标志位表示ff1和ff2。
This document changes Section 6 of [RFC3306] as follows:
本文件将[RFC3306]第6节更改如下：
OLD:
旧的：
These settings create an SSM range of FF3x::/32 (where 'x' is any valid scope value). The source address field in the IPv6 header identifies the owner of the multicast address.
这些设置创建的SSM范围为FF3x:：/32（其中“x”是任何有效的范围值）。IPv6标头中的源地址字段标识多播地址的所有者。
NEW:
新的：
If the flag bits in ff1 are set to 0011, these settings create an SSM range of ff3x::/32 (where 'x' is any valid scope value). The source address field in the IPv6 header identifies the owner of the multicast address. ff3x::/32 is not the only allowed SSM prefix range. For example, if the most significant flag bit in ff1 is set, then we would get the SSM range ffbx::/32.
如果ff1中的标志位设置为0011，则这些设置将创建ff3x:：/32的SSM范围（其中“x”是任何有效范围值）。IPv6标头中的源地址字段标识多播地址的所有者。ff3x:：/32不是唯一允许的SSM前缀范围。例如，如果设置了ff1中的最高有效标志位，则我们将获得SSM范围ffbx:：/32。
This document changes Section 2 of [RFC3956] as follows:
本文件将[RFC3956]第2节更改如下：
OLD:
旧的：
As described in [RFC3306], the multicast address format is as follows:
如[RFC3306]所述，多播地址格式如下：
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+----+----------------+----------+
|11111111|flgs|scop|reserved|plen| network prefix | group ID |
+--------+----+----+--------+----+----------------+----------+
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+----+----------------+----------+
|11111111|flgs|scop|reserved|plen| network prefix | group ID |
+--------+----+----+--------+----+----------------+----------+
Where flgs are "0011". (The first two bits are as yet undefined, sent as zero and ignored on receipt.)
其中FLG为“0011”。（前两位尚未定义，发送为零，接收时忽略。）
NEW:
新的：
The multicast address format is as follows:
多播地址格式如下：
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|ff1 |scop|ff2 |rsvd|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|ff1 |scop|ff2 |rsvd|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
+-+-+-+-+
ff1 (flag field 1) is a set of four flags: |X|R|P|T|
+-+-+-+-+
+-+-+-+-+
ff1 (flag field 1) is a set of four flags: |X|R|P|T|
+-+-+-+-+
where X is for future assignment as an additional flag bit. X may be set to 0 or 1.
其中，X作为附加标志位用于将来的分配。X可以设置为0或1。
+-+-+-+-+
ff2 (flag field 2) is a set of 4 flags: |r|r|r|r|
+-+-+-+-+
+-+-+-+-+
ff2 (flag field 2) is a set of 4 flags: |r|r|r|r|
+-+-+-+-+
where "rrrr" are for future assignment as additional flag bits. r bits MUST each be sent as zero and MUST be ignored on receipt.
其中“rrrr”作为附加标志位用于将来的分配。r位必须以零的形式发送，并且在接收时必须忽略。
Flag bits denote both ff1 and ff2.
标志位表示ff1和ff2。
This document changes Section 3 of [RFC3956] as follows:
本文件将[RFC3956]第3节更改如下：
OLD:
旧的：
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
+-+-+-+-+
flgs is a set of four flags: |0|R|P|T|
+-+-+-+-+
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
+-+-+-+-+
flgs is a set of four flags: |0|R|P|T|
+-+-+-+-+
When the highest-order bit is 0, R = 1 indicates a multicast address that embeds the address on the RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as specified in [RFC3306]. In effect, this implies the prefix FF70::/12. In this case, the last 4 bits of the previously reserved field are interpreted as embedding the RP interface ID, as specified in this memo.
当最高阶位为0时，R=1表示将地址嵌入RP的多播地址。然后P必须设置为1，因此T必须设置为1，如[RFC3306]中所述。实际上，这意味着前缀FF70:：/12。在这种情况下，先前保留字段的最后4位被解释为嵌入RP接口ID，如本备忘录中所述。
The behavior is unspecified if P or T is not set to 1, as then the prefix would not be FF70::/12. Likewise, the encoding and the protocol mode used when the two high-order bits in "flgs" are set to 11 ("FFF0::/12") is intentionally unspecified until such time that the highest-order bit is defined. Without further IETF specification, implementations SHOULD NOT treat the FFF0::/12 range as Embedded-RP.
如果P或T未设置为1，则行为未指定，因为前缀将不是FF70:：/12。同样，当“flgs”中的两个高阶位被设置为11（“FFF0:：/12”）时使用的编码和协议模式有意地未指定，直到定义了最高阶位为止。如果没有进一步的IETF规范，实现不应将FFF0:：/12范围视为嵌入式RP。
NEW:
新的：
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|ff1 |scop|ff2 |RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
+-+-+-+-+
ff1 is a set of four flags: |X|R|P|T|
+-+-+-+-+
where X is for future assignment as an additional flag bit.
X may be set to 0 or 1.
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|ff1 |scop|ff2 |RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
+-+-+-+-+
ff1 is a set of four flags: |X|R|P|T|
+-+-+-+-+
where X is for future assignment as an additional flag bit.
X may be set to 0 or 1.
R = 1 indicates a multicast address that embeds the address of the RP. Then, P MUST be set to 1, and consequently T MUST be set to 1, according to [RFC3306], as this is a special case of unicast-prefix-based addresses. This implies that, for instance, prefixes ff70::/12 and fff0::/12 are embedded RP prefixes. When the R-bit is set, the last 4 bits of the field that were reserved in [RFC3306] are interpreted as embedding the RP interface ID, as specified in this memo.
R=1表示嵌入RP地址的多播地址。然后，根据[RFC3306]，P必须设置为1，因此T必须设置为1，因为这是基于前缀的单播地址的特殊情况。这意味着，例如，前缀ff70:：/12和fff0:：/12是嵌入的RP前缀。设置R位时，[RFC3306]中保留的字段的最后4位被解释为嵌入RP接口ID，如本备忘录中所述。
This document changes Section 4 of [RFC3956] as follows:
本文件将[RFC3956]第4节更改如下：
OLD:
旧的：
o It MUST be a multicast address with "flgs" set to 0111, that is, to be of the prefix FF70::/12,
o 它必须是“flgs”设置为0111的多播地址，即前缀FF70:：/12，
NEW:
新的：
o It MUST be a multicast address with the R-bit set to 1.
o 它必须是R位设置为1的多播地址。
o It MUST have the P-bit and T-bit both set to 1 when using the embedding in this document as it is a prefix-based address.
o 在本文档中使用嵌入时，必须将P位和T位都设置为1，因为它是基于前缀的地址。
This document changes Section 7.1 of [RFC3956] as follows:
本文件将[RFC3956]第7.1节更改如下：
OLD:
旧的：
To avoid loops and inconsistencies, for addresses in the range FF70::/12, the Embedded-RP mapping MUST be considered the longest possible match and higher priority than any other mechanism.
为避免循环和不一致，对于FF70:：/12范围内的地址，必须将嵌入的RP映射视为最长的匹配，并且比任何其他机制的优先级更高。
NEW:
新的：
To avoid loops and inconsistencies, for addresses with the R-bit set to 1, the Embedded-RP mapping MUST be considered the longest possible match and higher priority than any other mechanism.
为了避免循环和不一致，对于R位设置为1的地址，必须将嵌入的RP映射视为最长的匹配，并比任何其他机制具有更高的优先级。
The same security considerations as those discussed in [RFC3956], [RFC3306], and [RFC4291] are to be taken into account.
应考虑与[RFC3956]、[RFC3306]和[RFC4291]中讨论的安全注意事项相同的安全注意事项。
Special thanks to Brian Haberman for the discussions prior to the publication of this document.
特别感谢Brian Haberman在本文件出版前的讨论。
Many thanks to Jouni Korhonen, Tatuya Jinmei, Charlie Kaufman, and Ben Campbell for their review.
非常感谢Jouni Korhonen、Tatuya Jinmei、Charlie Kaufman和Ben Campbell的评论。
[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月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月。
[ADDR-FORMAT] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv6 Multicast Address With Embedded IPv4 Multicast Address", Work in Progress, April 2013.
[ADDR-FORMAT]Boucadair，M.，Qin，J.，Lee，Y.，Venaas，S.，Li，X.，和M.Xu，“具有嵌入式IPv4多播地址的IPv6多播地址”，正在进行的工作，2013年4月。
Authors' Addresses
作者地址
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Stig Venaas Cisco USA
美国思科科技有限公司
EMail: stig@cisco.com
EMail: stig@cisco.com