draft-ietf-v6ops-design-choices-10.txt   draft-ietf-v6ops-design-choices-11.txt 
V6OPS Working Group P. Matthews V6OPS Working Group P. Matthews
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Informational V. Kuarsingh Intended status: Informational V. Kuarsingh
Expires: April 17, 2017 Cisco Expires: May 1, 2017 Cisco
October 14, 2016 October 28, 2016
Some Design Choices for IPv6 Networks Some Design Choices for IPv6 Networks
draft-ietf-v6ops-design-choices-10 draft-ietf-v6ops-design-choices-11
Abstract Abstract
This document presents advice on certain routing-related design This document presents advice on certain routing-related design
choices that arise when designing IPv6 networks (both dual-stack and choices that arise when designing IPv6 networks (both dual-stack and
IPv6-only). The intended audience is someone designing an IPv6 IPv6-only). The intended audience is someone designing an IPv6
network who is knowledgeable about best current practices around IPv4 network who is knowledgeable about best current practices around IPv4
network design, and wishes to learn the corresponding practices for network design, and wishes to learn the corresponding practices for
IPv6. IPv6.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 3 2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Addresses . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. Where to Use Addresses . . . . . . . . . . . . . . . 4
2.2.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? . . 3 2.1.2. Which Addresses to Use . . . . . . . . . . . . . . . 6
2.2.2. Interfaces with Only Link-Local Addresses? . . . . . 4 2.2. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Static Routes . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? . . 7
2.3.1. Link-Local Next-Hop in a Static Route? . . . . . . . 6 2.3. Static Routes . . . . . . . . . . . . . . . . . . . . . . 8
2.4. IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. Link-Local Next-Hop in a Static Route? . . . . . . . 8
2.4.1. IGP Choice . . . . . . . . . . . . . . . . . . . . . 7 2.4. IGPs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. IS-IS Topology Mode . . . . . . . . . . . . . . . . . 10 2.4.1. IGP Choice . . . . . . . . . . . . . . . . . . . . . 9
2.4.3. RIP / RIPng . . . . . . . . . . . . . . . . . . . . . 11 2.4.2. IS-IS Topology Mode . . . . . . . . . . . . . . . . . 12
2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.4.3. RIP / RIPng . . . . . . . . . . . . . . . . . . . . . 13
2.5.1. Which Transport for Which Routes? . . . . . . . . . . 12 2.5. BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1.1. BGP Sessions for Unlabeled Routes . . . . . . . . 13 2.5.1. Which Transport for Which Routes? . . . . . . . . . . 14
2.5.1.2. BGP sessions for Labeled or VPN Routes . . . . . 14 2.5.1.1. BGP Sessions for Unlabeled Routes . . . . . . . . 16
2.5.2. eBGP Endpoints: Global or Link-Local Addresses? . . . 14 2.5.1.2. BGP sessions for Labeled or VPN Routes . . . . . 17
3. General Observations . . . . . . . . . . . . . . . . . . . . 16 2.5.2. eBGP Endpoints: Global or Link-Local Addresses? . . . 18
3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 16 3. General Observations . . . . . . . . . . . . . . . . . . . . 19
3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 16 3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Informative References . . . . . . . . . . . . . . . . . . . 18 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 7. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document discusses routing-related design choices that arise This document discusses routing-related design choices that arise
when designing a Pv6-only or dual-stack network. The focus is on when designing a Pv6-only or dual-stack network. The focus is on
choices that do not come up when designing an IPv4-only network. The choices that do not come up when designing an IPv4-only network. The
document presents each choice and the alternatives, and then document presents each choice and the alternatives, and then
discusses the pros and cons of the alternatives in detail. Where discusses the pros and cons of the alternatives in detail. Where
consensus currently exists around the best practice, this is consensus currently exists around the best practice, this is
documented; otherwise the document simply summarizes the current documented; otherwise the document simply summarizes the current
skipping to change at page 3, line 15 skipping to change at page 3, line 16
technologies to ensure the best selection is made for their technologies to ensure the best selection is made for their
environment. environment.
This document does not present advice on strategies for adding IPv6 This document does not present advice on strategies for adding IPv6
to a network, nor does it discuss transition in these areas, see to a network, nor does it discuss transition in these areas, see
[RFC6180] for general advice,[RFC6782] for wireline service [RFC6180] for general advice,[RFC6782] for wireline service
providers, [RFC6342]for mobile network providers, [RFC5963] for providers, [RFC6342]for mobile network providers, [RFC5963] for
exchange point operators, [RFC6883] for content providers, and both exchange point operators, [RFC6883] for content providers, and both
[RFC4852] and [RFC7381] for enterprises. Nor does this document [RFC4852] and [RFC7381] for enterprises. Nor does this document
discuss the particulars of creating an IPv6 addressing plan; for discuss the particulars of creating an IPv6 addressing plan; for
advice in this area, see [RFC5375] or [v6-addressing-plan]. The advice in this area, see [RFC5375] or [v6-addressing-plan].
details of ULA usage is also not discussed; for this the reader is
referred to [I-D.ietf-v6ops-ula-usage-recommendations].
Finally, this document focuses on unicast routing design only and Finally, this document focuses on unicast routing design only and
does not cover multicast or the issues involved in running MPLS over does not cover multicast or the issues involved in running MPLS over
IPv6 transport. IPv6 transport.
2. Design Choices 2. Design Choices
Each subsection below presents a design choice and discusses the pros Each subsection below presents a design choice and discusses the pros
and cons of the various options. If there is consensus in the and cons of the various options. If there is consensus in the
industry for a particular option, then the consensus position is industry for a particular option, then the consensus position is
noted. noted.
2.1. Addresses 2.1. Addresses
TBD This section discusses the choice of addresses for router loopbacks
and links between routers. It does not cover the choice of addresses
for end hosts.
2.2. Interfaces In IPv6, all interfaces are assigned a Link-Local Address (LLA)
[ref]. The Link-Local address can only be used for communicating
with devices that are on-link, so often additional addresses are
assigned which are able to communicate off-link. These additional
addresses can be one of three types:
2.2.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface? o Provider-Independent Global Unicast Address (PI GUA): IPv6 address
allocated by a regional address registry [RFC4291]
If a network is going to carry both IPv4 and IPv6 traffic, as many o Provider-Aggregatable Global Unicast Address (PA GUA): IPv6
networks do today, then a question arises: Should an operator mix Address allocated by your upstream service provider
IPv4 and IPv6 traffic or keep them separated? More specifically,
should the design:
a. Mix IPv4 and IPv6 traffic on the same layer-3 interface, OR o Unique Local Address (ULA): IPv6 address locally assigned
[RFC4193]
b. Separate IPv4 and IPv6 by using separate interfaces (e.g., two This document uses the term "multi-hop address" to collectively refer
physical links or two VLANs on the same link)? to these three types of addresses.
Option (a) implies a single layer-3 interface at each end of the PI GUAs are, for many situations, the most flexible of these choices.
connection with both IPv4 and IPv6 addresses; while option (b) Their main disadvantages are that a regional address registry will
implies two layer-3 interfaces at each end, one for IPv4 addresses only allocate them to organizations that meet certain qualifications,
and one with IPv6 addresses. and one must pay an annual fee. These disadvantages mean that some
smaller organization may not qualify or be willing to pay for these
addresses.
The advantages of option (a) include: PA GUAs have the advantage that they are usually provided at no extra
charge when you contract with an upstream provider. However, they
have the disadvantage that, when switching upstream providers, one
must give back the old addresses and get new addresses from the new
provider ("renumbering"). Though IPv6 has mechanisms to make
renumbering easier than IPv4, these techniques are not generally
applicable to routers and renumbering is still fairly hard [RFC
5887]. PA GUAs also have the disadvantage that it is not easy to
have multiple upstream providers ("multi-homing") if they are used
(see section 1 of [RFC5533] ).
o Requires only half as many layer 3 interfaces as option (b), thus ULAs have the advantage that they are extremely easy to obtain and
providing better scaling; cost nothing. However, they have the disadvantage that they cannot
be routed on the Internet, so must be used only within a limited
scope. In many situations, this is not a problem, but in certain
situations this can be problematic. Though there is currently no
document that describes these situations, many of them are similar to
those described in RFC 6752. See also
[I-D.ietf-v6ops-ula-usage-recommendations].
o May require fewer physical ports, thus saving money and Not discussed in this document is the possibility of using the
simplifying operations; technology described in RFC 6296 to work around some of the
limitations of PA GUAs and ULAs.
o Can make the QoS implementation much easier (for example, rate- 2.1.1. Where to Use Addresses
limiting the combined IPv4 and IPv6 traffic to or from a
customer);
o Works well in practice, as any increase in IPv6 traffic is usually As mentioned above, all interfaces in IPv6 always have a link-local
counter-balanced by a corresponding decrease in IPv4 traffic to or address. This section addresses the question of when and where to
from the same host (ignoring the common pattern of an overall assign multi-hop addresses in addition to the LLA. We consider four
increase in Internet usage); options:
o And is generally conceptually simpler. a. Use only link-local addresses on all router interfaces.
For these reasons, there is a relatively strong consensus in the b. Assign multi-hop addresses to all link interfaces on each router,
operator community that option (a) is the preferred way to go. Most and use only a link-local address on the loopback interfaces.
networks today use option (a) wherever possible.
However, there can be times when option (b) is the pragmatic choice. c. Assign multi-hop addresses to the loopback interface on each
Most commonly, option (b) is used to work around limitations in router, and use only a link-local address on all link interfaces.
network equipment. One big example is the generally poor level of
support today for individual statistics on IPv4 traffic vs IPv6
traffic when option (a) is used. Other, device-specific, limitations
exist as well. It is expected that these limitations will go away as
support for IPv6 matures, making option (b) less and less attractive
until the day that IPv4 is finally turned off.
2.2.2. Interfaces with Only Link-Local Addresses? d. Assign multi-hop addresses to both link and loopback interfaces
on each router.
As noted in the introduction, this document does not cover the ins Option (a) means that the router cannot be reached (ping, management,
and outs around creating an IPv6 addressing plan. However, there is etc.) from farther than one-hop away. The authors are not aware of
one question in this area that often arises: Should an interface: anyone using this option.
a. Use only a link-local address ("link-local-only"), OR Option (b) means that the loopback interfaces are effectively
useless, since link-local addresses cannot be used for the purposes
that loopback interfaces are usually used for. So option (b)
degenerates into option (d).
b. Have global and/or unique-local addresses assigned in addition to Thus the real choice comes down to option (c) vs. option (d).
the link-local?
There are two advantages in interfaces with only link-local addresses Option (c) has two advantages over option (d). The first advantage
("link-local-only interfaces"). The first advantage is ease of is ease of configuration. In a network with a large number of links,
configuration. In a network with a large number of link-local-only the operator can just assign one multi-hop address to each router and
interfaces, the operator can just enable an IGP on each router, then enable the IGP, without going through the tedious process of
without going through the tedious process of assigning and tracking assigning and tracking the addresses on each link. The second
the addresses for each interface. The second advantage is security. advantage is security. Since packets with link-local addresses
Since packets with Link-Local destination addresses should not be cannot be should not be routed, it is very difficult to attack the
routed, it is very difficult to attack the associated nodes from an associated nodes from an off-link device. This implies less effort
off-link device. This implies less effort around maintaining around maintaining security ACLs.
security ACLs.
Countering this advantage are various disadvantages to link-local- Countering these advantages are various disadvantages to option (c)
only interfaces: compared with option (d):
o It is not possible to ping a link-local-only interface from a o It is not possible to ping a link-local-only interface from a
device that is not directly attached to the link. Thus, to device that is not directly attached to the link. Thus, to
troubleshoot, one must typically log into a device that is troubleshoot, one must typically log into a device that is
directly attached to the device in question, and execute the ping directly attached to the device in question, and execute the ping
from there. from there.
o A traceroute passing over the link-local-only interface will o A traceroute passing over the link-local-only interface will
return the loopback or system address of the router, rather than return the loopback address of the router, rather than the address
the address of the interface itself. of the interface itself.
o In cases of parallel point to point links it is difficult to o In cases of parallel point to point links it is difficult to
determine which of the parallel links was taken when attempting to determine which of the parallel links was taken when attempting to
troubleshoot unless one sends packets directly between the two troubleshoot unless one sends packets directly between the two
attached link-locals on the specific interfaces. Since many attached link-locals on the specific interfaces. Since many
network problems behave differently for traffic to/from a router network problems behave differently for traffic to/from a router
than for traffic through the router(s) in question, this can pose than for traffic through the router(s) in question, this can pose
a significant hurdle to some troubleshooting scenarios. a significant hurdle to some troubleshooting scenarios.
o On some routers, by default the link-layer address of the o On some routers, by default the link-layer address of the
skipping to change at page 6, line 14 skipping to change at page 6, line 29
because the MAC address is duplicated (due to manufacturing process because the MAC address is duplicated (due to manufacturing process
defaults or the use of virtualization), because a device deliberately defaults or the use of virtualization), because a device deliberately
re-uses automatically-assigned link-local addresses on different re-uses automatically-assigned link-local addresses on different
links, or because an operator manually assigns the same easy-to-type links, or because an operator manually assigns the same easy-to-type
link-local address to multiple interfaces. All these are allowed in link-local address to multiple interfaces. All these are allowed in
IPv6 as long as the addresses are used on different links. IPv6 as long as the addresses are used on different links.
For more discussion on the pros and cons, see [RFC7404]. See also For more discussion on the pros and cons, see [RFC7404]. See also
[RFC5375] for IPv6 unicast address assignment considerations. [RFC5375] for IPv6 unicast address assignment considerations.
Today, most operators use interfaces with global or unique-local Today, most operators use option (d).
addresses (option b).
2.1.2. Which Addresses to Use
Having considered above whether or not to use a "multi-hop address",
we now consider which of the addresses to use.
When selecting between these three "multi-hop address" types, one
needs to consider exactly how they will be used. An important
consideration is how Internet traffic is carried across the core of
the network. There are two main options: (1) the classic approach
where Internet traffic is carried as unlabeled traffic hop-by-hop
across the network, and (2) the more recent approach where Internet
traffic is carried inside an MPLS LSP (typically as part of a L3
VPN).
Under the classic approach:
o PI GUAs are a very reasonable choice, if they are available.
o PA GUAs suffer from the "must renumber" and "difficult to multi-
home" problems mentioned above.
o ULAs suffer from the "may be problematic" issues described above.
Under the MPLS approach:
o PA GUAs are a reasonable choice, if they are available.
o PA GUAs suffer from the "must renumber" problem, but the
"difficult to multi-home" problem does not apply.
o ULAs are a reasonable choice, since (unlike in the classic
approach) these addresses are not visible to the Internet, so the
problematic cases do not occur.
2.2. Interfaces
2.2.1. Mix IPv4 and IPv6 on the Same Layer-3 Interface?
If a network is going to carry both IPv4 and IPv6 traffic, as many
networks do today, then a question arises: Should an operator mix
IPv4 and IPv6 traffic or keep them separated? More specifically,
should the design:
a. Mix IPv4 and IPv6 traffic on the same layer-3 interface, OR
b. Separate IPv4 and IPv6 by using separate interfaces (e.g., two
physical links or two VLANs on the same link)?
Option (a) implies a single layer-3 interface at each end of the
connection with both IPv4 and IPv6 addresses; while option (b)
implies two layer-3 interfaces at each end, one for IPv4 addresses
and one with IPv6 addresses.
The advantages of option (a) include:
o Requires only half as many layer 3 interfaces as option (b), thus
providing better scaling;
o May require fewer physical ports, thus saving money and
simplifying operations;
o Can make the QoS implementation much easier (for example, rate-
limiting the combined IPv4 and IPv6 traffic to or from a
customer);
o Works well in practice, as any increase in IPv6 traffic is usually
counter-balanced by a corresponding decrease in IPv4 traffic to or
from the same host (ignoring the common pattern of an overall
increase in Internet usage);
o And is generally conceptually simpler.
For these reasons, there is a relatively strong consensus in the
operator community that option (a) is the preferred way to go. Most
networks today use option (a) wherever possible.
However, there can be times when option (b) is the pragmatic choice.
Most commonly, option (b) is used to work around limitations in
network equipment. One big example is the generally poor level of
support today for individual statistics on IPv4 traffic vs IPv6
traffic when option (a) is used. Other, device-specific, limitations
exist as well. It is expected that these limitations will go away as
support for IPv6 matures, making option (b) less and less attractive
until the day that IPv4 is finally turned off.
2.3. Static Routes 2.3. Static Routes
2.3.1. Link-Local Next-Hop in a Static Route? 2.3.1. Link-Local Next-Hop in a Static Route?
For the most part, the use of static routes in IPv6 parallels their For the most part, the use of static routes in IPv6 parallels their
use in IPv4. There is, however, one exception, which revolves around use in IPv4. There is, however, one exception, which revolves around
the choice of next-hop address in the static route. Specifically, the choice of next-hop address in the static route. Specifically,
should an operator: should an operator:
skipping to change at page 7, line 24 skipping to change at page 9, line 26
One of the main decisions for a network operator looking to deploy One of the main decisions for a network operator looking to deploy
IPv6 is the choice of IGP (Interior Gateway Protocol) within the IPv6 is the choice of IGP (Interior Gateway Protocol) within the
network. The main options are OSPF, IS-IS and EIGRP. RIPng is network. The main options are OSPF, IS-IS and EIGRP. RIPng is
another option, but very few networks run RIP in the core these days, another option, but very few networks run RIP in the core these days,
so it is covered in a separate section below. so it is covered in a separate section below.
OSPF [RFC2328] [RFC5340] and IS-IS [RFC5120][RFC5120] are both OSPF [RFC2328] [RFC5340] and IS-IS [RFC5120][RFC5120] are both
standardized link-state protocols. Both protocols are widely standardized link-state protocols. Both protocols are widely
supported by vendors, and both are widely deployed. By contrast, supported by vendors, and both are widely deployed. By contrast,
EIGRP [ref] is a Cisco proprietary distance-vector protocol. EIGRP EIGRP [RFC7868] is a Cisco proprietary distance-vector protocol.
is rarely deployed in service-provider networks, but is quite common EIGRP is rarely deployed in service-provider networks, but is quite
in enterprise networks, which is why it is discussed here. common in enterprise networks, which is why it is discussed here.
It is out of scope for this document to describe all the differences It is out of scope for this document to describe all the differences
between the three protocols; the interested reader can find books and between the three protocols; the interested reader can find books and
websites that go into the differences in quite a bit of detail. websites that go into the differences in quite a bit of detail.
Rather, this document simply highlights a few differences that can be Rather, this document simply highlights a few differences that can be
important to consider when designing IPv6 or dual-stack networks. important to consider when designing IPv6 or dual-stack networks.
Versions: There are two versions of OSPF: OSPFv2 and OSPFv3. The two Versions: There are two versions of OSPF: OSPFv2 and OSPFv3. The two
versions share many concepts, are configured in a similar manner and versions share many concepts, are configured in a similar manner and
seem very similar to most casual users, but have very different seem very similar to most casual users, but have very different
skipping to change at page 9, line 18 skipping to change at page 11, line 18
| | | | possible | Deployments | | | | | possible | Deployments |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| | | | | | | | | | | |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| OSPFv2 | OSPFv3 | YES | YES | YES (8) | | OSPFv2 | OSPFv3 | YES | YES | YES (8) |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| OSPFv2 | IS-IS | YES | - | YES (3) | | OSPFv2 | IS-IS | YES | - | YES (3) |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| OSPFv2 | EIGRP-v6 | YES | - | - | | OSPFv2 | EIGRP-v6 | YES | - | - |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| OSPFv3 | OSPFv3 | NO | YES | - |
+----------+----------+-------------+----------------+--------------+
| OSPFv3 | IS-IS | YES | - | - | | OSPFv3 | IS-IS | YES | - | - |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| OSPFv3 | EIGRP-v6 | YES | - | - | | OSPFv3 | EIGRP-v6 | YES | - | - |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| IS-IS | OSPFv3 | YES | - | YES (2) | | IS-IS | OSPFv3 | YES | - | YES (2) |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| IS-IS | IS-IS | - | YES | YES (12) | | IS-IS | IS-IS | - | YES | YES (12) |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
| IS-IS | EIGRP-v6 | YES | - | - | | IS-IS | EIGRP-v6 | YES | - | - |
+----------+----------+-------------+----------------+--------------+ +----------+----------+-------------+----------------+--------------+
skipping to change at page 12, line 9 skipping to change at page 14, line 9
networks, the single path means that the limitations of RIP/RIPng are networks, the single path means that the limitations of RIP/RIPng are
mostly not relevant and the very light-weight nature of RIP/RIPng mostly not relevant and the very light-weight nature of RIP/RIPng
gives it an advantage over the other protocols mentioned above. One gives it an advantage over the other protocols mentioned above. One
concrete example of this scenario is the use of RIP/RIPng between concrete example of this scenario is the use of RIP/RIPng between
cable modems and the CMTS. cable modems and the CMTS.
2.5. BGP 2.5. BGP
2.5.1. Which Transport for Which Routes? 2.5.1. Which Transport for Which Routes?
BGP these days is multi-protocol. It can carry routes from many BGP these days is multi-protocol. It can carry routes of many
different families, and it can do this when the BGP session, or more different types, or more precisely, many different AFI/SAFI
combinations. It can also carry routes when the BGP session, or more
accurately the underlying TCP connection, runs over either IPv4 or accurately the underlying TCP connection, runs over either IPv4 or
IPv6 (here referred to as either "IPv4 transport" or "IPv6 IPv6 (here referred to as either "IPv4 transport" or "IPv6
transport"). Given this flexibility, one of the biggest questions transport"). Given this flexibility, one of the biggest questions
when deploying BGP in a dual-stack network is the question of which when deploying BGP in a dual-stack network is the question of which
routes should be carried over sessions using IPv4 transport and which route types should be carried over sessions using IPv4 transport and
should be carried over sessions using IPv6 transport. which should be carried over sessions using IPv6 transport.
To answer this question, consider the following table: This section discusses this question for the three most-commonly-used
SAFI values: unlabeled (SAFI 1), labeled (SAFI 4) and VPN (SAFI 128).
Though we do not explicitly discuss other SAFI values, many of the
comments here can be applied to the other values.
+----------------+-----------+----------------------+ Consider the following table:
| Route Family | Transport | Comments |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| | | | | Route Family | Transport | Comments |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| Unlabeled IPv4 | IPv4 | Works well | | | | |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| Unlabeled IPv4 | IPv6 | Next-hop issues | | Unlabeled IPv4 | IPv4 | Works well |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| Unlabeled IPv6 | IPv4 | Next-hop issues | | Unlabeled IPv4 | IPv6 | Next-hop |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| Unlabeled IPv6 | IPv6 | Works well | | Unlabeled IPv6 | IPv4 | Next-hop |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| | | | | Unlabeled IPv6 | IPv6 | Works well |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| Labeled IPv4 | IPv4 | Works well | | | | |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| Labeled IPv4 | IPv6 | Next-hop issues | | Labeled IPv4 | IPv4 | Works well |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| Labeled IPv6 | IPv4 | (6PE) Works well | | Labeled IPv4 | IPv6 | Next-hop |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| Labeled IPv6 | IPv6 | Needs MPLS over IPv6 | | Labeled IPv6 | IPv4 | (6PE) Works well |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| | | | | Labeled IPv6 | IPv6 | Next-hop or MPLS over IPv6 |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| VPN IPv4 | IPv4 | Works well | | | | |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| VPN IPv4 | IPv6 | Next-hop issues | | VPN IPv4 | IPv4 | Works well |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| VPN IPv6 | IPv4 | (6VPE) Works well | | VPN IPv4 | IPv6 | Next-hop |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| VPN IPv6 | IPv6 | Needs MPLS over IPv6 | | VPN IPv6 | IPv4 | (6VPE) Works well |
+----------------+-----------+----------------------+ +----------------+-----------+----------------------------+
| VPN IPv6 | IPv6 | Next-hop or MPLS over IPv6 |
+----------------+-----------+----------------------------+
The first column in this table lists various route families, where The first column in this table lists various route families, where
"unlabeled" means SAFI 1, "labeled" means the routes carry an MPLS "unlabeled" means SAFI 1, "labeled" means the routes carry an MPLS
label (SAFI 4, see [RFC3107]), and "VPN" means the routes are label (SAFI 4, see [RFC3107]), and "VPN" means the routes are
normally associated with a layer-3 VPN (SAFI 128, see [RFC4364] ). normally associated with a layer-3 VPN (SAFI 128, see [RFC4364]).
The second column lists the protocol used to transport the BGP The second column lists the protocol used to transport the BGP
session, frequently specified by giving either an IPv4 or IPv6 session, frequently specified by giving either an IPv4 or IPv6
address in the "neighbor" statement. address in the "neighbor" statement.
The third column comments on the combination in the first two The third column comments on the combination in the first two
columns: columns:
o For combinations marked "Works well", these combinations are o For combinations marked "Works well", these combinations are
widely supported and are generally recommended. standardized, widely supported and widely deployed.
o For combinations marked "Next-hop issues", these combinations are o For combinations marked "Next-hop", these combinations are not
less-widely supported and when supported, often have next-hop standardized and are less-widely supported. These combinations
issues. That is, the next-hop address is typically a v4-mapped all have the "next-hop mismatch" problem: the transported route
IPv6 address, which is based on some IPv4 address on the sending needs a next-hop address from the other address family than the
router. This v4-mapped IPv6 address is often not reachable by transport address (for example, an IPv4 route needs an IPv4 next-
default using IPv6 routing. One common solution to this problem hop, even when transported over IPv6). Some vendors have
is to use routing policy to change the next-hop to a different implemented ways to solve this problem for specific combinations,
IPv6 address. but for combinations marked "next-hop", these solutions have not
been standardized (cf. 6PE and 6VPE, where the solution has been
standardized).
o For combinations marked as "Needs MPLS over IPv6", these require o For combinations marked as "Next-hop or MPLS over IPv6", these
MPLS over IPv6 for full support, though special policy combinations either require a non-standard solution to the next-
configuration may allow them to be used with MPLS over IPv4. hop problem, or require MPLS over IPv6. At the time of writing,
MPLS over IPv6 is not widely supported or deployed.
Also, it is important to note that changing the set of address Also, it is important to note that changing the set of address
families being carried over a BGP session requires the BGP session to families being carried over a BGP session requires the BGP session to
be reset (unless something like [I-D.ietf-idr-dynamic-cap] or be reset (unless something like [I-D.ietf-idr-dynamic-cap] or
[I-D.ietf-idr-bgp-multisession] is in use). This is generally more [I-D.ietf-idr-bgp-multisession] is in use). This is generally more
of an issue with eBGP sessions than iBGP sessions: for iBGP sessions of an issue with eBGP sessions than iBGP sessions: for iBGP sessions
it is common practice for a router to have two iBGP sessions, one to it is common practice for a router to have two iBGP sessions, one to
each member of a route reflector pair, so one can change the set of each member of a route reflector pair, so one can change the set of
address families on first one of the sessions and then the other. address families on first one of the sessions and then the other.
The following subsections discuss specific scenarios in more detail. The following subsections discuss specific combinations in more
detail.
2.5.1.1. BGP Sessions for Unlabeled Routes 2.5.1.1. BGP Sessions for Unlabeled Routes
Unlabeled routes are commonly carried on eBGP sessions, as well as on Unlabeled routes are commonly carried on eBGP sessions, as well as on
iBGP sessions in networks where Internet traffic is carried unlabeled iBGP sessions in networks where Internet traffic is carried unlabeled
across the network. In these scenarios, operators today most across the network.
commonly use two BGP sessions: one session is transported over IPv4
and carries the unlabeled IPv4 routes, while the second session is
transported over IPv6 and carries the unlabeled IPv6 routes.
There are several reasons for this choice: In these scenarios, there are three reasonable choices:
a. Carry unlabeled IPv4 and IPv6 routes over IPv4, OR
b. Carry unlabeled IPv4 and IPv6 routes over IPv6, OR
c. Carry unlabeled IPv4 routes over IPv4, and unlabeled IPv6 routes
over IPv6
Options (a) and (b) have the advantage that one one BGP session is
required between pairs of routers. However, option (c) is widely
considered to be the best choice. There are several reasons for this
:
o It gives a clean separation between IPv4 and IPv6. This can be o It gives a clean separation between IPv4 and IPv6. This can be
especially useful when first deploying IPv6 and troubleshooting especially useful when first deploying IPv6 and troubleshooting
resulting problems. resulting problems.
o This avoids the next-hop problem described in note 1 above. o This avoids the next-hop problem described above.
o The status of the routes follows the status of the underlying o The status of the routes follows the status of the underlying
transport. If, for example, the IPv6 data path between the two transport. If, for example, the IPv6 data path between the two
BGP speakers fails, then the IPv6 session between the two speakers BGP speakers fails, then the IPv6 session between the two speakers
will fail and the IPv6 routes will be withdrawn, which will allow will fail and the IPv6 routes will be withdrawn, which will allow
the traffic to be re-routed elsewhere. By contrast, if the IPv6 the traffic to be re-routed elsewhere. By contrast, if the IPv6
routes were transported over IPv4, then the failure of the IPv6 routes were transported over IPv4, then the failure of the IPv6
data path might leave a working IPv4 data path, so the BGP session data path might leave a working IPv4 data path, so the BGP session
would remain up and the IPv6 routes would not be withdrawn, and would remain up and the IPv6 routes would not be withdrawn, and
thus the IPv6 traffic would be sent into a black hole. thus the IPv6 traffic would be sent into a black hole.
o It avoids resetting the BGP session when adding IPv6 to an o It avoids resetting the BGP session when adding IPv6 to an
existing session, or when removing IPv4 from an existing session. existing session, or when removing IPv4 from an existing session.
Rarely, there are situations where option (c) is not practical. In
those cases today, most operators use option (a), carrying both route
types over a single BGP session.
2.5.1.2. BGP sessions for Labeled or VPN Routes 2.5.1.2. BGP sessions for Labeled or VPN Routes
In these scenarios, it is most common today to carry both the IPv4 When carrying labeled or VPN routes, the only widely-supported
and IPv6 routes over sessions transported over IPv4. This can be solution at time of writing is to carry both route types over IPv4.
done with either: (a) one session carrying both route families, or This may change in as MPLS over IPv6 becomes more widely implemented.
(b) two sessions, one for each family.
Using a single session is usually appropriate for an iBGP session There are two options when carrying both over IPv4:
going to a route reflector handling both route families. Using a
single session here usually means that the BGP session will reset a. Carry all routes over a single BGP session, OR
when changing the set of address families, but as noted above, this
is usually not a problem when redundant route reflectors are b. Carry the routes over multiple BGP sessions (e.g. one for VPN
involved. IPv4 routes and one for VPN IPv6 routes)
Using a single session is usually simplest for an iBGP session going
to a route reflector handling both route families. Using a single
session here usually means that the BGP session will reset when
changing the set of address families, but as noted above, this is
usually not a problem when redundant route reflectors are involved.
In eBGP situations, two sessions are usually more appropriate. In eBGP situations, two sessions are usually more appropriate.
[JUSTIFICATION?]
2.5.2. eBGP Endpoints: Global or Link-Local Addresses? 2.5.2. eBGP Endpoints: Global or Link-Local Addresses?
When running eBGP over IPv6, there are two options for the addresses When running eBGP over IPv6, there are two options for the addresses
to use at each end of the eBGP session (or more properly, the to use at each end of the eBGP session (or more properly, the
underlying TCP session): underlying TCP session):
a. Use link-local addresses for the eBGP session, OR a. Use link-local addresses for the eBGP session, OR
b. Use global addresses for the eBGP session. b. Use global addresses for the eBGP session.
skipping to change at page 18, line 28 skipping to change at page 21, line 45
[I-D.ietf-idr-bgp-multisession] [I-D.ietf-idr-bgp-multisession]
Scudder, J., Appanna, C., and I. Varlashkin, "Multisession Scudder, J., Appanna, C., and I. Varlashkin, "Multisession
BGP", draft-ietf-idr-bgp-multisession-07 (work in BGP", draft-ietf-idr-bgp-multisession-07 (work in
progress), September 2012. progress), September 2012.
[I-D.ietf-idr-dynamic-cap] [I-D.ietf-idr-dynamic-cap]
Ramachandra, S. and E. Chen, "Dynamic Capability for BGP- Ramachandra, S. and E. Chen, "Dynamic Capability for BGP-
4", draft-ietf-idr-dynamic-cap-14 (work in progress), 4", draft-ietf-idr-dynamic-cap-14 (work in progress),
December 2011. December 2011.
[I-D.ietf-v6ops-host-addr-availability]
Colitti, L., Cerf, D., Cheshire, S., and d.
dschinazi@apple.com, "Host address availability
recommendations", draft-ietf-v6ops-host-addr-
availability-07 (work in progress), May 2016.
[I-D.ietf-v6ops-ula-usage-recommendations] [I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B. and S. Jiang, "Considerations For Using Unique Liu, B. and S. Jiang, "Considerations For Using Unique
Local Addresses", draft-ietf-v6ops-ula-usage- Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-05 (work in progress), May 2015. recommendations-05 (work in progress), May 2015.
[ISO10589] [ISO10589]
International Standards Organization, "Intermediate system International Standards Organization, "Intermediate system
to Intermediate system intra-domain routeing information to Intermediate system intra-domain routeing information
exchange protocol for use in conjunction with the protocol exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode Network Service (ISO for providing the connectionless-mode Network Service (ISO
skipping to change at page 20, line 44 skipping to change at page 24, line 10
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>. <http://www.rfc-editor.org/info/rfc5340>.
[RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O., [RFC5375] Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
and C. Hahn, "IPv6 Unicast Address Assignment and C. Hahn, "IPv6 Unicast Address Assignment
Considerations", RFC 5375, DOI 10.17487/RFC5375, December Considerations", RFC 5375, DOI 10.17487/RFC5375, December
2008, <http://www.rfc-editor.org/info/rfc5375>. 2008, <http://www.rfc-editor.org/info/rfc5375>.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
June 2009, <http://www.rfc-editor.org/info/rfc5533>.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3", R. Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, DOI 10.17487/RFC5838, April 2010, RFC 5838, DOI 10.17487/RFC5838, April 2010,
<http://www.rfc-editor.org/info/rfc5838>. <http://www.rfc-editor.org/info/rfc5838>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <http://www.rfc-editor.org/info/rfc5925>. June 2010, <http://www.rfc-editor.org/info/rfc5925>.
[RFC5963] Gagliano, R., "IPv6 Deployment in Internet Exchange Points [RFC5963] Gagliano, R., "IPv6 Deployment in Internet Exchange Points
skipping to change at page 22, line 15 skipping to change at page 25, line 31
[RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014,
<http://www.rfc-editor.org/info/rfc7381>. <http://www.rfc-editor.org/info/rfc7381>.
[RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local
Addressing inside an IPv6 Network", RFC 7404, Addressing inside an IPv6 Network", RFC 7404,
DOI 10.17487/RFC7404, November 2014, DOI 10.17487/RFC7404, November 2014,
<http://www.rfc-editor.org/info/rfc7404>. <http://www.rfc-editor.org/info/rfc7404>.
[RFC7868] Savage, D., Ng, J., Moore, S., Slice, D., Paluch, P., and
R. White, "Cisco's Enhanced Interior Gateway Routing
Protocol (EIGRP)", RFC 7868, DOI 10.17487/RFC7868, May
2016, <http://www.rfc-editor.org/info/rfc7868>.
[v6-addressing-plan] [v6-addressing-plan]
SurfNet, "Preparing an IPv6 Address Plan", 2013, SurfNet, "Preparing an IPv6 Address Plan", 2013,
<http://www.ripe.net/lir-services/training/material/ <http://www.ripe.net/lir-services/training/material/
IPv6-for-LIRs-Training-Course/ IPv6-for-LIRs-Training-Course/
Preparing-an-IPv6-Addressing-Plan.pdf>. Preparing-an-IPv6-Addressing-Plan.pdf>.
Authors' Addresses Authors' Addresses
Philip Matthews Philip Matthews
Nokia Nokia
 End of changes. 49 change blocks. 
167 lines changed or deleted 301 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/