[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-blanchet-v6ops-routing-guidelines) 00 01

Network Working Group                                        M. Blanchet
Internet-Draft                                                  Viagenie
Expires: September 2, 2006                                    March 2006


                    IPv6 Routing Policies Guidelines
               draft-ietf-v6ops-routing-guidelines-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 September 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Guidelines on how to manage IPv6 routes are needed for operators of
   networks, either providers or enterprises.  This document is a
   followup on RFC2772 work but for the production IPv6 Internet.
   RFC2772 becomes historic.








Blanchet                Expires September 2, 2006               [Page 1]


Internet-Draft      IPv6 Routing Policies Guidelines          March 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
     2.2.  IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3
     2.3.  Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
     2.4.  Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3
     2.5.  Global Unicast  . . . . . . . . . . . . . . . . . . . . . . 3
       2.5.1.  Documentation Prefix  . . . . . . . . . . . . . . . . . 4
       2.5.2.  6to4  . . . . . . . . . . . . . . . . . . . . . . . . . 4
       2.5.3.  Teredo  . . . . . . . . . . . . . . . . . . . . . . . . 4
       2.5.4.  6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.6.  Default Route . . . . . . . . . . . . . . . . . . . . . . . 4
     2.7.  Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5
     2.8.  Unknown addresses . . . . . . . . . . . . . . . . . . . . . 5
   3.  Implementing routing policies . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8



























Blanchet                Expires September 2, 2006               [Page 2]


Internet-Draft      IPv6 Routing Policies Guidelines          March 2006


1.  Introduction

   To maintain stability, efficiency and scalability of the IPv6
   Internet, guidelines for routing policies are needed for operators
   deploying IPv6 networks.  Prior experience on IPv6 routing guidelines
   on the 6bone[RFC2772], practical deployment of the IPv6 internet and
   IPv6 specifications were used as input to this document.

   This document first describes the different types of addresses and
   then summarizes the suggested policies in RPSL.

   "Advertisement" in this document refers to the prefix advertisement,
   not the next-hop.


2.  Address Types

2.1.  Node-scoped Unicast

   The node-scoped unicast addresses[RFC4291] such as the loopback
   (::1/128), the unspecified (::/128) must not be advertised in an IGP
   or EGP and should be filtered out when received.

2.2.  IPv4-Mapped Addresses

   IPv4-mapped addresses (::FFFF:0:0/96)[RFC4291] must not be advertised
   and should be filtered out.

2.3.  Link-scoped Unicast

   The link-scoped unicast[RFC4291] routes (fe80::/10) must not be
   advertised in an IGP or EGP and should be filtered out when received.

2.4.  Site-scoped Unicast

   The site-scoped unicast routes, known as Unique-local[RFC4193],
   (fc00::/7) may be advertised in an IGP.  It must not be advertised in
   an EGP connected to the global Internet and should be filtered out
   when received.  However, it may be advertised in an EGP between two
   networks sharing a private interconnect, but must not be advertised
   outside the scope of these networks.  When advertised in an EGP,
   these routes should be of length /48.

2.5.  Global Unicast

   The global unicast routes (2000::/3)[RFC4291] may be advertised in an
   IGP or EGP.  A minimal EGP routing policy should filter out routes
   that exceed a maximum length.  Determining the maximum length of a



Blanchet                Expires September 2, 2006               [Page 3]


Internet-Draft      IPv6 Routing Policies Guidelines          March 2006


   global Internet route is outside the scope of this document.

   A finer EGP routing policy may use only the allocated address space
   from IANA to registry as specified in
   http://www.iana.org/assignments/ipv6-unicast-address-assignments.
   This would result in better filtering since the non-allocated
   prefixes will be filtered out.

   An even finer EGP routing policy may use only the assigned address
   space from registries to providers as available in the registry
   databases.  This would result in the best filtering since the non-
   assigned prefixes will be filtered out.  However, this requires the
   synchronization of the filters with the registry databases.

2.5.1.  Documentation Prefix

   The 2001:0db8::/32 prefix[RFC3849] is used for documentation purposes
   and must not be advertised in an IGP or EGP and should be filtered
   out when received.

