Internet Engineering Task Force (IETF)                      M. Behringer
Request for Comments: 7404                                     E. Vyncke
Category: Informational                                            Cisco
ISSN: 2070-1721                                            November 2014
Internet Engineering Task Force (IETF)                      M. Behringer
Request for Comments: 7404                                     E. Vyncke
Category: Informational                                            Cisco
ISSN: 2070-1721                                            November 2014

Using Only Link-Local Addressing inside an IPv6 Network




In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.


Status of This Memo


This document is not an Internet Standards Track specification; it is published for informational purposes.


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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents


   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Using Link-Local Addressing on Infrastructure Links . . . . .   2
     2.1.  The Approach  . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Advantages  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Caveats . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Internet Exchange Points  . . . . . . . . . . . . . . . .   6
     2.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   4.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Using Link-Local Addressing on Infrastructure Links . . . . .   2
     2.1.  The Approach  . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Advantages  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Caveats . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.  Internet Exchange Points  . . . . . . . . . . . . . . . .   6
     2.5.  Summary . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   4.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Acknowledgments   . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
1. Introduction
1. 介绍

An infrastructure link between a set of routers typically does not require global or unique local addresses [RFC4193]. Using only link-local addressing on such links has a number of advantages; for example, routing tables do not need to carry link addressing and can therefore be significantly smaller. This helps to decrease failover times in certain routing convergence events. An interface of a router is also not reachable beyond the link boundaries, therefore reducing the attack surface.


This document discusses the advantages and caveats of this approach.


Note that some traditional techniques used to operate a network, such as pinging interfaces or seeing interface information in a traceroute, do not work with this approach. Details are discussed below.


During WG and IETF last call, the technical correctness of the document was reviewed; however, debate exists as to whether to recommend this technique. The deployment of this technique is appropriate where it is found to be necessary.


2. Using Link-Local Addressing on Infrastructure Links
2. 在基础结构链接上使用链接本地寻址

This document discusses the approach of using only link-local addresses (LLAs) on all router interfaces on infrastructure links. Routers don't typically need to receive packets from hosts or nodes outside the network. For a network operator, there may be reasons to use addresses that are greater than link-local scope on infrastructure interfaces for certain operational tasks, such as pings to an interface or traceroutes across the network. This document discusses such cases and proposes alternative procedures.


2.1. The Approach
2.1. 方法

In this approach, neither globally routed IPv6 addresses nor unique local addresses are configured on infrastructure links. In the absence of specific global or unique local address definitions, the default behavior of routers is to use link-local addresses, notably for routing protocols.


The sending of ICMPv6 [RFC4443] error messages ("packet-too-big", "time-exceeded", etc.) is required for routers. Therefore, another interface must be configured with an IPv6 address that has a greater scope than link-local. This address will usually be a loopback interface with a global scope address belonging to the operator and part of an announced prefix (with a suitable prefix length) to avoid being dropped by other routers implementing ingress filtering [RFC3704]. This is implementation dependent. For the remainder of this document, we will refer to this interface as a "loopback interface".


[RFC6724] recommends that IPv6 addresses that are greater than link-local scope be used as the source IPv6 address for all generated ICMPv6 messages sent to a non-link-local address, with the exception of ICMPv6 redirect messages (as defined in Section 4.5 of [RFC4861]).


The effect on specific traffic types is as follows:


o Most control plane protocols (such as BGP [RFC4271], IS-IS [IS-IS], OSPFv3 [RFC5340], Routing Information Protocol Next Generation (RIPng) [RFC2080], and PIM [RFC4609]) work by default or can be configured to work with link-local addresses. Exceptions are explained in the caveats section (Section 2.3).

o 大多数控制平面协议(如BGP[RFC4271]、IS-IS[IS-IS]、OSPFv3[RFC5340]、下一代路由信息协议(RIPng)[RFC2080]和PIM[RFC4609])默认工作,或者可以配置为与链路本地地址一起工作。例外情况在“注意事项”一节(第2.3节)中解释。

