From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7113.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc7113.txt (limited to 'doc/rfc/rfc7113.txt') diff --git a/doc/rfc/rfc7113.txt b/doc/rfc/rfc7113.txt new file mode 100644 index 0000000..0c8a261 --- /dev/null +++ b/doc/rfc/rfc7113.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Gont +Request for Comments: 7113 Huawei Technologies +Updates: 6105 February 2014 +Category: Informational +ISSN: 2070-1721 + + + Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) + +Abstract + + The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly + employed to mitigate attack vectors based on forged ICMPv6 Router + Advertisement messages. Many existing IPv6 deployments rely on + RA-Guard as the first line of defense against the aforementioned + attack vectors. However, some implementations of RA-Guard have been + found to be prone to circumvention by employing IPv6 Extension + Headers. This document describes the evasion techniques that affect + the aforementioned implementations and formally updates RFC 6105, + such that the aforementioned RA-Guard evasion vectors are eliminated. + +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. + + 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/rfc7113. + + + + + + + + + + + + + + + +Gont Informational [Page 1] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Evasion Techniques for Some RA-Guard Implementations . . . . . 3 + 2.1. Attack Vector Based on IPv6 Extension Headers . . . . . . 3 + 2.2. Attack Vector Based on IPv6 Fragmentation . . . . . . . . 4 + 3. RA-Guard Implementation Advice . . . . . . . . . . . . . . . . 6 + 4. Other Implications . . . . . . . . . . . . . . . . . . . . . . 9 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 + Appendix A. Assessment Tools . . . . . . . . . . . . . . . . . . 12 + +1. Introduction + + IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique + for attack vectors based on ICMPv6 Router Advertisement [RFC4861] + messages. [RFC6104] describes the problem statement of "Rogue IPv6 + Router Advertisements", and [RFC6105] specifies the "IPv6 Router + Advertisement Guard" functionality. + + The concept behind RA-Guard is that a Layer-2 (L2) device filters + ICMPv6 Router Advertisement messages, according to a number of + different criteria. The most basic filtering criterion is that + Router Advertisement messages are discarded by the L2 device unless + they are received on a specified port of the L2 device. Clearly, the + effectiveness of RA-Guard relies on the ability of the L2 device to + identify ICMPv6 Router Advertisement messages. + + Some popular RA-Guard implementations have been found to be easy to + circumvent by employing IPv6 Extension Headers [CPNI-IPv6]. This + + + +Gont Informational [Page 2] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + document describes such evasion techniques and provides advice to + RA-Guard implementers such that the aforementioned evasion vectors + can be eliminated. + + It should be noted that the previously mentioned techniques could + also be exploited to evade network monitoring tools such as NDPMon + [NDPMon], ramond [ramond], and rafixd [rafixd], and could probably be + exploited to perform stealth DHCPv6 [RFC3315] attacks. + +2. Evasion Techniques for Some RA-Guard Implementations + + The following subsections describe two different vectors that have + been found to be effective for the evasion of popular implementations + of RA-Guard. Section 2.1 describes an attack vector based on the use + of IPv6 Extension Headers with ICMPv6 Router Advertisement messages, + which may be used to circumvent the RA-Guard protection of those + implementations that fail to process an entire IPv6 header chain when + trying to identify the ICMPv6 Router Advertisement messages. + Section 2.2 describes an attack method based on the use of IPv6 + fragmentation, possibly in conjunction with the use of IPv6 Extension + Headers. This later vector has been found to be effective against + all existing implementations of RA-Guard. + +2.1. Attack Vector Based on IPv6 Extension Headers + + While there is currently no legitimate use for IPv6 Extension Headers + in ICMPv6 Router Advertisement messages, Neighbor Discovery [RFC4861] + implementations allow the use of Extension Headers with these + messages, by simply ignoring the received options. Some RA-Guard + implementations try to identify ICMPv6 Router Advertisement messages + by simply looking at the "Next Header" field of the fixed IPv6 + header, rather than following the entire header chain. As a result, + such implementations fail to identify any ICMPv6 Router Advertisement + messages that include any Extension Headers (for example, a Hop-by- + Hop Options header, a Destination Options header, etc.), and can be + easily circumvented. + + The following figure illustrates the structure of ICMPv6 Router + Advertisement messages that implement this evasion technique: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |NH=60| |NH=58| | | + +-+-+-+ +-+-+-+ + + + | IPv6 Header | Dst Opt Hdr | ICMPv6 Router Advertisement | + + + + + + | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Gont Informational [Page 3] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + +2.2. Attack Vector Based on IPv6 Fragmentation + + This section presents a different attack vector, which has been found + to be effective against all implementations of RA-Guard. The basic + idea behind this attack vector is that if the forged ICMPv6 Router + Advertisement is fragmented into at least two fragments, the L2 + device implementing RA-Guard would be unable to identify the attack + packet and would thus fail to block it. + + A first variant of this attack vector would be an original ICMPv6 + Router Advertisement message preceded with a Destination Options + header, which results in two fragments. The following figure + illustrates the "original" attack packet, prior to fragmentation, and + the two resulting fragments that are actually sent as part of the + attack. + + Original Packet: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |NH=60| |NH=58| | | + +-+-+-+ +-+-+-+ + + + | IPv6 Header | Dst Opt Hdr | ICMPv6 RA | + + + + + + | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + First Fragment: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |NH=44| |NH=60| |NH=58| | + +-+-+-+ +-+-+-+ +-+-+-+ + + | IPv6 Header | Frag Hdr | Dst Opt Hdr | + + + + + + | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Second Fragment: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |NH=44| |NH=60| | | | + +-+-+-+ +-+-+-+ + + + + | IPv6 Header | Frag Hdr | Dst Opt Hdr | ICMPv6 RA | + + + + + + + | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Gont Informational [Page 4] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + It should be noted that the "Hdr Ext Len" field of the Destination + Options header is present in the First Fragment (rather than the + second). Therefore, it is impossible for a device processing only + the second fragment to locate the ICMPv6 header contained in that + fragment, since it is unknown how many bytes should be "skipped" to + get to the next header following the Destination Options header. + + Thus, by leveraging the use of the Fragment Header together with the + use of the Destination Options header, the attacker is able to + conceal the type and contents of the ICMPv6 message he is sending (an + ICMPv6 Router Advertisement in this example). Unless the L2 device + were to implement IPv6 fragment reassembly, it would be impossible + for the device to identify the ICMPv6 type of the message. + + An L2 device could, however, at least detect that an ICMPv6 + message (of some type) is being sent, since the "Next Header" + field of the Destination Options header contained in the First + Fragment is set to "58" (ICMPv6). + + This idea can be taken further, such that it is also impossible for + the L2 device to detect that the attacker is sending an ICMPv6 + message in the first place. This can be achieved with an original + ICMPv6 Router Advertisement message preceded with two Destination + Options headers that results in two fragments. The following figure + illustrates the "original" attack packet, prior to fragmentation, and + the two resulting packets that are actually sent as part of the + attack. + + Original Packet: + + +-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |NH=60| |NH=60| |NH=58| | | + +-+-+-+ +-+-+-+ +-+-+-+ + + + | IPv6 header | Dst Opt Hdr | Dst Opt Hdr | ICMPv6 RA | + + + + + + + | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + First Fragment: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |NH=44| |NH=60| |NH=60| | + +-+-+-+ +-+-+-+ +-+-+-+ + + | IPv6 header | Frag Hdr | Dst Opt Hdr | + + + + + + | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Gont Informational [Page 5] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + Second Fragment: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |NH=44| |NH=60| | |NH=58| | | + +-+-+-+ +-+-+-+ + +-+-+-+ + + + | IPv6 header | Frag Hdr | Dst O Hdr | Dst Opt Hdr | ICMPv6 RA | + + + + + + + + | | | | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + In this variant, the "Next Header" field of the Destination Options + header contained in the First Fragment is set to "60" (Destination + Options header); thus, it is impossible for a device processing only + the First Fragment to detect that an ICMPv6 message is being sent in + the first place. + + The second fragment presents the same challenges as the second + fragment of the previous variant. That is, it would be impossible + for a device processing only the second fragment to locate the second + Destination Options header (and hence the ICMPv6 header), since the + "Hdr Ext Len" field of the first Destination Options header is + present in the First Fragment (rather than the second). + +3. RA-Guard Implementation Advice + + The following filtering rules must be implemented as part of an + RA-Guard implementation on ports that face interfaces that are not + allowed to send ICMPv6 Router Advertisement messages, such that the + vulnerabilities discussed in this document are eliminated: + + 1. If the IPv6 Source Address of the packet is not a link-local + address (fe80::/10), RA-Guard must pass the packet. + + RATIONALE: This prevents RA-Guard from dedicating processing + cycles to filtering packets that originate off-net and that, + if they are RA's, would not be accepted by the host. Section + 6.1.2 of [RFC4861] requires nodes to discard Router + Advertisement messages if their IPv6 Source Address is not a + link-local address. + + 2. If the Hop Limit is not 255, RA-Guard must pass the packet. + + RATIONALE: This prevents RA-Guard from dedicating processing + cycles to filtering packets that originate off-net and that, + if they are RA's, would not be accepted by the destination + host. Section 6.1.2 of [RFC4861] requires nodes to discard + Router Advertisement messages if their Hop Limit is not 255. + + + + +Gont Informational [Page 6] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + 3. RA-Guard must parse the entire IPv6 header chain present in the + packet, to identify whether the packet is a Router Advertisement + message. + + NOTE: RA-Guard implementations must not enforce a limit on the + number of bytes they can inspect (starting from the beginning + of the IPv6 packet), since this could introduce false + positives: legitimate packets could be dropped simply because + the RA-Guard device does not parse the entire IPv6 header + chain present in the packet. An implementation that has such + an implementation-specific limit must not claim compliance + with this specification, and must pass the packet when such + implementation-specific limit is reached. + + 4. When parsing the IPv6 header chain, if the packet is a First + Fragment (i.e., a packet containing a Fragment Header with the + Fragment Offset set to 0) and it fails to contain the entire IPv6 + header chain (i.e., all the headers starting from the IPv6 header + up to, and including, the upper-layer header), RA-Guard must drop + the packet and should log the packet drop event in an + implementation-specific manner as a security fault. + + RATIONALE: [RFC7112] specifies that the First Fragment (i.e., + the fragment with the Fragment Offset set to 0) must contain + the entire IPv6 header chain, and allows intermediate systems + such as routers to drop those packets that fail to comply with + this requirement. + + NOTE: This rule should only be applied to IPv6 fragments with + a Fragment Offset of 0 (non-First Fragments can be safely + passed, since they will never reassemble into a complete + datagram if they are part of a Router Advertisement received + on a port where such packets are not allowed). + + 5. When parsing the IPv6 header chain, if the packet is identified + to be an ICMPv6 Router Advertisement message or the packet + contains an unrecognized Next Header value [IANA-IP-PROTO], + RA-Guard must drop the packet, and should log the packet drop + event in an implementation-specific manner as a security fault. + RA-Guard must provide a configuration knob that controls whether + packets with unrecognized Next Header values are dropped; this + configuration knob must default to "drop". + + RATIONALE: By definition, Router Advertisement messages are + required to originate on-link, have a link-local IPv6 Source + Address, and have a Hop Limit value of 255 [RFC4861]. + [RFC7045] requires that nodes be configurable with respect to + + + + +Gont Informational [Page 7] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + whether packets with unrecognized headers are forwarded, and + allows the default behavior to be that such packets be + dropped. + + 6. In all other cases, RA-Guard must pass the packet as usual. + + NOTE: For the purpose of enforcing the RA-Guard filtering policy, + an Encapsulating Security Payload (ESP) header [RFC4303] should be + considered to be an "upper-layer protocol" (that is, it should be + considered the last header in the IPv6 header chain). This means + that packets employing ESP would be passed by the RA-Guard device + to the intended destination. If the destination host does not + have a security association with the sender of the aforementioned + IPv6 packet, the packet would be dropped. Otherwise, if the + packet is considered valid by the IPsec implementation at the + receiving host and encapsulates a Router Advertisement message, it + is up to the receiving host what to do with such a packet. + + If a packet is dropped due to this filtering policy, then the packet + drop event should be logged in an implementation-specific manner as a + security fault. The logging mechanism should include a drop counter + dedicated to RA-Guard packet drops. + + In order to protect current end-node IPv6 implementations, Rule #4 + has been defined as a default rule to drop packets that cannot be + positively identified as not being Router Advertisement (RA) messages + (because the packet is a fragment that fails to include the entire + IPv6 header chain). This means that, at least in theory, RA-Guard + could result in false-positive blocking of some legitimate non-RA + packets that could not be positively identified as being non-RA. In + order to reduce the likelihood of false positives, Rule #1 and Rule + #2 require that packets that would not pass the required validation + checks for RA messages (Section 6.1.2 of [RFC4861]) be passed without + further inspection. In any case, as noted in [RFC7112], IPv6 packets + that fail to include the entire IPv6 header chain are virtually + impossible to police with state-less filters and firewalls and, + hence, are unlikely to survive in real networks. [RFC7112] requires + that hosts employing fragmentation include the entire IPv6 header + chain in the First Fragment (the fragment with the Fragment Offset + set to 0), thus eliminating the aforementioned false positives. + + This filtering policy assumes that host implementations require that + the IPv6 Source Address of ICMPv6 Router Advertisement messages be a + link-local address and that they discard the packet if this check + fails, as required by the current IETF specifications [RFC4861]. + Additionally, it assumes that hosts require the Hop Limit of Neighbor + Discovery messages to be 255, and that they discard those packets + otherwise. + + + +Gont Informational [Page 8] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + The aforementioned filtering rules implicitly handle the case of + fragmented packets: if the RA-Guard device fails to identify the + upper-layer protocol as a result of the use of fragmentation, the + corresponding packets would be dropped. + + Finally, we note that IPv6 implementations that allow overlapping + fragments (i.e., that do not comply with [RFC5722]) might still be + subject of RA-based attacks. However, a recent assessment of IPv6 + implementations [SI6-FRAG] with respect to their fragment reassembly + policy seems to indicate that most current implementations comply + with [RFC5722]. + +4. Other Implications + + A similar concept to that of RA-Guard has been implemented for + protecting against forged DHCPv6 messages. Such protection can be + circumvented with the same techniques discussed in this document, and + the countermeasures for such evasion attack are analogous to those + described in Section 3 of this document. + + [DHCPv6-Shield] specifies a mechanism to protect against rogue + DHCPv6 servers, while taking into consideration the evasion + techniques discussed in this document. + +5. Security Considerations + + This document describes a number of techniques that have been found + to be effective to circumvent popular RA-Guard implementations and + provides advice to RA-Guard implementers such that those evasion + vulnerabilities are eliminated. + + As noted in Section 3, IPv6 implementations that allow overlapping + fragments (i.e., that do not comply with [RFC5722]) might still be + subject of RA-based attacks. However, most current + implementations seem to comply with [RFC5722]. + + We note that if an attacker sends a fragmented ICMPv6 Router + Advertisement message on a port not allowed to send such packets, the + First Fragment would be dropped, and the rest of the fragments would + be passed. This means that the victim node would tie memory buffers + for the aforementioned fragments, which would never reassemble into a + complete datagram. If a large number of such packets were sent by an + attacker, and the victim node failed to implement proper resource + management for the IPv6 fragment reassembly buffer, this could lead + to a Denial of Service (DoS). However, this does not really + introduce a new attack vector, since an attacker could always perform + the same attack by sending forged fragmented datagrams in which at + + + + +Gont Informational [Page 9] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + least one of the fragments is missing. [CPNI-IPv6] discusses some + resource management strategies that could be implemented for the IPv6 + fragment reassembly buffer. + + We note that the most effective and efficient mitigation for these + attacks would rely on the prohibiting the use of IPv6 fragmentation + with Router Advertisement messages (as specified by [RFC6980]), such + that the RA-Guard functionality is easier to implement. However, + since such mitigation would require an update to existing + implementations, it cannot be relied upon in the short or near term. + + Finally, we note that RA-Guard only mitigates attack vectors based on + ICMPv6 Router advertisement messages. Protection against similar + attacks based on other messages (such as DCHPv6) is considered out of + the scope of this document and is left for other documents (e.g., + [DHCPv6-Shield]). + +6. Acknowledgements + + The author would like to thank Ran Atkinson, who provided very + detailed comments and suggested text that was incorporated into this + document. + + The author would like to thank Ran Atkinson, Karl Auer, Robert + Downie, Washam Fan, David Farmer, Mike Heard, Marc Heuse, Nick + Hilliard, Ray Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, + Gunter van de Velde, James Woodyatt, and Bjoern A. Zeeb, for + providing valuable comments on earlier versions of this document. + + The author would like to thank Arturo Servin, who presented this + document at IETF 81. + + This document resulted from the project "Security Assessment of the + Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by + Fernando Gont on behalf of the UK Centre for the Protection of + National Infrastructure (CPNI). + +7. References + +7.1. Normative References + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + + + +Gont Informational [Page 10] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. + Soliman, "Neighbor Discovery for IP version 6 + (IPv6)", RFC 4861, September 2007. + + [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 + Fragments", RFC 5722, December 2009. + + [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., + and J. Mohacsi, "IPv6 Router Advertisement Guard", + RFC 6105, February 2011. + + [RFC6980] Gont, F., "Security Implications of IPv6 + Fragmentation with IPv6 Neighbor Discovery", + RFC 6980, August 2013. + + [RFC7045] Carpenter, B. and S. Jiang, "Transmission and + Processing of IPv6 Extension Headers", RFC 7045, + December 2013. + + [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications + of Oversized IPv6 Header Chains", RFC 7112, + January 2014. + +7.2. Informative References + + [CPNI-IPv6] Gont, F., "Security Assessment of the Internet + Protocol version 6 (IPv6)", UK Centre for the + Protection of National Infrastructure, (available on + request). + + [DHCPv6-Shield] Gont, F., Liu, W., and G. Van de Velde, "DHCPv6- + Shield: Protecting Against Rogue DHCPv6 Servers", + Work in Progress, October 2013. + + [IANA-IP-PROTO] IANA, "Assigned Internet Protocol Numbers", + . + + [NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", + . + + [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router + Advertisement Problem Statement", RFC 6104, + February 2011. + + [SI6-FRAG] SI6 Networks, "IPv6 NIDS evasion and improvements in + IPv6 fragmentation/reassembly", 2012, + . + + + +Gont Informational [Page 11] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + + [SI6-IPv6] "SI6 Networks' IPv6 toolkit", + . + + [THC-IPV6] "The Hacker's Choice IPv6 Attack Toolkit", + . + + [rafixd] "rafixd", . + + [ramond] "ramond", . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gont Informational [Page 12] + +RFC 7113 RA-Guard Implementation Advice February 2014 + + +Appendix A. Assessment Tools + + [SI6-IPv6] is a publicly available set of tools (for Linux, *BSD, and + Mac OS) that implements the techniques described in this document. + + [THC-IPV6] is a publicly available set of tools (for Linux) that + implements some of the techniques described in this document. + +Author's Address + + Fernando Gont + Huawei Technologies + Evaristo Carriego 2644 + Haedo, Provincia de Buenos Aires 1706 + Argentina + + Phone: +54 11 4650 8472 + EMail: fgont@si6networks.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gont Informational [Page 13] + -- cgit v1.2.3