< draft-ymbk-idr-l3nd-01.txt   draft-ymbk-idr-l3nd-02.txt >
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Arrcus & Internet Initiative Japan Internet-Draft Arrcus & Internet Initiative Japan
Intended status: Standards Track R. Housley Intended status: Standards Track R. Housley
Expires: 4 September 2022 Vigil Security Expires: 8 September 2022 Vigil Security
R. Austein R. Austein
Arrcus Arrcus
S. Hares S. Hares
Hickory Hill Consulting Hickory Hill Consulting
K. Patel K. Patel
Arrcus Arrcus
3 March 2022 7 March 2022
Layer-3 Neighbor Discovery Layer-3 Neighbor Discovery
draft-ymbk-idr-l3nd-01 draft-ymbk-idr-l3nd-02
Abstract Abstract
Data Centers where the topology is BGP-based need to discover Data Centers where the topology is BGP-based need to discover
neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3 neighbor IP addressing, IP Layer-3 BGP neighbors, etc. This Layer-3
Neighbor Discovery protocol identifies BGP neighbor candidates. Neighbor Discovery protocol identifies BGP neighbor candidates.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 September 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.1. L3ND Ladder Diagram . . . . . . . . . . . . . . . . . . . 5 4.1. L3ND Ladder Diagram . . . . . . . . . . . . . . . . . . . 5
5. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. TLV PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. HELLO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. TCP Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. TCP Set-Up . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. OPEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. ACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 14 9.1. Retransmission . . . . . . . . . . . . . . . . . . . . . 14
10. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 14 10. The Encapsulations . . . . . . . . . . . . . . . . . . . . . 14
10.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 15 10.1. The Encapsulation PDU Skeleton . . . . . . . . . . . . . 15
10.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 16 10.2. Encapsulaion Flags . . . . . . . . . . . . . . . . . . . 16
10.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 16 10.3. IPv4 Encapsulation . . . . . . . . . . . . . . . . . . . 17
10.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 17 10.4. IPv6 Encapsulation . . . . . . . . . . . . . . . . . . . 17
10.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 18 10.5. MPLS Label List . . . . . . . . . . . . . . . . . . . . 18
10.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 18 10.6. MPLS IPv4 Encapsulation . . . . . . . . . . . . . . . . 19
10.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 19 10.7. MPLS IPv6 Encapsulation . . . . . . . . . . . . . . . . 19
11. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 19 11. VENDOR - Vendor Extensions . . . . . . . . . . . . . . . . . 20
12. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 20 12.1. HELLO Discussion . . . . . . . . . . . . . . . . . . . . 21
13. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 20 13. VLANs/SVIs/Sub-interfaces . . . . . . . . . . . . . . . . . . 21
14. Implementation Considerations . . . . . . . . . . . . . . . . 21 14. Implementation Considerations . . . . . . . . . . . . . . . . 21
15. Security Considerations . . . . . . . . . . . . . . . . . . . 21 15. Security Considerations . . . . . . . . . . . . . . . . . . . 22
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
16.1. Link Local Layer-3 Addresses . . . . . . . . . . . . . . 22 16.1. Link Local Layer-3 Addresses . . . . . . . . . . . . . . 23
16.2. Ports for TLS/TCP . . . . . . . . . . . . . . . . . . . 22 16.2. Ports for TLS/TCP . . . . . . . . . . . . . . . . . . . 23
16.3. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 22 16.3. PDU Types . . . . . . . . . . . . . . . . . . . . . . . 23
16.4. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 23 16.4. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . 23
16.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 23 16.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 24
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
18.1. Normative References . . . . . . . . . . . . . . . . . . 23 18.1. Normative References . . . . . . . . . . . . . . . . . . 24
18.2. Informative References . . . . . . . . . . . . . . . . . 24 18.2. Informative References . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The Massive Data Center (MDC) environment presents unusual problems The Massive Data Center (MDC) environment presents unusual problems
of scale, e.g. O(10,000) forwarding devices, while its homogeneity of scale, e.g. O(10,000) forwarding devices, while its homogeneity
presents opportunities for simple approaches. Layer-3 Discovery and presents opportunities for simple approaches. Layer-3 Discovery and
Liveness (L3DL), [I-D.ietf-lsvr-l3dl], provides neighbor discovery at Liveness (L3DL), [I-D.ietf-lsvr-l3dl], provides neighbor discovery at
Layer-2. This document (set) provides a similar solution at Layer-3, Layer-2. This document (set) provides a similar solution at Layer-3,
attempting to be as similar as reasonable to L3DL. attempting to be as similar as reasonable to L3DL.
skipping to change at page 8, line 32 skipping to change at page 8, line 32
Payload Length: Total number of octets in the Payload field. Payload Length: Total number of octets in the Payload field.
Payload: The application layer content of the L3ND PDU. Payload: The application layer content of the L3ND PDU.
6. HELLO 6. HELLO
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 8 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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type = 0 | Payload Length = 24 ~ | Version = 0 | PDU Type = 0 | Payload Length = 3 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Flags | Port ~ ~ | Flags | Port ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ~ |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Flags (bit): Flags (bit):
0 - 0 Raw TCP, 1 TLS 0 - 0 Raw TCP, 1 TLS
1 - 0 Self-Signed Cert for TLS, 1 CA-based 1 - 0 Self-Signed Cert for TLS, 1 CA-based
The Payload Length is 24 to cover the Flags and Port fields. The Payload Length is 3 to cover the Flags and Port fields.
The Port is the TCP Port Number (default is TBD3) on which the HELLO The Port is the two octet TCP Port Number (default is TBD3) on which
sender MUST have a waiting TLS/TCP (as specified in Flags) server the HELLO sender MUST have a waiting TLS/TCP (as specified in Flags)
listening. Though the IANA assigned well-known port SHOULD be used, server listening. Though the IANA assigned well-known port SHOULD be
this field allows configuration of alternate ports. used, this field allows configuration of alternate ports.
The IPv4 UDP packets are sent to the IPv4 link local multicast The IPv4 UDP packets are sent to the IPv4 link local multicast
address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link
Local multicast address (TBD2). See Section 12.1 for why multicast Local multicast address (TBD2). See Section 12.1 for why multicast
is used. is used.
The HELLO PDU solicits a unicast TLS/TCP open request(s) of the same The HELLO PDU solicits a unicast TLS/TCP session open request of the
AFI from other devices on the link. same AFI from other devices on the link.
When a HELLO is received from a source IP address with which there is When a HELLO is received from a source IP address with which there is
no established TLS/TCP L3ND session, the receiver SHOULD respond by no established TLS/TCP L3ND session, if the receiver has the higher
sending a TLS/TCP client open request, using the same AFI, to the of the two IP addresses, it SHOULD respond by sending a TLS/TCP
source IP address of the HELLO to establish an L3ND TLS/TCP session. client open request, using the same AFI, to the source IP address of
the HELLO to establish an L3ND TLS/TCP session.
All L3ND PDUs other than HELLO are sent via TLS/TCP, as the server's All L3ND PDUs other than HELLO are sent via TLS/TCP, as the server's
destination IP address is known after the HELLO. destination IP address is known after the HELLO.
When an interface is turned up on a device, it SHOULD issue a HELLO When an interface is turned up on a device, it SHOULD issue a HELLO
if it is to participate in L3ND sessions and repeat HELLOs at a if it is configured to participate in L3ND sessions and repeat HELLOs
configured interval, with a default of 60 seconds. at a configured interval, with a default of 60 seconds.
If the configured multicast destination address is one that is If the configured multicast destination address is one that is
propagated by switches, the HELLO SHOULD be repeated at a configured propagated by switches, the HELLO SHOULD be repeated at a configured
interval, with a default of 60 seconds. This allows discovery by new interval, with a default of 60 seconds. This allows discovery by new
devices which come up on the mesh. In this multi-link scenario, the devices which come up on the mesh. In this multi-link scenario, the
operator should be aware of the trade-off between timer tuning and operator should be aware of the trade-off between timer tuning and
network noise and adjust the inter-HELLO timer accordingly. network noise and adjust the inter-HELLO timer accordingly.
By default, GTSM, [RFC5082], SHOULD be enabled to test that a By default, GTSM, [RFC5082], SHOULD be enabled to test that a
received HELLO MUST be on the local link. It MAY be disabled by received HELLO MUST be on the local link. It MAY be disabled by
skipping to change at page 9, line 47 skipping to change at page 9, line 48
If more than one device responds, one adjacency is formed for each If more than one device responds, one adjacency is formed for each
unique source IP address. L3ND treats each adjacency as a separate unique source IP address. L3ND treats each adjacency as a separate
logical link. logical link.
To ameliorate possible load spikes during bootstrap or event To ameliorate possible load spikes during bootstrap or event
recovery, there SHOULD be a jittered delay between receipt of a HELLO recovery, there SHOULD be a jittered delay between receipt of a HELLO
and TLS/TCP open. The default delay range SHOULD be zero to five and TLS/TCP open. The default delay range SHOULD be zero to five
seconds, and MUST be configurable. seconds, and MUST be configurable.
If a HELLO is received from an IP Address with which there is an If a HELLO is received from an IP Address with which there is an
established session for that AFI, the HELLO should be dropped. established session for that AFI, the HELLO SHOULD be dropped.
A device with a TLS/TCP listener SHOULD log or otherwise report A device with a TLS/TCP listener SHOULD log or otherwise report
repeated failed inbound attempts. repeated failed inbound attempts.
7. TCP Set-Up 7. TCP Set-Up
If the receiver of a HELLO does not agree with the sender's choice of If the receiver of a HELLO does not agree with the sender's choice of
TLS/TCP or does not agree with the verification choice, Self-Signed TLS/TCP or does not agree with the verification choice, Self-Signed
or CA-based, the receiver SHOULD respond with a HELLO specifying its or CA-based, the receiver SHOULD respond with a HELLO specifying its
preferences. preferences.
As it is assumed that the configured deployment of a data center As it is assumed that the configured deployment of a data center
would have compatible parameters on all devices, any disagreement would have compatible parameters on all devices, any disagreement
over TLS/TCP or trust anchors MUST be logged. over TLS/TCP or trust anchors MUST be logged; with rate limiting of
the logging.
By default, GTSM, [RFC5082], SHOULD be enabled to ensure that a SYN By default, GTSM, [RFC5082], SHOULD be enabled to ensure that a SYN
received in response to a HELLO is on the local link. It MAY be received in response to a HELLO is on the local link. It MAY be
disabled by configuration. GTSM check failures SHOULD be logged, disabled by configuration. GTSM check failures SHOULD be logged;
though with rate limiting to keep from overwhelming logs. though with rate limiting to keep from overwhelming logs.
If the receiver of a HELLO agrees with the sender's choice of TLS/TCP If the receiver of a HELLO agrees with the sender's choice of TLS/TCP
and authentication, both sides have agreed on an AFI for the and authentication, both sides have agreed on an AFI for the
transport and on each other's IP address in that AFI. This is transport and on each other's IP address in that AFI. This is
sufficient to open a TCP session between them, which will allow for sufficient to open a TCP session between them, which will allow for
very large data PDUs while obviating the need to invent complex reliable transport of very large data PDUs while obviating the need
transports. to invent complex transports.
The L3ND peer with the higher IP address MUST act as the TLS/TCP The L3ND peer with the higher IP address MUST act as the TLS/TCP
client and open the transport session (send SYN) toward the peer with client and open the transport session (send SYN) toward the peer with
the lower IP address. the lower IP address.
The server, the sender of the HELLO with the lower IP address, The server, the sender of the HELLO with from the lower IP address,
listens on the advertised port for the TLS/TCP session open. The listens on the advertised port for the TLS/TCP session open. The
receiver of the acceptable HELLO, the TLS/TCP client, initiates a TLS receiver of the acceptable HELLO, the TLS/TCP client, initiates a TLS
or raw TCP session with the sender of the HELLO, the TLS/TCP server, or raw TCP session toward the sender of the HELLO, the TLS/TCP
preferably TLS, as advertised. If TLS, the server has chosen and server, preferably TLS, as advertised. If TLS, the server has chosen
signaled either a self-signed certificate or one configured from the and signaled either a self-signed certificate or one configured from
operational CA trusted by both parties, as negotiated in the HELLO the operational CA trusted by both parties, as negotiated in the
exchange. HELLO exchange.
Once the TLS/TCP session is established, if the link is configured as Once the TLS/TCP session is established, if its interface is
point to point, the client side SHOULD stop listening on any port for configured as point to point, the client side SHOULD stop listening
which it has sent a HELLO. The server side SHOULD stop sending on any port for which it has sent a HELLO. The server, if configured
HELLOs. as a point to point interface SHOULD stop sending HELLOs.
If the TLS/TCP open fails, then this SHOULD be logged and the parties If the TLS/TCP open fails, then this SHOULD be logged and the parties
MUST go back to the initial state and try HELLO. MUST go back to the initial state and try HELLO. Loggin SHOULD be
rate limited.
Should an interface with an established TLS/TCP session be Should an interface with an established TLS/TCP session be
reconfigured changing the TLS/TCP parameters, the TLS/TCP session reconfigured changing the TLS/TCP parameters, the TLS/TCP session
should be closed or torn down. should be closed or torn down and both parties should return to the
HELLO state.
Should the TLS/TCP session terminate for any reason, the devices Should the TLS/TCP session terminate for any reason, the devices
SHOULD restart/resume HELLOs. When the new TLS/TCP session is SHOULD restart/resume HELLOs. When the new TLS/TCP session is
started, if possible the OPEN PDU SHOULD try to resume the lost started, if possible the OPEN PDU SHOULD try to resume the lost
logical session by using the same nonce and resuming from the last logical session by using the same nonce and resuming from the last
Serial Number. Serial Number.
Once the TLS/TCP session has been established, the two devices Once the TLS/TCP session has been established, the two devices
exchange L3ND PDUs, starting with OPENs. exchange L3ND PDUs, starting with OPENs.
8. OPEN 8. OPEN
Each device has learned the other's IP Address from the HELLO Each device has learned the other's IP Address from the HELLO
exchange, see Section 6 and established a TLS/TCP session for a exchange, see Section 6 and established a TLS/TCP session over a
particular AFI. particular AFI.
The first PDU each sends MUST be an OPEN, and the other side MUST The first PDU each sends MUST be an OPEN, and the other side MUST
respond with an ACK PDU. respond with an ACK PDU.
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 8 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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type = 2 | Payload Length ~ | Version = 0 | PDU Type = 2 | Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Nonce ~ ~ | Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | AttrCount | ~ ~ | AttrCount | ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ Attribute List ... ~ ~ Attribute List ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Payload Length is the number of octets in all fields of the PDU The four octet Payload Length is the number of octets in all fields
from the Nonce through the Serial Number. of the PDU from the Nonce through the Serial Number.
The Nonce enables detection of a duplicate OPEN PDU. It SHOULD be The four octet Nonce enables detection of a duplicate OPEN PDU. It
either a random number or a high resolution timestamp. It is needed SHOULD be either a random number or a high resolution timestamp. It
to prevent session closure due to a repeated OPEN caused by a race or is needed to prevent session closure due to a repeated OPEN caused by
a dropped or delayed ACK. It can be used to resume a dropped logical a race or a dropped or delayed ACK. It can be used to resume a
session. dropped logical session.
AttrCount is the number of attributes in the Attribute List. A node The one octet AttrCount is the number of attributes in the Attribute
may send zero or more attributes. List. A node may send zero or more attributes.
Attributes are single octets the semantics of which are operator- Attributes are single octets the semantics of which are operator-
defined, e.g.: spine, leaf, backbone, route reflector, arabica, ... defined, e.g.: spine, leaf, backbone, route reflector, arabica, ...
Attribute syntax and semantics are local to an operator or Attribute syntax and semantics are local to an operator or
datacenter; hence there is no global registry. Nodes exchange their datacenter; hence there is no global registry. Nodes exchange their
attributes only in the OPEN PDU. attributes only in the OPEN PDU.
Unlike L3DL [I-D.ietf-lsvr-l3dl], there are no verifiable keys in the Unlike L3DL [I-D.ietf-lsvr-l3dl], there are no verifiable keys in the
PDUs. If the operator wants authentication, integrity, PDUs. If the operator wants authentication, integrity,
confidentiality, then TLS MUST have been requested by the HELLO and confidentiality, then TLS MUST have been requested by the HELLO and
agreed by the TLS session open. agreed by the TLS session open.
The Serial Number is a monotonically increasing 32-bit value The Serial Number is a monotonically increasing four octet value
representing the sender's state at the time of sending the last PDU. representing the sender's state at the time of sending the last PDU.
It may be an integer, a timestamp, etc. If incrementing the Serial It may be an non-negative integer, a timestamp, etc. If incrementing
Number would cause it to be zero, it should be incremented again. the Serial Number would cause it to be zero, it should be incremented
again.
On session restart (new OPEN, same Nonce), a receiver MAY send the On session restart (new OPEN, same Nonce), a receiver MAY send the
last received Serial Number to tell the sender to only send data with last received Serial Number to tell the sender to only send data with
a Serial Number greater (in the [RFC1982] sense), or send a Serial a Serial Number greater (in the [RFC1982] sense), or send a Serial
Number of zero to request all data. Number of zero to request all data.
This allows a sender of an OPEN to tell the receiver that the sender This allows a sender of an OPEN to tell the receiver that the sender
would like to resume a logical session and that the receiver only would like to resume a logical session and that the receiver of the
needs to send data starting with the PDU with the lowest Serial OPEN PDU only needs to send data starting with the PDU with the
Number greater (in the [RFC1982] sense) than the one sent in the lowest Serial Number greater (in the [RFC1982] sense) than the one
OPEN. If the sender is not trying to resume a dropped session, the sent in the OPEN. If the sender is not trying to resume a dropped
Serial Number MUST be zero. session, the Serial Number MUST be zero.
If the receiver of an OPEN PDU with a non-zero Serial Number can not If the receiver of an OPEN PDU with a non-zero Serial Number can not
resume from the requested point, it should return an ACK with an resume from the requested point, it should return an ACK with an
Error Code of 2, Session could not be continued. The sender of the Error Code of 5, Session May Not Be Continued, EType of 1. The
failing OPEN PDU SHOULD then send an OPEN PDU with a Serial Number of sender of the failing OPEN PDU SHOULD respond with an OPEN PDU with a
zero. Serial Number of zero.
If a sender of OPEN does not receive an ACK of the OPEN PDU in a If a sender of OPEN does not receive an ACK of the OPEN PDU in a
configurable time (default 30 seconds), then they SHOULD close or configurable time (default 5 seconds), then they SHOULD close or
otherwise terminate the TLS/TCP session and restart from the HELLO otherwise terminate the TLS/TCP session and restart from the HELLO
state. state.
If an OPEN arrives at L3ND speaker A from B with which A believes it If an OPEN arrives at L3ND speaker A from B with which A believes it
already has an L3ND session (i.e. OPENs have already been already has an L3ND session (i.e. OPENs have already been
exchanged), and the Serial Number in B's OPEN PDU is non-zero, exchanged), and the Serial Number in B's OPEN PDU is non-zero,
speaker A SHOULD establish a new sending session by sending an OPEN speaker A SHOULD establish a new sending session by sending an OPEN
with the Serial Number being the same as that of A's last sent and with the Serial Number being the same as that of A's last sent and
ACKed PDU. A MUST resume sending encapsulations etc. subsequent to ACKed PDU. A MUST resume sending encapsulations etc. subsequent to
the requested Sequence Number. And B MUST retain all previously the requested Sequence Number. And B MUST retain all previously
skipping to change at page 13, line 24 skipping to change at page 13, line 33
here. here.
9. ACK 9. ACK
The ACK PDU acknowledges receipt of a PDU and reports any error The ACK PDU acknowledges receipt of a PDU and reports any error
condition which might have been raised. condition which might have been raised.
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 8 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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type = 3 | Payload Length = 5 ~ | Version = 0 | PDU Type = 3 | Payload Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | ACKed PDU | EType | ~ | | ACKed PDU | EType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Error Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Error Code | Error Hint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ACK acknowledges receipt of an OPEN, Encapsulation, Vendor PDU, The ACK PDU acknowledges receipt of an OPEN, Encapsulation, Vendor
etc. PDU, etc. and is used to return error codes if any.
The ACKed PDU is the PDU Type of the PDU being acknowledged, e.g., The one octet ACKed PDU is the PDU Type of the PDU being
OPEN, one of the Encapsulations, etc. acknowledged, e.g., OPEN, one of the Encapsulations, etc.
If there was an error processing the received PDU, then the EType is If there was an error processing the received PDU, then the one octet
non-zero. If the EType is zero, Error Code and Error Hint MUST also EType is non-zero. If the EType is zero, Error Code and Error Hint
be zero. MUST also be zero.
A non-zero EType is the receiver's way of telling the PDU's sender A non-zero EType is the receiver's way of telling the PDU's sender
that the receiver had problems processing the PDU. The Error Code that the receiver had problems processing the PDU. The Error Code
and Error Hint will tell the sender more detail about the error. and Error Hint will tell the sender more detail about the error.
The decimal value of EType gives a strong hint how the receiver The decimal value of EType gives a strong hint how the receiver
sending the ACK believes things should proceed: sending the ACK believes things should proceed:
0 - No Error, Error Code and Error Hint MUST be zero 0 - No Error, Error Code and Error Hint MUST be zero
skipping to change at page 14, line 4 skipping to change at page 14, line 13
and Error Hint will tell the sender more detail about the error. and Error Hint will tell the sender more detail about the error.
The decimal value of EType gives a strong hint how the receiver The decimal value of EType gives a strong hint how the receiver
sending the ACK believes things should proceed: sending the ACK believes things should proceed:
0 - No Error, Error Code and Error Hint MUST be zero 0 - No Error, Error Code and Error Hint MUST be zero
1 - Warning, something not too serious happened, continue 1 - Warning, something not too serious happened, continue
2 - Session should not be continued, try to restart 2 - Session should not be continued, try to restart
3 - Restart is hopeless, call the operator 3 - Restart is hopeless, call the operator
4-15 - Reserved 4-15 - Reserved
The Error Codes, noting protocol failures, are listed in The two octet Error Code, noting protocol failures, are listed in
Section 16.5. Someone stuck in the 1990s might think the catenation Section 16.5. Someone stuck in the 1990s might think the catenation
of EType and Error Code as an echo of 0x1zzz, 0x2zzz, etc. They of EType and Error Code as an echo of 0x1zzz, 0x2zzz, etc. They
might be right; or not. might be right; or not.
The Error Hint, an arbitrary 16 bits, is any additional data the The two octet Error Hint, is arbitrary additional data the sender of
sender of the error PDU thinks will help the recipient or the the error PDU thinks will help the recipient or the debugger with the
debugger with the particular error. particular error.
9.1. Retransmission 9.1. Retransmission
If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a If a PDU sender expects an ACK, e.g. for an OPEN, an Encapsulation, a
Vendor PDU, etc., and does not receive the ACK for a configurable Vendor PDU, etc., and does not receive the ACK for a configurable
time (default three seconds) the TLS/TCP session should be closed or time (default five seconds) the TLS/TCP session should be closed or
dropped, and both sides revert to HELLO state. dropped, and both sides revert to HELLO state.
10. The Encapsulations 10. The Encapsulations
Once the devices know each other's IP Addresses, and have established Once the devices know each other's IP Addresses, and have established
a TLS/TCP session and have successfully exchanged OPENs, the L3ND a TLS/TCP session and have successfully exchanged OPENs, the L3ND
session is considered established, and the devices SHOULD exchange session is considered established, and the devices SHOULD exchange
Layer-3 interface encapsulations, Layer-3 addresses, and Layer-2.5 Layer-3 interface encapsulations, Layer-3 addresses, and Layer-2.5
labels. labels.
Encapsulations of any AFI/SAFI may be exchanged over a TLS/TCP Encapsulation data for any AFI/SAFI may be exchanged over a TLS/TCP
session irrespective of the AFI/SAFI of the session transport. session irrespective of the AFI/SAFI of the session transport.
The Encapsulation types the peers exchange may be IPv4 The Encapsulation types the peers exchange may be IPv4
(Section 10.3), IPv6 (Section 10.4), MPLS IPv4 (Section 10.6), MPLS (Section 10.3), IPv6 (Section 10.4), MPLS IPv4 (Section 10.6), MPLS
IPv6 (Section 10.7), and/or possibly others not defined here. IPv6 (Section 10.7), and/or possibly others not defined here.
The sender of an Encapsulation PDU MUST NOT assume that the peer is The sender of an Encapsulation PDU MUST NOT assume that the receiver
capable of the same Encapsulation Type. An ACK (Section 9) merely is capable of the same Encapsulation Type. An ACK (Section 9) with
acknowledges receipt. Only if both peers have sent the same EType of 0 merely acknowledges receipt. Only if both peers have sent
Encapsulation Type is it safe for Layer-3 protocols to assume that the same Encapsulation Type is it safe for Layer-3 protocols to
they are compatible for that type. assume that they are compatible for that Encapsulation Type.
A receiver of an encapsulation might recognize an addressing A receiver of an encapsulation might recognize an addressing
conflict, such as both ends of the link trying to use the same conflict, such as both ends of the link trying to use the same
address. In this case, the receiver MUST respond with an error address. In this case, the receiver MUST respond with an error
(Error Code 2) ACK. As there may be other usable addresses or (Error Code 2, Logical Link Addressing Conflict) ACK. As there may
encapsulations, this error might log and continue, letting an upper be other usable addresses or encapsulations, this error might log and
layer topology builder deal with what works. continue, letting an upper layer topology builder deal with what
works.
Further, to consider a logical link of a type to formally be Further, to consider a logical link of a Encapsulation Type to
established so that it may be pushed up to upper layer protocols, the formally be established so that it may be used by other protocols,
addressing for the type must be compatible, e.g. on the same IP the addressing for the type must be compatible, e.g. on the same IP
subnet. subnet.
10.1. The Encapsulation PDU Skeleton 10.1. The Encapsulation PDU Skeleton
The header for all encapsulation PDUs is as follows: The header for all encapsulation PDUs is as follows:
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 8 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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type | Payload Length ~ | Version = 0 | PDU Type | Payload Length ~
skipping to change at page 15, line 29 skipping to change at page 15, line 43
~ | Count ~ ~ | Count ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Serial Number ~ ~ | Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Encapsulation List... ~ ~ | Encapsulation List... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Encapsulation PDU describes zero or more addresses of the An Encapsulation PDU describes zero or more addresses of the
encapsulation type. encapsulation type.
The 24-bit Count is the number of Encapsulations in the Encapsulation The three octet Count is the number of Encapsulations in the
list. Encapsulation List.
The Serial Number is a monotonically increasing 32-bit value The Serial Number is a monotonically increasing four octet value
representing the sender's state in time. It may be an integer, a representing the sender's state in time. It may be an integer, a
timestamp, etc. On session restart (new OPEN), a receiver MAY send timestamp, etc. On session restart (new OPEN), a receiver MAY send
the last received Session Number to tell the sender to only send the last received Serial Number to request the sender to only send
newer data. newer data.
If a sender has multiple links on the same interface, separate state: If a sender has multiple links on the same interface, separate state:
data, ACKs, etc. must be kept for each peer session. data, ACKs, etc. must be kept for each peer session.
Over time, multiple Encapsulation PDUs may be sent for an interface Over time, multiple Encapsulation PDUs may be sent for an interface
in a session as configuration changes. in a session as configuration changes.
The Receiver MUST acknowledge the Encapsulation PDU with a Type=3, The Receiver MUST acknowledge the Encapsulation PDU with an ACK PDU
ACK PDU (Section 9) with the Encapsulation Type being that of the (Section 9) with the PDU Type being that of the type PDU being
encapsulation being announced, see Section 9. announced, see Section 9.
If the Sender does not receive an ACK in a configurable interval If the Sender does not receive an ACK in a configurable interval
(default three seconds), they SHOULD retransmit. After a user (default five seconds), they SHOULD retransmit. After a user
configurable number of failures (default three), the L3ND session configurable number of failures (default three), the L3ND session
should be considered dead and the HELLO process SHOULD be restarted. should be considered dead, TLS/TCP torn down, and the HELLO process
SHOULD be restarted.
If the link is broken below layer-3, retransmission MAY BE retried if If the link is broken below layer-3, retransmission MAY BE retried if
data have not changed in the interim and the TLS/TCP session is still data have not changed in the interim and the TLS/TCP session is still
alive. alive.
Should an Encapsulation in the Encapsulation List be syntactically
invalid, e.g. an out of bounds prefix length, the entire
Encapsulation PDU MUST be dropped and the sending party notified by
an ACK PDU with an EType of 1 and an Error Code of 3, Encapsulation
Error.
10.2. Encapsulaion Flags 10.2. Encapsulaion Flags
The Encapsulation Flags are a sequence of bit fields as follows: The one octet Encapsulation Flags field is a sequence of one bit
fields as follows:
0 1 2 3 4 ... 7 0 1 2 3 4 ... 7
+------------+------------+------------+------------+------------+ +------------+------------+------------+------------+------------+
| Ann/With | Primary | Under/Over | Loopback | Reserved ..| | Ann/With | Primary | Under/Over | Loopback | Reserved ..|
+------------+------------+------------+------------+------------+ +------------+------------+------------+------------+------------+
Each encapsulation in an Encapsulation PDU of Type T may announce new Each encapsulation in an Encapsulation PDU of Type T may announce new
and/or withdraw old encapsulations of Type T. It indicates this with and/or withdraw old encapsulations of Type T. It indicates this with
the Ann/With Encapsulation Flag, Announce == 1, Withdraw == 0. the Ann/With Encapsulation Flag, Announce == 1, Withdraw == 0.
Each Encapsulation interface address in an Encapsulation PDU is Announcing an encapsulation which already exists SHOULD raise an
either a new encapsulation be announced (Ann/With == 1) (yes, a la Announce/Withdraw Error (see Section 16.5); the EType SHOULD be 2,
BGP) or requests one be withdrawn (Ann/With == 0). Adding an suggesting a session restart (see Section 9) so all encapsulations
encapsulation which already exists SHOULD raise an Announce/Withdraw will be resent.
Error (see Section 16.5); the EType SHOULD be 2, suggesting a session
restart (see Section 9 so all encapsulations will be resent.
If an interface on a link has multiple addresses for an encapsulation If an interface on a link has multiple addresses for an encapsulation
type, one and only one address MAY be marked as primary (Primary Flag type, one and only one address MAY be marked as primary (Primary Flag
== 1) for that Encapsulation Type. == 1) for that Encapsulation Type.
An Encapsulation interface address in an Encapsulation PDU MAY be An Encapsulation interface address in an Encapsulation PDU MAY be
marked as a loopback, in which case the Loopback bit is set. marked as a loopback, in which case the Loopback bit is set.
Loopback addresses are generally not seen directly on an external Loopback addresses are generally not seen directly on an external
interface. One or more loopback addresses MAY be exposed by interface. One or more loopback addresses MAY be exposed by
configuration on one or more L3ND speaking external interfaces, e.g. configuration on one or more L3ND speaking external interfaces, e.g.
skipping to change at page 17, line 19 skipping to change at page 17, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Count ~ ~ | Count ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Serial Number ~ ~ | Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Encaps Flags | IPv4 Address ~ ~ | Encaps Flags | IPv4 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | PrefixLen | more ... ~ ~ | PrefixLen | more ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the sum of the number of IPv4 Encapsulations The three octet Count is the sum of the number of IPv4 Encapsulations
being announced and/or withdrawn. being announced and/or withdrawn.
10.4. IPv6 Encapsulation 10.4. IPv6 Encapsulation
The IPv6 Encapsulation describes a link's ability to exchange IPv6 The IPv6 Encapsulation describes a link's ability to exchange IPv6
packets on one or more subnets. It does so by stating the packets on one or more subnets. It does so by stating the
interface's addresses and the corresponding prefix lengths. interface's addresses and the corresponding prefix lengths.
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 8 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 8 9 0 1
skipping to change at page 17, line 48 skipping to change at page 18, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| ~ | ~
+ + + +
~ ~ ~ ~
+ + + +
~ IPv6 Prefix ~ ~ IPv6 Prefix ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | PrefixLen | more ... ~ ~ | PrefixLen | more ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the sum of the number of IPv6 Encapsulations The three octet Count is the sum of the number of IPv6 Encapsulations
being announced and/or withdrawn. being announced and/or withdrawn.
10.5. MPLS Label List 10.5. MPLS Label List
As an MPLS enabled interface may have a label stack, see [RFC3032], a As an MPLS enabled interface may have a label stack, see [RFC3032], a
variable length list of labels is needed. These are the labels the variable length list of labels is needed. These are the labels the
sender will accept for the prefix to which the list is attached. sender will accept for the prefix to which the list is attached.
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 8 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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Count | Label | Exp |S| | Label Count | Label | Exp |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Label | Exp |S| more ... ~ ~ Label | Exp |S| more ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Label Count of zero is an implicit withdraw of all labels for that A one octet Label Count of zero is an implicit withdraw of all labels
prefix on that interface. for that prefix on that interface.
The bottom of the stack flag, S, MUST be set on one and only one
label. Should this not be the case, the receiver of the erroneous
PDU MUST respond with an ACK PDU of EType 1 and Error Code 1, MPLS
Error.
10.6. MPLS IPv4 Encapsulation 10.6. MPLS IPv4 Encapsulation
The MPLS IPv4 Encapsulation describes a logical link's ability to The MPLS IPv4 Encapsulation describes a logical link's ability to
exchange labeled IPv4 packets on one or more subnets. It does so by exchange labeled IPv4 packets on one or more subnets. It does so by
stating the interface's addresses the corresponding prefix lengths, stating the interface's addresses the corresponding prefix lengths,
and the corresponding labels which will be accepted for each address. and the corresponding labels which will be accepted for each address.
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 8 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 8 9 0 1
skipping to change at page 18, line 45 skipping to change at page 19, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Serial Number ~ ~ | Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Encaps Flags | MPLS Label List ... ~ ~ | Encaps Flags | MPLS Label List ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address | | IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLen | more ... ~ | PrefixLen | more ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the sum of the number of MPLSv4 Encapsulation The three octet Count is the sum of the number of MPLSv4
being announced and/or withdrawn. Encapsulation being announced and/or withdrawn.
10.7. MPLS IPv6 Encapsulation 10.7. MPLS IPv6 Encapsulation
The MPLS IPv6 Encapsulation describes a logical link's ability to The MPLS IPv6 Encapsulation describes a logical link's ability to
exchange labeled IPv6 packets on one or more subnets. It does so by exchange labeled IPv6 packets on one or more subnets. It does so by
stating the interface's addresses, the corresponding prefix lengths, stating the interface's addresses, the corresponding prefix lengths,
and the corresponding labels which will be accepted for each address. and the corresponding labels which will be accepted for each address.
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 8 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 8 9 0 1
skipping to change at page 19, line 34 skipping to change at page 20, line 27
+ + + +
~ ~ ~ ~
+ IPv6 Address + + IPv6 Address +
~ ~ ~ ~
+ + + +
~ | ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Len | more ... ~ | Prefix Len | more ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 24-bit Count is the sum of the number of MPLSv6 Encapsulations The three octet Count is the sum of the number of MPLSv6
being announced and/or withdrawn. Encapsulations being announced and/or withdrawn.
11. VENDOR - Vendor Extensions 11. VENDOR - Vendor Extensions
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 8 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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type = 255| Payload Length ~ | Version = 0 | PDU Type = 255| Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Serial Number ~ ~ | Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 4 skipping to change at page 20, line 43
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 8 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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version = 0 | PDU Type = 255| Payload Length ~ | Version = 0 | PDU Type = 255| Payload Length ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Serial Number ~ ~ | Serial Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Enterprise Number ~ ~ | Enterprise Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Ent Type | Enterprise Data ... ~ ~ | Ent Type | Enterprise Data ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendors or enterprises may define TLVs beyond the scope of L3ND Vendors or enterprises may define TLVs beyond the scope of L3ND
standards. This is done using a Private Enterprise Number [IANA-PEN] standards. This is done using a Private Enterprise Number [IANA-PEN]
followed by Enterprise Data in a format defined for that Enterprise followed by Enterprise Data in a format defined for that three octet
Number and Ent Type. Enterprise Number and one octet Ent Type.
Ent Type allows a Vendor PDU to be sub-typed in the event that the Ent Type allows a Vendor PDU to be sub-typed in the event that the
vendor/enterprise needs multiple PDU types. vendor/enterprise needs multiple PDU types.
As with Encapsulation PDUs, a receiver of a Vendor PDU MUST respond As with Encapsulation PDUs, a receiver of a Vendor PDU MUST respond
with an ACK or an ERROR PDU. Similarly, a Vendor PDU MUST only be with an ACK or an ERROR PDU. Similarly, a Vendor PDU MUST only be
sent over an open session. sent over an open session.
12. Discussion 12. Discussion
This section explores some trade-offs taken and some considerations. This section explores some trade-offs taken and some considerations.
12.1. HELLO Discussion 12.1. HELLO Discussion
A device may send IP packets an Layer-3 interface which transmits A device may send IP packets over a Layer-3 interface which transmits
data over a single Layer-2 interface or multiple Layer-2 interfaces. data over a single Layer-2 interface or multiple Layer-2 interfaces.
Packets sourced by one Layer-3 IP interface over multiple Layer-2 Packets sourced by one Layer-3 IP interface over multiple Layer-2
should consider that an Layer-3 interface with multiple Layer-2 should consider that a Layer-3 interface with multiple Layer-2
interfaces could have many devices which might come at various times, interfaces could have many devices which might come at various times,
therefore the configured HELLO PDU retransmit time SHOULD be set to a therefore the configured HELLO PDU retransmit time SHOULD be set to a
non-zero value, and periodic HELLOs should continue. Packets non-zero value, and periodic HELLOs should continue. Packets
transmitted on a single Layer-2 interface on a point-to-point (p2p) transmitted on a single Layer-2 interface on a point-to-point (p2p)
connection, MAY set the configuration value to zero, so once a TLS/ connection, MAY set the configuration value to zero, so when a TLS/
TCP session is up, HELLOs are no longer desirable. TCP session is up, HELLOs are no longer desirable.
A device with multiple Layer-2 interfaces, traditionally called a A device with multiple Layer-2 interfaces, traditionally called a
switch, may be used to forward frames and therefore packets from switch, may be used to forward packets from multiple devices to one
multiple devices to one Layer-3 interface, I, on an L3ND speaking Layer-3 interface, I, on an L3ND speaking device. Interface I could
device. Interface I could discover a peer J across the switch. discover a peer J across the switch. Later, a prospective peer K
Later, a prospective peer K could come up across the switch. If I could come up across the switch. If I was not still sending and
was not still sending and listening for HELLOs, the potential peering listening for HELLOs, the potential peering with K could not be
with K could not be discovered. Therefore, on multi-link interfaces, discovered. Therefore, on multi-link interfaces, L3ND MUST continue
L3ND MUST continue to send HELLOs as long as they are turned up. to send HELLOs as long as they are turned up.
13. VLANs/SVIs/Sub-interfaces 13. VLANs/SVIs/Sub-interfaces
One can think of the protocol as an instance (i.e. state machine) One can think of the protocol as an instance (i.e. state machine)
which runs on each logical link of a device. which runs on each logical link of a device.
As the upper routing layer must view VLAN topologies as separate As the upper routing layer must view VLAN topologies as separate
graphs, L3ND treats VLAN ports as separate links. graphs, L3ND treats VLAN ports as separate links.
As Sub-Interfaces each have their own layer-3 identities, they act as As Sub-Interfaces each have their own layer-3 identities, they act as
skipping to change at page 21, line 29 skipping to change at page 22, line 24
addresses of an encapsulation as primary on an L3ND speaking addresses of an encapsulation as primary on an L3ND speaking
interface. If there is only one address for a particular interface. If there is only one address for a particular
encapsulation, the implementation MAY mark it as primary by default. encapsulation, the implementation MAY mark it as primary by default.
An implementation MAY allow optional configuration which updates the An implementation MAY allow optional configuration which updates the
local forwarding table with overlay and underlay data both learned local forwarding table with overlay and underlay data both learned
from L3ND peers and configured locally. from L3ND peers and configured locally.
15. Security Considerations 15. Security Considerations
For TLS, version 1.1 or later MUST be used. For TLS, version 1.1 or higher MUST be used.
The protocol as is MUST NOT be used outside a datacenter or similarly The protocol as is MUST NOT be used outside a datacenter or similarly
closed environment without using TLS encapsulation which is based on closed environment without using TLS encapsulation which is based on
a configured CA trust anchor. a configured CA trust anchor.
Many datacenter operators have a strange belief that physical walls Many datacenter operators have a strange belief that physical walls
and firewalls provide sufficient security. This is not credible. and firewalls provide sufficient security. This is not credible.
All DC protocols need to be examined for exposure and attack surface. All DC protocols need to be examined for exposure and attack surface.
In the case of L3ND, authentication and integrity as provided by TLS In the case of L3ND, authentication and integrity as provided by TLS
validated to a configured shared CA trust anchor is strongly validated to a configured shared CA trust anchor is strongly
skipping to change at page 23, line 33 skipping to change at page 24, line 25
This document requests the IANA create a registry for L3ND Error This document requests the IANA create a registry for L3ND Error
Codes, a 16 bit integer. The name of the registry should be L3ND- Codes, a 16 bit integer. The name of the registry should be L3ND-
Error-Codes. The policy for adding to the registry is RFC Required Error-Codes. The policy for adding to the registry is RFC Required
per [RFC5226], either standards track or experimental. The initial per [RFC5226], either standards track or experimental. The initial
entries should be the following: entries should be the following:
Error Error
Code Error Name Code Error Name
---- ------------------- ---- -------------------
0 No Error 0 No Error
1 Checksum Error 1 MPLS Error
2 Logical Link Addressing Conflict 2 Logical Link Addressing Conflict
3 reserved 3 Encapsulation Error
4 Announce/Withdraw Error 4 Announce/Withdraw Error
5 Session May Not Be Continued
17. Acknowledgments 17. Acknowledgments
Many kind people helped with the Layer-2 cousin of this protocol, Many kind people helped with the Layer-2 cousin of this protocol,
L3DL. Cristel Pelsser provided multiple reviews, Harsha Kovuru L3DL. Cristel Pelsser provided multiple reviews, Harsha Kovuru
commented during implementation, Jeff Haas reviewed and commented, commented during implementation, Jeff Haas reviewed and commented,
Joerg Ott did an early but deep transport review, Joe Clarke provided Joerg Ott did an early but deep transport review, Joe Clarke provided
a useful ops review, John Scudder a deeply serious review and a useful ops review, John Scudder a deeply serious review and
comments, Martijn Schmidt contributed, and Neeraj Malhotra reviewed. comments, Martijn Schmidt contributed, and Neeraj Malhotra reviewed.
 End of changes. 72 change blocks. 
139 lines changed or deleted 159 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/