2.5.2.  6to4

   The 6to4[RFC4291] prefix (2002::/16) may be advertised in an IGP or
   EGP, when the site is running a 6to4 relay or offering a 6to4 transit
   service.  However, the provider of this service should be aware of
   the implications of running such service[RFC3964], which includes
   some specific filtering rules for 6to4.

2.5.3.  Teredo

   The Teredo[RFC4380] prefix (2001::/32) may be advertised in an IGP or
   EGP, when the site is running a Teredo relay or offering a Teredo
   transit service.

2.5.4.  6bone

   The 6bone experimental network used some experimental allocations,
   such as 5f00::/8[RFC1897] and 3ffe::/16[RFC2471] that were later
   returned to IANA[RFC3701].  These prefixes should not be advertised
   in an EGP unless IANA reallocates them subsequently.

2.6.  Default Route

   The default unicast route (::) may be advertised in an IGP.  In an
   EGP, it may be only advertised to the downstream but must not be
   advertised in the core.





Blanchet                Expires September 2, 2006               [Page 4]


Internet-Draft      IPv6 Routing Policies Guidelines          March 2006


2.7.  Multicast

   Multicast addresses (ff00::/8)[RFC4291] have a scope in the address
   field.  In the multicast routing, the routes should be announced
   according to the scope, similar to unicast routes.  Multicast routes
   must not appear in unicast routing tables.

2.8.  Unknown addresses

   Any non listed address above must not be advertised and should be
   filtered out.  Future work might reserve additional address space for
   protocol use which might require specific routing guidelines.  The
   reader should refer to newer versions of the normative references in
   this document to verify the existence of newer protocol address
   space.


3.  Implementing routing policies

   This document focuses on protocol addresses and their use in the
   networks.  It does not discuss any allocation policies and their
   impact on the routing policies, such as /48 Micro-allocations for
   infrastructure providers or maximum length of a unicast prefix.  As
   such, to implement a complete routing policy, one should augment
   these guidelines with the current registry allocation policies and by
   appropriate ingress filtering techniques[RFC3704].

   The Route Policy Specification Language(RPSL)[RFC4012] used in route
   registries supports the policies described in this document and
   should be considered to manage route policies.

   The following RPSL code implements the policies described in this
   document.  This code should be considered as an example and should be
   adapted to its target usage.

   TBD: RPSL code to fill


4.  Security Considerations

   This document list guidelines to improve the security of networks by
   filtering of routing prefixes.


5.  Acknowledgements

   Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas,
   Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde,



Blanchet                Expires September 2, 2006               [Page 5]


Internet-Draft      IPv6 Routing Policies Guidelines          March 2006


   Michael Barnes and Fred Baker have provided input and suggestions to
   this document.


6.  References

6.1.  Normative References

   [RFC1897]  Hinden, R. and J. Postel, "IPv6 Testing Address
              Allocation", RFC 1897, January 1996.

   [RFC2471]  Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address
              Allocation", RFC 2471, December 1998.

   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849, July 2004.

   [RFC4012]  Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
              "Routing Policy Specification Language next generation
              (RPSLng)", RFC 4012, March 2005.

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

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

6.2.  Informative References

   [RFC2772]  Rockell, R. and B. Fink, "6Bone Backbone Routing
              Guidelines", RFC 2772, February 2000.

   [RFC3701]  Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
              Allocation) Phaseout", RFC 3701, March 2004.

   [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
              Networks", BCP 84, RFC 3704, March 2004.

   [RFC3964]  Savola, P. and C. Patel, "Security Considerations for
              6to4", RFC 3964, December 2004.







Blanchet                Expires September 2, 2006               [Page 6]


Internet-Draft      IPv6 Routing Policies Guidelines          March 2006


Author's Address

   Marc Blanchet
   Viagenie

   Email: Marc.Blanchet@viagenie.ca













































Blanchet                Expires September 2, 2006               [Page 7]


Internet-Draft      IPv6 Routing Policies Guidelines          March 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Blanchet                Expires September 2, 2006               [Page 8]


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