draft-ietf-v6ops-v6inixp-01.txt   draft-ietf-v6ops-v6inixp-02.txt 
Internet Engineering Task Force R. Gagliano Internet Engineering Task Force R. Gagliano
Internet-Draft LACNIC Internet-Draft LACNIC
Intended status: Informational July 03, 2009 Intended status: Informational September 08, 2009
Expires: January 4, 2010 Expires: March 12, 2010
IPv6 Deployment in Internet Exchange Points (IXPs) IPv6 Deployment in Internet Exchange Points (IXPs)
draft-ietf-v6ops-v6inixp-01.txt draft-ietf-v6ops-v6inixp-02.txt
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. provisions of BCP 78 and BCP 79.
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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 January 4, 2010. This Internet-Draft will expire on March 12, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This document provides a guide for IPv6 deployment in Internet This document provides a guide for IPv6 deployment in Internet
Exchange Points (IXP). It includes information about the switch Exchange Points (IXP). It includes information regarding the switch
fabric configuration, the addressing plan options and general fabric configuration, the addressing plan and general organizational
organizational tasks to be performed. IXP are mainly a layer 2 tasks to be performed. IXPs are mainly a layer 2 infrastructure and
device and in many case the best recommendations state that the IPv6 in many case the best recommendations state that the IPv6 data,
data, control and management plane should not be handled differently control and management plane should not be handled differently than
than in IPv4. in IPv4.
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 . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Route Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Route Server . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Internal and External Services support . . . . . . . . . . . . 7 7. External and Internal support . . . . . . . . . . . . . . . . 7
8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . . 7 8. IXP Policies and IPv6 . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Most Internet Exchange Points (IXP) work on the Layer 2 level, making Most Internet Exchange Points (IXP) work on 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, broadcast control that may be impacted by the implementation glasses and broadcast control that may be impacted by the
of IPv6. This document gives guidance on the impact of IPv6 on a new implementation of IPv6. This document clarifies the impact of IPv6
or an existing IXP that may or may not fit any particular deployment. on a new or an existing IXP that may or may not fit any particular
The document assumes an Ethernet switch fabric, algthouh other layer deployment. The document assumes an Ethernet switch fabric, although
2 canfigurations can be deployed. 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 require explicit IPv6 support (such as switch management,
SNMP support and flow analysis exportation) and its need should be SNMP support and flow analysis exportation) and this should be
evaluated by the IXP administrator. 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 port can be an option. interfaces, although independent port can be 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 their routers interfaces that are facing the (VLAN) tagging on their routers interfaces that are facing the
IXP switch, this only requires passing one additional VLAN tag IXP switch, this only requires passing one additional VLAN tag
across the interconnection. If participants are using untagged across the interconnection. If participants are using untagged
interconnections with the IXP switch and wish to continue doing interconnections with the IXP switch and wish to continue doing
so, they will need to facilitate a separate physical port to so, they will need to facilitate a separate physical port to
access the IPv6-specific LAN. 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
using flows techniques such as in IPFIX [RFC5101] considering the using flows techniques such as IPFIX [RFC5101] considering the
different ether-types (0x0800 for IPv4 and 0x86DD for IPv6). 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
it needs to be greater than or equal to 1280 octets [RFC2460]. they need to be greater than or equal to 1280 octets [RFC2460].
Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes, so typically Common MTU sizes in IXPs are 1500, 4470, or 9216 bytes.
this requires no change of configuration. The MTU size for every LAN Consequently, no MTU changes are typically required. The MTU size
in an IXP should be well know by all its participants. for every LAN in an IXP should be well know 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
allocate Provider Independent (PI) IPv6 address to IXPs. Those allocate 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 allocations Depending on the country and region of operation, address allocations
may be provided by NIRs (National Internet Registries). may be provided by NIRs (National Internet Registries). Unique Local
IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP
LAN as global reverse DNS resolution and whois services are required.
From the allocated prefix, following the recommendations of From the allocated prefix, following the recommendations of
[RFC4291], a /64 prefix should be allocated for each of the exchange [RFC4291], a /64 prefix should be allocated for each of the exchange
point IPv6 enabled LANs. A /48 prefix allows the addressing of 65536 point IPv6 enabled LANs. A /48 prefix allows the addressing of 65536
LANs. As IXP will normally use manual address configuration, longer LANs. As IXP will normally use manual address configuration, longer
prefixes (/65-/127), are technically feasible but are normally prefixes (/65-/127), are technically feasible but are normally
discouraged because of operational practices.The manual configuration discouraged because of operational practices. The manual
of IPv6 addresses allows IXP participants to replace network configuration of IPv6 addresses allows IXP participants to replace
interfaces with no need to reconfigure Border Gateway Protocol (BGP) network interfaces with no need to reconfigure Border Gateway
sessions information and facilitates management tasks. Protocol (BGP) sessions information and it also facilitates
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 "intelligently" fill its 64 bits (or
16 hexadecimal characters). A non exhausted list of possible IID 16 hexadecimal characters). A non-exhausted list of possible IID
selection mechanisms follows: selection 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 number encoding inside each IPv6 address. The ASN decimal number is
is used as the BCD (binary code decimal) encoding of the upper used as the BCD (binary code decimal) encoding of the upper part
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: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' ASN
number from the the 112nd bit.Remember that 32 bits ASNs require number from the 112nd bit. Remember that 32 bits ASNs require a
a maximum of 10 characters. Whith 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)
skipping to change at page 5, line 38 skipping to change at page 5, line 41
* IPv6 Address: 2001:DB8::132/64 * IPv6 Address: 2001:DB8::132/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.
The current practice that applies to IPv4 about publishing IXP The current practice that applies to IPv4 about publishing IXP
allocations to the DFZ (Default Free Zone) should also apply to the allocations to the DFZ (Default Free Zone) should also apply to the
IPv6 allocation (normally a /48 prefix). Typically IXPs LANs are not IPv6 allocation (normally a /48 prefix). Typically IXPs LANs are not
globally reachable in order to avoid a Distributed Denial of Service globally reachable in order to avoid a Distributed Denial of Service
(DDoS) attack but participant may route these prefixes inside their (DDoS) attack but participant may route these prefixes inside their
networks (ex. using BGP no-export communities or routing the IXP LANs networks (e. g. using BGP no-export communities or routing the IXP
within the participant' IGP) to perform fault management. IXP LANs within the participants' IGP) to perform fault management. IXP
external services (such as dns, web pages, ftp servers) needs to be external services (such as dns, web pages, ftp servers) needs to be
globally routed and due to strict prefix length filtering could be globally routed and due to strict prefix length filtering could be
the reason to request a shorter than /48 assignment from an RIR (ex the reason to request more than one /48 assignment from a RIR (i.e.
requesting a /47 assignment and using one /48 for the IXPs LANs that requesting one /48 for the IXPs LANs that is not globally routed and
is not globally routed and one /48 for the IXP external services that a different /48 for the IXP external services that is globally
is globally routed). routed). IPv6 prefixes for IXP LAN's are typically publicly well
known.
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 netighbor discovery and multicast in an IXP: multicast support for neighbor discovery and
multicast peering. multicast peering.
IXPs typically control broadcast traffic accross switching fabric in IXPs typically control broadcast traffic across the switching fabric
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 exchange using Solicitation and Neighbor Advertisement packets are exchange 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
initializate 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). Similarly to the group address:FF02::2 (MLD) or FF02::16 (MLDv2). Depending on the
ARP policy an IXP may limit multicast traffic acccross the switching addressing plan selected by the IXP, each solicited-node multicast
fabric in order to only allow ICMPv6 Neighbor Solicitation, Neighbor group may be shared by a sub-set of participants' conditioned by how
Advertisement and MLD messages. Configuring default routes in an IXP the last three octects of the addresses are selected. In Section 3
LAN without an agreement within the parties is normally against IXP example 1, only participants with ASNs with the same two last digits
policies. For that reason, eventhough routers should ignore them, are going to share the same solocited-node multicast group.
rogue ICMPv6 route advertisements may be monitored in order to
prevent configuration errors.
For IPv6 Multicast traffic exhange, an IXP may decide to use either Similarly to the ARP policy an IXP may limit multicast traffic
accross the switching fabric in order to only allow ICMPv6 Neighbor
Solicitation, Neighbor Advertisement and MLD messages. Configuring
default routes in an IXP LAN without an agreement within the parties
is normally against IXP policies. ICMPv6 Router Advertisement
packets should neither be issued nor accepted by routers connected to
the IXP. Where possible, the IXP operator should block link-local RA
packets using IPv6 RA-Guard. If this is not possible, the IXP
operator should monitor the exchange for rogue Router Advertisement
packets.
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 the Independent Multicast [RFC4601] messages will be sent to the the
link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the
selected LAN and should be allowed. Implementing IPv6 PIM snooping selected LAN and should be allowed. Implementing IPv6 PIM snooping
will allow that only the participants associated to a particular will allow only the participants associated to a particular group to
group will receive its multicast traffic. BGP reachability receive its multicast traffic. BGP reachability information for IPv6
information for IPv6 multicast address-family (SAFI=2) is normally multicast address-family (SAFI=2) is normally exchanged using MP-BGP
exchanged using MP-BGP [RFC4760] and is used for Reverse Path [RFC4760] and is used for Reverse Path Forwarding (RPF) lookups
Forwarding (RPF) lookups performed by the IPv6 PIM (Protocol performed by the IPv6 PIM. If a dedicated LAN is configured for
Independent Multicast) protocol [RFC4601]. If a dedicated LAN is Multicast IPv6 traffic exchange, reachability information for IPv6
configured for Multicast IPv6 traffic exchange, reachability Multicast address family should be carried in new BGP sessions.
information for IPv6 Multicast address familly should be carried in ICMPv6 Neighbor Discovery should be allowed in the Multicast IPv6 LAN
new BGP sessions. ICMPv6 Neighbor Discovery should be allowed in the as described in the previous paragraph.
Multicast IPv6 LAN as described in the previous paragraph.
5. Reverse DNS 5. Reverse DNS
PTR records for all addresses assigned to participants should be PTR records for all addresses assigned to participants should be
included in the IXP reverse zone under "ip6.arpa". DNS servers included in the IXP reverse zone under "ip6.arpa" for troubleshooting
should be reachable over IPv6 transport. purposes. DNS servers should be reachable over 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 to have IPv6 SAFI (Subsequent Address Family A good practice is that all BGP sessions used to exchange IPv6
Identifiers) information carried over sessions established also on network information are configured using IPv6 data transport. This
top of the IPv6 IP/TCP stack and independently of the IPv4 sessions. configuration style ensures that as both network reachability
This configuration allows that in the event of IPv6 reachability information and generic packet data transport use the same transport
issues to any IPv6 peer, the IPv6 session will be turned down and the plane, in the event of IPv6 reachability problems between IPv6 peers,
IPv4 session to the same peer will not be affected. Please consider the IPv6 BGP session may be terminated independently of any IPv4
the use of MD5 [RFC2385] or IPSEC [RFC4301] to authenticate the BGP sessions. The use of MD5 [RFC2385] or IPSEC [RFC4301] to
sessions. authenticate the BGP sessions and the use of GTSM (The Generalized
TTL Security Mechanism) [RFC3682] should be considered.
The Router-Server or Looking Glass external service should be The Router-Server or Looking Glass external service should be
available for external IPv6 access, either by an IPv6 enabled web available for external IPv6 access, either by an IPv6 enabled web
page or an IPv6 enabled console interface. page or an IPv6 enabled console interface.
7. Internal and External Services 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 may need to be revised as any mention of IP should be IXP Policies and contracts should be be revised as any mention of IP
clarified if it refers to IPv4, IPv6 or both. The current should be clarified if it refers to IPv4, IPv6 or both.
interpretation is that IP refers to the Internet Protocol,
independently of the its version (i.e. both IPv4 and IPv6). In any
case contracts and policies should be reviewed for any occurrence of
IP and/or IPv4 and replace it with the appropriate IP, IPv4 and/or
IPv6 language.
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 no Security Considerations. This memo includes information on practices at IXPs for monitoring
and/or avoiding broadcast storms in IXP LANs caused by IPv6 multicast
traffic. It also mentions avoiding IPv6 DDoS attacks to the IXP
switching fabric by not globally announce the IXP LANs prefix.
11. Acknowledgements 11. Acknowledgements
The author would like to thank the contributions from Stig Venaas, The author would like to thank the contributions from Stig Venaas,
Martin Levy, Bill Woodcock, Carlos Frias, Arien Vijn and Louis Lee. Martin Levy, Nick Hilliard, Martin Pels, Bill Woodcock, Carlos Frias,
Arien Vijn and Louis Lee.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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 9, line 7 skipping to change at page 9, line 22
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.
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
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
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
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006.
 End of changes. 34 change blocks. 
98 lines changed or deleted 118 lines changed or added

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