draft-ietf-v6ops-design-choices-00.txt		draft-ietf-v6ops-design-choices-01.txt
	V6OPS Working Group P. Matthews		V6OPS Working Group P. Matthews
	Internet-Draft Alcatel-Lucent		Internet-Draft Alcatel-Lucent
	Intended status: Informational February 14, 2013		Intended status: Informational V. Kuarsingh
	Expires: August 18, 2013		Expires: September 7, 2014 Dyn
			March 6, 2014
	Design Choices for IPv6 Networks		Design Choices for IPv6 Networks
	draft-ietf-v6ops-design-choices-00		draft-ietf-v6ops-design-choices-01
	Abstract		Abstract
	This document presents advice on the design choices that arise when		This document presents advice on the design choices that arise when
	designing IPv6 networks (both dual-stack and IPv6-only). The		designing IPv6 networks (both dual-stack and IPv6-only). The
	intended audience is someone designing an IPv6 network who is		intended audience is someone designing an IPv6 network who is
	knowledgeable about best current practices around IPv4 network		knowledgeable about best current practices around IPv4 network
	design, and wishes to learn the corresponding practices for IPv6.		design, and wishes to learn the corresponding practices for IPv6.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 August 18, 2013.		This Internet-Draft will expire on September 7, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Mix IPv4 and IPv6 on the Same Link? . . . . . . . . . . . 3		2.1. Mix IPv4 and IPv6 on the Same Link? . . . . . . . . . . . 3
	2.2. Links with Only Link-Local Addresses? . . . . . . . . . . 4		2.2. Links with Only Link-Local Addresses? . . . . . . . . . . 4
	2.3. Link-Local Next-Hop in a Static Route? . . . . . . . . . . 5		2.3. Link-Local Next-Hop in a Static Route? . . . . . . . . . 5
	2.4. Separate or Combined eBGP Sessions? . . . . . . . . . . . 6		2.4. Separate or Combined eBGP Sessions? . . . . . . . . . . . 6
	2.5. eBGP Endpoints: Global or Link-Local Addresses? . . . . . 7		2.5. eBGP Endpoints: Global or Link-Local Addresses? . . . . . 7
	3. General Observations . . . . . . . . . . . . . . . . . . . . . 8		2.6. IGP Choice . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 9		3. General Observations . . . . . . . . . . . . . . . . . . . . 9
	3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 9		3.1. Use of Link-Local Addresses . . . . . . . . . . . . . . . 9
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		3.2. Separation of IPv4 and IPv6 . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Informative References . . . . . . . . . . . . . . . . . . . . 10		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. Informative References . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	This document presents advice on the design choices that arise when		This document presents advice on the design choices that arise when
	designing IPv6 networks (both dual-stack and IPv6-only). The		designing IPv6 networks (both dual-stack and IPv6-only). The
	intended audience is someone designing an IPv6 network who is		intended audience is someone designing an IPv6 network who is
	knowledgeable about best current practices around IPv4 network		knowledgeable about best current practices around IPv4 network
	design, and wishes to learn the corresponding practices for IPv6.		design, and wishes to learn the corresponding practices for IPv6.
	The focus of the document is on design choices where there are		The focus of the document is on design choices where there are
	skipping to change at page 3, line 29		skipping to change at page 2, line 50
	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 to		state of the discussion. Thus this document serves to both to
	document the reasoning behind best current practices for IPv6, and to		document the reasoning behind best current practices for IPv6, and to
	allow a designer to make an intelligent choice where no such		allow a designer to make an intelligent choice where no such
	consensus exists.		consensus exists.
	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 mechanisms. For advice		to a network, nor does it discuss transition mechanisms. For advice
	in these areas, see [RFC6180] for general advice, [RFC6782] for		in these areas, see [RFC6180] for general advice, [RFC6782] for
	wireline service providers, [RFC6342] for mobile network providers,		wireline service providers, [RFC6342] for mobile network providers,
	[RFC5963] for exchange point operators, [I-D.ietf-v6ops-icp-guidance]		[RFC5963] for exchange point operators, [RFC6883] for content
	for content providers, and both [RFC4852] and		providers, and both [RFC4852] and
	[I-D.ietf-v6ops-enterprise-incremental-ipv6] for enterprises. Nor		[I-D.ietf-v6ops-enterprise-incremental-ipv6] for enterprises. Nor
	does the document cover the ins and outs of creating an IPv6		does the document cover the ins and outs of creating an IPv6
	addressing plan; for advice in this area, see [RFC5375].		addressing plan; for advice in this area, see [RFC5375].
	This document focuses on unicast network design only. It does not		This document focuses on unicast network design only. It does not
	cover multicast, nor supporting infrastructure such as DNS.		cover multicast, nor supporting infrastructure such as DNS.
	The current version is still work in progress, and it is expected		The current version is still work in progress, and it is expected
	that the presentation and discussion of additional design choices		that the presentation and discussion of additional design choices
	will be added as the document matures.		will be added as the document matures.
	skipping to change at page 7, line 49		skipping to change at page 7, line 25
	Note that the choice here is the addresses to use for the eBGP		Note that the choice here is the addresses to use for the eBGP
	sessions, and not whether the link itself has global (or unique-		sessions, and not whether the link itself has global (or unique-
	local) addresses. In particular, it is quite possible for the eBGP		local) addresses. In particular, it is quite possible for the eBGP
	session to use link-local addresses even when the link has global		session to use link-local addresses even when the link has global
	addresses.		addresses.
	The big attraction for option (a) is security: an eBGP session using		The big attraction for option (a) is security: an eBGP session using
	link-local addresses is impossible to attack from a device that is		link-local addresses is impossible to attack from a device that is
	off-link. This provides very strong protection against TCP RST and		off-link. This provides very strong protection against TCP RST and
	similar attacks. Though there are other ways to get an equivalent		similar attacks. Though there are other ways to get an equivalent
	level of security (e.g. GTSM [RFC5082], MD5 [RFC5925], or ACLs),		level of security (e.g. GTSM [RFC5082], MD5 [RFC5925], or ACLs),
	these other ways require additional configuration which can be		these other ways require additional configuration which can be
	forgotten or potentially mis-configured.		forgotten or potentially mis-configured.
	However, there are a number of small disadvantages to using link-		However, there are a number of small disadvantages to using link-
	local addresses:		local addresses:
	o Using link-local addresses only works for single-hop eBGP		o Using link-local addresses only works for single-hop eBGP
	sessions; it does not work for multi-hop sessions.		sessions; it does not work for multi-hop sessions.
	o One must use "next-hop self" at both endpoints, otherwise		o One must use "next-hop self" at both endpoints, otherwise
	skipping to change at page 8, line 46		skipping to change at page 8, line 22
	local end, and no reconfiguration is required at the remote end).		local end, and no reconfiguration is required at the remote end).
	o Finally, a strict interpretation of RFC 2545 can be seen as		o Finally, a strict interpretation of RFC 2545 can be seen as
	forbidding running eBGP between link-local addresses, as RFC 2545		forbidding running eBGP between link-local addresses, as RFC 2545
	requires the BGP next-hop field to contain at least a global		requires the BGP next-hop field to contain at least a global
	address.		address.
	For these reasons, most operators today choose to have their eBGP		For these reasons, most operators today choose to have their eBGP
	sessions use global addresses.		sessions use global addresses.
			2.6. IGP Choice
			One of the main decisions for an IPv6 implementor is the choice of
			IGP (Interior Gateway Protocol) within the network. The primary
			choices are the IETF protocols of RIP [RFC2080], OSPF [RFC2328]
			[RFC5340] and IS-IS [RFC5120] [RFC5308], though some operators may
			consider non-IETF protocols. Here we limit our discussion to the
			pros and cons of OSPF vs. IS-IS.
			Considering just OSPF vs. IS-IS, the options are:
			a. Use OSPFv2 for IPv4 and OSPFv3 for IPv6, OR
			b. Use OSPFv3 for both IPv4 and IPv6, OR
			c. Use OSPFv2 for IPv4, and IS-IS for IPv6, OR
			d. Use IS-IS for IPv4 and IPv6, OR
			e. Use IS-IS for IPv4 and OSPFv3 for IPv6.
			Note that options (a), (c), and (e) involve running two different
			routing protocols, while options (b) and (d) involve running just one
			routing protocol.
			o A big factor in the choice is the protocol the operator is
			currently using for routing IPv4. Option (e) is unlikely to be a
			good choice for an operator currently using OSPF for IPv4 routing,
			and similarly option (a) is unlikely to be a good choice for an
			operator currently using IS-IS.
			o A pro for options (a), (c), and (e), which use two routing
			protocols, is that they give a hard separation between IPv4 and
			IPv6 routing. Thus a problem with one protocol or one set of
			routes is unlikely to affect the other.
			o There are two cons for options (a), (c), and (e). One con is that
			two sets of all the protocol mechanisms need to be maintained. On
			a larger modern router, this is unlikely to be a problem, but on
			some edge devices this might be an issue. The second con is that
			some operational staff must be familiar with both protocols. For
			many routing problems, the protocols are sufficiently similar that
			they can be considered identical, but some problems require a
			detailed knowledge of the differences.
			o Option (b) requires the use of new protocol extensions that allow
			OSPFv3 to also route IPv4. At the time of writing, these
			extensions are still quite new.
	3. General Observations		3. General Observations
	There are two themes that run though many of the design choices in		There are two themes that run though many of the design choices in
	this document. This section presents some general discussion on		this document. This section presents some general discussion on
	these two themes.		these two themes.
	3.1. Use of Link-Local Addresses		3.1. Use of Link-Local Addresses
	The proper use of link-local addresses is a common theme in the IPv6		The proper use of link-local addresses is a common theme in the IPv6
	network design choices. Link-layer addresses are, of course, always		network design choices. Link-layer addresses are, of course, always
	skipping to change at page 10, line 29		skipping to change at page 11, line 5
	Many, many people in the V6OPS working group provided comments and		Many, many people in the V6OPS working group provided comments and
	suggestions that made their way into this document. A partial list		suggestions that made their way into this document. A partial list
	includes: Rajiv Asati, Fred Baker, Michael Behringer, Marc Blanchet,		includes: Rajiv Asati, Fred Baker, Michael Behringer, Marc Blanchet,
	Ron Bonica, Randy Bush, Cameron Byrne, Brian Carpenter, KK		Ron Bonica, Randy Bush, Cameron Byrne, Brian Carpenter, KK
	Chittimaneni, Tim Chown, Lorenzo Colitti, Gert Doering, Bill Fenner,		Chittimaneni, Tim Chown, Lorenzo Colitti, Gert Doering, Bill Fenner,
	Kedar K Gaonkar, Chris Grundemann, Steinar Haug, Ray Hunter, Joel		Kedar K Gaonkar, Chris Grundemann, Steinar Haug, Ray Hunter, Joel
	Jaeggli, Victor Kuarsingh, Ivan Pepelnjak, Alexandru Petrescu, Rob		Jaeggli, Victor Kuarsingh, Ivan Pepelnjak, Alexandru Petrescu, Rob
	Shakir, Mark Smith, Jean-Francois Tremblay, Tina Tsou, Dan York, and		Shakir, Mark Smith, Jean-Francois Tremblay, Tina Tsou, Dan York, and
	Xuxiaohu.		Xuxiaohu.
	I would also like to thank Pradeep Jain and Alastair Johnson for		The authors would also like to thank Pradeep Jain and Alastair
	helpful comments on a very preliminary version of this document.		Johnson for helpful comments on a very preliminary version of this
			document.
	7. Informative References		7. Informative References
	[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		Ramachandra, S. and E. Chen, "Dynamic Capability for
	BGP-4", draft-ietf-idr-dynamic-cap-14 (work in progress),		BGP-4", draft-ietf-idr-dynamic-cap-14 (work in progress),
	December 2011.		December 2011.
	[I-D.ietf-opsec-lla-only]		[I-D.ietf-opsec-lla-only]
	Behringer, M. and E. Vyncke, "Using Only Link-Local		Behringer, M. and E. Vyncke, "Using Only Link-Local
	Addressing Inside an IPv6 Network",		Addressing Inside an IPv6 Network", draft-ietf-opsec-lla-
	draft-ietf-opsec-lla-only-02 (work in progress),		only-07 (work in progress), February 2014.
	October 2012.
	[I-D.ietf-v6ops-enterprise-incremental-ipv6]		[I-D.ietf-v6ops-enterprise-incremental-ipv6]
	Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,		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",		Guidelines", draft-ietf-v6ops-enterprise-incremental-
	draft-ietf-v6ops-enterprise-incremental-ipv6-01 (work in		ipv6-05 (work in progress), January 2014.
	progress), September 2012.
	[I-D.ietf-v6ops-icp-guidance]		[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
	Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet		January 1997.
	Content and Application Service Providers",
	draft-ietf-v6ops-icp-guidance-05 (work in progress),		[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
	January 2013.
	[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.		[RFC4852] Bound, J., Pouffary, Y., Klynsma, S., Chown, T., and D.
	Green, "IPv6 Enterprise Network Analysis - IP Layer 3		Green, "IPv6 Enterprise Network Analysis - IP Layer 3
	Focus", RFC 4852, April 2007.		Focus", RFC 4852, April 2007.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.		[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
	Pignataro, "The Generalized TTL Security Mechanism		Pignataro, "The Generalized TTL Security Mechanism
	(GTSM)", RFC 5082, October 2007.		(GTSM)", RFC 5082, October 2007.
	[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,		[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
	October 2008.		Topology (MT) Routing in Intermediate System to
			Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
			[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
			2008.
	[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, July 2008.		for IPv6", RFC 5340, July 2008.
	[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, December 2008.		Considerations", RFC 5375, December 2008.
	[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP		[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
	Authentication Option", RFC 5925, June 2010.		Authentication Option", RFC 5925, June 2010.
	skipping to change at page 12, line 9		skipping to change at page 12, line 31
	[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,
	May 2011.		May 2011.
	[RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6		[RFC6342] Koodli, R., "Mobile Networks Considerations for IPv6
	Deployment", RFC 6342, August 2011.		Deployment", RFC 6342, August 2011.
	[RFC6782] Kuarsingh, V. and L. Howard, "Wireline Incremental IPv6",		[RFC6782] Kuarsingh, V. and L. Howard, "Wireline Incremental IPv6",
	RFC 6782, November 2012.		RFC 6782, November 2012.
	Author's Address		[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
			Content Providers and Application Service Providers", RFC
			6883, March 2013.
			Authors' Addresses
	Philip Matthews		Philip Matthews
	Alcatel-Lucent		Alcatel-Lucent
	600 March Road		600 March Road
	Ottawa, Ontario K2K 2E6		Ottawa, Ontario K2K 2E6
	Canada		Canada
	Phone: +1 613-784-3139		Phone: +1 613-784-3139
	Email: philip_matthews@magma.ca		Email: philip_matthews@magma.ca
			Victor Kuarsingh
			Dyn
			150 Dow Street
			Manchester, NH 03101
			USA
			Email: victor@jvknet.com
End of changes. 16 change blocks.
	40 lines changed or deleted		98 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/