< draft-ietf-manet-dlep-25.txt   draft-ietf-manet-dlep-26.txt >
Mobile Ad hoc Networks Working Group S. Ratliff Mobile Ad hoc Networks Working Group S. Ratliff
Internet-Draft VT iDirect Internet-Draft VT iDirect
Intended status: Standards Track S. Jury Intended status: Standards Track S. Jury
Expires: May 1, 2017 Cisco Systems Expires: June 12, 2017 Cisco Systems
D. Satterwhite D. Satterwhite
Broadcom Broadcom
R. Taylor R. Taylor
Airbus Defence & Space Airbus Defence & Space
B. Berry B. Berry
October 28, 2016 December 9, 2016
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-25 draft-ietf-manet-dlep-26
Abstract Abstract
When routing devices rely on modems to effect communications over When routing devices rely on modems to effect communications over
wireless links, they need timely and accurate knowledge of the wireless links, they need timely and accurate knowledge of the
characteristics of the link (speed, state, etc.) in order to make characteristics of the link (speed, state, etc.) in order to make
routing decisions. In mobile or other environments where these routing decisions. In mobile or other environments where these
characteristics change frequently, manual configurations or the characteristics change frequently, manual configurations or the
inference of state through routing or transport protocols does not inference of state through routing or transport protocols does not
allow the router to make the best decisions. A bidirectional, event- allow the router to make the best decisions. A bidirectional, event-
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 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 May 1, 2017. This Internet-Draft will expire on June 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9
4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11 5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11
5.2. Session Initialization State . . . . . . . . . . . . . . 12 5.2. Session Initialization State . . . . . . . . . . . . . . 12
5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 13 5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 13
5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13 5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13
5.4. Session Termination State . . . . . . . . . . . . . . . . 14 5.4. Session Termination State . . . . . . . . . . . . . . . . 14
5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14 5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14
5.5.1. Unexpected TCP connection termination . . . . . . . . 15 5.5.1. Unexpected TCP connection termination . . . . . . . . 14
6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15 6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15
7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16
8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 17 9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 17
9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17 9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17
9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 18 9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 18
9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 19 9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 18
10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19 10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19
10.1. General Processing Rules . . . . . . . . . . . . . . . . 19 10.1. General Processing Rules . . . . . . . . . . . . . . . . 19
10.2. Status code processing . . . . . . . . . . . . . . . . . 20 10.2. Status code processing . . . . . . . . . . . . . . . . . 20
10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 21 10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 20
10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21 10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21
10.5. Session Initialization Message . . . . . . . . . . . . . 22 10.5. Session Initialization Message . . . . . . . . . . . . . 21
10.6. Session Initialization Response Message . . . . . . . . 23 10.6. Session Initialization Response Message . . . . . . . . 22
10.7. Session Update Message . . . . . . . . . . . . . . . . . 24 10.7. Session Update Message . . . . . . . . . . . . . . . . . 24
10.8. Session Update Response Message . . . . . . . . . . . . 26 10.8. Session Update Response Message . . . . . . . . . . . . 25
10.9. Session Termination Message . . . . . . . . . . . . . . 26 10.9. Session Termination Message . . . . . . . . . . . . . . 26
10.10. Session Termination Response Message . . . . . . . . . . 26 10.10. Session Termination Response Message . . . . . . . . . . 26
10.11. Destination Up Message . . . . . . . . . . . . . . . . . 27 10.11. Destination Up Message . . . . . . . . . . . . . . . . . 26
10.12. Destination Up Response Message . . . . . . . . . . . . 28 10.12. Destination Up Response Message . . . . . . . . . . . . 28
10.13. Destination Announce Message . . . . . . . . . . . . . . 29 10.13. Destination Announce Message . . . . . . . . . . . . . . 28
10.14. Destination Announce Response Message . . . . . . . . . 29 10.14. Destination Announce Response Message . . . . . . . . . 29
10.15. Destination Down Message . . . . . . . . . . . . . . . . 31 10.15. Destination Down Message . . . . . . . . . . . . . . . . 30
10.16. Destination Down Response Message . . . . . . . . . . . 31 10.16. Destination Down Response Message . . . . . . . . . . . 31
10.17. Destination Update Message . . . . . . . . . . . . . . . 31 10.17. Destination Update Message . . . . . . . . . . . . . . . 31
10.18. Link Characteristics Request Message . . . . . . . . . . 33 10.18. Link Characteristics Request Message . . . . . . . . . . 32
10.19. Link Characteristics Response Message . . . . . . . . . 33 10.19. Link Characteristics Response Message . . . . . . . . . 33
10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34 10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34
11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 35 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 35
11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 39 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 38
11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 40 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 39
11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 41 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 40
11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 41 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 41
11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 42 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 41
11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 42 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 42
11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 43 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 42
11.8.1. IPv4 Address Processing . . . . . . . . . . . . . . 44 11.8.1. IPv4 Address Processing . . . . . . . . . . . . . . 43
11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 45 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 44
11.9.1. IPv6 Address Processing . . . . . . . . . . . . . . 46 11.9.1. IPv6 Address Processing . . . . . . . . . . . . . . 45
11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 47 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 46
11.10.1. IPv4 Attached Subnet Processing . . . . . . . . . . 48 11.10.1. IPv4 Attached Subnet Processing . . . . . . . . . . 47
11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 48 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 48
11.11.1. IPv6 Attached Subnet Processing . . . . . . . . . . 50 11.11.1. IPv6 Attached Subnet Processing . . . . . . . . . . 49
11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 50 11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 50
11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 51 11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 51
11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 52 11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 52
11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 52 11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 52
11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 53 11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 53
11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 54 11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 54
11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 55 11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 55
11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 55 11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 55
11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 56 11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 56
12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58
13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 57 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 58
13.2. Signal Type Registration . . . . . . . . . . . . . . . . 57 13.2. Signal Type Registration . . . . . . . . . . . . . . . . 58
13.3. Message Type Registration . . . . . . . . . . . . . . . 58 13.3. Message Type Registration . . . . . . . . . . . . . . . 58
13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 59 13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 59
13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 59 13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 60
13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 60 13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 61
13.7. DLEP IPv4 Connection Point Flags . . . . . . . . . . . . 60 13.7. DLEP IPv4 Connection Point Flags . . . . . . . . . . . . 61
13.8. DLEP IPv6 Connection Point Flags . . . . . . . . . . . . 61 13.8. DLEP IPv6 Connection Point Flags . . . . . . . . . . . . 62
13.9. DLEP IPv4 Address Flag . . . . . . . . . . . . . . . . . 61 13.9. DLEP IPv4 Address Flag . . . . . . . . . . . . . . . . . 62
13.10. DLEP IPv6 Address Flag . . . . . . . . . . . . . . . . . 61 13.10. DLEP IPv6 Address Flag . . . . . . . . . . . . . . . . . 62
13.11. DLEP IPv4 Attached Subnet Flag . . . . . . . . . . . . . 62 13.11. DLEP IPv4 Attached Subnet Flag . . . . . . . . . . . . . 63
13.12. DLEP IPv6 Attached Subnet Flag . . . . . . . . . . . . . 62 13.12. DLEP IPv6 Attached Subnet Flag . . . . . . . . . . . . . 63
13.13. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 62 13.13. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 63
13.14. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 63 13.14. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 64
13.15. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 63 13.15. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 64
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
15.1. Normative References . . . . . . . . . . . . . . . . . . 63 15.1. Normative References . . . . . . . . . . . . . . . . . . 64
15.2. Informative References . . . . . . . . . . . . . . . . . 63 15.2. Informative References . . . . . . . . . . . . . . . . . 65
Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 64 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 65
Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 65 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 66
B.1. Session Initialization . . . . . . . . . . . . . . . . . 65 B.1. Session Initialization . . . . . . . . . . . . . . . . . 66
B.2. Session Initialization - Refused . . . . . . . . . . . . 65 B.2. Session Initialization - Refused . . . . . . . . . . . . 67
B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 66 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 67
B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 66 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 67
B.5. Router Terminates Session . . . . . . . . . . . . . . . . 67 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 68
B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 67 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 68
B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 68 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 69
B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 69 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 70
B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 70 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 71
Appendix C. Destination Specific Message Flows . . . . . . . . . 70 Appendix C. Destination Specific Message Flows . . . . . . . . . 71
C.1. Common Destination Notification . . . . . . . . . . . . . 70 C.1. Common Destination Notification . . . . . . . . . . . . . 71
C.2. Multicast Destination Notification . . . . . . . . . . . 71 C.2. Multicast Destination Notification . . . . . . . . . . . 72
C.3. Link Characteristics Request . . . . . . . . . . . . . . 72 C.3. Link Characteristics Request . . . . . . . . . . . . . . 73
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74
1. Introduction 1. Introduction
There exist today a collection of modem devices that control links of There exist today a collection of modem devices that control links of
variable datarate and quality. Examples of these types of links variable datarate and quality. Examples of these types of links
include line-of-sight (LOS) terrestrial radios, satellite terminals, include line-of-sight (LOS) terrestrial radios, satellite terminals,
and broadband modems. Fluctuations in speed and quality of these and broadband modems. Fluctuations in speed and quality of these
links can occur due to configuration, or on a moment-to-moment basis, links can occur due to configuration, or on a moment-to-moment basis,
due to physical phenomena like multipath interference, obstructions, due to physical phenomena like multipath interference, obstructions,
rain fade, etc. It is also quite possible that link quality and rain fade, etc. It is also quite possible that link quality and
skipping to change at page 9, line 32 skipping to change at page 9, line 32
DLEP MUST be implemented on a single Layer 2 domain. The protocol DLEP MUST be implemented on a single Layer 2 domain. The protocol
identifies next-hop destinations by using the MAC address for identifies next-hop destinations by using the MAC address for
delivering data traffic. No manipulation or substitution is delivering data traffic. No manipulation or substitution is
performed; the MAC address supplied in all DLEP Messages is used as performed; the MAC address supplied in all DLEP Messages is used as
the Destination MAC address for frames emitted by the participating the Destination MAC address for frames emitted by the participating
router. MAC addresses MUST be unique within the context of router- router. MAC addresses MUST be unique within the context of router-
modem session. modem session.
To enforce the single Layer 2 domain, implementations MUST support To enforce the single Layer 2 domain, implementations MUST support
The Generalized TTL Security Mechanism [RFC5082]. The Generalized TTL Security Mechanism [RFC5082], and implementations
MUST adher to this specification for all DLEP Messages.
DLEP specifies UDP multicast for single-hop discovery signaling, and DLEP specifies UDP multicast for single-hop discovery signaling, and
TCP for transport of the Messages. Modems and routers participating TCP for transport of the Messages. Modems and routers participating
in DLEP sessions MUST have topologically consistent IP addresses in DLEP sessions MUST have topologically consistent IP addresses
assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 assigned. It is RECOMMENDED that DLEP implementations utilize IPv6
link-local addresses to reduce the administrative burden of address link-local addresses to reduce the administrative burden of address
assignment. If the router and modem support both IPv4 and IPv6, the assignment. If the router and modem support both IPv4 and IPv6, the
IPv6 transport MUST be used for the DLEP session. IPv6 transport SHOULD be used for the DLEP session.
To enforce the single Layer 2 domain for DLEP Messages,
implementations MUST adhere to the Generalized TTL Security Mechanism
documented in [RFC5082] for all TCP-based DLEP Messages.
In order to keep the DLEP discovery Signals, which are multicast UDP-
based, limited to the same Layer 2 domain, implementations MUST set
the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on
receipt of DLEP Signals. Any signal received with a TTL not equal to
1 MUST be discarded.
DLEP relies on the guaranteed delivery of its Messages between router DLEP relies on the guaranteed delivery of its Messages between router
and modem, once the 1 hop discovery process is complete, hence, the and modem, once the 1 hop discovery process is complete, hence, the
specification of TCP to carry the Messages. Other reliable specification of TCP to carry the Messages. Other reliable
transports for the protocol are possible, but are outside the scope transports for the protocol are possible, but are outside the scope
of this document. of this document.
DLEP further requires that security of the implementations (e.g., DLEP further requires that security of the implementations (e.g.,
authentication of stations, encryption of traffic, or both) is dealt authentication of stations, encryption of traffic, or both) is dealt
with by utilizing Layer 2 security techniques. This reliance on with by utilizing Layer 2 security techniques. This reliance on
skipping to change at page 12, line 13 skipping to change at page 12, line 6
by a DLEP router, at regular intervals. The interval MUST be a by a DLEP router, at regular intervals. The interval MUST be a
minimum of one second; it SHOULD be a configurable parameter. Note minimum of one second; it SHOULD be a configurable parameter. Note
that this operation (sending Peer Discovery and waiting for Peer that this operation (sending Peer Discovery and waiting for Peer
Offer) is outside the DLEP Transaction Model (Section 6), as the Offer) is outside the DLEP Transaction Model (Section 6), as the
Transaction Model only describes Messages on a TCP session. Transaction Model only describes Messages on a TCP session.
Routers receiving a Peer Offer Signal MUST use one of the modem Routers receiving a Peer Offer Signal MUST use one of the modem
address/port combinations from the Peer Offer Signal to establish a address/port combinations from the Peer Offer Signal to establish a
TCP connection to the modem, even if a priori configuration exists. TCP connection to the modem, even if a priori configuration exists.
If multiple connection point Data Items exist in the received Peer If multiple connection point Data Items exist in the received Peer
Offer Signal, routers MUST prioritize IPv6 connection points over Offer Signal, routers SHOULD prioritize IPv6 connection points over
IPv4 connection points. If multiple connection points exist with the IPv4 connection points. Routers supporting TLS [RFC5246] MUST
same transport (e.g. IPv6 or IPv4), implementations MAY use their prioritize connection points using TLS over those that do not. If
own heuristics to determine the order in which they are tried. If a multiple connection points exist with the same transport (e.g. IPv6
TCP connection cannot be achieved using any of the address/port or IPv4), implementations MAY use their own heuristics to determine
combinations and the Discovery mechanism is in use, then the router the order in which they are tried. If a TCP connection cannot be
SHOULD resume issuing Peer Discovery Signals. If no Connection Point achieved using any of the address/port combinations and the Discovery
Data Items are included in the Peer Offer Signal, the router MUST use mechanism is in use, then the router SHOULD resume issuing Peer
the source address of the UDP packet containing the Peer Offer Signal Discovery Signals. If no Connection Point Data Items are included in
as the IP address, and the DLEP well-known port number. the Peer Offer Signal, the router MUST use the source address of the
UDP packet containing the Peer Offer Signal as the IP address, and
the DLEP well-known port number.
In the Peer Discovery state, the modem implementation MUST listen for In the Peer Discovery state, the modem implementation MUST listen for
incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or
IPv4 link-local multicast address and port. On receipt of a valid IPv4 link-local multicast address and port. On receipt of a valid
Peer Discovery Signal, it MUST reply with a Peer Offer Signal. Peer Discovery Signal, it MUST reply with a Peer Offer Signal.
Modems MUST be prepared to accept a TCP connection from a router that Modems MUST be prepared to accept a TCP connection from a router that
is not using the Discovery mechanism, i.e. a connection attempt that is not using the Discovery mechanism, i.e. a connection attempt that
occurs without a preceding Peer Discovery Signal. occurs without a preceding Peer Discovery Signal.
skipping to change at page 19, line 37 skipping to change at page 19, line 20
particular Data Item. particular Data Item.
10. DLEP Signals and Messages 10. DLEP Signals and Messages
10.1. General Processing Rules 10.1. General Processing Rules
If an unrecognized, or unexpected Signal is received, or a received If an unrecognized, or unexpected Signal is received, or a received
Signal contains unrecognized, invalid, or disallowed duplicate Data Signal contains unrecognized, invalid, or disallowed duplicate Data
Items, the receiving implementation MUST ignore the Signal. Items, the receiving implementation MUST ignore the Signal.
If a Signal is received with a TTL value that is NOT equal to 1, the If a Signal is received with a TTL value that is NOT equal to 255,
receiving implementation MUST ignore the Signal. the receiving implementation MUST ignore the Signal.
If an unrecognized Message is received, the receiving implementation If an unrecognized Message is received, the receiving implementation
MUST issue a Session Termination Message (Section 10.9) containing a MUST issue a Session Termination Message (Section 10.9) containing a
Status Data Item (Section 11.1) with status code set to 128 'Unknown Status Data Item (Section 11.1) with status code set to 128 'Unknown
Message', see Table 2, and transition to the Session Termination Message', see Table 2, and transition to the Session Termination
state. state.
If an unexpected Message is received, the receiving implementation If an unexpected Message is received, the receiving implementation
MUST issue a Session Termination Message containing a Status Data MUST issue a Session Termination Message containing a Status Data
Item with status code set to 129 'Unexpected Message', and transition Item with status code set to 129 'Unexpected Message', and transition
skipping to change at page 39, line 44 skipping to change at page 39, line 7
If the Length field is 7, the port number specified MUST be used to If the Length field is 7, the port number specified MUST be used to
establish the TCP session. If the TCP Port Number is omitted, i.e. establish the TCP session. If the TCP Port Number is omitted, i.e.
the Length field is 5, the router MUST use the DLEP well-known port the Length field is 5, the router MUST use the DLEP well-known port
number (Section 13.13) to establish the TCP connection. number (Section 13.13) to establish the TCP connection.
The Flags field is defined as: The Flags field is defined as:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved | | Reserved |T|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Reserved: MUST be zero. Reserved for future use. T: :Use TLS flag, indicating whether the TCP connection requires the
use of TLS [RFC5246] (1), or not (0).
Reserved: MUST be zero. Left for future assignment.
11.3. IPv6 Connection Point 11.3. IPv6 Connection Point
The IPv6 Connection Point Data Item indicates the IPv6 address and, The IPv6 Connection Point Data Item indicates the IPv6 address and,
optionally, the TCP port number on the modem available for optionally, the TCP port number on the modem available for
connections. If provided, the router MUST use this information to connections. If provided, the router MUST use this information to
initiate the TCP connection to the modem. initiate the TCP connection to the modem.
The IPv6 Connection Point Data Item contains the following fields: The IPv6 Connection Point Data Item contains the following fields:
skipping to change at page 40, line 42 skipping to change at page 40, line 4
Length: 17 (or 19 if TCP Port included) Length: 17 (or 19 if TCP Port included)
Flags: Flags field, defined below. Flags: Flags field, defined below.
IPv6 Address: The IPv6 address listening on the modem. IPv6 Address: The IPv6 address listening on the modem.
TCP Port Number: TCP Port number on the modem. TCP Port Number: TCP Port number on the modem.
If the Length field is 19, the port number specified MUST be used to If the Length field is 19, the port number specified MUST be used to
establish the TCP session. If the TCP Port Number is omitted, i.e. establish the TCP session. If the TCP Port Number is omitted, i.e.
the Length field is 17, the router MUST use the DLEP well-known port the Length field is 17, the router MUST use the DLEP well-known port
number (Section 13.13) to establish the TCP connection. number (Section 13.13) to establish the TCP connection.
The Flags field is defined as: The Flags field is defined as:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved | | Reserved |T|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Reserved: MUST be zero. Reserved for future use. T: :Use TLS flag, indicating whether the TCP connection requires the
use of TLS [RFC5246] (1), or not (0).
Reserved: MUST be zero. Left for future assignment.
11.4. Peer Type 11.4. Peer Type
The Peer Type Data Item is used by the router and modem to give The Peer Type Data Item is used by the router and modem to give
additional information as to its type. The Peer Type is a string and additional information as to its type. The Peer Type is a string and
is envisioned to be used for informational purposes (e.g., as output is envisioned to be used for informational purposes (e.g., as output
in a display command). in a display command).
The Peer Type Data Item contains the following fields: The Peer Type Data Item contains the following fields:
skipping to change at page 57, line 20 skipping to change at page 57, line 20
The potential security concerns when using DLEP are: The potential security concerns when using DLEP are:
1. An attacker might pretend to be a DLEP participant, either at 1. An attacker might pretend to be a DLEP participant, either at
DLEP session initialization, or by injection of DLEP Messages DLEP session initialization, or by injection of DLEP Messages
once a session has been established, and/or once a session has been established, and/or
2. DLEP Data Items could be altered by an attacker, causing the 2. DLEP Data Items could be altered by an attacker, causing the
receiving implementation to inappropriately alter its information receiving implementation to inappropriately alter its information
base concerning network status. base concerning network status.
Since DLEP is restricted to operation over a single (possibly The implications of attacks on DLEP peers are directly proportional
logical) hop at layer 2, implementations requiring authentication to the extent to which DLEP data is used within the control plane.
and/or encryption of traffic MUST take steps to secure the Layer 2 While the use of DLEP data in other control plane components is out
link. Examples of technologies that can be deployed to secure the of scope for this document, as an example, if DLEP statistics are
incorporated into route cost calculations, adversaries masquerading
as a DLEP peer, and injecting malicious data via DLEP, could cause
suboptimal route selection, adversely impacting network performance.
Similar issues can arise if DLEP data is used as an input to policing
algorithms - injection of malicious data via DLEP can cause those
policing algorithms to make incorrect decisions, degrading network
throughput.
For these reasons, security of the DLEP transport must be considered
at both the transport layer, and at Layer 2.
At the transport layer, implementations of DLEP SHOULD implement, and
use, TLS [RFC5246] to protect the TCP session. Deployments that are
protected by strong physical security (e.g., deployments where the
DLEP router and modem are the only devices on a physical Layer 2
segment) may consider use of DLEP without TLS. When TLS is in use,
each peer SHOULD check the validity of credentials presented by the
other peer during TLS session extablishment. Refer to [RFC7525] for
additional details.
At layer 2 - since DLEP is restricted to operation over a single
(possibly logical) hop, implementations SHOULD also secure the Layer
2 link. Examples of technologies that can be deployed to secure the
Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X].
To avoid potential denial of service attack, it is RECOMMENDED that To avoid potential denial of service attack, it is RECOMMENDED that
implementations using the Peer Discovery mechanism maintain an implementations using the Peer Discovery mechanism maintain an
information base of hosts that persistently fail Session information base of hosts that persistently fail Session
Initialization having provided an acceptable Peer Discovery Signal, Initialization having provided an acceptable Peer Discovery Signal,
and ignore subsequent Peer Discovery Signals from such hosts. and ignore subsequent Peer Discovery Signals from such hosts.
This specification does not address security of the data plane, as it This specification does not address security of the data plane, as it
(the data plane) is not affected, and standard security procedures (the data plane) is not affected, and standard security procedures
skipping to change at page 61, line 5 skipping to change at page 62, line 5
Table 3: DLEP Extension types Table 3: DLEP Extension types
13.7. DLEP IPv4 Connection Point Flags 13.7. DLEP IPv4 Connection Point Flags
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv4 Connection Point Flags". DLEP registry, named "IPv4 Connection Point Flags".
The following table provides initial registry values and the The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry: [RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+ +------------+------------------------------------+
| Bit | Description/Policy | | Bit | Description/Policy |
+------------+----------------------------------+ +------------+------------------------------------+
| 0-7 | Reserved/Specification Required | | 0-6 | Unassigned/Specification Required |
+------------+----------------------------------+ | 7 | Use TLS [RFC5246] indicator |
+------------+------------------------------------+
13.8. DLEP IPv6 Connection Point Flags 13.8. DLEP IPv6 Connection Point Flags
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv6 Connection Point Flags". DLEP registry, named "IPv6 Connection Point Flags".
The following table provides initial registry values and the The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry: [RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+ +------------+------------------------------------+
| Bit | Description/Policy | | Bit | Description/Policy |
+------------+----------------------------------+ +------------+------------------------------------+
| 0-7 | Reserved/Specification Required | | 0-6 | Unassigned/Specification Required |
+------------+----------------------------------+ | 7 | Use TLS [RFC5246] indicator |
+------------+------------------------------------+
13.9. DLEP IPv4 Address Flag 13.9. DLEP IPv4 Address Flag
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv4 Address Flags". DLEP registry, named "IPv4 Address Flags".
The following table provides initial registry values and the The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry: [RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+ +------------+------------------------------------+
| Bit | Description/Policy | | Bit | Description/Policy |
+------------+----------------------------------+ +------------+------------------------------------+
| 0-6 | Reserved/Specification Required | | 0-6 | Unassigned/Specification Required |
| 7 | Add/Drop indicator | | 7 | Add/Drop indicator |
+------------+----------------------------------+ +------------+------------------------------------+
13.10. DLEP IPv6 Address Flag 13.10. DLEP IPv6 Address Flag
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv6 Address Flags". DLEP registry, named "IPv6 Address Flags".
The following table provides initial registry values and the The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry: [RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+ +------------+------------------------------------+
| Bit | Description/Policy | | Bit | Description/Policy |
+------------+----------------------------------+ +------------+------------------------------------+
| 0-6 | Reserved/Specification Required | | 0-6 | Unassigned/Specification Required |
| 7 | Add/Drop indicator | | 7 | Add/Drop indicator |
+------------+----------------------------------+ +------------+------------------------------------+
13.11. DLEP IPv4 Attached Subnet Flag 13.11. DLEP IPv4 Attached Subnet Flag
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv4 Attached Subnet Flags". DLEP registry, named "IPv4 Attached Subnet Flags".
The following table provides initial registry values and the The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry: [RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+ +------------+------------------------------------+
| Bit | Description/Policy | | Bit | Description/Policy |
+------------+----------------------------------+ +------------+------------------------------------+
| 0-6 | Reserved/Specification Required | | 0-6 | Unassigned/Specification Required |
| 7 | Add/Drop indicator | | 7 | Add/Drop indicator |
+------------+----------------------------------+ +------------+------------------------------------+
13.12. DLEP IPv6 Attached Subnet Flag 13.12. DLEP IPv6 Attached Subnet Flag
Upon approval of this document, IANA is requested to create a new Upon approval of this document, IANA is requested to create a new
DLEP registry, named "IPv6 Attached Subnet Flags". DLEP registry, named "IPv6 Attached Subnet Flags".
The following table provides initial registry values and the The following table provides initial registry values and the
[RFC5226] defined policies that should apply to the registry: [RFC5226] defined policies that should apply to the registry:
+------------+----------------------------------+ +------------+------------------------------------+
| Bit | Description/Policy | | Bit | Description/Policy |
+------------+----------------------------------+ +------------+------------------------------------+
| 0-6 | Reserved/Specification Required | | 0-6 | Unassigned/Specification Required |
| 7 | Add/Drop indicator | | 7 | Add/Drop indicator |
+------------+----------------------------------+ +------------+------------------------------------+
13.13. DLEP Well-known Port 13.13. DLEP Well-known Port
Upon approval of this document, IANA is requested to assign a single Upon approval of this document, IANA is requested to assign a single
value in the "Service Name and Transport Protocol Port Number value in the "Service Name and Transport Protocol Port Number
Registry" found at https://www.iana.org/assignments/service-names- Registry" found at https://www.iana.org/assignments/service-names-
port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as
defined in this document. This assignment should be valid for TCP defined in this document. This assignment should be valid for TCP
and UDP. and UDP.
skipping to change at page 63, line 46 skipping to change at page 64, line 46
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C.
Pignataro, "The Generalized TTL Security Mechanism Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007,
<http://www.rfc-editor.org/info/rfc5082>. <http://www.rfc-editor.org/info/rfc5082>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
15.2. Informative References 15.2. Informative References
[CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF
draft draft-ietf-manet-credit-window-04, March 2016. draft draft-ietf-manet-credit-window-04, March 2016.
[IEEE-802.1AE] [IEEE-802.1AE]
"IEEE Standards for Local and Metropolitan Area Networks: "IEEE Standards for Local and Metropolitan Area Networks:
Media Access Control (MAC) Security", Media Access Control (MAC) Security",
DOI 10.1109/IEEESTD.2006.245590, August 2006. DOI 10.1109/IEEESTD.2006.245590, August 2006.
skipping to change at page 64, line 25 skipping to change at page 65, line 30
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and
M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit
Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578,
February 2010, <http://www.rfc-editor.org/info/rfc5578>. February 2010, <http://www.rfc-editor.org/info/rfc5578>.
Appendix A. Discovery Signal Flows [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
Appendix A. Discovery Signal Flows
Router Modem Signal Description Router Modem Signal Description
======================================================================== ========================================================================
| Router initiates discovery, starts | Router initiates discovery, starts
| a timer, send Peer Discovery | a timer, send Peer Discovery
|-------Peer Discovery---->X Signal. |-------Peer Discovery---->X Signal.
~ ~ ~ ~ ~ ~ ~ Router discovery timer expires ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires
without receiving Peer Offer. without receiving Peer Offer.
 End of changes. 40 change blocks. 
129 lines changed or deleted 164 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/