o Management plane traffic (such as Secure SHell (SSH) Protocol [RFC4251], Telnet [RFC0495], Simple Network Management Protocol (SNMP) [RFC1157], and ICMPv6 Echo Request [RFC4443]) can use the address of the router loopback interface as the destination address. Router management can also be done over out-of-band channels.

o 管理平面通信(如安全外壳(SSH)协议[RFC4251]、Telnet[RFC0495]、简单网络管理协议(SNMP)[RFC1157]和ICMPv6回显请求[RFC4443])可以使用路由器环回接口的地址作为目标地址。路由器管理也可以通过带外通道完成。

o ICMP error messages are usually sourced from a loopback interface with a scope that is greater than link-local. Section 4.5 of [RFC4861] explains one exception: ICMP redirect messages can also be sourced from a link-local address.

o ICMP错误消息通常来自范围大于本地链路的环回接口。[RFC4861]第4.5节解释了一个例外情况:ICMP重定向消息也可以来自链路本地地址。

o Data plane traffic is forwarded independently of the link address type.

o 数据平面流量的转发独立于链路地址类型。

o Neighbor discovery (neighbor solicitation and neighbor advertisement) is done by using link-local unicast and multicast addresses. Therefore, neighbor discovery is not affected.

o 邻居发现(邻居请求和邻居广告)是通过使用链路本地单播和多播地址来完成的。因此,邻居发现不受影响。

Thus, we conclude that it is possible to construct a working network in this way.


2.2. Advantages
2.2. 优势

The following list of advantages is in no particular order.


Smaller routing tables: Since the routing protocol only needs to carry one global address (the loopback interface) per router, it is smaller than the traditional approach where every infrastructure link address is carried in the routing protocol. This reduces memory consumption and increases the convergence speed in some routing failover cases. Because the Forwarding Information Base to be downloaded to line cards is smaller, and there are fewer prefixes in the Routing Information Base, the routing algorithm is accelerated. Note that smaller routing tables can also be achieved by putting interfaces in passive mode for the Interior Gateway Protocol (IGP).


Simpler address management: Only loopback interface addresses need to be considered in an addressing plan. This also allows for easier renumbering.


Lower configuration complexity: Link-local addresses require no specific configuration, thereby lowering the complexity and size of router configurations. This also reduces the likelihood of configuration mistakes.


Simpler DNS: Less routable address space in use also means less reverse and forward mapping DNS resource records to maintain. Of course, if the operator selects not to enter any global interface addresses in the DNS anyway, then this is less of an advantage.


Reduced attack surface: Every routable address on a router constitutes a potential attack point; a remote attacker can send traffic to that address, for example, a TCP SYN flood (see [RFC4987]). If a network only uses the addresses of the router loopback interface(s), only those addresses need to be protected from outside the network. This may ease protection measures, such as Infrastructure Access Control Lists (iACL). Without using link-local addresses, it is still possible to achieve the simple iACL if the network addressing scheme is set up such that all link and loopback interfaces have addresses that are greater than link-local and are aggregatable, and if the infrastructure access list covers that entire aggregated space. See also [RFC6752] for further discussion

减少攻击面:路由器上的每个可路由地址构成潜在攻击点;远程攻击者可以向该地址发送流量,例如TCP SYN洪水(请参阅[RFC4987])。如果网络仅使用路由器环回接口的地址,则只有这些地址需要从网络外部进行保护。这可能会简化保护措施,如基础设施访问控制列表(iACL)。在不使用链路本地地址的情况下,如果将网络寻址方案设置为所有链路和环回接口的地址都大于链路本地地址且可聚合,并且基础设施访问列表覆盖整个聚合空间,则仍然可以实现简单的iACL。进一步讨论请参见[RFC6752]

on this topic. [RFC6860] describes another approach to hide addressing on infrastructure links for OSPFv2 and OSPFv3 by modifying the existing protocols. This document does not modify any protocol and applies only to IPv6.


2.3. Caveats
2.3. 警告

The caveats listed in this section are in no particular order.


