[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Internet Engineering Task Force                              R. Gagliano
Internet-Draft                                                    LACNIC
Intended status: Informational                         December 10, 2008
Expires: June 13, 2009


           IPv6 Deployment in Internet Exchange Points (IXPs)
                  draft-rgaglian-v6ops-v6inixp-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 June 13, 2009.

Abstract

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


1.  Introduction

   Most Internet Exchange Points (IXP) work on the Layer 2 level, making



Gagliano                  Expires June 13, 2009                 [Page 1]

Internet-Draft                 IPv6 in IXP                 December 2008


   the adoption of IPv6 an easy task.  However, IXPs normally implement
   additional services such as statistics, route servers, looking
   glasses, broadcast control and others that may be impacted by the
   implementation of IPv6.This document gives some tips and guidance on
   the impact of IPv6 on a new or existing IXP that may or may not fit
   any particular implementation.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119
   [RFC2119].


2.  Switch Fabric Configuration

   The Switch Fabric is a Layer 2 device, therefore the switching of
   IPv6 traffic happens in the same way as in IPv4.  However, some
   functionalities in the management plane require support for IPv6
   extensions.  Such functionalities may include: switch management,
   SNMP support and flow analysis tools.

   The port setup normally has two classic configurations:

   1.  dual stack: both IPv4 and IPv6 traffic share a common interface.
       No extra configuration is required in the switch.

   2.  independent VLAN: an IPv6 VLAN is created for IPv6 traffic.  If
       customers' ports have access to several VLANs this configuration
       involves a new tag.  Otherwise, it may required a new physical
       port for every member that wants to exchange IPv6 traffic.

   The "independent VLAN" configuration provides a physical separation
   for IPv4 and IPv6 traffic.  This simplifies separate analysis for
   IPv4 and IPv6 traffic.  However, it can be more costly in both
   capital expends (if new ports are needed) and operational expends.
   On the other side, the dual stack implementation allows a quick and
   cost-free start-up for IPv6 support in the IXP, and allows the IXP to
   avoid transforming access mode ports into tagged ports.  In this
   implementation, traffic split for statistical analysis may be done
   using flows techniques considering the different ether-types (0x0800
   for IPv4 and 0x86DD for IPv6).

   The support for jumbo frames MTU should be evaluated.  The only
   technical requirement for IPv6 referring the MTU is that it needs to
   be greater than 1280 bytes.  Typical option for MTU size (including
   ethernet headers) are: 1518 bytes, 4460 bytes or 9216 bytes.



Gagliano                  Expires June 13, 2009                 [Page 2]

Internet-Draft                 IPv6 in IXP                 December 2008


3.  Addressing Plan

   All five Regional Internet Registries (RIRs) have specific address
   policies to allocate Provider Independent (PI) IPv6 address to IXPs.
   Those allocations are usually /48 prefixes [RIR_IXP_POLICIES].

   From the allocated /48 prefix, following the recommendations of RFC
   4291 [RFC4291], a /64 prefix should be allocated for each of the
   exchange point Local Area Networks (LANs).  A /48 prefix allows the
   addressing of 65536 LANs.  Longer prefixes (/65-/127), are
   technically feasible using static address configuration, but should
   be avoided, in order to keep EUI-64 compatibility.

   The common practice for Interface Identifiers (IID) configuration is
   to use static configuration, disallowing auto-configuration on every
   interface.  Also, on a LAN where all its members are typically
   routers, it is important that every node has it's router
   advertisement protocol RFC 4861 [RFC4861] turned off.  The goal is
   that none of the remaining routers configure it-selves a default
   ICMPv6 route by accident.  A scanning device can be set up at the IXP
   LANs to monitor link-local multicast traffic (addresses ff02::/16),
   allowing only ICMPv6 Neighbor Solicitation and Neighbor Advertisement
   messages.  Particularly rogue ICMPv6 route advertisements should be
   monitored.

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

   1.  Some IXPs like to include the members' 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::6449:6000:0000:0001/64 or its
          equivalent representation 2001:DB8::6:4496:1/64

       Please remember that 32 bits ASNs requires a maximum of 10
       characters, as 16 characters are available, up to 2^24 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:



Gagliano                  Expires June 13, 2009                 [Page 3]

Internet-Draft                 IPv6 in IXP                 December 2008


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

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

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

       The four zero before the ASN (bits 63-96) will be used by 32 bits
       ASNs.

   3.  A third scheme for statically assigning IPv6 addresses on a IXP
       LAN could be to match the last decimals of the IPv4 address into
       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 forth approach might be based on IXP the membership ID for that
       provider.

   The current practice that applies to IPv4 about publishing IXP
   allocations to the DFZ (Default Free Zone) should also applies to the
   IPv6 allocation (normally a /48 prefix).  IXP external services (such
   as dns, web pages, ftp servers) could be part of this prefix.  Beware
   that a /48 may not be routed globally due to strict prefix length
   filtering.


4.  Reverse DNS

   PTR records for all addresses assigned to members should be included
   in the IXP reverse zone under "ip6.arpa".


5.  Route Server Configuration

   Some IXPs may offer a Route Server service, either for Multi-Lateral
   (ML) Peering Agreements or for a looking glass service.  IPv6 support
   needs to be added to the router used as BGP end point.  The equipment
   should be able to transport IPv6 traffic and to support Multi-
   protocol BGP (MP-BGP) extensions for IPv6 address family (RFC 2545
   [RFC2545] and RFC 4760 [RFC4760]).




Gagliano                  Expires June 13, 2009                 [Page 4]

Internet-Draft                 IPv6 in IXP                 December 2008


   A good practice is to have IPv6 reachability information carried over
   sessions established also on top of the IPv6 IP/TCP stack and
   independently of the IPv4 sessions.  This configuration allows that
   in the event of IPv6 reachability issues to any IPv6 peer, the
   specific session will be turned down (state changes to "Active") and
   the IPv4 session to the same peer will not be affected.  Please
   consider the use of MD5 (even better IPSEC) to authenticate the BGP
   sessions.

   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 server.


6.  Internal and External Services support.

   Some external services that need to have IPv6 support are Traffic
   Graphics, DNS, FTP, Web 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 accessed through IPv4 or that handle
   IPv4 addresses should be compatible with IPv6.

   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
   needs to be evaluated to determinate its IPv6 support level.


7.  IXP Policies and IPv6

   IXP Policies may need to 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.

   Particular IPv6 policies may be needed, particularly in IXP that
   control rogue ICMPv6 Router Advertisements and link-local multicast
   traffic from its members or for MLPA (Multi Lateral Peering
   Agreement).

   As with IPv4, the very success of an IPv6 IX is measured by the
   number of participants and/or the amount of traffic flowing across
   the switch.  In order to acquire participants, it's important to
   market the fact that IPv6 is available on the IX.



Gagliano                  Expires June 13, 2009                 [Page 5]

Internet-Draft                 IPv6 in IXP                 December 2008


   Marketing is also important.  The following steps will help promote
   IPv6 peering and traffic on an IX community:

   o  Announce the existence of IPv6 on the IX via the home page and if
      possible via a press release.

   o  Announce the existence of IPv6 via appropriate mailing lists
      including as an email to all participants.

   o  If the website lists participants and their ASN and allocated IPv4
      address, more to include the IPv6 address.

   o  Review the existing members ASN's and see if their ASN shows up in
      the IPv6 global routing tables; if so, then contact directly to
      promote the enabling of IPv6 peering at your IX.

   o  Include IPv6 information at the peeringdb.com database.

   o  Over time, normalize all uses and references to IPv4 and convert
      them into IPv4/IPv6 references (for example within the members
      agreement)


8.   Multicast IPv6.

   Multicast IPv6 is not different from an IXP perspective than
   Multicast IPv4.  Again, the IXP may decide to use a reserved VLAN for
   Multicast traffic or to exchange that traffic in the same VLAN as the
   unicast traffic.  As it was already mentioned, link-local multicast
   traffic could be monitored to detect bad behaviors or configuration
   problems.  This traffic should be reduced to ICMPv6 neighbor
   discovery RFC 4861 [RFC4861] and MLD (Multicast Listener Discovery)
   Protocol (MLDv2) RFC 3810 [RFC3810].


9.  IANA Considerations

   This memo includes no request to IANA.


10.  Security Considerations

   This memo includes no Security Considerations.


11.  Acknowledgements

   I would like to thank the contributions from Martin Levy (Hurricane



Gagliano                  Expires June 13, 2009                 [Page 6]

Internet-Draft                 IPv6 in IXP                 December 2008


   Electric), Carlos FriaAS.as of FCCN (GIGAPIX), Arien Vijn (AMS-IX)
   and Louis Lee (Equinix).


12.  References

12.1.  Normative References

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

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

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 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.

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: rgaglian@lacnic.net




Gagliano                  Expires June 13, 2009                 [Page 7]

Internet-Draft                 IPv6 in IXP                 December 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Gagliano                  Expires June 13, 2009                 [Page 8]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/