draft-ietf-v6ops-v6inixp-03.txt   draft-ietf-v6ops-v6inixp-04.txt 
Internet Engineering Task Force R. Gagliano Internet Engineering Task Force R. Gagliano
Internet-Draft LACNIC Internet-Draft LACNIC
Intended status: Informational October 23, 2009 Intended status: Informational November 24, 2009
Expires: April 8, 2010 Expires: May 28, 2010
IPv6 Deployment in Internet Exchange Points (IXPs) IPv6 Deployment in Internet Exchange Points (IXPs)
draft-ietf-v6ops-v6inixp-03.txt draft-ietf-v6ops-v6inixp-04.txt
Abstract
This document provides guidance on IPv6 deployment in Internet
Exchange Points (IXP). It includes information regarding the switch
fabric configuration, the addressing plan and general organizational
tasks that need to be performed. IXPs are mainly a layer 2
infrastructure and in many cases the best recommendations suggest
that the IPv6 data, control and management plane should not be
handled differently than in IPv4.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 8, 2010. This Internet-Draft will expire on May 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract 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 BSD License.
This document provides guidance on IPv6 deployment in Internet This document may contain material from IETF Documents or IETF
Exchange Points (IXP). It includes information regarding the switch Contributions published or made publicly available before November
fabric configuration, the addressing plan and general organizational 10, 2008. The person(s) controlling the copyright in some of this
tasks that need to be performed. IXPs are mainly a layer 2 material may not have granted the IETF Trust the right to allow
infrastructure and in many cases the best recommendations suggest modifications of such material outside the IETF Standards Process.
that the IPv6 data, control and management plane should not be Without obtaining an adequate license from the person(s) controlling
handled differently than in IPv4. the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 exhange 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Informative References . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
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 require explicit IPv6 support (such as switch management, functions may require explicit IPv6 support (such as switch
SNMP [RFC1157] support and flow analysis exportation) and this should management, SNMP [RFC1157] support and flow analysis exportation) and
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: both IPv4 and IPv6 traffic share a common LAN.
No extra configuration is required in the switch. In this No extra configuration is required in the switch. In this
scenario, participants will typically configure dual-stack scenario, participants will typically configure dual-stack
interfaces, although independent interfaces are an option. interfaces, although independent interfaces are an option.
2. independent LAN: an exclusive IPv6 LAN is created for IPv6 2. independent LAN: an exclusive IPv6 LAN is created for IPv6
traffic. If IXP participants are already using Virtual LAN traffic. If IXP participants are already using Virtual LAN
(VLAN) tagging on the interfaces of their routers that are facing (VLAN) tagging on the interfaces of their routers that are facing
the IXP switch, this only requires passing one additional VLAN the IXP switch, this only requires passing one additional VLAN
tag across the interconnection. If participants are using tag across the interconnection. If participants are using
untagged interconnections with the IXP switch and wish to untagged interconnections with the IXP switch and wish to
continue doing so, they will need to facilitate a separate continue doing so, they will need to provision a separate
physical port to access the IPv6-specific LAN. physical port to access the IPv6-specific LAN.
The "independent LAN" configuration provides a physical separation The "independent LAN" configuration provides a physical separation
for IPv4 and IPv6 traffic simplifying separate analysis for IPv4 and for IPv4 and IPv6 traffic simplifying separate analysis for IPv4 and
IPv6 traffic. However, it can be more costly in both capital IPv6 traffic. However, it can be more costly in both capital
expenses (if new ports are needed) and operational expends. expenses (if new ports are needed) and operational expends.
Conversely, the dual-stack implementation allows a quick and capital Conversely, the dual-stack implementation allows a quick and capital
cost-free start-up for IPv6 support in the IXP, allowing the IXP to cost-free start-up for IPv6 support in the IXP, allowing the IXP to
avoid transforming untagged ports into tagged ports. In this avoid transforming untagged ports into tagged ports. In this
implementation, traffic-split for statistical analysis may be done implementation, traffic-split for statistical analysis may be done
skipping to change at page 4, line 21 skipping to change at page 5, line 21
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.
From the allocated prefix, following the recommendations of IXPs will normally use manual address configuration. Address prefix
[RFC4291], a /64 prefix should be allocated for each of the exchange between /64 and /127 are technically feasible [RFC4291]. Because of
point IPv6 enabled LANs. A /48 prefix allows the addressing of 65536 operational practices, IXP will normally chose a /64 prefix to be
LANs. As IXP will normally use manual address configuration. Longer allocated for each of the IXP's IPv6 enabled LANs. In this case, a
prefixes (/65-/127), are technically feasible but are normally /48 prefix allows the addressing of 65536 LANs. The manual
discouraged because of operational practices. 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.
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 "intelligently" fill its 64 bits (or are different options on how to fill its 64 bits (or 16 hexadecimal
16 hexadecimal characters). A non-exhausted list of possible IID characters). A non-exhausted list of possible IID selection
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:
* IXP LAN prefix: 2001:DB8::/64 * IXP LAN prefix: 2001:db8::/64
* ASN: 64496 * ASN: 64496
* IPv6 Address: 2001:DB8::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' 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 bits 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: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
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
three 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::132/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.The current practice that applies
to IPv4 about publishing IXP allocations to the DFZ (Default Free to IPv4 about publishing IXP allocations to the DFZ (Default Free
Zone) should also apply to the IPv6 allocation. When considering the Zone) should also apply to the IPv6 allocation. When considering the
routing of the IXP LANs two options are identified: routing of 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 Distributed Denial of order to limit the possible origins of a Denial of Service (DoS)
Service (DDoS) attack to its particpant' AS boundries. In this attack to its particpants' AS boundaries. In this configuration
configuration participants may route these prefixes inside their participants may route these prefixes inside their networks (e. g.
networks (e. g. using BGP no-export communities or routing the IXP using BGP no-export communities or routing the IXP LANs within the
LANs within the participants' IGP) to perform fault management. participants' IGP) to perform fault management. Using this
Using this configuration, the monitoring of the IXP LANs from configuration, the monitoring of the IXP LANs from outside of its
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 be globally routed. In this case,
IXP LANs monitoring from outside its participants' AS boundaries IXP LANs monitoring from outside its participants' AS boundaries
is possible but the IXP LANs will be vulnerable to DDoS from is possible but the IXP LANs will be vulnerable to DoS from
outside of those broundries. outside of those boundaries.
IXP external services (such as dns, web pages, ftp servers) need to IXP external services (such as dns, web pages, ftp servers) need to
be globally routed. Strict prefix length filtering could be the be globally routed. Strict prefix length filtering could be the
reason for requesting more than one /48 assignment from a RIR (i.e. reason for requesting more than one /48 assignment from a RIR (i.e.
requesting one /48 assignment for the IXPs LANs that may not be requesting one /48 assignment for the IXPs LANs that may not be
globally routed and a different /48 assignment for the IXP external globally routed and a different /48 assignment for the IXP external
services that will be globally routed). services that will be globally routed).
4. Multicast IPv6 4. Multicast IPv6
skipping to change at page 6, line 31 skipping to change at page 7, line 29
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 IXP may intend to control multicast traffic in broadcast support but IXP may intend to control multicast traffic in
each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the
following necessary functions in an IXP switching fabric: Address 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 its interfaces by joining its 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 two last 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 Similarly 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 packets using IPv6 RA-GUARD [I-D.ietf-v6ops-ra-guard]. If this is
not possible, the IXP operator should monitor the exchange for rogue not possible, the IXP operator should monitor the exchange for rogue
Router Advertisement packets as decribed in Router Advertisement packets as described in
[I-D.ietf-v6ops-rogue-ra]. [I-D.ietf-v6ops-rogue-ra].
4.2. IPv6 Multicast traffic exhange 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 LAN
for IPv6 Multicast traffic exchange. The reason for having a 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 to reach participants that do not have multicast support. Protocol
Independent Multicast [RFC4601] messages will be sent to the link- Independent Multicast (PIM) [RFC4601] messages will be sent to the
local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the selected link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the
LAN and should be allowed. Implementing IPv6 PIM snooping will allow selected LAN and should be allowed. Implementing IPv6 PIM snooping
only the participants associated to a particular group to receive its will allow only the participants associated to a particular group to
multicast traffic. BGP reachability information for IPv6 multicast receive its multicast traffic. BGP reachability information for IPv6
address-family (SAFI=2) is normally exchanged using MP-BGP [RFC4760] multicast address-family (SAFI=2) is normally exchanged using MP-BGP
and is used for Reverse Path Forwarding (RPF) lookups performed by [RFC4760] and is used for Reverse Path Forwarding (RPF) lookups
the IPv6 PIM. If a dedicated LAN is configured for Multicast IPv6 performed by the IPv6 PIM. If a dedicated LAN is configured for
traffic exchange, reachability information for IPv6 Multicast address Multicast IPv6 traffic exchange, reachability information for IPv6
family should be carried in new BGP sessions. ICMPv6 Neighbor Multicast address family should be carried in new BGP sessions.
Discovery should be allowed in the Multicast IPv6 LAN as described in ICMPv6 Neighbor Discovery should be allowed in the Multicast IPv6 LAN
the previous paragraph. 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 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. In the event of IPv6 reachability problems between IPv6
peers, the IPv6 BGP session may be terminated independently of any peers, the IPv6 BGP session may be terminated independently of any
IPv4 sessions. The use of MD5 [RFC2385] or IPSEC [RFC4301] to IPv4 sessions. The use of MD5 [RFC2385] or IPSEC [RFC4301] to
authenticate the BGP sessions and the use of GTSM (The Generalized authenticate the BGP sessions and the use of GTSM (The Generalized
TTL Security Mechanism) [RFC3682] should be considered. 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.
The Router-Server or Looking Glass external service should be External services should be available for external IPv6 access,
available for external IPv6 access, either by an IPv6 enabled web either by an IPv6 enabled web page or an IPv6 enabled console
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.
skipping to change at page 8, line 35 skipping to change at page 9, line 34
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
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 information on practices at IXPs for monitoring This memo includes procedures for monitoring and/or avoiding
and/or avoiding broadcast storms in IXP LANs caused by IPv6 multicast particular ICMPv6 traffic at IXPs' LANs. It also mentions how to
traffic. It also mentions avoiding IPv6 DDoS attacks to the IXP limit IPv6 DoS attacks to the IXP switch fabric by not globally
switching fabric by not globally announce the IXP LANs prefix and announce the IXP LANs prefix.
recommends to monitor ICMPv6 activity.
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 Frias, Arien Vijn, Fernando Gont and Louis Lee,
12. References 12. Informative References
12.1. Normative 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.
skipping to change at page 10, line 37 skipping to change at page 11, line 36
January 2007. January 2007.
[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.
12.2. Informative References
[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", 2008,
<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
UY Uruguay
Phone: +598 2 4005633 Phone: +598 2 4005633
Email: roque@lacnic.net Email: roque@lacnic.net
 End of changes. 38 change blocks. 
101 lines changed or deleted 105 lines changed or added

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