< draft-ietf-mpls-ldp-ipv6-15.txt   draft-ietf-mpls-ldp-ipv6-16.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: July 2015 Expires: August 2015
Vishwas Manral Vishwas Manral
Hewlett-Packard, Inc Hewlett-Packard, Inc
Rajiv Papneja Rajiv Papneja
Huawei Huawei
January 11, 2015 February 11, 2015
Updates to LDP for IPv6 Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-15 draft-ietf-mpls-ldp-ipv6-16
Abstract
The Label Distribution Protocol (LDP) specification defines
procedures to exchange label bindings over either IPv4, or IPv6 or
both networks. This document corrects and clarifies the LDP behavior
when IPv6 network is used (with or without IPv4). This document
updates RFC 5036 and RFC 6720.
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 July 11, 2015. This Internet-Draft will expire on August 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 19 skipping to change at page 2, line 29
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
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.
Abstract
The Label Distribution Protocol (LDP) specification defines
procedures to exchange label bindings over either IPv4, or IPv6 or
both networks. This document corrects and clarifies the LDP behavior
when IPv6 network is used (with or without IPv4). This document
updates RFC 5036 and RFC 6720.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
1.1. Topology Scenarios for Dual-stack Environment.............4 1.1. Topology Scenarios for Dual-stack Environment.............4
1.2. Single-hop vs. Multi-hop LDP Peering......................5 1.2. Single-hop vs. Multi-hop LDP Peering......................5
2. Specification Language.........................................6 2. Specification Language.........................................6
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. Address Distribution..........................................15 7. Binding Distribution..........................................14
8. Label Distribution............................................16 7.1. Address Distribution.....................................15
9. LDP Identifiers and Duplicate Next Hop Addresses..............17 7.2. Label Distribution.......................................16
10. LDP TTL Security.............................................18
11. IANA Considerations..........................................18 8. LDP Identifiers and Duplicate Next Hop Addresses..............17
12. Security Considerations......................................18 9. LDP TTL Security..............................................17
13. Acknowledgments..............................................19 10. IANA Considerations..........................................18
14. Additional Contributors......................................19 11. Security Considerations......................................18
15. References...................................................21 12. Acknowledgments..............................................19
15.1. Normative References....................................21 13. Additional Contributors......................................19
15.2. Informative References..................................21 14. References...................................................21
14.1. Normative References....................................21
14.2. Informative References..................................21
Appendix A.......................................................23 Appendix A.......................................................23
A.1. LDPv6 and LDPv4 Interoperability Safety Net..............23 A.1. LDPv6 and LDPv4 Interoperability Safety Net..............23
A.2. Accommodating Non-RFC5036 compliant implementations......23 A.2. Accommodating Non-RFC5036-compliant implementations......23
A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP...........24 A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP...........24
A.4. Why 32-bit value even for IPv6 LDP Router ID.............24 A.4. Why 32-bit value even for IPv6 LDP Router ID.............24
Author's Addresses...............................................25 Author's Addresses...............................................25
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.
skipping to change at page 4, line 14 skipping to change at page 4, line 18
7) Next Hop Address Resolution: No rule for accommodating the usage 7) Next Hop Address Resolution: No rule for accommodating the usage
of duplicate link-local IPv6 addresses of duplicate link-local IPv6 addresses
8) LDP TTL Security: No rule for built-in Generalized TTL Security 8) LDP TTL Security: No rule for built-in Generalized TTL Security
Mechanism (GTSM) in LDP with IPv6 (this is a deficiency in Mechanism (GTSM) in LDP with IPv6 (this is a deficiency in
RFC6720) RFC6720)
This document addresses the above deficiencies by specifying the This document addresses the above deficiencies by specifying the
desired behavior/rules/details for using LDP in IPv6 enabled desired behavior/rules/details for using LDP in IPv6 enabled
networks (IPv6-only or Dual-stack networks). networks (IPv6-only or Dual-stack networks). This document closes
the IPv6 MPLS gap discussed in Sections 3.2.1, 3.2.2, and 3.3.1.1 of
[RFC7439].
Note that this document updates RFC5036 and RFC6720. Note that this document updates RFC5036 and RFC6720.
1.1. Topology Scenarios for Dual-stack Environment 1.1. Topology Scenarios for Dual-stack Environment
Two LSRs may involve basic and/or extended LDP discovery in IPv6 Two LSRs may involve basic and/or extended LDP discovery in IPv6
and/or IPv4 address-families in various topology scenarios. and/or IPv4 address-families in various topology scenarios.
This document addresses the following 3 topology scenarios in which This document addresses the following 3 topology scenarios in which
the LSRs may be connected via one or more Dual-stack LDP enabled the LSRs may be connected via one or more Dual-stack LDP enabled
skipping to change at page 7, line 18 skipping to change at page 7, line 18
particular packet to a particular LSP using three rules. Quoting the particular packet to a particular LSP using three rules. Quoting the
3rd rule from RFC5036: 3rd rule from RFC5036:
"If it is known that a packet must traverse a particular egress "If it is known that a packet must traverse a particular egress
router, and there is an LSP that has an Address Prefix FEC element router, and there is an LSP that has an Address Prefix FEC element
that is a /32 address of that router, then the packet is mapped to that is a /32 address of that router, then the packet is mapped to
that LSP." that LSP."
This rule is correct for IPv4, but not for IPv6, since an IPv6 This rule is correct for IPv4, but not for IPv6, since an IPv6
router may even have a /64 or /96 or /128 (or whatever prefix router may even have a /64 or /96 or /128 (or whatever prefix
length) address. Hence, it is reasonable to say IPv4 or IPv6 address length) address. Hence, that rule is updated to use IPv4 or IPv6
instead of /32 or /128 addresses as shown below in the updated rule: address instead of /32 or /128 addresses as shown below:
"If it is known that a packet must traverse a particular egress "If it is known that a packet must traverse a particular egress
router, and there is an LSP that has an Address Prefix FEC element router, and there is an LSP that has an Address Prefix FEC element
that is an IPv4 or IPv6 address of that router, then the packet is that is an IPv4 or IPv6 address of that router, then the packet is
mapped to that LSP." mapped to that LSP."
4. LDP Identifiers 4. LDP Identifiers
In line with section 2.2.2 of [RFC5036], this document specifies the In line with section 2.2.2 of [RFC5036], this document specifies the
usage of 32-bit (unsigned non-zero integer) LSR Id on an IPv6 usage of 32-bit (unsigned non-zero integer) LSR Id on an IPv6
skipping to change at page 9, line 14 skipping to change at page 9, line 14
More importantly, if an interface is a Dual-stack LDP interface More importantly, if an interface is a Dual-stack LDP interface
(e.g. LDP enabled in both IPv6 and IPv4 address families), then the (e.g. LDP enabled in both IPv6 and IPv4 address families), then the
LSR MUST periodically transmit both IPv6 and IPv4 LDP Link Hellos LSR MUST periodically transmit both IPv6 and IPv4 LDP Link Hellos
(using the same LDP Identifier per section 4) on that interface and (using the same LDP Identifier per section 4) on that interface and
be able to receive them. This facilitates discovery of IPv6-only, be able to receive them. This facilitates discovery of IPv6-only,
IPv4-only and Dual-stack peers on the interface's subnet and ensures IPv4-only and Dual-stack peers on the interface's subnet and ensures
successful subsequent peering using the appropriate (address family) successful subsequent peering using the appropriate (address family)
transport on a multi-access or broadcast interface. transport on a multi-access or broadcast interface.
An implementation MUST transmit IPv6 LDP link Hellos before IPv4 LDP
Link Hellos on a Dual-stack interface, particularly during the
interface coming into service or configuration time.
5.1.1. Maintaining Hello Adjacencies 5.1.1. Maintaining Hello Adjacencies
In case of Dual-stack LDP enabled interface, the LSR SHOULD maintain In case of Dual-stack LDP enabled interface, the LSR SHOULD maintain
link Hello adjacencies for both IPv4 and IPv6 address families. This link Hello adjacencies for both IPv4 and IPv6 address families. This
document, however, allows an LSR to maintain Rx-side Link Hello document, however, allows an LSR to maintain Rx-side Link Hello
adjacency only for the address family that has been used for the adjacency only for the address family that has been used for the
establishment of the LDP session (whether LDPoIPv4 or LDPoIPv6 establishment of the LDP session (whether LDPoIPv4 or LDPoIPv6
session). session).
5.2. Extended Discovery Mechanism 5.2. Extended Discovery Mechanism
skipping to change at page 10, line 40 skipping to change at page 10, line 38
of the IP packet carrying the Hello message. An LSR SHOULD of the IP packet carrying the Hello message. An LSR SHOULD
accept only the first transport object for a given address accept only the first transport object for a given address
family in the received Hello message, and ignore the rest, if family in the received Hello message, and ignore the rest, if
the LSR receives more than one transport object for a given the LSR receives more than one transport object for a given
address family. address family.
3. An LSR MUST send separate Hello messages (each containing 3. An LSR MUST send separate Hello messages (each containing
either IPv4 or IPv6 transport address optional object) for each either IPv4 or IPv6 transport address optional object) for each
IP address family, if Dual-stack LDP was enabled. IP address family, if Dual-stack LDP was enabled.
An LSR MUST transmit IPv6 LDP link Hellos before IPv4 LDP Link
Hellos, if Dual-stack LDP was enabled on an interface,
particularly during the interface coming into service or
configuration time.
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.
skipping to change at page 11, line 31 skipping to change at page 11, line 31
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-
stack LSR convey its transport connection preference in every LDP stack LSR conveys its transport connection preference in every LDP
Hello message. This preference is encoded in a new TLV, named Dual- Hello message. This preference is encoded in a new TLV, named Dual-
stack capability TLV, as defined below: stack capability TLV, as defined below:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Dual-stack capability | Length | |1|0| Dual-stack capability | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TR | Reserved | MBZ | |TR | Reserved | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 12 skipping to change at page 13, line 12
roles for TCP connection by using IPv6 transport address roles for TCP connection by using IPv6 transport address
as defined in section 2.5.2 of RFC 5036. as defined in section 2.5.2 of RFC 5036.
3. If "Dual-stack capability" TLV is NOT present, and 3. If "Dual-stack capability" TLV is NOT present, and
a) Only IPv4 hellos are received, then the neighbor is deemed a) Only IPv4 hellos are received, then the neighbor is deemed
as a legacy IPv4-only LSR (supporting Single-stack LDP), as a legacy IPv4-only LSR (supporting Single-stack LDP),
hence, an LDPoIPv4 session SHOULD be established (similar hence, an LDPoIPv4 session SHOULD be established (similar
to that of 2a above). to that of 2a above).
However, if IPv6 hellos are also received at any time from However, if IPv6 hellos are also received at any time
that neighbor, then the neighbor is deemed as a non- during the life of session from that neighbor, then the
compliant Dual-stack LSR (similar to that of 3c below), neighbor is deemed as a non-compliant Dual-stack LSR
resulting in any established LDPoIPv4 session being reset (similar to that of 3c below), resulting in any
and a fatal Notification message being sent (with status established LDPoIPv4 session being reset and a fatal
code of 'Dual-Stack Non-Compliance', IANA allocation TBD). Notification message being sent (with status code of
'Dual-Stack Non-Compliance', IANA allocation TBD).
b) Only IPv6 hellos are received, then the neighbor is deemed b) Only IPv6 hellos are received, then the neighbor is deemed
as an IPv6-only LSR (supporting Single-stack LDP) and as an IPv6-only LSR (supporting Single-stack LDP) and
LDPoIPv6 session SHOULD be established (similar to that of LDPoIPv6 session SHOULD be established (similar to that of
2b above). 2b above).
However, if IPv4 hellos are also received at any time from However, if IPv4 hellos are also received at any time
that neighbor, then the neighbor is deemed as a non- during the life of session from that neighbor, then the
compliant Dual-stack LSR (similar to that of 3c below), neighbor is deemed as a non-compliant Dual-stack LSR
resulting in any established LDPoIPv6 session being reset (similar to that of 3c below), resulting in any
and a fatal Notification message being sent (with status established LDPoIPv6 session being reset and a fatal
code of 'Dual-Stack Non-Compliance', IANA allocation TBD). Notification message being sent (with status 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. A Notification not allowed to have any LDP session. A Notification
message should be sent (with status code of 'Dual-Stack message should be sent (with status code of 'Dual-Stack
Non-Compliance', IANA allocation TBD). Non-Compliance', IANA allocation TBD).
A Dual-stack LSR MUST convey the same transport connection A Dual-stack LSR MUST convey the same transport connection
preference ("TR" field value) in all (link and targeted) Hellos that preference ("TR" field value) in all (link and targeted) Hellos that
advertise the same label space to the same peer and/or on same advertise the same label space to the same peer and/or on same
skipping to change at page 14, line 31 skipping to change at page 14, line 31
regardless of number of Link or Targeted Hello adjacencies between regardless of number of Link or Targeted Hello adjacencies between
them, as described in section 6.1. This is independent of whether: them, as described in section 6.1. This is independent of whether:
- they are connected via a Dual-stack LDP enabled interface(s) or - they are connected via a Dual-stack LDP enabled interface(s) or
via two (or more) Single-stack LDP enabled interfaces; via two (or more) Single-stack LDP enabled interfaces;
- a Single-stack LDP enabled interface is converted to a Dual-stack - a Single-stack LDP enabled interface is converted to a Dual-stack
LDP enabled interface (e.g. figure 1) on either LSR; LDP enabled interface (e.g. figure 1) on either LSR;
- an additional Single-stack or Dual-stack LDP enabled interface is - an additional Single-stack or Dual-stack LDP enabled interface is
added or removed between two LSRs (e.g. figure 2). added or removed between two LSRs (e.g. figure 2).
The procedures defined in section 6.1 SHOULD result in setting up
the LDP session in preferred AFI only after the loss of an existing
LDP session (because of link failure, node failure, reboot etc.).
If the last hello adjacency for a given address family goes down If the last hello adjacency for a given address family goes down
(e.g. due to Dual-stack LDP enabled interfaces being converted into (e.g. due to Dual-stack LDP enabled interfaces being converted into
a Single-stack LDP enabled interfaces on one LSR etc.), and that a Single-stack LDP enabled interfaces on one LSR etc.), and that
address family is the same as the one used in the transport address family is the same as the one used in the transport
connection, then the transport connection (LDP session) MUST be connection, then the transport connection (LDP session) MUST be
reset. Otherwise, the LDP session MUST stay intact. reset. Otherwise, the LDP session MUST stay intact.
If the LDP session is torn down for whatever reason (LDP disabled If the LDP session is torn down for whatever reason (LDP disabled
for the corresponding transport, hello adjacency expiry, preference for the corresponding transport, hello adjacency expiry, preference
mismatch etc.), then the LSRs SHOULD initiate establishing a new LDP mismatch etc.), then the LSRs SHOULD initiate establishing a new LDP
skipping to change at page 15, line 21 skipping to change at page 15, line 16
However, there might be some legacy LSRs that are fully RFC 5036 However, there might be some legacy LSRs that are fully RFC 5036
compliant for IPv4, but non-compliant for IPv6 (say, section 3.5.5.1 compliant for IPv4, but non-compliant for IPv6 (say, section 3.5.5.1
of RFC 5036), causing them to reset the session upon receiving IPv6 of RFC 5036), causing them to reset the session upon receiving IPv6
address bindings or IPv6 FEC (Prefix) label bindings from a peer address bindings or IPv6 FEC (Prefix) label bindings from a peer
compliant with this document. This is somewhat undesirable, as compliant with this document. This is somewhat undesirable, as
clarified further Appendix A.1 and A.2. clarified further Appendix A.1 and A.2.
To help maintain backward compatibility (i.e. accommodate IPv4-only To help maintain backward compatibility (i.e. accommodate IPv4-only
LDP 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 3.5.5.1), this specification requires that an LSR MUST NOT send any
any IPv6 bindings to a peer if peer has been determined as a legacy IPv6 bindings to a peer if peer has been determined as a legacy LSR.
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.
skipping to change at page 18, line 15 skipping to change at page 18, line 7
9. LDP TTL Security 9. LDP TTL Security
This document recommends enabling Generalized TTL Security Mechanism This document recommends enabling Generalized TTL Security Mechanism
(GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport (GTSM) for LDP, as specified in [RFC6720], for the LDP/TCP transport
connection over IPv6 (i.e. LDPoIPv6). The GTSM inclusion is intended connection over IPv6 (i.e. LDPoIPv6). The GTSM inclusion is intended
to automatically protect IPv6 LDP peering session from off-link to automatically protect IPv6 LDP peering session from off-link
attacks. attacks.
[RFC6720] allows for the implementation to statically [RFC6720] allows for the implementation to statically
(configuration) and/or dynamically override the default behavior (configuration) and/or dynamically override the default behavior
(enable/disable GTSM) on a per-peer basis. Suffice to say that such (enable/disable GTSM) on a per-peer basis. Such a configuration an
an option could be set on either LSR (since GTSM negotiation would option could be set on either LSR (since GTSM negotiation would
ultimately disable GTSM between LSR and its peer(s)). ultimately disable GTSM between LSR and its peer(s)).
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.
skipping to change at page 23, line 5 skipping to change at page 22, line 16
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.
[RFC4038] M-K. Shin, Y-G. Hong, J. Hagino, P. Savola, and E. M. [RFC4038] M-K. Shin, Y-G. Hong, J. Hagino, P. Savola, and E. M.
Castro, "Application Aspects of IPv6 Transition", RFC Castro, "Application Aspects of IPv6 Transition", RFC
4038, March 2005. 4038, March 2005.
[RFC7439] W. George, and C. Pignataro, "Gap Analysis for Operating
IPv6-Only MPLS Networks", RFC 7439, January 2015.
Appendix A. Appendix A.
A.1. LDPv6 and LDPv4 Interoperability Safety Net A.1. LDPv6 and LDPv4 Interoperability Safety Net
It is not safe to assume that RFC5036 compliant implementations have It is not safe to assume that RFC5036 compliant implementations have
supported handling IPv6 address family (IPv6 FEC label) in Label supported handling IPv6 address family (IPv6 FEC label) in Label
Mapping message all along. Mapping message all along.
If a router upgraded with this specification advertised both IPv4 If a router upgraded with this specification advertised both IPv4
and IPv6 FECs in the same label mapping message, then an IPv4-only and IPv6 FECs in the same label mapping message, then an IPv4-only
peer (not knowing how to process such a message) may abort peer (not knowing how to process such a message) may abort
processing the entire label mapping message (thereby discarding even processing the entire label mapping message (thereby discarding even
the IPv4 label FECs), as per the section 3.4.1.1 of RFC5036. the IPv4 label FECs), as per the section 3.4.1.1 of RFC5036.
This would result in LDPv6 to be somewhat undeployable in existing This would result in LDPv6 to be somewhat undeployable in existing
production networks. production networks.
The change proposed in section 8 of this document provides a good The change proposed in section 7 of this document provides a good
safety net and makes LDPv6 incrementally deployable without making safety net and makes LDPv6 incrementally deployable without making
any such assumption on the routers' support for IPv6 FEC processing any such assumption on the routers' support for IPv6 FEC processing
in current production networks. in current production networks.
A.2. Accommodating Non-RFC5036-compliant implementations A.2. Accommodating Non-RFC5036-compliant implementations
It is not safe to assume that implementations have been RFC5036 It is not safe to assume that implementations have been RFC5036
compliant in gracefully handling IPv6 address family (IPv6 Address compliant in gracefully handling IPv6 address family (IPv6 Address
List TLV) in Address message all along. List TLV) in Address message all along.
If a router upgraded with this specification advertised IPv6 If a router upgraded with this specification advertised IPv6
addresses (with or without IPv4 addresses) in Address message, then addresses (with or without IPv4 addresses) in Address message, then
an IPv4-only peer (not knowing how to process such a message) may an IPv4-only peer (not knowing how to process such a message) may
not follow section 3.5.5.1 of RFC5036, and tear down the LDP not follow section 3.5.5.1 of RFC5036, and tear down the LDP
session. session.
This would result in LDPv6 to be somewhat undeployable in existing This would result in LDPv6 to be somewhat undeployable in existing
production networks. production networks.
The change proposed in section 7 of this document provides a good The changes proposed in section 6 and 7 of this document provides a
safety net and makes LDPv6 incrementally deployable without making good safety net and makes LDPv6 incrementally deployable without
any such assumption on the routers' support for IPv6 FEC processing making any such assumption on the routers' support for IPv6 FEC
in current production networks. processing in current production networks.
A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP A.3. Why prohibit IPv4-mapped IPv6 addresses in LDP
Per discussion with 6MAN and V6OPS working groups, the overwhelming Per discussion with 6MAN and V6OPS working groups, the overwhelming
consensus was to not promote IPv4-mapped IPv6 addresses appear in consensus was to not promote IPv4-mapped IPv6 addresses appear in
the routing table, as well as in LDP (address and label) databases. the routing table, as well as in LDP (address and label) databases.
Also, [RFC4038] section 4.2 suggests that IPv4-mapped IPv6 addressed Also, [RFC4038] section 4.2 suggests that IPv4-mapped IPv6 addressed
packets should never appear on the wire. packets should never appear on the wire.
 End of changes. 21 change blocks. 
59 lines changed or deleted 63 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/