Interface ping: If an interface doesn't have a routable address, it can only be pinged from a node on the same link. Therefore, it is not possible to ping a specific link interface remotely. A possible workaround is to ping the loopback address of a router instead. In most cases today, it is not possible to see which link the packet was received on; however, [RFC5837] suggests including the interface identifier of the interface a packet was received on in the ICMPv6 response. It must be noted that there are few implementations of this ICMPv6 extension. With this approach, it would be possible to ping a router on the addresses of loopback interfaces, yet see which interface the packet was received on. To check liveliness of a specific interface, it may be necessary to use other methods, such as connecting to the router via SSH and checking locally or using SNMP.


Traceroute: Similar to the ping case, a reply to a traceroute packet would come from the address of a loopback interface, and current implementations do not display the specific interface the packets came in on. Again, [RFC5837] provides a solution. As in the ping case above, it is not possible to traceroute to a particular interface if it only has a link-local address. Conversely, this approach may make network topology discovery from outside the network simpler: instead of responding with multiple different interface IP addresses, which have to be correlated by the outsider, a router will always respond with the same loopback address. If reverse DNS mapping is used, the mapping is trivial in either case.


Hardware dependency: LLAs have usually been based on 64-bit Extended Unique Identifiers (EUI-64); hence, they change when the Message Authentication Code (MAC) address is changed. This could pose a problem in a case where the routing neighbor must be configured explicitly (e.g., BGP) and a line card needs to be physically replaced, hence changing the EUI-64 LLA and breaking the routing neighborship. LLAs can be statically configured, such as fe80::1 and fe80::2, which can be used to configure any required static routing neighborship. However, this static LLA configuration may be more complex to operate than statically configured addresses that are greater than link-local scope. This is because LLAs are inherently ambiguous. For a multi-link node, such as a router, to deal with the

硬件依赖性:LLA通常基于64位扩展唯一标识符(EUI-64);因此,当消息身份验证码(MAC)地址更改时,它们也会更改。在必须明确配置路由邻居(例如BGP)并且需要物理更换线路卡的情况下,这可能会造成问题,从而更改EUI-64 LLA并中断路由邻居关系。LLA可以静态配置,例如fe80::1和fe80::2,它们可以用于配置任何所需的静态路由邻居。然而,这种静态LLA配置可能比大于链路本地作用域的静态配置地址更复杂。这是因为LLA本质上是不明确的。对于多链路节点,如路由器,要处理

ambiguity, the link zone index must also be considered explicitly, e.g., using the extended textual notation described in [RFC4007], as in this example, 'BGP neighbor fe80::1%eth0 is down'.


Network Management System (NMS) toolkits: If there is any NMS tool that makes use of an interface IP address of a router to carry out any of its NMS functions, then it would no longer work if the interface does not have a routable address. A possible workaround for such tools is to use the routable address of the router loopback interface instead. Most vendor implementations allow the specification of loopback interface addresses for SYSLOG, IPFIX, and SNMP. The Link Layer Discovery Protocol (LLDP) (IEEE 802.1AB-2009) runs directly over Ethernet and does not require any IPv6 address, so dynamic network discovery is not hindered by using only LLA when using LLDP. But, network discovery based on Neighbor Discovery Protocol (NDP) cache content will only display the link-local addresses and not the addresses of the loopback interfaces; therefore, network discovery should rather be based on the Route Information Base to detect adjacent nodes.

网络管理系统(NMS)工具包:如果有任何NMS工具利用路由器的接口IP地址来执行其任何NMS功能,那么如果接口没有可路由地址,则该工具将不再工作。此类工具的一个可能的解决方法是使用路由器环回接口的可路由地址。大多数供应商实现都允许为SYSLOG、IPFIX和SNMP指定环回接口地址。链路层发现协议(LLDP)(IEEE 802.1AB-2009)直接在以太网上运行,不需要任何IPv6地址,因此在使用LLDP时仅使用LLA不会妨碍动态网络发现。但是,基于邻居发现协议(NDP)缓存内容的网络发现只显示链路本地地址,而不显示环回接口的地址;因此,网络发现应该基于路由信息库来检测相邻节点。

