< draft-ietf-mpls-ldp-ipv6-14.txt   draft-ietf-mpls-ldp-ipv6-15.txt >
MPLS Working Group Rajiv Asati MPLS Working Group Rajiv Asati
Internet Draft Carlos Pignataro Internet Draft Carlos Pignataro
Updates: 5036, 6720 (if approved) Kamran Raza Updates: 5036, 6720 (if approved) Kamran Raza
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: April 2015 Expires: July 2015
Vishwas Manral Vishwas Manral
Hewlett-Packard, Inc Hewlett-Packard, Inc
Rajiv Papneja Rajiv Papneja
Huawei Huawei
October 2, 2014 January 11, 2015
Updates to LDP for IPv6 Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-14 draft-ietf-mpls-ldp-ipv6-15
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 Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 2, 2015. This Internet-Draft will expire on July 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3. LSP Mapping....................................................7 3. LSP Mapping....................................................7
4. LDP Identifiers................................................7 4. LDP Identifiers................................................7
5. Neighbor Discovery.............................................8 5. Neighbor Discovery.............................................8
5.1. Basic Discovery Mechanism.................................8 5.1. Basic Discovery Mechanism.................................8
5.1.1. Maintaining Hello Adjacencies........................9 5.1.1. Maintaining Hello Adjacencies........................9
5.2. Extended Discovery Mechanism..............................9 5.2. Extended Discovery Mechanism..............................9
6. LDP Session Establishment and Maintenance......................9 6. LDP Session Establishment and Maintenance......................9
6.1. Transport connection establishment.......................10 6.1. Transport connection establishment.......................10
6.1.1. Determining Transport connection Roles..............11 6.1.1. Determining Transport connection Roles..............11
6.2. LDP Sessions Maintenance.................................14 6.2. LDP Sessions Maintenance.................................14
7. Binding Distribution..........................................14 7. Address Distribution..........................................15
7.1. Address Distribution.....................................15 8. Label Distribution............................................16
7.2. Label Distribution.......................................15 9. LDP Identifiers and Duplicate Next Hop Addresses..............17
10. LDP TTL Security.............................................18
8. LDP Identifiers and Duplicate Next Hop Addresses..............16 11. IANA Considerations..........................................18
9. LDP TTL Security..............................................17 12. Security Considerations......................................18
10. IANA Considerations..........................................18 13. Acknowledgments..............................................19
11. Security Considerations......................................18 14. Additional Contributors......................................19
12. Acknowledgments..............................................19 15. References...................................................21
13. Additional Contributors......................................19 15.1. Normative References....................................21
14. References...................................................20 15.2. Informative References..................................21
14.1. Normative References....................................20 Appendix A.......................................................23
14.2. Informative References..................................20 A.1. LDPv6 and LDPv4 Interoperability Safety Net..............23
Appendix A.......................................................22 A.2. Accommodating Non-RFC5036 compliant implementations......23
A.1. LDPv6 and LDPv4 Interoperability Safety Net..............22 A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP...........24
A.2. Accommodating Non-RFC5036-compliant implementations......22 A.4. Why 32-bit value even for IPv6 LDP Router ID.............24
A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP...........23 Author's Addresses...............................................25
A.4. Why 32-bit value even for IPv6 LDP Router ID.............23
Author's Addresses...............................................24
1. Introduction 1. Introduction
The LDP [RFC5036] specification defines procedures and messages for The LDP [RFC5036] specification defines procedures and messages for
exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g. exchanging FEC-label bindings over either IPv4 or IPv6 or both (e.g.
Dual-stack) networks. Dual-stack) networks.
However, RFC5036 specification has the following deficiency (or However, RFC5036 specification has the following deficiency (or
lacks details) in regards to IPv6 usage (with or without IPv4): lacks details) in regards to IPv6 usage (with or without IPv4):
skipping to change at page 11, line 5 skipping to change at page 11, line 5
4. An LSR MUST use a global unicast IPv6 address in IPv6 transport 4. An LSR MUST use a global unicast IPv6 address in IPv6 transport
address optional object of outgoing targeted Hellos, and check address optional object of outgoing targeted Hellos, and check
for the same in incoming targeted hellos (i.e. MUST discard the for the same in incoming targeted hellos (i.e. MUST discard the
targeted hello, if it failed the check). targeted hello, if it failed the check).
5. An LSR MUST prefer using a global unicast IPv6 address in IPv6 5. An LSR MUST prefer using a global unicast IPv6 address in IPv6
transport address optional object of outgoing Link Hellos, if transport address optional object of outgoing Link Hellos, if
it had to choose between global unicast IPv6 address and it had to choose between global unicast IPv6 address and
unique-local or link-local IPv6 address. unique-local or link-local IPv6 address.
6. A Dual-stack LSR MUST NOT initiate (or accept the request for) 6. A Single-stack LSR MUST establish LDPoIPv4 or LDPoIPv6 session
with a remote LSR as per the enabled address-family.
7. A Dual-stack LSR MUST NOT initiate (or accept the request for)
a TCP connection for a new LDP session with a remote LSR, if a TCP connection for a new LDP session with a remote LSR, if
they already have an LDPoIPv4 or LDPoIPv6 session (for the same they already have an LDPoIPv4 or LDPoIPv6 session (for the same
LDP Identifier) established. LDP Identifier) established.
This means that only one transport connection is established This means that only one transport connection is established
regardless of IPv6 or/and IPv4 Hello adjacencies presence regardless of IPv6 or/and IPv4 Hello adjacencies presence
between two LSRs. between two LSRs.
7. A Dual-stack LSR MUST prefer establishing LDPoIPv6 session with 8. A Dual-stack LSR MUST prefer establishing LDPoIPv6 session with
a remote LSR by following the 'transport connection role' a remote LSR by following the 'transport connection role'
determination logic in section 6.1.1. determination logic in section 6.1.1.
8. A Single-stack LSR MUST establish LDPoIPv4 or LDPoIPv6 session
with a remote LSR as per the enabled address-family.
6.1.1. Determining Transport connection Roles 6.1.1. Determining Transport connection Roles
Section 2.5.2 of [RFC5036] specifies the rules for determining Section 2.5.2 of [RFC5036] specifies the rules for determining
active/passive roles in setting up TCP connection. These rules are active/passive roles in setting up TCP connection. These rules are
clear for a Single-stack LDP, but not for a Dual-stack LDP, in which clear for a Single-stack LDP, but not for a Dual-stack LDP, in which
an LSR may assume different roles for different address families, an LSR may assume different roles for different address families,
causing LDP session to not get established. causing LDP session to not get established.
To ensure deterministic transport connection (active/passive) role To ensure deterministic transport connection (active/passive) role
in case of Dual-stack LDP, this document specifies that the Dual- in case of Dual-stack LDP, this document specifies that the Dual-
skipping to change at page 12, line 15 skipping to change at page 12, line 15
U and F bits: 1 and 0 (as specified by RFC5036) U and F bits: 1 and 0 (as specified by RFC5036)
Dual-stack capability: TLV code point (to be assigned by IANA). Dual-stack capability: TLV code point (to be assigned by IANA).
TR, Transport Connection Preference. TR, Transport Connection Preference.
This document defines the following 2 values: This document defines the following 2 values:
0100: LDPoIPv4 connection 0100: LDPoIPv4 connection
0110: LDPoIPv6 connection 0110: LDPoIPv6 connection (default)
Reserved Reserved
This field is reserved. It MUST be set to zero on This field is reserved. It MUST be set to zero on
transmission and ignored on receipt. transmission and ignored on receipt.
A Dual-stack LSR MUST include "Dual-stack capability" TLV in all of A Dual-stack LSR (i.e. LSR supporting Dual-stack LDP for a peer)
its LDP Hellos, and MUST set the "TR" field to announce its MUST include "Dual-stack capability" TLV in all of its LDP Hellos,
preference for either LDPoIPv4 or LDPoIPv6 transport connection. The and MUST set the "TR" field to announce its preference for either
default preference is LDPoIPv6. LDPoIPv4 or LDPoIPv6 transport connection for that peer. The default
preference is LDPoIPv6.
Upon receiving the hello messages from the neighbor, a Dual-stack A Dual-stack LSR MUST always check for the presence of "Dual-stack
LSR MUST check for the presence of "Dual-stack capability" TLV and capability" TLV in the received hello messages, and take appropriate
take appropriate actions as follows: actions as follows:
1. If "Dual-stack capability" TLV is present and remote preference 1. If "Dual-stack capability" TLV is present and remote preference
does not match with the local preference, then the LSR MUST does not match with the local preference (or does not get
discard the hello message and log an error. recognized), then the LSR MUST discard the hello message and
log an error.
If LDP session was already in place, then LSR MUST send a fatal If LDP session was already in place, then LSR MUST send a fatal
Notification message with status code [Transport Connection Notification message with status code [Transport Connection
mismatch, IANA allocation TBD] and reset the session. mismatch, IANA allocation TBD] and reset the session.
2. If "Dual-stack capability" TLV is present, and remote 2. If "Dual-stack capability" TLV is present, and remote
preference matches with the local preference, then: preference matches with the local preference, then:
a) If TR=0100 (LDPoIPv4), then determine the active/passive a) If TR=0100 (LDPoIPv4), then determine the active/passive
roles for TCP connection using IPv4 transport address as roles for TCP connection using IPv4 transport address as
skipping to change at page 13, line 30 skipping to change at page 13, line 33
However, if IPv4 hellos are also received at any time from However, if IPv4 hellos are also received at any time from
that neighbor, then the neighbor is deemed as a non- that neighbor, then the neighbor is deemed as a non-
compliant Dual-stack LSR (similar to that of 3c below), compliant Dual-stack LSR (similar to that of 3c below),
resulting in any established LDPoIPv6 session being reset resulting in any established LDPoIPv6 session being reset
and a fatal Notification message being sent (with status and a fatal Notification message being sent (with status
code of 'Dual-Stack Non-Compliance', IANA allocation TBD). code of 'Dual-Stack Non-Compliance', IANA allocation TBD).
c) Both IPv4 and IPv6 hellos are received, then the neighbor c) Both IPv4 and IPv6 hellos are received, then the neighbor
is deemed as a non-compliant Dual-stack neighbor, and is is deemed as a non-compliant Dual-stack neighbor, and is
not allowed to have any LDP session. not allowed to have any LDP session. A Notification
message should be sent (with status code of 'Dual-Stack
Non-Compliance', IANA allocation TBD).
An LSR MUST convey the same transport connection preference ("TR" A Dual-stack LSR MUST convey the same transport connection
field value) in all (link and targeted) Hellos that advertise the preference ("TR" field value) in all (link and targeted) Hellos that
same label space to the same peer and/or on same interface. This advertise the same label space to the same peer and/or on same
ensures that two LSRs linked by multiple Hello adjacencies using the interface. This ensures that two LSRs linked by multiple Hello
same label spaces play the same connection establishment role for adjacencies using the same label spaces play the same connection
each adjacency. establishment role for each adjacency.
A Dual-stack LSR MUST follow section 2.5.5 of RFC5036 and check for
matching Hello messages from the peer (either all Hellos also
include the Dual-stack capability (with same TR value) or none do).
A Single-stack LSR do not need to use the Dual-stack capability in
hello messages and SHOULD ignore this capability, if received.
An implementation may provide an option to favor one AFI (IPv4, say) An implementation may provide an option to favor one AFI (IPv4, say)
over another AFI (IPv6, say) for the TCP transport connection, so as over another AFI (IPv6, say) for the TCP transport connection, so as
to use the favored IP version for the LDP session, and force to use the favored IP version for the LDP session, and force
deterministic active/passive roles. deterministic active/passive roles.
Note - An alternative to this new Capability TLV could be a new Flag Note - An alternative to this new Capability TLV could be a new Flag
value in LDP Hello message, however, it will get used even in a value in LDP Hello message, however, it will get used even in a
Single-stack IPv6 LDP networks and linger on forever, even though Single-stack IPv6 LDP networks and linger on forever, even though
Dual-stack will not. Hence, this alternative is discarded. Dual-stack will not. Hence, this alternative is discarded.
skipping to change at page 14, line 42 skipping to change at page 15, line 12
session as per the procedures described in section 6.1 of this session as per the procedures described in section 6.1 of this
document. document.
7. Binding Distribution 7. Binding Distribution
LSRs by definition can be enabled for Dual-stack LDP globally and/or LSRs by definition can be enabled for Dual-stack LDP globally and/or
per peer so as to exchange the address and label bindings for both per peer so as to exchange the address and label bindings for both
IPv4 and IPv6 address-families, independent of LDPoIPv4 or LDPoIPV6 IPv4 and IPv6 address-families, independent of LDPoIPv4 or LDPoIPV6
session between them. session between them.
However, there might be some legacy LSRs that are fully compliant However, there might be some legacy LSRs that are fully RFC 5036
with RFC 5036 for IPv4, but non-compliant for IPv6 (say, section compliant for IPv4, but non-compliant for IPv6 (say, section 3.5.5.1
3.5.5.1 of RFC 5036), causing them to reset the session upon of RFC 5036), causing them to reset the session upon receiving IPv6
receiving IPv6 address bindings or IPv6 FEC (Prefix) label bindings. address bindings or IPv6 FEC (Prefix) label bindings from a peer
This is somewhat undesirable, as clarified further Appendix A.1 and compliant with this document. This is somewhat undesirable, as
A.2. clarified further Appendix A.1 and A.2.
To help maintain backward compatibility (accommodate IPv4-only LDP To help maintain backward compatibility (i.e. accommodate IPv4-only
implementations that may not be compliant with RFC 5036 section LDP implementations that may not be compliant with RFC 5036 section
3.5.5.1), this specification requires that an LSR MUST NOT send any 3.5.5.1 ), this specification requires that an LSR MUST NOT send
IPv6 bindings to a peer if peer has been determined as a legacy LSR. any IPv6 bindings to a peer if peer has been determined as a legacy
LSR.
The 'Dual-stack capability' TLV, which is defined in section 6.1.1, The 'Dual-stack capability' TLV, which is defined in section 6.1.1,
is also used to determine if a peer is a legacy (IPv4-only Single- is also used to determine if a peer is a legacy (IPv4-only Single-
stack) LSR or not. stack) LSR or not.
7.1. Address Distribution 7.1. Address Distribution
An LSR MUST NOT advertise (via ADDRESS message) any IPv4-mapped IPv6 An LSR MUST NOT advertise (via ADDRESS message) any IPv4-mapped IPv6
addresses (defined in section 2.5.5.2 of [RFC4291]), and ignore such addresses (defined in section 2.5.5.2 of [RFC4291]), and ignore such
addresses, if ever received. Please see Appendix A.3. addresses, if ever received. Please see Appendix A.3.
If an LSR is enabled with Single-stack LDP for any peer, then it
MUST advertise (via ADDRESS message) its local IP addresses as per
the enabled address family to that peer, and process received
Address messages containing IP addresses as per the enabled address
family from that peer.
If an LSR is enabled with Dual-stack LDP for a peer and If an LSR is enabled with Dual-stack LDP for a peer and
1. Is NOT able to find the Dual-stack capability TLV in the 1. Is NOT able to find the Dual-stack capability TLV in the
incoming IPv4 LDP hello messages from that peer, then the LSR incoming IPv4 LDP hello messages from that peer, then the LSR
MUST NOT advertise its local IPv6 Addresses to the peer. MUST NOT advertise its local IPv6 Addresses to the peer.
2. Is able to find the Dual-stack capability in the incoming IPv4 2. Is able to find the Dual-stack capability in the incoming IPv4
(or IPv6) LDP Hello messages from that peer, then it MUST (or IPv6) LDP Hello messages from that peer, then it MUST
advertise (via ADDRESS message) its local IPv4 and IPv6 advertise (via ADDRESS message) its local IPv4 and IPv6
addresses to that peer. addresses to that peer.
3. Is NOT able to find the Dual-stack capability in the incoming 3. Is NOT able to find the Dual-stack capability in the incoming
IPv6 LDP Hello messages, then it MUST advertise (via ADDRESS IPv6 LDP Hello messages, then it MUST advertise (via ADDRESS
message) only its local IPv6 addresses to that peer. message) only its local IPv6 addresses to that peer.
The last point helps to maintain forward compatibility (no need This last point helps to maintain forward compatibility (no
to require this TLV in case of IPv6 Single-stack LDP). need to require this TLV in case of IPv6 Single-stack LDP).
If an LSR is enabled with Single-stack LDP for any peer, then it
MUST advertise (via ADDRESS message) its local IP addresses as per
the enabled address family, and accept received Address messages
containing IP addresses as per the enabled address family.
7.2. Label Distribution 7.2. Label Distribution
An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings An LSR MUST NOT allocate and MUST NOT advertise FEC-Label bindings
for link-local or IPv4-mapped IPv6 addresses (defined in section for link-local or IPv4-mapped IPv6 addresses (defined in section
2.5.5.2 of [RFC4291]), and ignore such bindings, if ever received. 2.5.5.2 of [RFC4291]), and ignore such bindings, if ever received.
Please see Appendix A.3. Please see Appendix A.3.
If an LSR enabled with Dual-stack LDP for a peer and If an LSR is enabled with Single-stack LDP for any peer, then it
MUST advertise (via Label Mapping message) FEC-Label bindings for
the enabled address family to that peer, and process received FEC-
Label bindings for the enabled address family from that peer.
If an LSR is enabled with Dual-stack LDP for a peer and
1. Is NOT able to find the Dual-stack capability TLV in the 1. Is NOT able to find the Dual-stack capability TLV in the
incoming IPv4 LDP hello messages from that peer, then the LSR incoming IPv4 LDP hello messages from that peer, then the LSR
MUST NOT advertise IPv6 FEC-label bindings to the peer. MUST NOT advertise IPv6 FEC-label bindings to the peer (even if
IP capability negotiation for IPv6 address family was done).
2. Is able to find the Dual-stack capability in the incoming IPv4 2. Is able to find the Dual-stack capability in the incoming IPv4
(or IPv6) LDP Hello messages from that peer, then it MUST (or IPv6) LDP Hello messages from that peer, then it MUST
advertise FEC-Label bindings for both IPv4 and IPv6 address advertise FEC-Label bindings for both IPv4 and IPv6 address
families to that peer. families to that peer.
3. Is NOT able to find the Dual-stack capability in the incoming 3. Is NOT able to find the Dual-stack capability in the incoming
IPv6 LDP Hello messages, then it MUST advertise FEC-Label IPv6 LDP Hello messages, then it MUST advertise FEC-Label
bindings for IPv6 address families to that peer. bindings for IPv6 address families to that peer.
The last point helps to maintain forward compatibility (no need This last point helps to maintain forward compatibility (no
to require this TLV for IPv6 Single-stack LDP). need to require this TLV for IPv6 Single-stack LDP).
If an LSR is enabled with Single-stack LDP for any peer, then it
MUST advertise (via ADDRESS message) FEC-Label bindings for the
enabled address family, and accept FEC-Label bindings for the
enabled address family.
An LSR MAY further constrain the advertisement of FEC-label bindings An LSR MAY further constrain the advertisement of FEC-label bindings
for a particular address family by negotiating the IP Capability for for a particular address family by negotiating the IP Capability for
a given address family, as specified in [IPPWCap] document. This a given address family, as specified in [IPPWCap] document. This
allows an LSR pair to neither advertise nor receive the undesired allows an LSR pair to neither advertise nor receive the undesired
FEC-label bindings on a per address family basis to a peer. FEC-label bindings on a per address family basis to a peer.
If an LSR is configured to change an interface or peer from Single- If an LSR is configured to change an interface or peer from Single-
stack LDP to Dual-stack LDP, then an LSR SHOULD use Typed Wildcard stack LDP to Dual-stack LDP, then an LSR SHOULD use Typed Wildcard
FEC procedures [RFC5918] to request the label bindings for the FEC procedures [RFC5918] to request the label bindings for the
skipping to change at page 18, line 11 skipping to change at page 18, line 29
LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255, LDP Link Hello packets MUST have their IPv6 Hop Limit set to 255,
and be checked for the same upon receipt before any further and be checked for the same upon receipt before any further
processing, as per section 3 of [RFC5082]. processing, as per section 3 of [RFC5082].
10. IANA Considerations 10. IANA Considerations
This document defines a new optional parameter for the LDP Hello This document defines a new optional parameter for the LDP Hello
Message and two new status codes for the LDP Notification Message. Message and two new status codes for the LDP Notification Message.
The 'Dual-Stack capability' parameter requires a code point from the The 'Dual-Stack capability' parameter requires a code point from the
TLV Type Name Space. [RFC5036] partitions the TLV Type Name Space TLV Type Name Space. IANA is requested to allocated a code point
into 3 regions: IETF Consensus region, First Come First Served from the IETF Consensus range 0x0700-0x07ff for the 'Dual-Stack
region, and Private Use region. The authors recommend that a code
point from the IETF Consensus range be assigned to the 'Dual-Stack
capability' TLV. capability' TLV.
The 'Transport Connection Mismatch' status code requires a code The 'Transport Connection Mismatch' status code requires a code
point from the Status Code Name Space. [RFC5036] partitions the point from the Status Code Name Space. IANA is requested to allocate
Status Code Name Space into 3 regions: IETF Consensus region, First a code point from the IETF Consensus range and mark the E bit column
Come First Served region, and Private Use region. The authors with a '1'.
recommend that a code point from the IETF Consensus range be
assigned to the 'Transport Connection Mismatch ' status code.
The 'Dual-Stack Non-Compliance' status code requires a code point The 'Dual-Stack Non-Compliance' status code requires a code point
from the Status Code Name Space. [RFC5036] partitions the Status from the Status Code Name Space. IANA is requested to allocate a
Code Name Space into 3 regions: IETF Consensus region, First Come code point from the IETF Consensus range and mark the E bit column
First Served region, and Private Use region. The authors recommend with a '1'.
that a code point from the IETF Consensus range be assigned to the
'Dual-Stack Non-Compliance' status code.
11. Security Considerations 11. Security Considerations
The extensions defined in this document only clarify the behavior of The extensions defined in this document only clarify the behavior of
LDP, they do not define any new protocol procedures. Hence, this LDP, they do not define any new protocol procedures. Hence, this
document does not add any new security issues to LDP. document does not add any new security issues to LDP.
While the security issues relevant for the [RFC5036] are relevant While the security issues relevant for the [RFC5036] are relevant
for this document as well, this document reduces the chances of off- for this document as well, this document reduces the chances of off-
link attacks when using IPv6 transport connection by including the link attacks when using IPv6 transport connection by including the
skipping to change at page 20, line 43 skipping to change at page 21, line 43
Authentication Header (AH)", RFC 7321, April 2007. Authentication Header (AH)", RFC 7321, April 2007.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS [RFC4798] De Clercq, et al., "Connecting IPv6 Islands over IPv4 MPLS
Using IPv6 Provider Edge Routers (6PE)", RFC 4798, Using IPv6 Provider Edge Routers (6PE)", RFC 4798,
February 2007. February 2007.
[IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp- [IPPWCap] Raza, K., "LDP IP and PW Capability", draft-ietf-mpls-ldp-
ip-pw-capability, June 2011. ip-pw-capability, October 2014.
[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.
[RFC6286] E. Chen, and J. Yuan, "Autonomous-System-Wide Unique BGP [RFC6286] E. Chen, and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, June 2011. Identifier for BGP-4", RFC 6286, June 2011.
[RFC6720] R. Asati, and C. Pignataro, "The Generalized TTL Security [RFC6720] R. Asati, and C. Pignataro, "The Generalized TTL Security
Mechanism (GTSM) for the Label Distribution Protocol Mechanism (GTSM) for the Label Distribution Protocol
(LDP)", RFC 6720, August 2012. (LDP)", RFC 6720, August 2012.
 End of changes. 26 change blocks. 
87 lines changed or deleted 93 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/