draft-ietf-v6ops-design-choices-11.txt   draft-ietf-v6ops-design-choices-12.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: May 1, 2017 Cisco Expires: May 17, 2017 Cisco
October 28, 2016 November 13, 2016
Some Design Choices for IPv6 Networks Routing-Related Design Choices for IPv6 Networks
draft-ietf-v6ops-design-choices-11 draft-ietf-v6ops-design-choices-12
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 May 1, 2017. This Internet-Draft will expire on May 17, 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 39 skipping to change at page 2, line 39
3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 20 3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 20
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
7. Informative References . . . . . . . . . . . . . . . . . . . 21 7. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 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 an IPv6-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
state of the discussion. Thus this document serves to both document state of the discussion. Thus this document serves to both document
the reasoning behind best current practices for IPv6, and to allow a the reasoning behind best current practices for IPv6, and to allow a
designer to make an informed choice where no such consensus exists. designer to make an informed choice where no such consensus exists.
The design choices presented apply to both Service Provider and The design choices presented apply to both Service Provider and
skipping to change at page 3, line 16 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]. advice in this area, see [RFC5375] or [v6-addressing-plan]. The
document focuses on unicast routing design only and does not cover
multicast or the issues involved in running MPLS over IPv6 transport
Finally, this document focuses on unicast routing design only and Section 2 presents and discusses a number of design choices.
does not cover multicast or the issues involved in running MPLS over Section 3 discusses some general themes that run through these
IPv6 transport. choices.
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
This section discusses the choice of addresses for router loopbacks This section discusses the choice of addresses for router loopbacks
and links between routers. It does not cover the choice of addresses and links between routers. It does not cover the choice of addresses
for end hosts. for end hosts.
In IPv6, all interfaces are assigned a Link-Local Address (LLA) In IPv6, an interface is always assigned a Link-Local Address (LLA)
[ref]. The Link-Local address can only be used for communicating [RFC4291]. The link-local address can only be used for communicating
with devices that are on-link, so often additional addresses are with devices that are on-link, so often one or more additional
assigned which are able to communicate off-link. These additional addresses are assigned which are able to communicate off-link. This
addresses can be one of three types: additional address or addresses can be one of three types:
o Provider-Independent Global Unicast Address (PI GUA): IPv6 address o Provider-Independent Global Unicast Address (PI GUA): IPv6 address
allocated by a regional address registry [RFC4291] allocated by a regional address registry [RFC4291]
o Provider-Aggregatable Global Unicast Address (PA GUA): IPv6 o Provider-Aggregatable Global Unicast Address (PA GUA): IPv6
Address allocated by your upstream service provider Address allocated by your upstream service provider
o Unique Local Address (ULA): IPv6 address locally assigned o Unique Local Address (ULA): IPv6 address locally assigned
[RFC4193] [RFC4193]
This document uses the term "multi-hop address" to collectively refer This document uses the term "multi-hop address" to collectively refer
to these three types of addresses. to these three types of addresses.
PI GUAs are, for many situations, the most flexible of these choices. PI GUAs are, for many situations, the most flexible of these choices.
Their main disadvantages are that a regional address registry will Their main disadvantages are that a regional address registry will
only allocate them to organizations that meet certain qualifications, only allocate them to organizations that meet certain qualifications,
and one must pay an annual fee. These disadvantages mean that some and one must pay an annual fee. These disadvantages mean that many
smaller organization may not qualify or be willing to pay for these smaller organization may not qualify or be willing to pay for these
addresses. addresses.
PA GUAs have the advantage that they are usually provided at no extra PA GUAs have the advantage that they are usually provided at no extra
charge when you contract with an upstream provider. However, they charge when you contract with an upstream provider. However, they
have the disadvantage that, when switching upstream providers, one have the disadvantage that, when switching upstream providers, one
must give back the old addresses and get new addresses from the new must give back the old addresses and get new addresses from the new
provider ("renumbering"). Though IPv6 has mechanisms to make provider ("renumbering"). Though IPv6 has mechanisms to make
renumbering easier than IPv4, these techniques are not generally renumbering easier than IPv4, these techniques are not generally
applicable to routers and renumbering is still fairly hard [RFC applicable to routers and renumbering is still fairly hard [RFC5887]
5887]. PA GUAs also have the disadvantage that it is not easy to [RFC6879] [RFC7010] . PA GUAs also have the disadvantage that it is
have multiple upstream providers ("multi-homing") if they are used not easy to have multiple upstream providers ("multi-homing") if they
(see section 1 of [RFC5533] ). are used (see "Ingress Filtering Problem" in [RFC5220] ).
ULAs have the advantage that they are extremely easy to obtain and ULAs have the advantage that they are extremely easy to obtain and
cost nothing. However, they have the disadvantage that they cannot cost nothing. However, they have the disadvantage that they cannot
be routed on the Internet, so must be used only within a limited 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 scope. In many situations, this is not a problem, but in certain
situations this can be problematic. Though there is currently no situations this can be problematic. Though there is currently no
document that describes these situations, many of them are similar to document that describes these situations, many of them are similar to
those described in RFC 6752. See also those described in [RFC6752]. See also
[I-D.ietf-v6ops-ula-usage-recommendations]. [I-D.ietf-v6ops-ula-usage-recommendations].
Not discussed in this document is the possibility of using the Not discussed in this document is the possibility of using the
technology described in RFC 6296 to work around some of the technology described in [RFC6296] to work around some of the
limitations of PA GUAs and ULAs. limitations of PA GUAs and ULAs.
2.1.1. Where to Use Addresses 2.1.1. Where to Use Addresses
As mentioned above, all interfaces in IPv6 always have a link-local As mentioned above, all interfaces in IPv6 always have a link-local
address. This section addresses the question of when and where to address. This section addresses the question of when and where to
assign multi-hop addresses in addition to the LLA. We consider four assign multi-hop addresses in addition to the LLA. We consider four
options: options:
a. Use only link-local addresses on all router interfaces. a. Use only link-local addresses on all router interfaces.
skipping to change at page 9, line 41 skipping to change at page 9, line 46
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
packet formats and other "under the hood" differences. The most packet formats and other "under the hood" differences. The most
important difference is that OSPFv2 will only route IPv4, while important difference is that OSPFv2 will only route IPv4, while
OSPFv3 will route both IPv4 and IPv6. OSPFv2 was by far the most OSPFv3 will route both IPv4 and IPv6 (see [RFC5838]). OSPFv2 was by
widely deployed version of OSPF when this document was published. By far the most widely deployed version of OSPF when this document was
contrast, both IS-IS and EIGRP have just a single version, which can published. By contrast, both IS-IS and EIGRP have just a single
route both IPv4 and IPv6. version, which can route both IPv4 and IPv6.
Transport. IS-IS runs over layer 2 (e.g. Ethernet). This means Transport. IS-IS runs over layer 2 (e.g. Ethernet). This means
that the functioning of IS-IS has no dependencies on the IP layer: if that the functioning of IS-IS has no dependencies on the IP layer: if
there is a problem at the IP layer (e.g. bad addresses), two routers there is a problem at the IP layer (e.g. bad addresses), two routers
can still exchange IS-IS packets. By contrast, OSPF and EIGRP both can still exchange IS-IS packets. By contrast, OSPF and EIGRP both
run over the IP layer. This means that the IP layer must be run over the IP layer. This means that the IP layer must be
configured and working OSPF or EIGRP packets to be exchanged between configured and working OSPF or EIGRP packets to be exchanged between
routers. For EIGRP, the dependency on the IP layer is simple: EIGRP routers. For EIGRP, the dependency on the IP layer is simple: EIGRP
for IPv4 runs over IPv4, while EIGRP for IPv6 runs over IPv6. For for IPv4 runs over IPv4, while EIGRP for IPv6 runs over IPv6. For
OSPF, the story is more complex: OSPFv2 runs over IPv4, but OSPFv3 OSPF, the story is more complex: OSPFv2 runs over IPv4, but OSPFv3
skipping to change at page 12, line 52 skipping to change at page 12, line 52
o All links in the network must support both IPv4 and IPv6, as the o All links in the network must support both IPv4 and IPv6, as the
calculation of routes does not take this into account. If some calculation of routes does not take this into account. If some
links do not support IPv6 (or IPv4), then packets may get routed links do not support IPv6 (or IPv4), then packets may get routed
across links where support is lacking and get dropped. This can across links where support is lacking and get dropped. This can
cause problems if some network devices do not support IPv6 (or cause problems if some network devices do not support IPv6 (or
IPv4). IPv4).
o It is also important to keep the previous point in mind when o It is also important to keep the previous point in mind when
adding or removing support for either IPv4 or IPv6. adding or removing support for either IPv4 or IPv6.
With multi-topology mode [ref]: With multi-topology mode [RFC5120]:
o IS-IS keeps two link-state databases, one for IPv4 and one for o IS-IS keeps two link-state databases, one for IPv4 and one for
IPv6. IPv6.
o IPv4 and IPv6 can have separate link metrics. Note that most o IPv4 and IPv6 can have separate link metrics. Note that most
implementations today require separate link metrics: a number of implementations today require separate link metrics: a number of
operators have rudely discovered that they have forgotten to operators have rudely discovered that they have forgotten to
configure the IPv6 metric until sometime after deploying IPv6 in configure the IPv6 metric until sometime after deploying IPv6 in
multi-topology mode! multi-topology mode!
skipping to change at page 22, line 12 skipping to change at page 22, line 12
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
8473)", International Standard 10589:2002, Nov 2002. 8473)", International Standard 10589:2002, Nov 2002.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
DOI 10.17487/RFC2080, January 1997, DOI 10.17487/RFC2080, January 1997,
<http://www.rfc-editor.org/info/rfc2080>. <http://www.rfc-editor.org/info/rfc2080>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, Extensions for IPv6 Inter-Domain Routing", RFC 2545,
skipping to change at page 24, line 10 skipping to change at page 24, line 5
[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>.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, DOI 10.17487/RFC5887, May
2010, <http://www.rfc-editor.org/info/rfc5887>.
[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
(IXPs)", RFC 5963, DOI 10.17487/RFC5963, August 2010, (IXPs)", RFC 5963, DOI 10.17487/RFC5963, August 2010,
<http://www.rfc-editor.org/info/rfc5963>. <http://www.rfc-editor.org/info/rfc5963>.
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment", RFC 6180, Transition Mechanisms during IPv6 Deployment", RFC 6180,
 End of changes. 16 change blocks. 
36 lines changed or deleted 33 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/