draft-ietf-mpls-ldp-ipv6-16.txt   draft-ietf-mpls-ldp-ipv6-17.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
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: August 2015 Expires: August 2015
Vishwas Manral Vishwas Manral
Hewlett-Packard, Inc Hewlett-Packard, Inc
Rajiv Papneja Rajiv Papneja
Huawei Huawei
February 11, 2015 February 26, 2015
Updates to LDP for IPv6 Updates to LDP for IPv6
draft-ietf-mpls-ldp-ipv6-16 draft-ietf-mpls-ldp-ipv6-17
Abstract Abstract
The Label Distribution Protocol (LDP) specification defines The Label Distribution Protocol (LDP) specification defines
procedures to exchange label bindings over either IPv4, or IPv6 or procedures to exchange label bindings over either IPv4, or IPv6 or
both networks. This document corrects and clarifies the LDP behavior both networks. This document corrects and clarifies the LDP behavior
when IPv6 network is used (with or without IPv4). This document when IPv6 network is used (with or without IPv4). This document
updates RFC 5036 and RFC 6720. updates RFC 5036 and RFC 6720.
Status of this Memo Status of this Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 August 11, 2015. This Internet-Draft will expire on August 26, 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
skipping to change at page 2, line 45 skipping to change at page 2, line 45
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. Binding Distribution..........................................15
7.1. Address Distribution.....................................15 7.1. Address Distribution.....................................15
7.2. Label Distribution.......................................16 7.2. Label Distribution.......................................16
8. LDP Identifiers and Duplicate Next Hop Addresses..............17 8. LDP Identifiers and Duplicate Next Hop Addresses..............17
9. LDP TTL Security..............................................17 9. LDP TTL Security..............................................18
10. IANA Considerations..........................................18 10. IANA Considerations..........................................18
11. Security Considerations......................................18 11. Security Considerations......................................18
12. Acknowledgments..............................................19 12. Acknowledgments..............................................19
13. Additional Contributors......................................19 13. Additional Contributors......................................19
14. References...................................................21 14. References...................................................21
14.1. Normative References....................................21 14.1. Normative References....................................21
14.2. Informative 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
skipping to change at page 10, line 36 skipping to change at page 10, line 36
and IPv6 transport address optional objects, but MUST use only and IPv6 transport address optional objects, but MUST use only
the transport address whose address family is the same as that the transport address whose address family is the same as that
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 is enabled (for an
interface or neighbor).
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.
6. A Single-stack LSR MUST establish LDPoIPv4 or LDPoIPv6 session 6. A Single-stack LSR MUST establish either LDPoIPv4 or LDPoIPv6
with a remote LSR as per the enabled address-family. session with a remote LSR as per the enabled address-family.
7. A Dual-stack LSR MUST NOT initiate (or accept the request for) 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.
8. A Dual-stack LSR MUST prefer establishing LDPoIPv6 session with 8. A Dual-stack LSR SHOULD prefer establishing an LDPoIPv6 session
a remote LSR by following the 'transport connection role' (instead of LDPoIPv4 session) with a remote Dual-stack LSR by
determination logic in section 6.1.1. following the 'transport connection role' determination logic
in section 6.1.1.
Additionally, to ensure the above preference in case of Dual-
stack LDP being enabled on an interface, it would be desirable
that IPv6 LDP Link Hellos are transmitted before IPv4 LDP Link
Hellos, particularly when an interface is coming into service
or being reconfigured.
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
skipping to change at page 25, line 7 skipping to change at page 25, line 7
deployments, this 32-bit LSR Id must be derived by some other means deployments, this 32-bit LSR Id must be derived by some other means
that guarantees global uniqueness within the MPLS network, similar that guarantees global uniqueness within the MPLS network, similar
to that of BGP Identifier [RFC6286] and OSPF router ID [RFC5340]. to that of BGP Identifier [RFC6286] and OSPF router ID [RFC5340].
This document reserves 0.0.0.0 as the LSR Id, and prohibits its This document reserves 0.0.0.0 as the LSR Id, and prohibits its
usage with IPv6, in line with OSPF router Id in OSPF version 3 usage with IPv6, in line with OSPF router Id in OSPF version 3
[RFC5340]. [RFC5340].
Author's Addresses Author's Addresses
Rajiv Asati
Cisco Systems, Inc.
7025 Kit Creek Road
Research Triangle Park, NC 27709-4987
Email: rajiva@cisco.com
Vishwas Manral Vishwas Manral
Hewlet-Packard, Inc. Hewlet-Packard, Inc.
19111 Pruneridge Ave., Cupertino, CA, 95014 19111 Pruneridge Ave., Cupertino, CA, 95014
Phone: 408-447-1497 Phone: 408-447-1497
Email: vishwas.manral@hp.com Email: vishwas@ionosnetworks.com
Kamran Raza
Cisco Systems, Inc.,
2000 Innovation Drive,
Ottawa, ON K2K-3E8, Canada.
E-mail: skraza@cisco.com
Rajiv Papneja Rajiv Papneja
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
Phone: +1 571 926 8593 Phone: +1 571 926 8593
EMail: rajiv.papneja@huawei.com EMail: rajiv.papneja@huawei.com
Rajiv Asati
Cisco Systems, Inc.
7025 Kit Creek Road
Research Triangle Park, NC 27709-4987
Email: rajiva@cisco.com
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
7200 Kit Creek Road 7200 Kit Creek Road
Research Triangle Park, NC 27709-4987 Research Triangle Park, NC 27709-4987
Email: cpignata@cisco.com Email: cpignata@cisco.com
 End of changes. 11 change blocks. 
23 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/