draft-ietf-v6ops-v6inixp-05.txt   draft-ietf-v6ops-v6inixp-06.txt 
Internet Engineering Task Force R. Gagliano Internet Engineering Task Force R. Gagliano
Internet-Draft LACNIC Internet-Draft Cisco Systems
Intended status: Informational February 8, 2010 Intended status: Informational May 20, 2010
Expires: August 12, 2010 Expires: November 21, 2010
IPv6 Deployment in Internet Exchange Points (IXPs) IPv6 Deployment in Internet Exchange Points (IXPs)
draft-ietf-v6ops-v6inixp-05.txt draft-ietf-v6ops-v6inixp-06.txt
Abstract Abstract
This document provides guidance on IPv6 deployment in Internet This document provides guidance on IPv6 deployment in Internet
Exchange Points (IXP). It includes information regarding the switch Exchange Points (IXP). It includes information regarding the switch
fabric configuration, the addressing plan and general organizational fabric configuration, the addressing plan and general organizational
tasks that need to be performed. IXPs are mainly a layer 2 tasks that need to be performed. IXPs are mainly a layer 2
infrastructure and in many cases the best recommendations suggest infrastructure and in many cases the best recommendations suggest
that the IPv6 data, control and management plane should not be that the IPv6 data, control and management plane should not be
handled differently than in IPv4. handled differently than in IPv4.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
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 This Internet-Draft will expire on November 21, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 12, 2010.
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 BSD License. described in the Simplified BSD License.
This document may contain material 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3 2. Switch Fabric Configuration . . . . . . . . . . . . . . . . . 3
3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4 3. Addressing Plan . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6 4.1. Multicast Support and Monitoring for ND at an IXP . . . . 6
4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7 4.2. IPv6 Multicast traffic exchange at an IXP . . . . . . . . 7
5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . 7
skipping to change at page 4, line 18 skipping to change at page 3, line 18
the adoption of IPv6 an easy task. However, IXPs normally implement the adoption of IPv6 an easy task. However, IXPs normally implement
additional services such as statistics, route servers, looking additional services such as statistics, route servers, looking
glasses and broadcast control that may be impacted by the glasses and broadcast control that may be impacted by the
implementation of IPv6. This document clarifies the impact of IPv6 implementation of IPv6. This document clarifies the impact of IPv6
on a new or an existing IXP. The document assumes an Ethernet switch on a new or an existing IXP. The document assumes an Ethernet switch
fabric, although other layer 2 configurations can be deployed. fabric, although other layer 2 configurations can be deployed.
2. Switch Fabric Configuration 2. Switch Fabric Configuration
An Ethernet based IXP switch fabric implements IPv6 over Ethernet as An Ethernet based IXP switch fabric implements IPv6 over Ethernet as
described in [RFC2464]. Therefore, the switching of IPv6 traffic described in [RFC2464] . Therefore, the switching of IPv6 traffic
happens in the same way as in IPv4. However, some management happens in the same way as in IPv4. However, some management
functions may require explicit IPv6 support (such as switch functions may require explicit IPv6 support (such as switch
management, SNMP [RFC3411] support and flow analysis exportation) and management, SNMP [RFC3411] support and flow analysis exportation) and
this should be assessed by the IXP operator. this should be assessed by the IXP operator.
There are two common configurations of IXP switch ports to support There are two common configurations of IXP switch ports to support
IPv6: IPv6:
1. dual-stack LAN (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
skipping to change at page 5, line 21 skipping to change at page 4, line 21
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 address to IXPs. Those
allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES].
Depending on the country and region of operation, address assignments Depending on the country and region of operation, address assignments
may be made by NIRs (National Internet Registries). Unique Local may be made by NIRs (National Internet Registries). Unique Local
IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP IPv6 Unicast Addresses ( [RFC4193] ) are normally not used in an IXP
LAN as global reverse DNS resolution and whois services are required. LAN as global reverse DNS resolution and whois services are required.
IXPs will normally use manual address configuration. 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
starting with binary 000, resulting in a maximum prefix length of 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.
skipping to change at page 7, line 48 skipping to change at page 6, line 48
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 described in Router Advertisement packets as described in
[I-D.ietf-v6ops-rogue-ra]. [I-D.ietf-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 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 (PIM) [RFC4601] messages will be sent to the Independent Multicast (PIM) [RFC4601] messages will be sent to the
skipping to change at page 9, line 46 skipping to change at page 8, line 46
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 Section 4 .
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
This memo includes procedures for monitoring and/or avoiding This memo includes procedures for monitoring and/or avoiding
particular ICMPv6 traffic at IXPs' LANs. None of these methods particular ICMPv6 traffic at IXPs' LANs. None of these methods
prevent Ethernet loops caused by mischief in the LAN. The document prevent Ethernet loops caused by mischief in the LAN. The document
also mentions how to limit IPv6 DoS attacks to the IXP switch fabric also mentions how to limit IPv6 DoS attacks to the IXP switch fabric
by not globally announce the IXP LANs prefix. by not globally announce the IXP LANs prefix.
11. Acknowledgements 11. Acknowledgements
The author would like to thank the contributions from Alain Aina, The author would like to thank the contributions from Alain Aina,
Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels,
Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont and Louis Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont and Louis
Lee, Lee.
12. Informative References 12. Informative References
[I-D.ietf-v6ops-ra-guard] [I-D.ietf-v6ops-ra-guard]
Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-03 Mohacsi, "IPv6 RA-Guard", draft-ietf-v6ops-ra-guard-03
(work in progress), May 2009. (work in progress), May 2009.
[I-D.ietf-v6ops-rogue-ra] [I-D.ietf-v6ops-rogue-ra]
Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
skipping to change at page 12, line 11 skipping to change at page 11, line 11
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>.
Author's Address Author's Address
Roque Gagliano Roque Gagliano
LACNIC Cisco Systems
Rambla Rep Mexico 6125 Avenue des Uttins 5
Montevideo, 11400 Rolle, 1180
Uruguay Switzerland
Phone: +598 2 4005633 Email: rogaglia@cisco.com
Email: roque@lacnic.net
 End of changes. 15 change blocks. 
39 lines changed or deleted 21 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/