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
draft-baker-6man-multiprefix-default-route-00
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 May 8, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
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
community.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
38.
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
policy.
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
prefix.
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
discretion.
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
USA
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
"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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Baker Expires May 8, 2008 [Page 7]