draft-ietf-idr-v4nlri-v6nh-00.txt		draft-ietf-idr-v4nlri-v6nh-01.txt
	Inter-Domain Routing F. Le Faucheur		Inter-Domain Routing F. Le Faucheur
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track E. Rosen		Intended status: Standards Track E. Rosen
	Expires: September 24, 2007 Cisco Systems, Inc.		Expires: April 18, 2008 Cisco Systems, Inc.
	March 23, 2007		October 16, 2007
	Advertising an IPv4 NLRI with an IPv6 Next Hop		Advertising an IPv4 NLRI with an IPv6 Next Hop
	draft-ietf-idr-v4nlri-v6nh-00.txt		draft-ietf-idr-v4nlri-v6nh-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 24, 2007.		This Internet-Draft will expire on April 18, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer		MultiProtocol-BGP (MP-BGP) specifies that the set of Network Layer
	protocols to which the address carried in the Next Hop field may		protocols to which the address carried in the Next Hop field may
	belong is determined by the Address Family Identifier (AFI) and the		belong is determined by the Address Family Identifier (AFI) and the
	skipping to change at page 3, line 34		skipping to change at page 3, line 34
	Furthermore, a number of these existing AFI/SAFIs allow the Next Hop		Furthermore, a number of these existing AFI/SAFIs allow the Next Hop
	to belong to either the IPv4 Network Layer Protocol or the IPv6		to belong to either the IPv4 Network Layer Protocol or the IPv6
	Network Layer Protocol, and specify the encoding of the Next Hop		Network Layer Protocol, and specify the encoding of the Next Hop
	information in order to determine which of the protocols the address		information in order to determine which of the protocols the address
	actually belongs to. For example, [RFC4684] allows the Next Hop		actually belongs to. For example, [RFC4684] allows the Next Hop
	address to be either IPv4 or IPv6 and states that the Next Hop field		address to be either IPv4 or IPv6 and states that the Next Hop field
	address shall be interpreted as an IPv4 address, whenever the length		address shall be interpreted as an IPv4 address, whenever the length
	of Next Hop address is 4 octets, and as a IPv6 address, whenever the		of Next Hop address is 4 octets, and as a IPv6 address, whenever the
	length of the Next Hop address is 16 octets.		length of the Next Hop address is 16 octets.
	There are situations such as those described in		There are situations such as those described in [RFC4925] and in
	[I-D.ietf-softwire-problem-statement] and in		[I-D.ietf-softwire-mesh-framework] where carriers (or large
	[I-D.wu-softwire-mesh-framework] where carriers (or large enterprise		enterprise networks acting as carrier for their internal resources)
	networks acting as carrier for their internal resources) may be		may be required to establish connectivity between 'islands' of
	required to establish connectivity between 'islands' of networks of		networks of one address family type across a transit core of a
	one address family type across a transit core of a differing address		differing address family type. This includes both the case of IPv6
	family type. This includes both the case of IPv6 islands across an		islands across an IPv4 core and the case of IPv4 islands across an
	IPv4 core and the case of IPv4 islands across an IPv6 core. Where		IPv6 core. Where Multi-Protocol BGP (MP-BGP) is used to advertise
	Multi-Protocol BGP (MP-BGP) is used to advertise the corresponding		the corresponding reachability information, this translates into the
	reachability information, this translates into the requirement for a		requirement for a BGP speaker to advertise Network Layer Reachability
	BGP speaker to advertise Network Layer Reachability Information		Information (NLRI) of a given address family via a Next Hop of a
	(NLRI) of a given address family via a Next Hop of a different		different address family (i.e. IPv6 NLRI with IPv4 Next Hop and IPv4
	address family (i.e. IPv6 NLRI with IPv4 Next Hop and IPv4 NLRI with		NLRI with IPv6 Next Hop).
	IPv6 Next Hop).
	The current AFI/SAFI definitions for the IPv6 address family assume		The current AFI/SAFI definitions for the IPv6 address family assume
	that the Next Hop address belongs to the IPv6 address family type.		that the Next Hop address belongs to the IPv6 address family type.
	Specifically, as per [RFC2545] and [RFC3107], when the <AFI/SAFI> is		Specifically, as per [RFC2545] and [RFC3107], when the <AFI/SAFI> is
	<2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6		<2/1>, <2/2>, or <2/4>, the Next Hop address is assumed to be of IPv6
	type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the Next Hop		type. As per [RFC4659], when the <AFI/SAFI> is <2/128>, the Next Hop
	address is assumed to be of IPv6-VPN type.		address is assumed to be of IPv6-VPN type.
	However, [RFC4798] and [RFC4659] specify how an IPv4 address can be		However, [RFC4798] and [RFC4659] specify how an IPv4 address can be
	encoded inside the Next Hop IPv6 address field when an IPv6 NLRI		encoded inside the Next Hop IPv6 address field when an IPv6 NLRI
	skipping to change at page 8, line 19		skipping to change at page 8, line 19
	by the BGP capability advertisement), then the NLRI in question		by the BGP capability advertisement), then the NLRI in question
	cannot be distributed to that client. For sound routing in certain		cannot be distributed to that client. For sound routing in certain
	scenarios, this will require that all the RR clients be able to		scenarios, this will require that all the RR clients be able to
	handle whatever encodings any of them may generate.		handle whatever encodings any of them may generate.
	5. Usage Examples		5. Usage Examples
	5.1. IPv4 over IPv6 Core		5.1. IPv4 over IPv6 Core
	The extensions defined in this document may be used as discussed in		The extensions defined in this document may be used as discussed in
	[I-D.wu-softwire-mesh-framework] for the interconnection of IPV4		[I-D.ietf-softwire-mesh-framework] for the interconnection of IPV4
	islands over an IPv6 backbone. In this application, Address Family		islands over an IPv6 backbone. In this application, Address Family
	Border Routers (AFBR) (as defined in		Border Routers (AFBR) (as defined in [RFC4925]) advertise IPv4 NLRI
	[I-D.ietf-softwire-problem-statement]) advertise IPv4 NLRI
	information in the MP_REACH_NLRI along with an IPv6 next hop.		information in the MP_REACH_NLRI along with an IPv6 next hop.
	The MP_REACH_NLRI is encoded with:		The MP_REACH_NLRI is encoded with:
	o AFI=1		o AFI=1
	o SAFI=1		o SAFI=1
	o Length of Next Hop Network Address = 16 (or 32)		o Length of Next Hop Network Address = 16 (or 32)
	skipping to change at page 10, line 42		skipping to change at page 10, line 42
	[I-D.ietf-idr-dynamic-cap]		[I-D.ietf-idr-dynamic-cap]
	Chen, E. and S. Sangli, "Dynamic Capability for BGP-4",		Chen, E. and S. Sangli, "Dynamic Capability for BGP-4",
	draft-ietf-idr-dynamic-cap-09 (work in progress),		draft-ietf-idr-dynamic-cap-09 (work in progress),
	November 2006.		November 2006.
	[I-D.ietf-l2vpn-signaling]		[I-D.ietf-l2vpn-signaling]
	Rosen, E., "Provisioning, Autodiscovery, and Signaling in		Rosen, E., "Provisioning, Autodiscovery, and Signaling in
	L2VPNs", draft-ietf-l2vpn-signaling-08 (work in progress),		L2VPNs", draft-ietf-l2vpn-signaling-08 (work in progress),
	May 2006.		May 2006.
	[I-D.ietf-softwire-problem-statement]		[I-D.ietf-softwire-mesh-framework]
	Dawkins, S., "Softwire Problem Statement",
	draft-ietf-softwire-problem-statement-03 (work in
	progress), March 2007.
	[I-D.wu-softwire-mesh-framework]
	Wu, J., "Softwire Mesh Framework",		Wu, J., "Softwire Mesh Framework",
	draft-wu-softwire-mesh-framework-02 (work in progress),		draft-ietf-softwire-mesh-framework-02 (work in progress),
	March 2007.		July 2007.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,		[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur,
	"BGP-MPLS IP Virtual Private Network (VPN) Extension for		"BGP-MPLS IP Virtual Private Network (VPN) Extension for
	IPv6 VPN", RFC 4659, September 2006.		IPv6 VPN", RFC 4659, September 2006.
	[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,		[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
	R., Patel, K., and J. Guichard, "Constrained Route		R., Patel, K., and J. Guichard, "Constrained Route
	Distribution for Border Gateway Protocol/MultiProtocol		Distribution for Border Gateway Protocol/MultiProtocol
	Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual		Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
	Private Networks (VPNs)", RFC 4684, November 2006.		Private Networks (VPNs)", RFC 4684, November 2006.
	[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,		[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
	"Connecting IPv6 Islands over IPv4 MPLS Using IPv6		"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
	Provider Edge Routers (6PE)", RFC 4798, February 2007.		Provider Edge Routers (6PE)", RFC 4798, February 2007.
			[RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
			Problem Statement", RFC 4925, July 2007.
	Authors' Addresses		Authors' Addresses
	Francois Le Faucheur		Francois Le Faucheur
	Cisco Systems		Cisco Systems
	Greenside, 400 Avenue de Roumanille		Greenside, 400 Avenue de Roumanille
	Sophia Antipolis 06410		Sophia Antipolis 06410
	France		France
	Email: flefauch@cisco.com		Email: flefauch@cisco.com
End of changes. 9 change blocks.
	29 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/