draft-ietf-v6ops-v6inixp-09.txt   rfc5963.txt 
Internet Engineering Task Force R. Gagliano Internet Engineering Task Force (IETF) R. Gagliano
Internet-Draft Cisco Systems Request for Comments: 5963 Cisco Systems
Intended status: Informational July 15, 2010 Category: Informational August 2010
Expires: January 16, 2011 ISSN: 2070-1721
IPv6 Deployment in Internet Exchange Points (IXPs) IPv6 Deployment in Internet Exchange Points (IXPs)
draft-ietf-v6ops-v6inixp-09.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 (IXPs). 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.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on January 16, 2011. 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/rfc5963.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 2. Switch Fabric Configuration .....................................2
3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 3. Addressing Plan .................................................3
4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Multicast IPv6 ..................................................5
4.1. Multicast Support and Monitoring for Neighbor 4.1. Multicast Support and Monitoring for Neighbor
Discovery at an IXP . . . . . . . . . . . . . . . . . . . 6 Discovery at an IXP ........................................6
4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7 4.2. IPv6 Multicast Traffic Exchange at an IXP ..................6
5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Reverse DNS .....................................................7
6. Route-Server . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Route-Server ....................................................7
7. External and Internal support . . . . . . . . . . . . . . . . 8 7. External and Internal Support ...................................7
8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8 8. IXP Policies and IPv6 ...........................................8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations .........................................8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements ...............................................8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. Informative References .........................................8
12. Informative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Most Internet Exchange Points (IXP) work at the Layer 2 level, making Most Internet Exchange Points (IXPs) work at the Layer 2 level,
the adoption of IPv6 an easy task. However, IXPs normally implement making the adoption of IPv6 an easy task. However, IXPs normally
additional services such as statistics, route servers, looking implement additional services such as statistics, route servers,
glasses and broadcast control that may be impacted by the looking glasses, and broadcast controls 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 could 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 (such as switch management, SNMP [RFC3411] support or flow functions (such as switch management, SNMP (Simple Network Management
analysis exportation) may require IPv6 as underlying layer and this Protocol) [RFC3411] support, or flow analysis exportation) may
should be assessed by the IXP operator. require IPv6 as an underlying layer, and 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 (Local Area Network): when both IPv4 and IPv6 1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6
traffic share a common LAN. No extra configuration is required traffic share a common LAN. No extra configuration is required
in the switch. in the switch.
2. independent VLAN (Virtual Local Area Network)[IEEE.P802-1Q.1998]: 2. independent VLAN (Virtual Local Area Network)[IEEE.P802-1Q.1998]:
when an IXP logically separates IPv4 and IPv6 traffic in when an IXP logically separates IPv4 and IPv6 traffic in
different VLANs. different VLANs.
In both configurations, IPv6 and IPv4 traffic can either share a In both configurations, IPv6 and IPv4 traffic can either share a
common physical port or use independent physical ports. The use of common physical port or use independent physical ports. The use of
independent ports can be more costly in both capital expenses (as new independent ports can be more costly in both capital expenses (as new
ports are needed) and operational expenses. ports are needed) and operational expenses.
When using the same physical port for both IPv4 and IPv6 traffic, When using the same physical port for both IPv4 and IPv6 traffic,
some changes may be needed at the participants' interfaces some changes may be needed at the participants' interfaces'
configurations. If the IXP implements the "dual-stack configurations. If the IXP implements the "dual-stack
configuration", IXP's participants will configure dual-stack configuration", IXP's participants will configure dual-stack
interfaces. On the other hand, if the IXP implements the interfaces. On the other hand, if the IXP implements the
"independent VLAN configuration", IXP participants are required to "independent VLAN configuration", IXP participants are required to
pass one additional VLAN tag across the interconnection. In this pass one additional VLAN tag across the interconnection. In this
case, if the IXP did not originally use VLAN tagging, VLAN tagging case, if the IXP did not originally use VLAN tagging, VLAN tagging
should be established and previously configured LAN may continue should be established and the previously configured LAN may continue
untagged as a "native VLAN" or be transitioned to a tagged VLAN. The untagged as a "native VLAN" or be transitioned to a tagged VLAN. The
"independent VLAN" configuration provides a logical separation of "independent VLAN" configuration provides a logical separation of
IPv4 and IPv6 traffic, simplifying separate statistical analysis for IPv4 and IPv6 traffic, simplifying separate statistical analysis for
IPv4 and IPv6 traffic. Conversely, the "dual-stack" configuration IPv4 and IPv6 traffic. Conversely, the "dual-stack" configuration
(when performing separate statistical analysis for IPv4 and IPv6 (when performing separate statistical analysis for IPv4 and IPv6
traffic) would require the use of flows techniques such as IPFIX traffic) would require the use of flow techniques such as IPFIX (IP
[RFC5101] to classify traffic based on the different ether-types Flow Information Export) [RFC5101] to classify traffic based on the
(0x0800 for IPv4, 0x0806 for ARP and 0x86DD for IPv6). different Ethertypes (0x0800 for IPv4, 0x0806 for ARP (Address
Resolution Protocol), 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]. The they need to be greater than or equal to 1280 octets [RFC2460]. The
MTU size for every LAN in an IXP should be well known by all its MTU size for every LAN in an IXP should be well known by all its
participants. 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 addresses 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. The manual IXPs will normally use manual address configuration. 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. The IPv6 Addressing Architecture [RFC4291] management tasks. The IPv6 Addressing Architecture [RFC4291]
requires that interface identifiers are 64 bits in size for prefixes requires that interface identifiers are 64 bits in size for prefixes
not starting with binary 000, resulting in a maximum prefix length of not starting with binary 000, resulting in a maximum prefix length of
/64. Longer prefix lengths up to /127 have been used operationally. /64. Longer prefix lengths up to /127 have been used operationally.
If prefix lengths longer than 64 bits are chosen, the implications If prefix lengths longer than 64 bits are chosen, the implications
described in [RFC3627] need to be considered. A /48 prefix allows described in [RFC3627] need to be considered. A /48 prefix allows
the addressing of 65536 /64 LANs. 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-exhaustive list of possible IID selection characters). A non-exhaustive 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 decimal encoding of each
encoding inside each IPv6 address. The ASN decimal number is participant's ASN (Autonomous System Number) inside its
used as the BCD (binary code decimal) encoding of the upper part correspondent IPv6 address. The ASN decimal number is used as
of the IID such as shown in this example: the BCD (binary code decimal) encoding of the upper part of the
IID such as shown in this example:
* IXP LAN prefix: 2001:db8::/64 * IXP LAN prefix: 2001:db8::/64
* ASN: 64496 * ASN: 64496
* IPv6 Address: 2001:db8:0000:0000:0000:0006:4496:0001/64 or its * IPv6 Address: 2001:db8:0000:0000:0000:0006:4496:0001/64 or its
equivalent representation 2001:db8::6:4496:1/64 equivalent representation 2001:db8::6:4496:1/64
In this example we are right justifying the participant's ASN In this example, we are right-justifying the participant's ASN
number from the 112nd bit. Remember that 32 bits ASNs require a number from the 112nd bit. Remember that 32-bit ASNs require a
maximum of 10 characters. With this example, up to 2^16 IPv6 maximum of 10 characters. With this example, up to 2^16 IPv6
addresses can be configured per ASN. addresses can be configured per ASN.
2. Although BCD encoding is more "human-readable", some IXPs prefer 2. Although BCD encoding is more "human-readable", some IXPs prefer
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 In this case, a maximum of 8 characters will be needed to
represent 32 bits ASNs. represent 32-bit 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
skipping to change at page 5, line 51 skipping to change at page 5, line 22
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. These blocks are usually only this purpose by the different RIRs. These blocks are usually only
meant for addressing the exchange fabric, and may be filtered out by meant for addressing the exchange fabric, and may be filtered out by
DFZ (Default Free Zone) operators. When considering the routing of DFZ (Default Free Zone) operators. When considering the 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 participants' AS boundaries. In this configuration attack to its participants' AS (Autonomous System) boundaries. In
participants may route these prefixes inside their networks (e. g. this configuration, participants may route these prefixes inside
using BGP no-export communities or routing the IXP LANs within the their networks (e.g., using BGP no-export communities or routing
participants' IGP) to perform fault management. Using this the IXP LANs within the participants' IGP) to perform fault
configuration, the monitoring of the IXP LANs from outside of its management. Using this configuration, the monitoring of the IXP
participants' AS boundaries is not possible. LANs from outside of its participants' AS boundaries is not
possible.
o IXP may decide that LANs should (attempt to be) be globally o IXP may decide that LANs should (attempt to) be globally routed.
routed. In this case, IXP LANs monitoring from outside its In this case, IXP LANs monitoring from outside its participants'
participants' AS boundaries may be possible but the IXP LANs will AS boundaries may be possible, but the IXP LANs will be vulnerable
be vulnerable to DoS from outside of those boundaries. to DoS from outside of those boundaries.
Additionally, possible IXP external services (such as DNS, web pages, Additionally, possible IXP external services (such as DNS, web pages,
FTP servers) need to be globally routed. These should be addressed FTP servers) need to be globally routed. These should be addressed
from separate address blocks, either from upstream providers' address from separate address blocks, either from upstream providers' address
space, or separate independent assignments. Strict prefix length space or separate independent assignments. Strict prefix length
filtering could be a reason for requesting more than one /48 filtering could be a reason for requesting more than one /48
assignment from a RIR (i.e. requesting one /48 assignment for the 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 IXPs LANs that may not be globally routed and a different, non-IXP
/48 assignment for the IXP external services that will be globally /48 assignment for the IXP external services that will be globally
routed). 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 Neighbor Discovery at an IXP 4.1. Multicast Support and Monitoring for Neighbor Discovery at an IXP
IXPs typically control broadcast traffic across the switching fabric IXPs typically control broadcast traffic across the switching fabric
in order to avoid broadcast storms by only allowing limited ARP in order to avoid broadcast storms by only allowing limited ARP
[RFC0826] traffic for address resolution. In IPv6 there is not [RFC0826] traffic for address resolution. In IPv6 there is not
broadcast support but IXPs may intend to control multicast traffic in broadcast support, but IXPs may intend to control multicast traffic
each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the in each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements
following necessary functions in an IXP switching fabric: Address the following necessary functions in an IXP switching fabric: Address
Resolution, Neighbor Unreachability Detection and Duplicate Address Resolution, Neighbor Unreachability Detection, and Duplicate Address
Detection. In order to perform these functions, Neighbor Detection. In order to perform these functions, Neighbor
Solicitation and Neighbor Advertisement packets are exchanged using Solicitation and Neighbor Advertisement packets are exchanged using
the link-local all-nodes multicast address (ff02::1) and/or the link-local all-nodes multicast address (ff02::1) and/or
solicited-node multicast addresses (ff02:0:0:0:0:1:ff00:0000 to ff02: solicited-node multicast addresses (ff02:0:0:0:0:1:ff00:0000 to ff02:
0:0:0:0:1:ffff:ffff). As described in [RFC4861] routers will 0:0:0:0:1:ffff:ffff). As described in [RFC4861], routers will
initialize its interfaces by joining its solicited-node multicast initialize their interfaces by joining their solicited-node multicast
addresses using either Multicast Listener Discovery (MLD) [RFC2710] addresses using either Multicast Listener Discovery (MLD) [RFC2710]
or MLDv2 [RFC3810] . MLD messages may be sent to the corresponding or MLDv2 [RFC3810]. MLD messages may be sent to the corresponding
group address ff02::2 (MLD) or ff02::16 (MLDv2). Depending on the group address: ff02::2 (MLD) or ff02::16 (MLDv2). Depending on the
addressing plan selected by the IXP, each solicited-node multicast addressing plan selected by the IXP, each solicited-node multicast
group may be shared by a sub-set of participants' conditioned by how group may be shared by a sub-set of participants' conditioned by how
the last three octets of the addresses are selected. In Section 3 the last three octets of the addresses are selected. In Section 3,
example 1, only participants with ASNs with the same two last digits example 1, only participants with ASNs with the same last two digits
are going to share the same solicited-node multicast group. are going to share the same solicited-node multicast group.
Similarly to the ARP policy an IXP may limit multicast traffic across Similar to the ARP policy, an IXP may limit multicast traffic across
the switching fabric in order to only allow ICMPv6 Neighbor the switching fabric in order to only allow ICMPv6 Neighbor
Solicitation, Neighbor Advertisement and MLD messages. Configuring Solicitation, Neighbor Advertisement, and MLD messages. Configuring
default routes in an IXP LAN without an agreement between the parties default routes in an IXP LAN without an agreement between the parties
is normally against IXP policies. ICMPv6 Router Advertisement is normally against IXP policies. ICMPv6 Router Advertisement
packets should neither be issued nor accepted by routers connected to packets should neither be issued nor accepted by routers connected to
the IXP. Where possible, the IXP operator should block link-local RA the IXP. Where possible, the IXP operator should block link-local RA
packets using IPv6 RA-GUARD [I-D.ietf-v6ops-ra-guard] . If this is (Router Advertisement) packets using IPv6 RA-GUARD [V6OPS-RA-GUARD] .
not possible, the IXP operator should monitor the exchange for rogue If this is not possible, the IXP operator should monitor the exchange
Router Advertisement packets as described in for rogue Router Advertisement packets as described in
[I-D.ietf-v6ops-rogue-ra] . [V6OPS-ROGUE-RA] .
4.2. IPv6 Multicast traffic exchange at an IXP 4.2. IPv6 Multicast Traffic Exchange at an IXP
For IPv6 Multicast traffic exchange, an IXP may decide to use either For IPv6 Multicast traffic exchange, an IXP may decide to use either
the same LAN being used for unicast IPv6 traffic exchange, the same the same LAN being used for unicast IPv6 traffic exchange, the same
LAN being used for IPv4 Multicast traffic exchange or a dedicated LAN LAN being used for IPv4 Multicast traffic exchange, or a dedicated
for IPv6 Multicast traffic exchange. The reason for having a LAN for IPv6 Multicast traffic exchange. The reason for having a
dedicated LAN for multicast is to prevent unwanted multicast traffic dedicated LAN for multicast is to prevent unwanted multicast traffic
to reach participants that do not have multicast support. Protocol from reaching participants that do not have multicast support.
Independent Multicast (PIM) [RFC4601] messages will be sent to the Protocol Independent Multicast (PIM) [RFC4601] messages will be sent
link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the to the link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in
selected LAN and should be allowed. Implementing IPv6 PIM snooping the selected LAN and should be allowed. Implementing IPv6 PIM
will allow only the participants associated to a particular group to snooping will allow only the participants associated with a
receive its multicast traffic. BGP reachability information for IPv6 particular group to receive its multicast traffic. BGP reachability
multicast address-family (SAFI=2) is normally exchanged using MP-BGP information for IPv6 multicast address family (SAFI=2) is normally
[RFC4760] and is used for Reverse Path Forwarding (RPF) lookups exchanged using MP-BGP (Multi-Protocol BGP) [RFC4760] and is used for
performed by the IPv6 PIM. If a dedicated LAN is configured for Reverse Path Forwarding (RPF) lookups performed by the IPv6 PIM. If
Multicast IPv6 traffic exchange, reachability information for IPv6 a dedicated LAN is configured for Multicast IPv6 traffic exchange,
Multicast address family should be carried in new BGP sessions. reachability information for IPv6 Multicast address family should be
ICMPv6 Neighbor Discovery should be allowed in the Multicast IPv6 LAN carried in new BGP sessions. ICMPv6 Neighbor Discovery should be
as described in the previous paragraph. allowed in the Multicast IPv6 LAN as described in the previous
paragraph.
5. Reverse DNS 5. Reverse DNS
The inclusion of PTR records for all addresses assigned to The inclusion of PTR records for all addresses assigned to
participants in the IXP reverse zone under "ip6.arpa" facilitates participants in the IXP reverse zone under "ip6.arpa" facilitates
troubleshooting, particularly when using tools such as traceroute. troubleshooting, particularly when using tools such as traceroute.
If reverse DNS is configured, DNS servers should be reachable over If reverse DNS is configured, DNS servers should be reachable over
IPv6 transport for complete IPv6 support. IPv6 transport for complete IPv6 support.
6. Route-Server 6. Route-Server
IXPs may offer a Route-Server service, either for Multi-Lateral IXPs may offer a route-server service, either for Multi-Lateral
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 MP-BGP extensions for IPv6 address family
IPv6 address family ([RFC2545] and [RFC4760]). ([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. Because of the size of the IPv6 space, limiting the maximum plane. Because of the size of the IPv6 space, limiting the maximum
number of IPv6 prefixes in every session should be studied. 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
evaluated as well. In general, each service that is currently evaluated as well. In general, each service that is currently
accessed through IPv4 or that handle IPv4 addresses should be accessed through IPv4 or that handle IPv4 addresses should be
evaluated for IPv6 support. evaluated for IPv6 support.
Internal services are also important when considering IPv6 adoption Internal services are also important when considering IPv6 adoption
at an IXP. Such services may not deal with IPv6 traffic but may at an IXP. Such services may not deal with IPv6 traffic, but may
handle IPv6 addresses; that is the case of provisioning systems, handle IPv6 addresses; that is the case of provisioning systems,
logging tools and statistics analysis tools. Databases and tools logging tools and statistics analysis tools. Databases and tools
should be evaluated for IPv6 support. should be evaluated for IPv6 support.
8. IXP Policies and IPv6 8. IXP Policies and IPv6
IXP Policies and contracts should be revised as any mention of IP IXP policies and contracts should be revised as any mention of IP
should be clarified if it refers to IPv4, IPv6 or both. should be clarified if it refers to IPv4, IPv6, or both.
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 4.
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations 9. Security Considerations
This memo includes references to procedures for monitoring and/or This memo includes references to procedures for monitoring and/or
avoiding particular ICMPv6 traffic at IXPs' LANs. None of these avoiding particular ICMPv6 traffic at IXPs' LANs. None of these
procedures prevent Ethernet loops caused by mischief in the LAN. The procedures prevent Ethernet loops caused by mischief in the LAN. The
document also mentions how to limit IPv6 DoS attacks to the IXP document also mentions how to limit IPv6 DoS attacks to the IXP
switch fabric by not globally announce the IXP LANs prefix. switch fabric by not globally announce the IXP LANs prefix.
11. Acknowledgements 10. 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 Friacas, Arien Vijn, Fernando Gont and Louis Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont, and Louis
Lee. Lee.
12. Informative References 11. Informative References
[I-D.ietf-v6ops-ra-guard]
Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-05
(work in progress), May 2010.
[I-D.ietf-v6ops-rogue-ra]
Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", draft-ietf-v6ops-rogue-ra-00 (work in
progress), May 2009.
[IEEE.P802-1Q.1998] [IEEE.P802-1Q.1998]
Institute of Electrical and Electronics Engineers, "Local Institute of Electrical and Electronics Engineers, "Local
and Metropolitan Area Networks: Virtual Bridged Local Area and Metropolitan Area Networks: Virtual Bridged Local Area
Networks", IEEE Draft P802.1Q, March 1998. Networks", IEEE Draft P802.1Q, March 1998.
[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.
skipping to change at page 11, line 5 skipping to change at page 10, line 5
[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", 2009, 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>.
[V6OPS-RA-GUARD]
Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 RA-Guard", Work in Progress, June 2010.
[V6OPS-ROGUE-RA]
Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
Problem Statement", Work in Progress, June 2010.
Author's Address Author's Address
Roque Gagliano Roque Gagliano
Cisco Systems Cisco Systems
Avenue des Uttins 5 Avenue des Uttins 5
Rolle, 1180 Rolle, 1180
Switzerland Switzerland
Email: rogaglia@cisco.com EMail: rogaglia@cisco.com
 End of changes. 51 change blocks. 
136 lines changed or deleted 133 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/