IPv6 Multihoming Workingroup K. Lindqvist
Internet-Draft Netnod
Expires: June 1, 2003 December 2002
Multihoming in IPv6 by multiple announcements of longer prefixes
draft-kurtis-multihoming-longprefix-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 1, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
In the current IP version 4 Internet, many organizations that are not
Internet Service Providers are still getting their Internet
connectivity through multiple providers by having address space that
are announced via multiple paths. This is commonly referred to as
multihoming. For the IP version 6 Internet, there have long been a
debate as to how to achieve the same effect. This document addresses
these issues by highlighting some of the current policies and how
these can be used to achive multihoming for IP version 6 connected
networks.
Lindqvist Expires June 1, 2003 [Page 1]
Internet-Draft IPv6 Multihoming December 2002
1. Introduction
Traditionally Internet Service Providers or ISPs have had multiple
connections from their own network that is servicing customers to the
rest of the Internet. In order to achive this, they have been
allocated blocks of IP addresses that are unique to them. These
blocks are allocated based on the need an ISP can justify to the
Regional Internet Registrys, or RIRs, that are handling the
allocations. Many enterprises have adopted the same technique with
multiple connections to the rest of the world for a number of reasons
such as increased redundancy, load sharing or simply costs of
connections. For this they have also applied for similar blocks an
their own AS numbers just as the ISPs use today. This document how
the organizations that today are multihoming in IPv4 can achieving
the same thing with the the current policies of IPv6 networks.
Lindqvist Expires June 1, 2003 [Page 2]
Internet-Draft IPv6 Multihoming December 2002
2. Terminology
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 [1].
Lindqvist Expires June 1, 2003 [Page 3]
Internet-Draft IPv6 Multihoming December 2002
3. Network requirements
In order to make use of the methods for achiving multihoming as
described in this document, the network wishing to multihome in the
IPv6 Internet will need to have obtained a block of IPv6 addresses,
have multiple network connections either natively or through some
transition or tunneling technique. The network must also be running
the Border Gateway Protocol version 4 [2] with the BGP Multiprotocol
Extensions [3] on their border routers. How do this with IPv6 is
described in [4].
Lindqvist Expires June 1, 2003 [Page 4]
Internet-Draft IPv6 Multihoming December 2002
4. Obtaining IPv6 addresses
Networks that are registered as Local Internet Registries, or LIRs,
should apply for a IPv6 delegation from their respective RIR.
Networks that are not registered as LIRs should apply for IPv6
addresses from their network service provide. In the case of already
existing multiple service providers, only one of the should allocate
a address block to be used for multihoming with longer prefix
announcements. The allocations currently being made to LIRs are 32
bit long prefixes and allocations made to end-sites are currently 48
bit prefixes.
Lindqvist Expires June 1, 2003 [Page 5]
Internet-Draft IPv6 Multihoming December 2002
5. Announcing a longer prefix
5.1 Description of procedure
The first step in order to achive the multihoming solution is
establish an exchange of routing information using BGP to all the
upstream providers of the network. These upstreams SHOULD accept a
prefix length of 48 bits from their peers, and SHOULD NOT aggregate
these routes. For the provider that have allocated the addresses to
the network this is especially important. The multihomed network
should configure it's border routers to announce the prefix it have
received from one of it's providers to all it's peers. If these
providers will accept the prefix is a business relationship between
the multihomed network and their upstream providers. This will have
the affect that in the global routing table at least two paths for
the multihomed network will be visible. One is the aggregate route
representing the block allocated to the same ISP from where the
multihomed network have received their IPv6 address block, the other
route is a more specific route with a path through one of the
upstreams of the multihomed network. There are a number of
considerations that a network that wishes to use the approach needs
to make. This approach does not have a long term scaling effect and
will at some point in the future be abandoned.
5.2 Reasoning of model
The first advantage of this model is that it gives a jump start
mechanism to the problem of multihoming that have often been quoted
as one of the main reasons as to why not IPv6 is deployed in the
enterprise environment. Giving the enterprises a way to handle this
will prove that claim either false or right. the second advantage of
this model is that it does not require the implementation of any sort
to the installed base of equipment. The third advantage of this
model is that this mirrors existing operating practices in the IPv4
world. This is likely to lead to easier general adoption. However,
this is also the largest point of concern with this model. This
model will without doubt not scale for a widespread adoption so the
growth rate of the routing table and the predictions of the growth
needs to be monitored carefully. This model does however provide for
mechanisms to control this as described below. This might be enough
of concern for some enterprises to stay way from IPv6, but it does at
least give them a way to start out with the technology and mirror the
their existing network functions.
5.3 What this model does not give you
The reasons for going to mutlihoming is many. Mostly these are for
traffic flow purposes, being either resiliency or the ability to
Lindqvist Expires June 1, 2003 [Page 6]
Internet-Draft IPv6 Multihoming December 2002
better control how the traffic reaches the enterprise. Another
popular reason in the IPv4 Internet have also been the fact that you
with a multihoming setup would get so called Provider Independent
addresses. These PI addresses are allocated directly from the RIRs
to the enterprise. This means that a enterpise will keep the same
the addresses even through a shift of ISPs as their upstreams. This
model does not address this issue, and will not allow for address
allocations outside the generally adopted allocation rules of the
RIRs.
Lindqvist Expires June 1, 2003 [Page 7]
Internet-Draft IPv6 Multihoming December 2002
6. Effects on the growth of the current routing table
6.1 Aggregation effects with the current allocation policies
In the IPv4 Internet routing table, also know as the Default Free
Zone, there is currently around 125 000 routes announced with around
14000 originating AS:es, of which 1500 ASes are providing transit.
In recent years the routing table for the default free zone have
grown tremendously. The reasons for this growth is still unknown,
but reasons might be a mix of many new providers with a lower level
of routing knowledge announcing larger allocations blocks as many
more specifics, and the economic upswing around Internet based serves
(the so called dot com bubble). More recently the growth seems to
have slowed down though. This could indicate that the interest in
multihoming have decreased and that operating practices have
improved. With the proposal for multihoming IPv6 as described in
this document, the potential for the same routing table growth
explosion as we have today exists. However, given that the current
allocation blocks to ISPs are blocks with 32 bit long prefixes, one
of these blocks will fit the current address assignments of most
ISPs. This means that the routing table will be inherently small to
start with. Even if all ASes that are active today where to announce
IPv6 address space, it would only be around 14 000 routes. Almost
90% less of the current routing table. This means that we have quite
a lot of breathing space before we starting running into the same
scalability problems as today. This is due to the current
allocations. Doing multihoming by announcing longer prefixes out of
allocated blocks will make the routing larger but looking at the
current amount of multihomed networks, this should not pose a
problem.
6.2 Scaling back an explosion in routing table growth
In the case this method of achiving mutlihoming is in so wide use
that is starts to pose a problem, or that the routing table size in
combination with the increased prefix length of IPv6 starts causing a
problem, this model can be backed out from by simply reducing the
length of prefixes that have to be accepted. Backing out will pose
the problem that sites using this model today will no longer be able
to multihome. However, given what we today know of the routing table
growth this should not be a problem before the time where we should
have other solutions for multihoming.
Lindqvist Expires June 1, 2003 [Page 8]
Internet-Draft IPv6 Multihoming December 2002
7. Security considerations
Using this approach, networks need to take care not to announce their
prefixes in such a way that they generate asymmetric traffic flows.
Traffic following asymmetrical paths might get blocked by so called
strict Reverse Path Forwarding (RPF) checks. These checks are
implemented in routers and will make sure that the source address of
a packet arriving on an interface also have a route to the source
address through that interface. RPF checks are implemented in order
to help block address spoofing. Longer prefix multihoming SHOULD NOT
be used as an excuse to disable RPF checks.
Lindqvist Expires June 1, 2003 [Page 9]
Internet-Draft IPv6 Multihoming December 2002
8. Acknowledgments
This paper builds on a discussion at the IETF-55 in Atlanta. People
who was part in the idea is Thomas Narten and Chirstian Huitema but
also all the people who where are the unofficial multi6 meeting.
Lindqvist Expires June 1, 2003 [Page 10]
Internet-Draft IPv6 Multihoming December 2002
Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[2] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4", RFC 1771,
March 1995.
[3] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "", RFC 2283,
February 1998.
[4] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 1771, March 1995.
Author's Address
Kurt Erik Lindqvist
Netnod Internet Exchange
Bellmansgatan 30
Stockholm S-118 47
Sweden
Phone: +46 708 30 60 01
EMail: kurtis@kurtis.pp.se
URI: http://www.kurtis.pp.se
Lindqvist Expires June 1, 2003 [Page 11]
Internet-Draft IPv6 Multihoming December 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lindqvist Expires June 1, 2003 [Page 12]