MPLS and RSVP-Traffic Engineering (RSVP-TE) [RFC3209] allow the establishment of an MPLS Label Switched Path (LSP) on a path that is explicitly identified by a strict sequence of IP prefixes or addresses (each pertaining to an interface or a router on the path). This is commonly used for Fast Reroute (FRR). However, if an interface uses only a link-local address, then such LSPs cannot be established. At the time of writing this document, there is no workaround for this case; therefore, where RSVP-TE is being used, the approach described in this document does not work.


2.4. Internet Exchange Points
2.4. 互联网交换点

Internet Exchange Points (IXPs) have a special importance in the global Internet because they connect a high number of networks in a single location and because a significant part of Internet traffic passes through at least one IXP. An IXP requires, therefore, a very high level of security. The address space used on an IXP is generally known, as it is registered in the global Internet Route Registry, or it is easily discoverable through traceroute. The IXP prefix is especially critical because practically all addresses on this prefix are critical systems in the Internet.


Apart from general device security guidelines, there are basically two additional ways to raise security (see also [BGP-OPSEC]):


1. Not to announce the prefix in question, and

1. 不公布有问题的前缀,以及

2. To drop all traffic from remote locations destined to the IXP prefixes.

2. 删除从远程位置发送到IXP前缀的所有流量。

Not announcing the prefix of the IXP would frequently result in traceroute and similar packets (required for Path MTU Discovery (PMTUD)) being dropped due to unicast Reverse Path Forwarding (uRPF) checks. Given that PMTUD is critical, this is generally not acceptable. Dropping all external traffic to the IXP prefix is hard to implement because if only one service provider connected to an IXP does not filter correctly, then all IXP routers are reachable from at least that service provider network.


As the prefix used in the IXP is usually longer than a /48, it is frequently dropped by route filters on the Internet having the same net effect as not announcing the prefix.


Using link-local addresses on the IXP may help in this scenario. In this case, the generated ICMPv6 packets would be generated from loopback interfaces or from any other interface with a globally routable address without any configuration. However, in this case, each service provider would use their own address space, making a generic attack against all devices on the IXP harder. All of an IXP's loopback interface addresses can be discovered by a potential attacker with a simple traceroute; a generic attack is, therefore, still possible, but it would require more work.


In some cases, service providers carry the IXP addresses in their IGP for certain forms of traffic engineering across multiple exit points. Link-local addresses cannot be used for this purpose; in this case, the service provider would have to employ other methods of traffic engineering.


If an Internet Exchange Point is using a global prefix registered for this purpose, a traceroute will indicate whether the trace crosses an IXP rather than a private interconnect. If link-local addressing is used instead, a traceroute will not provide this distinction.


2.5. Summary
2.5. 总结

Exclusively using link-local addressing on infrastructure links has a number of advantages and disadvantages, both of which are described in detail in this document. A network operator can use this document to evaluate whether or not using link-local addressing on


infrastructure links is a good idea in the context of his/her network. This document makes no particular recommendation either in favor or against.


3. Security Considerations
3. 安全考虑

Using only LLAs on infrastructure links reduces the attack surface of a router. Loopback interfaces with routed addresses are still reachable and must be secured, but infrastructure links can only be attacked from the local link. This simplifies security of control and management planes. The approach does not impact the security of the data plane. The link-local-only approach does not address control plane [RFC6192] attacks generated by data plane packets (such as hop-limit expiration or packets containing a hop-by-hop extension header).


For additional security considerations, as previously stated, see also [RFC5837] and [BGP-OPSEC].


4. Informative References
4. 资料性引用

[BGP-OPSEC] Durand, J., Pepelnjak, I., and G. Doering, "BGP operations and security", Work in Progress, draft-ietf-opsec-bgp-security-05, August 2014.


[IS-IS] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO Standard 10589, 2002.

[IS-IS]国际标准化组织,“与提供无连接模式网络服务协议一起使用的中间系统到中间系统域内路由信息交换协议(ISO 8473)”,ISO标准10589,2002年。

[RFC0495] McKenzie, A., "Telnet Protocol specifications", RFC 495, May 1973, <>.

[RFC0495]McKenzie,A.,“Telnet协议规范”,RFC 495,1973年5月<>.

