< draft-ietf-manet-dlep-18.txt   draft-ietf-manet-dlep-19.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: August 7, 2016 Cisco Systems Expires: August 21, 2016 Cisco Systems
D. Satterwhite D. Satterwhite
Broadcom Broadcom
R. Taylor R. Taylor
Airbus Defence & Space Airbus Defence & Space
B. Berry B. Berry
February 4, 2016 February 18, 2016
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-18 draft-ietf-manet-dlep-19
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 43 skipping to change at page 1, line 43
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 August 7, 2016. This Internet-Draft will expire on August 21, 2016.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9
3. Destinations . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Destinations . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Router-requested Destinations . . . . . . . . . . . . . . 10 3.1. Router-requested Destinations . . . . . . . . . . . . . . 10
4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 12 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 12 5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 13
5.2. Session Initialization State . . . . . . . . . . . . . . 14 5.2. Session Initialization State . . . . . . . . . . . . . . 14
5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 15 5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 16 5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 16
5.4. Session Termination State . . . . . . . . . . . . . . . . 16 5.4. Session Termination State . . . . . . . . . . . . . . . . 16
5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 17 5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 17
5.5.1. Unexpected TCP connection termination . . . . . . . . 17 5.5.1. Unexpected TCP connection termination . . . . . . . . 17
6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 17 6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 17
7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 19
8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 19 9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 19
9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 20 9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 20
9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 20 9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 21
9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 21 9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 21
10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 21 10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 22
10.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . 22 10.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . 23
10.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 23 10.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 24
10.3. Session Initialization Message . . . . . . . . . . . . . 23 10.3. Session Initialization Message . . . . . . . . . . . . . 24
10.4. Session Initialization Response Message . . . . . . . . 24 10.4. Session Initialization Response Message . . . . . . . . 25
10.5. Session Update Message . . . . . . . . . . . . . . . . . 26 10.5. Session Update Message . . . . . . . . . . . . . . . . . 27
10.6. Session Update Response Message . . . . . . . . . . . . 27 10.6. Session Update Response Message . . . . . . . . . . . . 28
10.7. Session Termination Message . . . . . . . . . . . . . . 28 10.7. Session Termination Message . . . . . . . . . . . . . . 28
10.8. Session Termination Response Message . . . . . . . . . . 28 10.8. Session Termination Response Message . . . . . . . . . . 29
10.9. Destination Up Message . . . . . . . . . . . . . . . . . 28 10.9. Destination Up Message . . . . . . . . . . . . . . . . . 29
10.10. Destination Up Response Message . . . . . . . . . . . . 30 10.10. Destination Up Response Message . . . . . . . . . . . . 30
10.11. Destination Announce Message . . . . . . . . . . . . . . 30 10.11. Destination Announce Message . . . . . . . . . . . . . . 31
10.12. Destination Announce Response Message . . . . . . . . . 31 10.12. Destination Announce Response Message . . . . . . . . . 31
10.13. Destination Down Message . . . . . . . . . . . . . . . . 32 10.13. Destination Down Message . . . . . . . . . . . . . . . . 33
10.14. Destination Down Response Message . . . . . . . . . . . 32 10.14. Destination Down Response Message . . . . . . . . . . . 33
10.15. Destination Update Message . . . . . . . . . . . . . . . 33 10.15. Destination Update Message . . . . . . . . . . . . . . . 34
10.16. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34 10.16. Heartbeat Message . . . . . . . . . . . . . . . . . . . 35
10.17. Link Characteristics Request Message . . . . . . . . . . 35 10.17. Link Characteristics Request Message . . . . . . . . . . 35
10.18. Link Characteristics Response Message . . . . . . . . . 35 10.18. Link Characteristics Response Message . . . . . . . . . 36
11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 37 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 39
11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 40 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 41
11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 41 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 42
11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 42 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 43
11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 43 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 44
11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 43 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 44
11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 44 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 45
11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 45 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 46
11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 46 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 47
11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 47 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 48
11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 48 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 49
11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 49 11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 50
11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 49 11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 50
11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 50 11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 51
11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 51 11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 52
11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 52 11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 53
11.17. Resources (Receive) . . . . . . . . . . . . . . . . . . 52 11.17. Resources (Receive) . . . . . . . . . . . . . . . . . . 53
11.18. Resources (Transmit) . . . . . . . . . . . . . . . . . . 53 11.18. Resources (Transmit) . . . . . . . . . . . . . . . . . . 54
11.19. Relative Link Quality (Receive) . . . . . . . . . . . . 54 11.19. Relative Link Quality (Receive) . . . . . . . . . . . . 55
11.20. Relative Link Quality (Transmit) . . . . . . . . . . . . 54 11.20. Relative Link Quality (Transmit) . . . . . . . . . . . . 55
11.21. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 55 11.21. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 56
12. Security Considerations . . . . . . . . . . . . . . . . . . . 56 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57
13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 56 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 57
13.2. Signal/Message Type Registration . . . . . . . . . . . . 57 13.2. Signal/Message Type Registration . . . . . . . . . . . . 58
13.3. DLEP Data Item Registrations . . . . . . . . . . . . . . 57 13.3. DLEP Data Item Registrations . . . . . . . . . . . . . . 58
13.4. DLEP Status Code Registrations . . . . . . . . . . . . . 57 13.4. DLEP Status Code Registrations . . . . . . . . . . . . . 58
13.5. DLEP Extensions Registrations . . . . . . . . . . . . . 58 13.5. DLEP Extensions Registrations . . . . . . . . . . . . . 59
13.6. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 58 13.6. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 59
13.7. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 58 13.7. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 59
13.8. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 58 13.8. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 59
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 60
15.1. Normative References . . . . . . . . . . . . . . . . . . 59 15.1. Normative References . . . . . . . . . . . . . . . . . . 60
15.2. Informative References . . . . . . . . . . . . . . . . . 59 15.2. Informative References . . . . . . . . . . . . . . . . . 60
Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 59 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 60
Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 60 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 61
B.1. Session Initialization . . . . . . . . . . . . . . . . . 60 B.1. Session Initialization . . . . . . . . . . . . . . . . . 61
B.2. Session Initialization - Refused . . . . . . . . . . . . 61 B.2. Session Initialization - Refused . . . . . . . . . . . . 62
B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 61 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 62
B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 61 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 62
B.5. Router Terminates Session . . . . . . . . . . . . . . . . 62 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 63
B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 62 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 63
B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 63 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 64
B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 64 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 65
B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 65 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 66
Appendix C. Destination Specific Message Flows . . . . . . . . . 65 Appendix C. Destination Specific Message Flows . . . . . . . . . 66
C.1. Common Destination Notification . . . . . . . . . . . . . 65 C.1. Common Destination Notification . . . . . . . . . . . . . 66
C.2. Multicast Destination Notification . . . . . . . . . . . 66 C.2. Multicast Destination Notification . . . . . . . . . . . 67
C.3. Link Characteristics Request . . . . . . . . . . . . . . 67 C.3. Link Characteristics Request . . . . . . . . . . . . . . 68
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69
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 7, line 44 skipping to change at page 7, line 44
Figure 2: DLEP Network with Multiple Modem Devices Figure 2: DLEP Network with Multiple Modem Devices
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [RFC2119]. 14, RFC 2119 [RFC2119].
DLEP requires that the MAC address for delivering data traffic is the
MAC address used by DLEP to identify the destination. No
manipulation or substitution is performed; the MAC address supplied
in all destination messages is used as the OSI Layer 2 Destination
MAC address. DLEP also requires that MAC addresses are unique within
the context of a router-modem session.
The reliance on MAC addresses by DLEP forces the requirement that
participating DLEP peers are on a single segment (either physical or
logically, via tunneling protocols) at Layer 2.
2. Protocol Overview 2. Protocol Overview
DLEP defines a set of messages used by modems and their attached DLEP defines a set of messages used by modems and their attached
routers to communicate events that occur on the physical link(s) routers to communicate events that occur on the physical link(s)
managed by the modem: for example, a remote node entering or leaving managed by the modem: for example, a remote node entering or leaving
the network, or that the link has changed. Associated with these the network, or that the link has changed. Associated with these
messages are a set of Data Items - information that describes the messages are a set of Data Items - information that describes the
remote node (e.g., address information), and/or the characteristics remote node (e.g., address information), and/or the characteristics
of the link to the remote node. Throughout this document, we refer of the link to the remote node. Throughout this document, we refer
to a modems/routers participating in a DLEP session as 'DLEP Peers', to a modems/routers participating in a DLEP session as 'DLEP Peers',
unless a specific distinction (e.g. modem or router) is required. or 'DLEP Participants', unless a specific distinction (e.g. modem or
router) is required.
DLEP uses a session-oriented paradigm between the modem device and DLEP uses a session-oriented paradigm between the modem device and
its associated router. If multiple modem devices are attached to a its associated router. If multiple modem devices are attached to a
router (as in Figure 2), or the modem supports multiple connections router (as in Figure 2), or the modem supports multiple connections
(via multiple logical or physical interfaces), then separate DLEP (via multiple logical or physical interfaces), then separate DLEP
sessions exist for each modem or connection. A router and modem form sessions exist for each modem or connection. A router and modem form
a session by completing the discovery and initialization process. a session by completing the discovery and initialization process.
This router-modem session persists unless or until it either (1) This router-modem session persists unless or until it either (1)
times out, based on the absence of traffic (including heartbeats), or times out, based on the absence of traffic (including heartbeats), or
(2) is explicitly torn down by one of the participants. (2) is explicitly torn down by one of the participants.
skipping to change at page 9, line 22 skipping to change at page 9, line 36
TCP for transport of the control messages. Therefore, DLEP assumes TCP for transport of the control messages. Therefore, DLEP assumes
that the modem and router have topologically consistent IP addresses that the modem and router 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. DLEP relies on the guaranteed- delivery of its messages assignment. DLEP relies on the guaranteed- delivery of its messages
between router and modem, once the 1 hop discovery process is between router and modem, once the 1 hop discovery process is
complete, hence, the specification of TCP to carry the messages. complete, hence, the specification of TCP to carry the messages.
Other reliable transports for the protocol are possible, but are Other reliable transports for the protocol are possible, but are
outside the scope of this document. outside the scope of this document.
DLEP assumes that the MAC address for delivering data traffic is the DLEP further assumes that security of the implementations (e.g.,
MAC address used by DLEP to identify the destination. No authentication of stations, encryption of traffic, or both) is dealt
manipulation or substitution is performed; the MAC address supplied with by utilizing Layer 2 security techniques. This reliance on
in all destination messages is used as the OSI Layer 2 Destination Layer 2 mechanisms secures all DLEP messages - both the UDP discovery
MAC address. DLEP also assumes that MAC addresses are unique within
the context of a router-modem session.
The reliance on MAC addresses by DLEP forces the assumption that
participating DLEP peers are on a single segment (either physical or
logically, via tunneling protocols) at Layer 2. DLEP further assumes
that security of the implementations (e.g., authentication of
stations, encryption of traffic, or both) is dealt with by by
utilizing Layer 2 security techniques. This reliance on Layer 2
mechanisms secures all DLEP messages - both the UDP discovery
messages and the TCP control messages. messages and the TCP control messages.
3. Destinations 3. Destinations
Destination messages describe the acquisition and loss of network Destination messages describe the acquisition and loss of network
destinations, and control the flow of information about the destinations, and control the flow of information about the
destinations in the several ways. A destination MUST contain a MAC destinations in the several ways. A destination MUST contain a MAC
address; it MAY optionally include a Layer 3 address (or multiple address; it MAY optionally include a Layer 3 address (or multiple
addresses). The MAC address MAY reference a logical destination, as addresses). The MAC address MAY reference a logical destination, as
in a derived multicast MAC address, as well as a physical device. As in a derived multicast MAC address, as well as a physical device. As
skipping to change at page 30, line 29 skipping to change at page 31, line 21
The Destination Up Response message MAY contain one Status The Destination Up Response message MAY contain one Status
(Section 11.1) data item. (Section 11.1) data item.
A modem receiving a Destination Up Response message without a Status A modem receiving a Destination Up Response message without a Status
data item MUST behave as if a Status data item with status code data item MUST behave as if a Status data item with status code
'Success' had been received, see Table 3. 'Success' had been received, see Table 3.
10.11. Destination Announce Message 10.11. Destination Announce Message
If a router wishes to request information concerning a destination If a router wishes to request information concerning a destination
that has not yet been announced by a mode via a Destination Up that has not yet been announced by a modem via a Destination Up
message (Section 10.9), it MAY send a Destination Announce message to message (Section 10.9), it MAY send a Destination Announce message to
the modem. the modem.
A Destination Announce message MUST be acknowledged by the modem A Destination Announce message MUST be acknowledged by the modem
issuing a Destination Announce Response message (Section 10.12). issuing a Destination Announce Response message (Section 10.12).
To construct a Destination Announce message, the Message Type value To construct a Destination Announce message, the Message Type value
in the message header is set to 17, from Table 1. in the message header is set to 17, from Table 1.
The Destination Announce message MUST contain one of each of the The Destination Announce message MUST contain one of each of the
skipping to change at page 41, line 7 skipping to change at page 42, 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.6) to establish the TCP connection. number (Section 13.6) 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 |T| | Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
T: Use TLS flag, indicating whether the TCP connection requires the
use of TLS (1), or not (0).
Reserved: MUST be zero. Reserved for future use. Reserved: MUST be zero. Reserved for future use.
11.3. IPv6 Connection Point 11.3. IPv6 Connection Point
The IPv6 Connection Point data item MAY appear in the Peer Offer The IPv6 Connection Point data item MAY appear in the Peer Offer
signal (Section 10.2). signal (Section 10.2).
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 DLEP modem available for optionally, the TCP port number on the DLEP modem available for
connections. If provided, the router MUST use this information to connections. If provided, the router MUST use this information to
skipping to change at page 42, line 14 skipping to change at page 43, line 14
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.6) to establish the TCP connection. number (Section 13.6) 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 |T| | Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
T: Use TLS flag, indicating whether the TCP connection requires the
use of TLS (1), or not (0).
Reserved: MUST be zero. Reserved for future use. Reserved: MUST be zero. Reserved for future use.
11.4. Peer Type 11.4. Peer Type
The Peer Type data item MAY appear in the Peer Discovery The Peer Type data item MAY appear in the Peer Discovery
(Section 10.1) and Peer Offer (Section 10.2) signals, and the Session (Section 10.1) and Peer Offer (Section 10.2) signals, and the Session
Initialization (Section 10.3) and Session Initialization Response Initialization (Section 10.3) and Session Initialization Response
(Section 10.4) messages. (Section 10.4) messages.
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
skipping to change at page 56, line 23 skipping to change at page 57, line 23
session initialization, or by injection of messages once a session initialization, or by injection of messages once a
session has been established, and/or 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 Since DLEP is restricted to operation over a single (possibly
logical) hop at layer 2, implementations requiring authentication logical) hop at layer 2, implementations requiring authentication
and/or encryption of traffic MUST take steps to secure the Layer 2 and/or encryption of traffic MUST take steps to secure the Layer 2
link. link. Examples of technologies that can be deployed to secure the
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 Discovery signal, and Initialization having provided an acceptable Discovery signal, and
ignore Peer Discovery signals from such hosts. ignore 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
can be employed. can be employed.
skipping to change at page 59, line 35 skipping to change at page 60, line 35
[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>.
[IEEE-802.1AE]
IEEE Standards for Local and Metropolitan Area
Networks: Media Access Control (MAC) Security, July 2006
[IEEE-802.1X]
IEEE Standards for Local and Metropolitan Area
Networks: Port based Network Access Control, IEEE
P802.1x-2001, June 2001.
Appendix A. Discovery Signal Flows 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---->|| signal. |-------Peer Discovery---->|| signal.
~ ~ ~ ~ ~ ~ ~ Router discovery timer expires ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires
without receiving Peer Offer. without receiving Peer Offer.
 End of changes. 23 change blocks. 
100 lines changed or deleted 106 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/