Internet Engineering Task Force                              R. Gagliano
Internet-Draft                                                    LACNIC
Intended status: Informational                             July 03,                        September 08, 2009
Expires: January 4, March 12, 2010

           IPv6 Deployment in Internet Exchange Points (IXPs)
                    draft-ietf-v6ops-v6inixp-01.txt
                    draft-ietf-v6ops-v6inixp-02.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   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 January 4, March 12, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document provides a guide for IPv6 deployment in Internet
   Exchange Points (IXP).  It includes information about regarding the switch
   fabric configuration, the addressing plan options and general organizational
   tasks to be performed.  IXP  IXPs are mainly a layer 2
   device infrastructure and
   in many case the best recommendations state that the IPv6 data,
   control and management plane should not be handled differently than
   in IPv4.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Switch Fabric Configuration  . . . . . . . . . . . . . . . . . .  3
   3.  Addressing Plan  . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Multicast IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 5  6
   5.  Reverse DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . 6  7
   6.  Route Server . . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Internal and  External Services and Internal support  . . . . . . . . . . . . . . . .  7
   8.  IXP Policies and IPv6  . . . . . . . . . . . . . . . . . . . . . 7  8
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  8
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . .  8
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     12.1.  Normative References  . . . . . . . . . . . . . . . . . . .  8
     12.2.  Informative References  . . . . . . . . . . . . . . . . . . 9 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 10

1.  Introduction

   Most Internet Exchange Points (IXP) work on the Layer 2 level, making
   the adoption of IPv6 an easy task.  However, IXPs normally implement
   additional services such as statistics, route servers, looking
   glasses,
   glasses and broadcast control that may be impacted by the
   implementation of IPv6.  This document gives guidance on clarifies the impact of IPv6
   on a new or an existing IXP that may or may not fit any particular
   deployment.  The document assumes an Ethernet switch fabric, algthouh although
   other layer 2 canfigurations configurations can be deployed.

2.  Switch Fabric Configuration

   An Ethernet based IXP switch fabric implements IPv6 over Ethernet as
   described in [RFC2464], therefore [RFC2464].  Therefore, the switching of IPv6 traffic
   happens in the same way as in IPv4.  However, some management
   functions require explicit IPv6 support (such as switch management,
   SNMP support and flow analysis exportation) and its need this should be
   evaluated
   assessed by the IXP administrator. operator.

   There are two common configurations of IXP switch ports to support
   IPv6:

   1.  dual stack LAN: both IPv4 and IPv6 traffic share a common LAN.
       No extra configuration is required in the switch.  In this
       scenario, participants will typically configure dual stack
       interfaces
       interfaces, although independent port can be an option.

   2.  independent LAN: an exclusive IPv6 LAN is created for IPv6
       traffic.  If IXP participants are already using Virtual LAN
       (VLAN) tagging on their routers interfaces that are facing the
       IXP switch, this only requires passing one additional VLAN tag
       across the interconnection.  If participants are using untagged
       interconnections with the IXP switch and wish to continue doing
       so, they will need to facilitate a separate physical port to
       access the IPv6-specific LAN.

   The "independent LAN" configuration provides a physical separation
   for IPv4 and IPv6 traffic simplifying separate analysis for IPv4 and
   IPv6 traffic.  However, it can be more costly in both capital
   expenses (if new ports are needed) and operational expends.
   Conversely, the dual stack implementation allows a quick and capital
   cost-free start-up for IPv6 support in the IXP, allowing the IXP to
   avoid transforming untagged ports into tagged ports.  In this
   implementation, traffic split traffic-split for statistical analysis may be done
   using flows techniques such as in IPFIX [RFC5101] considering the
   different ether-types (0x0800 for IPv4 IPv4, 0x0806 for ARP and 0x86DD for
   IPv6).

   The only technical requirement for IPv6 referring link MTUs is that
   it needs
   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
   this requires bytes.
   Consequently, no change of configuration. MTU changes are typically required.  The MTU size
   for every LAN in an IXP should be well know by all its participants.