[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990, <>.

[RFC1157]Case,J.,Fedor,M.,Schoffstall,M.,和J.Davin,“简单网络管理协议(SNMP)”,STD 15,RFC 1157,1990年5月<>.

[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997, <>.


[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001, <>.

[RFC3209]Awduche,D.,Berger,L.,Gan,D.,Li,T.,Srinivasan,V.,和G.Swallow,“RSVP-TE:LSP隧道RSVP的扩展”,RFC 3209,2001年12月<>.

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004, <>.

[RFC3704]Baker,F.和P.Savola,“多宿网络的入口过滤”,BCP 84,RFC 37042004年3月<>.

[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005, <>.

[RFC4007]Deering,S.,Haberman,B.,Jinmei,T.,Nordmark,E.,和B.Zill,“IPv6作用域地址体系结构”,RFC 4007,2005年3月<>.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <>.

[RFC4193]Hinden,R.和B.Haberman,“唯一本地IPv6单播地址”,RFC 41932005年10月<>.

[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006, <>.

[RFC4251]Ylonen,T.和C.Lonvick,“安全外壳(SSH)协议架构”,RFC 42512006年1月<>.

[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006, <>.

[RFC4271]Rekhter,Y.,Li,T.,和S.Hares,“边境网关协议4(BGP-4)”,RFC 42712006年1月<>.

[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006, <>.

[RFC4443]Conta,A.,Deering,S.和M.Gupta,“互联网协议版本6(IPv6)规范的互联网控制消息协议(ICMPv6)”,RFC 4443,2006年3月<>.

[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006, <>.

[RFC4609]Savola,P.,Lehtonen,R.,和D.Meyer,“协议独立多播-稀疏模式(PIM-SM)多播路由安全问题和增强”,RFC 4609,2006年10月<>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <>.

[RFC4861]Narten,T.,Nordmark,E.,Simpson,W.,和H.Soliman,“IP版本6(IPv6)的邻居发现”,RFC 48612007年9月<>.

[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007, <>.

[RFC4987]Eddy,W.“TCP SYN洪泛攻击和常见缓解措施”,RFC 4987,2007年8月<>.

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008, <>.

[RFC5340]Coltun,R.,Ferguson,D.,Moy,J.,和A.Lindem,“IPv6的OSPF”,RFC 53402008年7月<>.

[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010, <>.

[RFC5837]Atlas,A.,Bonica,R.,Pignataro,C.,Shen,N.,和JR.Rivers,“为接口和下一跳识别扩展ICMP”,RFC 5837,2010年4月<>.

[RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, March 2011, <>.

[RFC6192]Dugal,D.,Pignataro,C.,和R.Dunn,“保护路由器控制平面”,RFC 61922011年3月<>.

[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012, <>.

[RFC6724]Thaler,D.,Draves,R.,Matsumoto,A.,和T.Chown,“互联网协议版本6(IPv6)的默认地址选择”,RFC 67242012年9月<>.

[RFC6752] Kirkham, A., "Issues with Private IP Addressing in the Internet", RFC 6752, September 2012, <>.

[RFC6752]Kirkham,A.“互联网中的私有IP地址问题”,RFC 67522012年9月<>.

[RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only Networks in OSPF", RFC 6860, January 2013, <>.

[RFC6860]Yang,Y.,Retana,A.和A.Roy,“在OSPF中隐藏公交专用网络”,RFC 68602013年1月<>.



The authors would like to thank Salman Asadullah, Brian Carpenter, Bill Cerveny, Benoit Claise, Rama Darbha, Simon Eng, Wes George, Fernando Gont, Jen Linkova, Harald Michl, Janos Mohacsi, Ivan Pepelnjak, Alvaro Retana, Jinmei Tatuya, and Peter Yee for their useful comments about this work.


Authors' Addresses


Michael Behringer Cisco Building D, 45 Allee des Ormes Mougins 06250 France

Michael Behringer Cisco D栋,45 Allee des Ormes Mougins法国06250


Eric Vyncke Cisco De Kleetlaan, 6A Diegem 1831 Belgium

Eric Vyncke Cisco De Kleetlaan,6A Diegem 1831比利时