draft-ietf-v6ops-v6inixp-04.txt   draft-ietf-v6ops-v6inixp-05.txt 
Internet Engineering Task Force R. Gagliano Internet Engineering Task Force R. Gagliano
Internet-Draft LACNIC Internet-Draft LACNIC
Intended status: Informational November 24, 2009 Intended status: Informational February 8, 2010
Expires: May 28, 2010 Expires: August 12, 2010
IPv6 Deployment in Internet Exchange Points (IXPs) IPv6 Deployment in Internet Exchange Points (IXPs)
draft-ietf-v6ops-v6inixp-04.txt draft-ietf-v6ops-v6inixp-05.txt
Abstract Abstract
This document provides guidance on IPv6 deployment in Internet This document provides guidance on IPv6 deployment in Internet
Exchange Points (IXP). It includes information regarding the switch Exchange Points (IXP). It includes information regarding the switch
fabric configuration, the addressing plan and general organizational fabric configuration, the addressing plan and general organizational
tasks that need to be performed. IXPs are mainly a layer 2 tasks that need to be performed. IXPs are mainly a layer 2
infrastructure and in many cases the best recommendations suggest infrastructure and in many cases the best recommendations suggest
that the IPv6 data, control and management plane should not be that the IPv6 data, control and management plane should not be
handled differently than in IPv4. handled differently than in IPv4.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 28, 2010. This Internet-Draft will expire on August 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3
3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6 4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6
4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7 4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7
5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Route-Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Route-Server . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. External and Internal support . . . . . . . . . . . . . . . . 8 7. External and Internal support . . . . . . . . . . . . . . . . 8
8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12. Informative References . . . . . . . . . . . . . . . . . . . . 9 12. Informative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Most Internet Exchange Points (IXP) work at the Layer 2 level, making Most Internet Exchange Points (IXP) work at the Layer 2 level, making
the adoption of IPv6 an easy task. However, IXPs normally implement the adoption of IPv6 an easy task. However, IXPs normally implement
additional services such as statistics, route servers, looking additional services such as statistics, route servers, looking
glasses and broadcast control that may be impacted by the glasses and broadcast control that may be impacted by the
implementation of IPv6. This document clarifies the impact of IPv6 implementation of IPv6. This document clarifies the impact of IPv6
on a new or an existing IXP. The document assumes an Ethernet switch on a new or an existing IXP. The document assumes an Ethernet switch
fabric, although other layer 2 configurations can be deployed. fabric, although other layer 2 configurations can be deployed.
2. Switch Fabric Configuration 2. Switch Fabric Configuration
An Ethernet based IXP switch fabric implements IPv6 over Ethernet as An Ethernet based IXP switch fabric implements IPv6 over Ethernet as
described in [RFC2464]. Therefore, the switching of IPv6 traffic described in [RFC2464]. Therefore, the switching of IPv6 traffic
happens in the same way as in IPv4. However, some management happens in the same way as in IPv4. However, some management
functions may require explicit IPv6 support (such as switch functions may require explicit IPv6 support (such as switch
management, SNMP [RFC1157] support and flow analysis exportation) and management, SNMP [RFC3411] support and flow analysis exportation) and
this should be assessed by the IXP operator. this should be assessed by the IXP operator.
There are two common configurations of IXP switch ports to support There are two common configurations of IXP switch ports to support
IPv6: IPv6:
1. dual-stack LAN: both IPv4 and IPv6 traffic share a common LAN. 1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6
No extra configuration is required in the switch. In this traffic share a common LAN. No extra configuration is required
scenario, participants will typically configure dual-stack in the switch.
interfaces, although independent interfaces are an option.
2. independent LAN: an exclusive IPv6 LAN is created for IPv6 2. independent VLAN (Virtual Local Area Network): when an IXP
traffic. If IXP participants are already using Virtual LAN logically separates IPv4 and IPv6 traffic in different VLANs.
(VLAN) tagging on the interfaces of their routers that are facing
the IXP switch, this only requires passing one additional VLAN
tag across the interconnection. If participants are using
untagged interconnections with the IXP switch and wish to
continue doing so, they will need to provision a separate
physical port to access the IPv6-specific LAN.
The "independent LAN" configuration provides a physical separation In both configurations, IPv6 and IPv4 traffic can either share a
for IPv4 and IPv6 traffic simplifying separate analysis for IPv4 and common physical port or use independent physical ports. The use of
IPv6 traffic. However, it can be more costly in both capital independent ports can be more costly in both capital expenses (as new
expenses (if new ports are needed) and operational expends. ports are needed) and operational expenses.
Conversely, the dual-stack implementation allows a quick and capital
cost-free start-up for IPv6 support in the IXP, allowing the IXP to When using the same physical port for both IPv4 and IPv6 traffic,
avoid transforming untagged ports into tagged ports. In this some changes may be needed at the participants' interfaces
implementation, traffic-split for statistical analysis may be done configurations. If the IXP implements the "dual-stack
using flows techniques such as IPFIX [RFC5101] considering the configuration", IXP participants will configure dual-stack
different ether-types (0x0800 for IPv4, 0x0806 for ARP and 0x86DD for interfaces. On the other hand, if the IXP implements the
IPv6). "independent VLAN configuration", IXP participants are required to
pass one additional VLAN tag across the interconnection. In this
case, if the IXP did not originally use VLAN tagging, VLAN tagging
may to be established and previous use may continue untagged as a
"native VLAN" or be transitioned to a tagged VLAN. The "independent
VLAN" configuration provides a logical separation of IPv4 and IPv6
traffic, simplifying separate statistical analysis for IPv4 and IPv6
traffic. Conversely, the "dual-stack" configuration (when performing
separate statistical analysis for IPv4 and IPv6 traffic) would
require the use of flows techniques such as IPFIX [RFC5101] to
classify traffic based on the different ether-types (0x0800 for IPv4,
0x0806 for ARP and 0x86DD for IPv6).
The only technical requirement for IPv6 referring link MTUs is that The only technical requirement for IPv6 referring link MTUs is that
they need to be greater than or equal to 1280 octets [RFC2460]. they need to be greater than or equal to 1280 octets [RFC2460]. The
Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes. MTU size for every LAN in an IXP should be well known by all its
Consequently, no MTU changes are typically required. The MTU size participants.
for every LAN in an IXP should be well known by all its participants.
3. Addressing Plan 3. Addressing Plan
Regional Internet Registries (RIRs) have specific address policies to Regional Internet Registries (RIRs) have specific address policies to
assign Provider Independent (PI) IPv6 address to IXPs. Those assign Provider Independent (PI) IPv6 address to IXPs. Those
allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES].
Depending on the country and region of operation, address assignments Depending on the country and region of operation, address assignments
may be made by NIRs (National Internet Registries). Unique Local may be made by NIRs (National Internet Registries). Unique Local
IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP
LAN as global reverse DNS resolution and whois services are required. LAN as global reverse DNS resolution and whois services are required.
IXPs will normally use manual address configuration. Address prefix IXPs will normally use manual address configuration. The manual
between /64 and /127 are technically feasible [RFC4291]. Because of
operational practices, IXP will normally chose a /64 prefix to be
allocated for each of the IXP's IPv6 enabled LANs. In this case, a
/48 prefix allows the addressing of 65536 LANs. The manual
configuration of IPv6 addresses allows IXP participants to replace configuration of IPv6 addresses allows IXP participants to replace
network interfaces with no need to reconfigure Border Gateway network interfaces with no need to reconfigure Border Gateway
Protocol (BGP) sessions information and it also facilitates Protocol (BGP) sessions information and it also facilitates
management tasks. management tasks. The IPv6 Addressing Architecture [RFC4291]
requires that interface identifiers are 64 bits in size for prefixes
starting with binary 000, resulting in a maximum prefix length of
/64. Longer prefix lengths up to /127 have been used operationally.
If prefix lengths longer than 64 bits are chosen, the implications
described in [RFC3627] need to be considered. A /48 prefix allows
the addressing of 65536 /64 LANs.
When selecting the use of static Interface Identifiers (IIDs), there When selecting the use of static Interface Identifiers (IIDs), there
are different options on how to fill its 64 bits (or 16 hexadecimal are different options on how to fill its 64 bits (or 16 hexadecimal
characters). A non-exhausted list of possible IID selection characters). A non-exhausted list of possible IID selection
mechanisms is the following: mechanisms is the following:
1. Some IXPs like to include the participants' ASN number decimal 1. Some IXPs like to include the participants' ASN number decimal
encoding inside each IPv6 address. The ASN decimal number is encoding inside each IPv6 address. The ASN decimal number is
used as the BCD (binary code decimal) encoding of the upper part used as the BCD (binary code decimal) encoding of the upper part
of the IID such as shown in this example: of the IID such as shown in this example:
skipping to change at page 6, line 16 skipping to change at page 6, line 23
to use the hexadecimal encoding of the ASNs number as the upper to use the hexadecimal encoding of the ASNs number as the upper
part of the IID as follow: part of the IID as follow:
* IXP LAN prefix: 2001:db8::/64 * IXP LAN prefix: 2001:db8::/64
* ASN: 64496 (DEC) or fbf0 (HEX) * ASN: 64496 (DEC) or fbf0 (HEX)
* IPv6 Address: 2001:db8:0000:0000:0000:0000:fbf0:0001/64 or its * IPv6 Address: 2001:db8:0000:0000:0000:0000:fbf0:0001/64 or its
equivalent representation 2001:db8::fbf0:1/64 equivalent representation 2001:db8::fbf0:1/64
In this case a maximum of 8 characters will be needed to
represent 32 bits ASNs.
3. A third scheme for statically assigning IPv6 addresses on an IXP 3. A third scheme for statically assigning IPv6 addresses on an IXP
LAN could be to relate some portions of a participant's IPv6 LAN could be to relate some portions of a participant's IPv6
address to its IPv4 address. In the following example, the last address to its IPv4 address. In the following example, the last
four decimals of the IPv4 address are copied to the last four decimals of the IPv4 address are copied to the last
hexadecimals of the IPv6 address, using the decimal number as the hexadecimals of the IPv6 address, using the decimal number as the
BCD encoding for the last three characters of the IID such as in BCD encoding for the last three characters of the IID such as in
the following example: the following example:
* IXP LAN prefix: 2001:db8::/64 * IXP LAN prefix: 2001:db8::/64
* IPv4 Address: 192.0.2.123/23 * IPv4 Address: 192.0.2.123/23
* IPv6 Address: 2001:db8:2:123/64 * IPv6 Address: 2001:db8:2:123/64
4. A fourth approach might be based on the IXPs ID for that 4. A fourth approach might be based on the IXPs ID for that
participant. participant.
IPv6 prefixes for IXP LANs are typically publicly well known and IPv6 prefixes for IXP LANs are typically publicly well known and
taken from dedicated IPv6 blocks for IXP assignments reserved for taken from dedicated IPv6 blocks for IXP assignments reserved for
this purpose by the different RIRs.The current practice that applies this purpose by the different RIRs. These blocks are usually only
to IPv4 about publishing IXP allocations to the DFZ (Default Free meant for addressing the exchange fabric, and may be filtered out by
Zone) should also apply to the IPv6 allocation. When considering the DFZ (Default Free Zone) operators. When considering the routing of
routing of the IXP LANs two options are identified: the IXP LANs two options are identified:
o IXPs may decide that LANs should not to be globally routed in o IXPs may decide that LANs should not to be globally routed in
order to limit the possible origins of a Denial of Service (DoS) order to limit the possible origins of a Denial of Service (DoS)
attack to its particpants' AS boundaries. In this configuration attack to its participants' AS boundaries. In this configuration
participants may route these prefixes inside their networks (e. g. participants may route these prefixes inside their networks (e. g.
using BGP no-export communities or routing the IXP LANs within the using BGP no-export communities or routing the IXP LANs within the
participants' IGP) to perform fault management. Using this participants' IGP) to perform fault management. Using this
configuration, the monitoring of the IXP LANs from outside of its configuration, the monitoring of the IXP LANs from outside of its
participants' AS boundaries is not possible. participants' AS boundaries is not possible.
o IXP may decide that LANs should be globally routed. In this case, o IXP may decide that LANs should (attempt to be) be globall routed.
IXP LANs monitoring from outside its participants' AS boundaries In this case, IXP LANs monitoring from outside its participants'
is possible but the IXP LANs will be vulnerable to DoS from AS boundaries may be possible but the IXP LANs will be vulnerable
outside of those boundaries. to DoS from outside of those boundaries.
IXP external services (such as dns, web pages, ftp servers) need to Additionally, possible IXP external services (such as dns, web pages,
be globally routed. Strict prefix length filtering could be the ftp servers) need to be globally routed. These should be addressed
reason for requesting more than one /48 assignment from a RIR (i.e. from separate address blocks, either from upstream providers' address
requesting one /48 assignment for the IXPs LANs that may not be space, or separate independent assignments. Strict prefix length
globally routed and a different /48 assignment for the IXP external filtering could be a reason for requesting more than one /48
services that will be globally routed). assignment from a RIR (i.e. requesting one /48 assignment for the
IXPs LANs that may not be globally routed and a different, non-IXP
/48 assignment for the IXP external services that will be globally
routed).
4. Multicast IPv6 4. Multicast IPv6
There are two elements that need to be evaluated when studying IPv6 There are two elements that need to be evaluated when studying IPv6
multicast in an IXP: multicast support for neighbor discovery and multicast in an IXP: multicast support for neighbor discovery and
multicast peering. multicast peering.
4.1. Multicast Support and Monitoring for ND at an IXP 4.1. Multicast Support and Monitoring for ND at an IXP
IXPs typically control broadcast traffic across the switching fabric IXPs typically control broadcast traffic across the switching fabric
skipping to change at page 8, line 49 skipping to change at page 9, line 18
Peering Agreements (MLPA) service, looking glass service or route- Peering Agreements (MLPA) service, looking glass service or route-
collection service. IPv6 support needs to be added to the BGP collection service. IPv6 support needs to be added to the BGP
speaking router. The equipment should be able to transport IPv6 speaking router. The equipment should be able to transport IPv6
traffic and to support Multi-protocol BGP (MP-BGP) extensions for traffic and to support Multi-protocol BGP (MP-BGP) extensions for
IPv6 address family ([RFC2545] and [RFC4760]). IPv6 address family ([RFC2545] and [RFC4760]).
A good practice is that all BGP sessions used to exchange IPv6 A good practice is that all BGP sessions used to exchange IPv6
network information are configured using IPv6 data transport. This network information are configured using IPv6 data transport. This
configuration style ensures that both network reachability configuration style ensures that both network reachability
information and generic packet data transport use the same transport information and generic packet data transport use the same transport
plane. In the event of IPv6 reachability problems between IPv6 plane. Because of the size of the IPv6 space, limiting the maximum
peers, the IPv6 BGP session may be terminated independently of any number of IPv6 prefixes in every session should be studied.
IPv4 sessions. The use of MD5 [RFC2385] or IPSEC [RFC4301] to
authenticate the BGP sessions and the use of GTSM (The Generalized
TTL Security Mechanism) [RFC3682] should be considered. Because of
the size of the IPv6 space, limiting the maximum number of IPv6
prefixes in every session should be studied.
External services should be available for external IPv6 access, External services should be available for external IPv6 access,
either by an IPv6 enabled web page or an IPv6 enabled console either by an IPv6 enabled web page or an IPv6 enabled console
interface. interface.
7. External and Internal support 7. External and Internal support
Some external services that need to have IPv6 support are traffic Some external services that need to have IPv6 support are traffic
graphics, DNS, FTP, Web, Route Server and Looking Glass. Other graphics, DNS, FTP, Web, Route Server and Looking Glass. Other
external services such as NTP servers, or SIP Gateways need to be external services such as NTP servers, or SIP Gateways need to be
skipping to change at page 9, line 44 skipping to change at page 10, line 12
Policies for IPv6 traffic monitoring and filtering may be in place as Policies for IPv6 traffic monitoring and filtering may be in place as
described in Section Section 4. described in Section Section 4.
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
This memo includes procedures for monitoring and/or avoiding This memo includes procedures for monitoring and/or avoiding
particular ICMPv6 traffic at IXPs' LANs. It also mentions how to particular ICMPv6 traffic at IXPs' LANs. None of these methods
limit IPv6 DoS attacks to the IXP switch fabric by not globally prevent Ethernet loops caused by mischief in the LAN. The document
announce the IXP LANs prefix. also mentions how to limit IPv6 DoS attacks to the IXP switch fabric
by not globally announce the IXP LANs prefix.
11. Acknowledgements 11. Acknowledgements
The author would like to thank the contributions from Alain Aina, The author would like to thank the contributions from Alain Aina,
Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels,
Bill Woodcock, Carlos Frias, Arien Vijn, Fernando Gont and Louis Lee, Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont and Louis
Lee,
12. Informative References 12. Informative References
[I-D.ietf-v6ops-ra-guard] [I-D.ietf-v6ops-ra-guard]
Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-03 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-03
(work in progress), May 2009. (work in progress), May 2009.
[I-D.ietf-v6ops-rogue-ra] [I-D.ietf-v6ops-rogue-ra]
Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", draft-ietf-v6ops-rogue-ra-00 (work in Problem Statement", draft-ietf-v6ops-rogue-ra-00 (work in
progress), May 2009. progress), May 2009.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37, address for transmission on Ethernet hardware", STD 37,
RFC 826, November 1982. RFC 826, November 1982.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998. Signature Option", RFC 2385, August 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, Extensions for IPv6 Inter-Domain Routing", RFC 2545,
March 1999. March 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999. October 1999.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL [RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
Security Mechanism (GTSM)", RFC 3682, February 2004. Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
skipping to change at page 11, line 38 skipping to change at page 12, line 5
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC5101] Claise, B., "Specification of the IP Flow Information [RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008. Flow Information", RFC 5101, January 2008.
[RIR_IXP_POLICIES] [RIR_IXP_POLICIES]
Numbers Resource Organization (NRO)., "RIRs Allocations Numbers Resource Organization (NRO)., "RIRs Allocations
Policies for IXP. NRO Comparison matrix", 2008, Policies for IXP. NRO Comparison matrix", 2009,
<http://www.nro.net/documents/comp-pol.html#3-4-2>. <http://www.nro.net/documents/comp-pol.html#3-4-2>.
Author's Address Author's Address
Roque Gagliano Roque Gagliano
LACNIC LACNIC
Rambla Rep Mexico 6125 Rambla Rep Mexico 6125
Montevideo, 11400 Montevideo, 11400
Uruguay Uruguay
 End of changes. 25 change blocks. 
74 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/