3.  Addressing Plan

   Regional Internet Registries (RIRs) have specific address policies to
   allocate Provider Independent (PI) IPv6 address to IXPs.  Those
   allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES].
   Depending on the country and region of operation, address allocations
   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
   [RFC4291], a /64 prefix should be allocated for each of the exchange
   point IPv6 enabled LANs.  A /48 prefix allows the addressing of 65536
   LANs.  As IXP will normally use manual address configuration, longer
   prefixes (/65-/127), are technically feasible but are normally
   discouraged because of operational practices.The practices.  The manual
   configuration of IPv6 addresses allows IXP participants to replace
   network interfaces with no need to reconfigure Border Gateway
   Protocol (BGP) sessions information and it also facilitates
   management tasks.

   When selecting the use of static Interface Identifiers (IIDs), there
   are different options on how to "intelligently" fill its 64 bits (or
   16 hexadecimal characters).  A non exhausted non-exhausted list of possible IID
   selection mechanisms follows: is the following:

   1.  Some IXPs like to include the participants' ASN number decimal
       encoding inside each IPv6 address.  The ASN decimal number number is
       used as 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

       *  ASN: 64496

       *  IPv6 Address: 2001:DB8::0000:0006:4496:0001/64 or its
          equivalent representation 2001:DB8::6:4496:1/64

       In this example we are right justifying the participant' ASN
       number from the the 112nd bit.Remember bit.  Remember that 32 bits ASNs require a
       maximum of 10 characters.  Whith  With this example, up to 2^16 IPv6
       addresses can be configured per ASN.

   2.  Although BCD encoding is more "human-readable", some IXPs prefer
       to use the hexadecimal encoding of the ASNs number as the upper
       part of the IID as follow:

       *  IXP LAN prefix: 2001:DB8::/64

       *  ASN: 64496 (DEC) or FBF0 (HEX)

       *  IPv6 Address: 2001:DB8::0000:0000:FBF0:0001/64 or its
          equivalent representation 2001:DB8::FBF0:1/64

   3.  A third scheme for statically assigning IPv6 addresses on an IXP
       LAN could be to relate some portion of a participant's IPv6
       address to its IPv4 address.  In the following example, the last
       three decimals of the IPv4 address are copied to the last
       hexadecimals of the IPv6 address, using the decimal number as the
       BCD encoding for the last three characters of the IID such as in
       the following example:

       *  IXP LAN prefix: 2001:DB8::/64

       *  IPv4 Address: 240.0.20.132/23

       *  IPv6 Address: 2001:DB8::132/64

   4.  A fourth approach might be based on the IXPs ID for that
       participant.

   The current practice that applies to IPv4 about publishing IXP
   allocations to the DFZ (Default Free Zone) should also apply to the
   IPv6 allocation (normally a /48 prefix).  Typically IXPs LANs are not
   globally reachable in order to avoid a Distributed Denial of Service
   (DDoS) attack but participant may route these prefixes inside their
   networks (ex. (e. g. using BGP no-export communities or routing the IXP
   LANs within the participant' participants' IGP) to perform fault management.  IXP
   external services (such as dns, web pages, ftp servers) needs to be
   globally routed and due to strict prefix length filtering could be
   the reason to request a shorter more than one /48 assignment from an a RIR (ex (i.e.
   requesting a /47 assignment and using one /48 for the IXPs LANs that is not globally routed and one
   a different /48 for the IXP external services that is globally
   routed).  IPv6 prefixes for IXP LAN's are typically publicly well
   known.

4.  Multicast IPv6

   There are two elements that need to be evaluated when studying IPv6
   multicast in an IXP: multicast support for netighbor neighbor discovery and
   multicast peering.

   IXPs typically control broadcast traffic accross across the switching fabric
   in order to avoid broadcast storms by only allowing limited ARP
   [RFC0826] traffic for address resolution.  In IPv6 there is not
   broadcast support but IXP may intend to control multicast traffic in
   each LAN instead.  ICMPv6 Neighbor Discovery [RFC4861] implements the
   following necessary functions in an IXP switching fabric: Address
   Resolution, Neighbor Unreachability Detection and Duplicate Address
   Detection.  In order to perform these functions, Neighbor
   Solicitation and Neighbor Advertisement packets are exchange using
   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:
   0:0:0:0:1:FFFF:FFFF).  As described in [RFC4861] routers will
   initializate
   initialize its interfaces by joining its solicited-node multicast
   addresses using either Multicast Listener Discovery (MLD) [RFC2710]
   or MLDv2 [RFC3810].  MLD messages may be sent to the corresponding
   group address:FF02::2 (MLD) or FF02::16 (MLDv2).  Depending on the
   addressing plan selected by the IXP, each solicited-node multicast
   group may be shared by a sub-set of participants' conditioned by how
   the last three octects of the addresses are selected.  In Section 3
   example 1, only participants with ASNs with the same two last digits
   are going to share the same solocited-node multicast group.

   Similarly to the ARP policy an IXP may limit multicast traffic acccross
   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.  For that reason, eventhough routers should ignore them,
   rogue  ICMPv6 route advertisements may Router Advertisement
   packets should neither be monitored in order issued nor accepted by routers connected to
   prevent configuration errors.
   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 exhange, exchange, an IXP may decide to use either
   the same LAN being used for unicast IPv6 traffic exchange, the same
   LAN being used for IPv4 Multicast traffic exchange or a dedicated LAN
   for IPv6 Multicast traffic exchange.  The reason for having a
   dedicated LAN for multicast is to prevent unwanted multicast traffic
   to reach participants that do not have multicast support.  Protocol
   Independent Multicast [RFC4601] messages will be sent to the the
   link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the
   selected LAN and should be allowed.  Implementing IPv6 PIM snooping
   will allow that only the participants associated to a particular group will to
   receive its multicast traffic.  BGP reachability information for IPv6
   multicast address-family (SAFI=2) is normally exchanged using MP-BGP
   [RFC4760] and is used for Reverse Path Forwarding (RPF) lookups
   performed by the IPv6 PIM (Protocol
   Independent Multicast) protocol [RFC4601]. PIM.  If a dedicated LAN is configured for
   Multicast IPv6 traffic exchange, reachability information for IPv6
   Multicast address familly family should be carried in new BGP sessions.
   ICMPv6 Neighbor Discovery should be allowed in the Multicast IPv6 LAN
   as described in the previous paragraph.

5.  Reverse DNS

   PTR records for all addresses assigned to participants should be
   included in the IXP reverse zone under "ip6.arpa". "ip6.arpa" for troubleshooting
   purposes.  DNS servers should be reachable over IPv6 transport. transport for
   complete IPv6 support.

6.  Route Server

   IXPs may offer a Route Server service, either for Multi-Lateral
   Peering Agreements (MLPA) service, looking glass service or route-
   collection service.  IPv6 support needs to be added to the BGP
   speaking router.  The equipment should be able to transport IPv6
   traffic and to support Multi-protocol BGP (MP-BGP) extensions for
   IPv6 address family ([RFC2545] and [RFC4760]).

   A good practice is that all BGP sessions used to have exchange IPv6 SAFI (Subsequent Address Family
   Identifiers)
   network information carried over sessions established also on
   top of the are configured using IPv6 IP/TCP stack and independently of the IPv4 sessions. data transport.  This
   configuration allows style ensures that as both network reachability
   information and generic packet data transport use the same transport
   plane, in the event of IPv6 reachability
   issues to any problems between IPv6 peer, peers,
   the IPv6 BGP session will may be turned down and the terminated independently of any IPv4 session to the same peer will not be affected.  Please consider
   the
   sessions.  The use of MD5 [RFC2385] or IPSEC [RFC4301] to
   authenticate the BGP
   sessions. 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
   available for external IPv6 access, either by an IPv6 enabled web
   page or an IPv6 enabled console interface.

7.  Internal and  External Services and Internal support

   Some external services that need to have IPv6 support are Traffic
   Graphics, DNS, FTP, Web, Route Server and Looking Glass.  Other
   external services such as NTP servers, or SIP Gateways need to be
   evaluated as well.  In general, each service that is currently
   accessed through IPv4 or that handle IPv4 addresses should be
   evaluated for IPv6 support.

   Internal services are also important when considering IPv6 adoption
   at an IXP.  Such services may not deal with IPv6 traffic but may
   handle IPv6 addresses; that is the case of provisioning systems,
   logging tools and statistics analysis tools.  Databases and tools
   should be evaluated for IPv6 support.

8.  IXP Policies and IPv6

   IXP Policies may need to and contracts should be be revised as any mention of IP
   should be clarified if it refers to IPv4, IPv6 or both.  The current
   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

   This memo includes no request to IANA.

10.  Security Considerations

   This memo includes no Security Considerations. 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

   The author would like to thank the contributions from Stig Venaas,
   Martin Levy, Nick Hilliard, Martin Pels, Bill Woodcock, Carlos Frias,
   Arien Vijn and Louis Lee.

12.  References

12.1.  Normative References

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC2545]  Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
              Extensions for IPv6 Inter-Domain Routing", RFC 2545,
              March 1999.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              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
              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
              Architecture", RFC 4291, February 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.

12.2.  Informative References

   [RIR_IXP_POLICIES]
              Numbers Support Organization (NRO)., "RIRs Allocations
              Policies for IXP. NRO Comparison matrix", 2008,
              <http://www.nro.net/documents/comp-pol.html#3-4-2>.

Author's Address

   Roque Gagliano
   LACNIC
   Rambla Rep Mexico 6125
   Montevideo,   11400
   UY

   Phone: +598 2 4005633
   Email: roque@lacnic.net