< draft-kumar-idr-link-local-nexthop-01.txt		draft-kumar-idr-link-local-nexthop-02.txt >
	Network Working Group V. Kumar		Network Working Group V. Kumar
	Internet-Draft Cumulus Networks		Internet-Draft Cumulus Networks
	Intended status: Standards Track P. Mohapatra		Intended status: Standards Track P. Mohapatra
	Expires: April 9, 2015 Sproute Networks		Expires: May 17, 2015 Sproute Networks
	D. Dutt		D. Dutt
	Cumulus Networks		Cumulus Networks
	M. Valentine		M. Valentine
	Goldman Sachs		Goldman Sachs
	October 6, 2014		November 13, 2014
	BGP Link-Local Next Hop Capability		BGP Link-Local Next Hop Capability
	draft-kumar-idr-link-local-nexthop-01.txt		draft-kumar-idr-link-local-nexthop-02.txt
	Abstract		Abstract
	This document proposes a new BGP capability to allow route resolution		This document proposes a new BGP capability to allow route resolution
	over IPv6 link-local next hop. It eliminates the requirement of		over IPv6 link-local next hop. It eliminates the requirement of
	assigning a global IPv6 address for the next hop.		assigning a global IPv6 address for the next hop.
	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
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 9, 2015.		This Internet-Draft will expire on May 17, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 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
	skipping to change at page 2, line 27 ¶		skipping to change at page 2, line 27 ¶
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. Link-Local Next Hop Capability . . . . . . . . . . . . . . . 3		2. Link-Local Next Hop Capability . . . . . . . . . . . . . . . 3
	3. Constructing the Next Hop field . . . . . . . . . . . . . . . 4		3. Constructing the Next Hop field . . . . . . . . . . . . . . . 4
	4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Deployment Considerations . . . . . . . . . . . . . . . . . . 4		5. Deployment Considerations . . . . . . . . . . . . . . . . . . 5
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 5		8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
	9. Normative References . . . . . . . . . . . . . . . . . . . . 5		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5		9.1. Normative References . . . . . . . . . . . . . . . . . . 5
			9.2. Informational References . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
	1. Introduction		1. Introduction
	BGP [RFC4271] implementations support peering over link-local IPv6		BGP [RFC4271] implementations support peering over link-local IPv6
	addresses [RFC4291]. However, for the prefixes advertised over such		addresses [RFC4291]. However, for the prefixes advertised over such
	a peering the resulting next hop attribute and route installation is		a peering the resulting next hop attribute and route installation is
	still dependent on the Next Hop carrying a global IPv6 address. For		still dependent on the Next Hop carrying a global IPv6 address. For
	the deployments where next hops need not have a scope beyond the		the deployments where next hops need not have a scope beyond the
	peering link, the configuration can be simplified by lifting the		peering link, the configuration can be simplified by lifting the
	requirement that the Next Hop field carry a global IPv6 address.		requirement that the Next Hop field carry a global IPv6 address.
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 44 ¶
	implicit next-hop-self should not be done. Same goes for eBGP to		implicit next-hop-self should not be done. Same goes for eBGP to
	iBGP scenarios.		iBGP scenarios.
	4. Operation		4. Operation
	A BGP speaker that is willing to use (send and receive) only link-		A BGP speaker that is willing to use (send and receive) only link-
	local addresses as next hops with a peer SHOULD advertise the LINK-		local addresses as next hops with a peer SHOULD advertise the LINK-
	LOCAL-ONLY-NEXT-HOP Capability to the peer using BGP Capabilities		LOCAL-ONLY-NEXT-HOP Capability to the peer using BGP Capabilities
	advertisement.		advertisement.
			[draft-kato] recommended implementations to ignore the ipv6 global
			next hop if it didn't match any of the link's global addresses. The
			proposal has the following limitations:
			o It results in poor error handling, specifically for next hop
			validation.
			o It does not allow the sender to set a global next hop value that
			is _not_ one of the assigned prefixes on the link.
			o It does not specify the behavior for IBGP sessions.
			o A global next hop field has to be always present in the UPDATE
			messages.
			We formalize this idea with the proposed new capability, so that the
			peers have the flexibility to include both link-local and global next
			hops or link-local only next hop. The error handling of messages is
			not compromised.
	5. Deployment Considerations		5. Deployment Considerations
	The usage of this capability is restricted to the cases where the		The usage of this capability is restricted to the cases where the
	scope of the next hop is limited to the peering interface. This		scope of the next hop is limited to the peering interface. This
	restriction comes from the fact that link-local IPv6 addresses are		restriction comes from the fact that link-local IPv6 addresses are
	link-scoped, therefore link-local address of the one peer can not be		link-scoped, therefore link-local address of the one peer can not be
	used as next hop if its to be carried with the updates over another		used as next hop if its to be carried with the updates over another
	peer.		peer.
	6. Acknowledgments		6. Acknowledgments
	skipping to change at page 5, line 19 ¶		skipping to change at page 5, line 38 ¶
	7. IANA Considerations		7. IANA Considerations
	This document defines a new link-local next hop capability. IANA is		This document defines a new link-local next hop capability. IANA is
	requested to assign a capability number to the same.		requested to assign a capability number to the same.
	8. Security Considerations		8. Security Considerations
	There are no additional security risks introduced by this design.		There are no additional security risks introduced by this design.
	9. Normative References		9. References
			9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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, March		Extensions for IPv6 Inter-Domain Routing", RFC 2545, March
	1999.		1999.
	[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway		[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
	Protocol 4 (BGP-4)", RFC 4271, January 2006.		Protocol 4 (BGP-4)", RFC 4271, January 2006.
	skipping to change at page 5, line 44 ¶		skipping to change at page 6, line 18 ¶
	[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN		[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN
	in Link State Routing Protocols", RFC 5309, October 2008.		in Link State Routing Protocols", RFC 5309, October 2008.
	[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement		[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
	with BGP-4", RFC 5492, February 2009.		with BGP-4", RFC 5492, February 2009.
	[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network		[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
	Layer Reachability Information with an IPv6 Next Hop", RFC		Layer Reachability Information with an IPv6 Next Hop", RFC
	5549, May 2009.		5549, May 2009.
			9.2. Informational References
			[draft-kato]
			"http://tools.ietf.org/html/
			draft-kato-bgp-ipv6-link-local-00", September 2001.
	Authors' Addresses		Authors' Addresses
	Vipin Kumar		Vipin Kumar
	Cumulus Networks		Cumulus Networks
	185 E. Dana Street		185 E. Dana Street
	Mountain View, CA 94041		Mountain View, CA 94041
	USA		USA
	Email: vipin@cumulusnetworks.com		Email: vipin@cumulusnetworks.com
	Pradosh Mohapatra		Pradosh Mohapatra
	Sproute Networks		Sproute Networks
	Email: mpradosh@yahoo.com		Email: mpradosh@yahoo.com
	Dinesh Dutt		Dinesh Dutt
	Cumulus Networks		Cumulus Networks
	185 E. Dana Street		185 E. Dana Street
	Mountain View, CA 94041		Mountain View, CA 94041
	USA		USA
End of changes. 10 change blocks.
	8 lines changed or deleted		39 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/