draft-ietf-idr-bgp4-ipv6-00.txt   draft-ietf-idr-bgp4-ipv6-01.txt 
Network Working Group Pedro R. Marques Network Working Group Pedro R. Marques
Internet Draft cisco Systems, Inc. Internet Draft cisco Systems, Inc.
Expiration Date: May 1998 Expiration Date: August 1998
Francis Dupont Francis Dupont
Inria Inria
November 1997 February 1998
Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
draft-ietf-idr-bgp4-ipv6-00.txt draft-ietf-idr-bgp4-ipv6-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
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
skipping to change at page 2, line 41 skipping to change at page 2, line 41
between global and site-local addresses and refers to both as between global and site-local addresses and refers to both as
"global" or "non-link-local". Network administrators must however "global" or "non-link-local". Network administrators must however
respect address scope restrictions and should be aware that the respect address scope restrictions and should be aware that the
concepts of a BGP-4 routing domain and "site" are orthogonal notions concepts of a BGP-4 routing domain and "site" are orthogonal notions
and that they may or may not coincide in a given situation. and that they may or may not coincide in a given situation.
Companion IPv6 specifications further define that only link-local Companion IPv6 specifications further define that only link-local
address can be used when generating ICMP Redirect Messages [ND] and address can be used when generating ICMP Redirect Messages [ND] and
as next hop addresses in some routing protocols (eg. RIPng [RIP]). as next hop addresses in some routing protocols (eg. RIPng [RIP]).
This restrictions does imply that an IPv6 router MUST have a link- This restrictions does imply that an IPv6 router must have a link-
local next hop address for all directly connected routes (routes for local next hop address for all directly connected routes (routes for
which the given router and the next hop router share a common subnet which the given router and the next hop router share a common subnet
prefix). prefix).
Link-local addresses are not, however, well suited to be used as next Link-local addresses are not, however, well suited to be used as next
hop attributes in BGP-4 given the rules defined for this attribute in hop attributes in BGP-4 given the rules defined for this attribute in
the protocol specification [BGP-4]. the protocol specification [BGP-4].
For the above reasons, when BGP-4 is used to convey IPv6 reachability For the above reasons, when BGP-4 is used to convey IPv6 reachability
information it is sometimes necessary to announce a next hop information it is sometimes necessary to announce a next hop
skipping to change at page 4, line 13 skipping to change at page 4, line 13
at session establishment time, within an OPEN message. This is a at session establishment time, within an OPEN message. This is a
system wide value determined at startup which must be unique in the system wide value determined at startup which must be unique in the
network and should be derived from an IPv4 address regardless of the network and should be derived from an IPv4 address regardless of the
network protocol(s) a particular BGP-4 instance is configured to network protocol(s) a particular BGP-4 instance is configured to
convey at a given moment. convey at a given moment.
The use of TCP over IPv6 as transport protocol for IPv6 reachability The use of TCP over IPv6 as transport protocol for IPv6 reachability
information also has the advantage of providing explicit confirmation information also has the advantage of providing explicit confirmation
of IPv6 network reachability between two peers. of IPv6 network reachability between two peers.
6. Capability Negotiation 6. Security Considerations
BGP-4 speakers using Multiprotocol Extensions to carry IPv6 NLRI
information should use the Capabilities Optional Parameter as defined
in [BGP-CAP]. The MP_EXT Capability Code, as defined in [CAP-MP], is
used to negotiate the (AFI, SAFI) pairs available on a particular
connection.
7. Security Considerations
Routing protocols such as the one discussed in this document provide
control information for the network infrastructure and are, as such,
sensible in security terms.
The authors recommend that authentication mechanisms such has IPSEC The extensions defined in this document allow BGP to propagate
AH are used to guaranty the integrity and origin of the information. reachability information about IPv6 routes. As such, no new security
issues are raised beyond those that already exist in BGP-4 and its
use with IPv4.
8. Acknowledgments 7. Acknowledgments
This document derives from the work on BGP-4 Multiprotocol Extensions This document derives from the work on BGP-4 Multiprotocol Extensions
by Tony Bates, Ravi Chandra, Dave Katz and Yakov Rekhter. by Tony Bates, Ravi Chandra, Dave Katz and Yakov Rekhter.
9. References 8. References
[ADDR-ARCH] "IP Version 6 Addressing Architecture", [ADDR-ARCH] "IP Version 6 Addressing Architecture",
S. Deering and R. Hiden, Internet Draft, November 1997. S. Deering and R. Hiden, Internet Draft, January 1998.
<draft-ietf-ipngwg-addr-arch-v2-04.txt> <draft-ietf-ipngwg-addr-arch-v2-06.txt>
[BGP-4] "A Border Gateway Protocol 4 (BGP-4)", [BGP-4] "A Border Gateway Protocol 4 (BGP-4)",
Y. Rekhter and T. Li, RFC1771, March 1995. Y. Rekhter and T. Li, RFC1771, March 1995.
[BGP-CAP] "Capabilities Negotiation with BGP-4",
R. Chandra and J. Scudder, Internet Draft, August 1997.
<draft-ietf-idr-bgp4-cap-neg-00.txt>
[BGP-MP] "Multiprotocol Extensions for BGP-4", [BGP-MP] "Multiprotocol Extensions for BGP-4",
T. Bates, R. Chandra, D. Katz, and Y. Rekhter, T. Bates, R. Chandra, D. Katz, and Y. Rekhter,
Internet Draft, September 1997. Internet Draft, January 1998.
<draft-ietf-idr-bgp4-multiprotocol-01.txt> <draft-ietf-idr-bgp4-multiprotocol-02.txt>
[CAP-MP] "BGP-4 Capabilities Negotiation for BGP Multiprotocol
Extensions", P. Marques, November 1997.
<draft-marques-bgp4-cap-mp-00.txt>
[IPv6] "Internet Protocol, Version 6 (IPv6) Specification", [IPv6] "Internet Protocol, Version 6 (IPv6) Specification",
S. Deering and R. Hiden, RFC1883, December 1995. S. Deering and R. Hiden, RFC1883, December 1995.
[ND] "Neighbor Discovery for IP Version 6 (IPv6)", [ND] "Neighbor Discovery for IP Version 6 (IPv6)",
T. Narten, E. Nordmark and W. Simpson, T. Narten, E. Nordmark and W. Simpson,
Internet Draft, July 1997. Internet Draft, November 1997.
<draft-ietf-ipngwg-discovery-v2-00.txt> <draft-ietf-ipngwg-discovery-v2-01.txt>
[RIP] "RIPng for IPv6", [RIP] "RIPng for IPv6",
G. Malkin and R. Minnear, RFC 2080, January 1997. G. Malkin and R. Minnear, RFC 2080, January 1997.
10. Author Information 9. Author Information
Pedro R. Marques Pedro R. Marques
cisco Systems, Inc. cisco Systems, Inc.
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
email: roque@cisco.com email: roque@cisco.com
Francis Dupont Francis Dupont
INRIA Rocquencourt INRIA Rocquencourt
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/