As per Relevance of the word standards, we have this rfc below:
Network Working Group P.
Request for Comments: 2545 cisco Systems, Inc
Category: Standards Track F.
March 1999
Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two
attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used
announce and withdraw the announcement of reachability information
This document defines how compliant systems should make use of
attributes for the purpose of conveying IPv6 routing information
1.
The BGP-4 protocol [BGP-4] in particular, and path vector
protocols in general, are mostly independent of the
Address Family for which the protocol is being used
IPv6 falls under the generic category of protocols for which BGP-4
suitable and, unless stated otherwise in this document, the BGP-4
procedures to apply when using BGP-4 to carry IPv6
information are those defined in [BGP-4] and in subsequent
that extend or update the BGP-4 specification
In terms of routing information, the most significant
between IPv6 and IPv4 (for which BGP was originally designed) is
fact that IPv6 introduces scoped unicast addresses and
particular situations when a particular address scope must be used
This document concerns itself essentially with the necessary rules
accommodate IPv6 address scope requirements
Marques & Dupont Standards Track [Page 1]
RFC 2545 BGP-4 Multiprotocol Extensions for IPv6 IDR March 1999
2. IPv6 Address
IPv6 defines 3 unicast address scopes [ADDR-ARCH]: global, site-
and link-local. Site-local addresses are non-link-local address
are valid within the scope of a "site" and cannot be exported
it. As this document makes no assumption on the characteristics of
particular routing realm where BGP-4 is used, it makes no
between global and site-local addresses and refers to both
"global" or "non-link-local". Network administrators must
respect address scope restrictions and should be aware that
concepts of a BGP-4 routing domain and "site" are orthogonal
and that they may or may not coincide in a given situation
Companion IPv6 specifications further define that only link-
address can be used when generating ICMP Redirect Messages [ND]
as next hop addresses in some routing protocols (eg. RIPng [RIP]).
This restrictions does imply that an IPv6 router must have a link
local next hop address for all directly connected routes (routes
which the given router and the next hop router share a common
prefix).
Link-local addresses are not, however, well suited to be used as
hop attributes in BGP-4 given the rules defined for this attribute
the protocol specification [BGP-4].
For the above reasons, when BGP-4 is used to convey IPv6
information it is sometimes necessary to announce a next
attribute that consists of a global address and a link-local address
The following section describes the rules that should be
when constructing the Network Address of Next Hop field of
MP_REACH_NLRI attribute
3. Constructing the Next Hop
A BGP speaker shall advertise to its peer in the Network Address
Next Hop field the global IPv6 address of the next hop,
followed by the link-local IPv6 address of the next hop
The value of the Length of Next Hop Network Address field on
MP_REACH_NLRI attribute shall be set to 16, when only a
address is present, or 32 if a link-local address is also included
the Next Hop field
The link-local address shall be included in the Next Hop field if
only if the BGP speaker shares a common subnet with the
identified by the global IPv6 address carried in the Network
of Next Hop field and the peer the route is being advertised to
Marques & Dupont Standards Track [Page 2]
RFC 2545 BGP-4 Multiprotocol Extensions for IPv6 IDR March 1999
In all other cases a BGP speaker shall advertise to its peer in
Network Address field only the global IPv6 address of the next
(the value of the Length of Network Address of Next Hop field
be set to 16).
As a consequence, a BGP speaker that advertises a route to
internal peer may modify the Network Address of Next Hop field
removing the link-local IPv6 address of the next hop
4.
TCP connections, on top of which BGP-4 messages are exchanged, can
established either over IPv4 or IPv6. While BGP-4 itself
independent of the particular transport used it derives
configuration information from the address used to establish
peering session. This information (the network address of a peer)
taken in account in the route dissemination procedure. Thus,
using TCP over IPv4 as a transport for IPv6 reachability information
additional explicit configuration of the peer's network address
required
Note that the information referred above is distinct from the
Identifier used in the BGP-4 tie breaking procedure. The
Identifier is a 32 bit unsigned integer exchanged between two
at session establishment time, within an OPEN message. This is
system wide value determined at startup which must be unique in
network and should be derived from an IPv4 address regardless of
network protocol(s) a particular BGP-4 instance is configured
convey at a given moment
The use of TCP over IPv6 as transport protocol for IPv6
information also has the advantage of providing explicit
of IPv6 network reachability between two peers
5. Security
The extensions defined in this document allow BGP to
reachability information about IPv6 routes. As such, no new
issues are raised beyond those that already exist in BGP-4 and
use with IPv4.
6.
This document derives from the work on BGP-4 Multiprotocol
by Tony Bates, Ravi Chandra, Dave Katz and Yakov Rekhter
Marques & Dupont Standards Track [Page 3]
RFC 2545 BGP-4 Multiprotocol Extensions for IPv6 IDR March 1999
7.
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6
Architecture", RFC 2373, July 1998.
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter
"Multiprotocol Extensions for BGP-4", RFC 2283,
1998.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[ND] Narten, T., Nordmark, E. and W. Simpson, "
Discovery for IP Version 6 (IPv6)", RFC 2461,
1998.
[RIP] Malkin, G. and R. Minnear, "RIPng for IPv6",
RFC 2080, January 1997.
8. Author
Pedro R.
cisco Systems, Inc
170 W. Tasman Dr
San Jose, CA 95134
Phone: +1 408 527-5202
Fax: +1 408 526-4952
EMail: roque@cisco.
Francis
GIE
INRIA
Domaine de
BP 105
78153 Le Chesnay
Phone: +33 1 39 63 52 13
Fax: +33 1 39 63 58 66
EMail: Francis.Dupont@inria.
Marques & Dupont Standards Track [Page 4]
RFC 2545 BGP-4 Multiprotocol Extensions for IPv6 IDR March 1999
9. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Marques & Dupont Standards Track [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
