IPv6 Maintanence (6man)                                         F. Baker
Internet-Draft                                             Cisco Systems
Intended status: Informational                          November 5, 2007
Expires: May 8, 2008

              Multiprefix IPv6 Routing for Ingress Filters

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on May 8, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


   This note addresses routing in a network that supports multiple
   prefixes and has different DMZs, in the context of BCPs 38 and 84
   (ingress filtering).  It proposes a change to the way IPv6 forwarding
   occurs, and so should be considered carefully by the Internet

Baker                      Expires May 8, 2008                  [Page 1]

Internet-Draft            Filtered IPv6 Routing            November 2007

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Proposal  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Host selection of an address  . . . . . . . . . . . . . . . 3
     2.2.  Host selection of a router  . . . . . . . . . . . . . . . . 4
     2.3.  Selection of a multipath route by a router  . . . . . . . . 4
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7

Baker                      Expires May 8, 2008                  [Page 2]

Internet-Draft            Filtered IPv6 Routing            November 2007

1.  Introduction

   BCP 38 [RFC2827] recommends that routing systems protect themselves
   against spoofed source addresses by the application of ingress
   filtering.  In short, this means discarding datagrams that
   purportedly come from addresses that the routing system does not
   believe are reachable from the direction whence they have arrived.
   BCP 84 [RFC3704] discusses the problems this raises in a multihomed
   network that uses multiple prefixes internally.  In short, it
   recommends that a routing system route in such a way that datagrams
   are only presented to an upstream routing system if and only if that
   upstream routing system will not discard them in accordance with BCP

   In IPv6 [RFC2460] networks, this poses several problems.  The IPv6
   Addressing Architecture [RFC4291] leads one to assume that on any
   interface, a system is likely to have at least two addresses - its
   link local address and its address in the relevant prefix.  If
   Privacy addresses [RFC4941] are in use, it might have many addresses
   in the same prefix.  In a routing system with multiple prefixes
   overlaid, an interface might have numerous addresses even if it has
   only one per prefix.

   It is this last situation that causes the present concern.  Is there
   a way that we can ensure that routing to the egress router is optimal
   while ensuring that traffic sent upstream uses the right upstreams
   without forcing the host to be involved in datagram routing?

2.  Proposal

   In short, the author suggests that datagrams should be sent in a
   direction that will avoid ingress filtering, starting from the
   originating host.  This section discusses the ramifications of that

2.1.  Host selection of an address

   [RFC3484] describes an architecture by which a network administrator
   can define which source address prefixes should be used on datagrams
   sent to various destination prefixes.  This proposal assumes that if
   remote non-default prefixes are propagated within a network, this
   technology governs the choice of address.  As such, traffic headed to
   destinations for which there is routing other than the default route
   will never be sent to an upstream that will discard them.

Baker                      Expires May 8, 2008                  [Page 3]

Internet-Draft            Filtered IPv6 Routing            November 2007

2.2.  Host selection of a router

   Having selected a source address, the host must now determine what
   router to send its datagram to.

   If Neighbor Discovery [RFC4861] or SEcure Neighbor Discovery
   [RFC3971] are in use, the prefix that the host is using will have
   been advertised to it in a Router Advertisement.  In either case, the
   host SHOULD send the datagram to the router from which it learned the

   if DHCP [RFC3315] is in use, it may be possible to rely on the Router
   Advertisements bring broadcast periodically.  This case requires
   further thought.

2.3.  Selection of a multipath route by a router

   Once a datagram has been handed to a router, the router has two
   possible options: either it has a single route to that prefix, or it
   has a multipath route.  If it has a single route or an internal
   route, it SHOULD of course use it.

   If the chosen route is a multipath route to an external network, the
   router SHOULD use the path that was advertised into the network by
   the DMZ that injected the prefix used in the datagram's source
   address.  This can be determined, for example, by observing the OSPF
   [RFC2740] inter-area-router-LSA, which will contain at least one
   interface using the prefix of the relevant upstream and will have a
   companion AS-external-LSA indicating a default route.  This would
   generally apply t default routes, but may also apply to more specific
   aggregated routes advertised into the network via multiple DMZs.

3.  IANA Considerations

   This memo adds no new IANA considerations.  The presence of this
   template text indicates that the author/editor has not actually
   reviewed IANA considerations.

   Note to RFC Editor: This section will have served its purpose if it
   correctly tells IANA that no new assignments or registries are
   required, or if those assignments or registries are created during
   the RFC publication process.  From the author"s perspective, it may
   therefore be removed upon publication as an RFC at the RFC Editor"s

Baker                      Expires May 8, 2008                  [Page 4]

Internet-Draft            Filtered IPv6 Routing            November 2007

4.  Security Considerations

   One could argue that hist note addresses a security concern raised in
   BCP 84, that the communications between two systems may be inhibited
   or obstructed by a poor choice of source address in a poorly thought
   through routing system.  At this writing, the security issues have
   not been fully thought through, so this section needs to be updated.

5.  Acknowledgements

6.  References

6.1.  Normative References

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

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

6.2.  Informative References

   [RFC2740]  Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
              RFC 2740, December 1999.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

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

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,

Baker                      Expires May 8, 2008                  [Page 5]

Internet-Draft            Filtered IPv6 Routing            November 2007

              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

Author's Address

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117

   Phone: +1-408-526-4257
   Fax:   +1-413-473-2403
   Email: fred@cisco.com

Baker                      Expires May 8, 2008                  [Page 6]

Internet-Draft            Filtered IPv6 Routing            November 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Baker                      Expires May 8, 2008                  [Page 7]