draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt   draft-ietf-dhc-dhcpv6-pd-relay-requirements-01.txt 
DHC Work Group I. Farrer DHC Work Group I. Farrer
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Standards Track Naveen. Kottapalli Intended status: Standards Track Naveen. Kottapalli
Expires: September 6, 2020 Benu Networks Expires: December 10, 2020 Benu Networks
M. Hunek M. Hunek
Technical University of Liberec Technical University of Liberec
Richard. Patterson R. Patterson
March 5, 2020 Sky UK Ltd
June 8, 2020
DHCPv6 Prefix Delegating Relay DHCPv6 Prefix Delegating Relay
draft-ietf-dhc-dhcpv6-pd-relay-requirements-00 draft-ietf-dhc-dhcpv6-pd-relay-requirements-01
Abstract Abstract
Operational experience with DHCPv6 prefix delegation has shown that Operational experience with DHCPv6 prefix delegation (PD) has shown
when the DHCPv6 relay function is not co-located with the DHCPv6 that when the DHCPv6 relay function is not co-located with the DHCPv6
server function, issues such as timer synchronization between the server function, issues such as timer synchronization between the
DHCP functional elements, rejection of client's messages by the DHCP functional elements, rejection of client's messages by the
relay, and other problems have been observed. These problems can relay, and other problems have been observed. These problems can
result in prefix delegation failing or traffic to/from clients result in prefix delegation failing or traffic to/from clients
addressed from the delegated prefix being unrouteable. Although addressed from the delegated prefix not being routed. Although
[RFC8415] mentions this deployment scenario, it does not provide RFC8415 mentions this deployment scenario, it does not provide
necessary detail on how the relay element should behave when used necessary detail on how the relay element should behave when used
with PD. with PD.
This document describes functional requirements for a DHCPv6 PD relay This document describes functional requirements for a DHCPv6 PD relay
when used for relaying prefixes delegated by a separate DHCPv6 when used for relaying prefixes delegated by a separate DHCPv6
server. server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 47 skipping to change at page 1, line 48
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 September 6, 2020. This Internet-Draft will expire on December 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Topology . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Problems Observed with Existing Delegating Relays 3. Problems Observed with Existing Delegating Relay
Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 Implementations . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. DHCP Messages not being Forwarded by the Delegating relay 5 3.1. DHCP Messages not being Forwarded by the Delegating Relay 5
3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6
3.3. Multiple Simultaneous Delegated Prefixes for a Single 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6
DUID on a Single Client . . . . . . . . . . . . . . 6
3.4. Dropping Messages from Devices with Duplicate MAC 3.4. Dropping Messages from Devices with Duplicate MAC
addresses and DUIDs . . . . . . . . . . . . . . . . 6 addresses and DUIDs . . . . . . . . . . . . . . . . 6
4. Requirements for Delegating Relays . . . . . . . . . . . . . 6 4. Requirements for Delegating Relays . . . . . . . . . . . . . 6
4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7
4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 7 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8
4.3. Service Continuity Requirements . . . . . . . . . . . . . 8 4.3. Service Continuity Requirements . . . . . . . . . . . . . 8
4.4. Operational Requirements . . . . . . . . . . . . . . . . 8 4.4. Operational Requirements . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
For Internet service providers that offer native IPv6 access with For Internet service providers that offer native IPv6 access with
prefix delegation to their customers, a common deployment prefix delegation to their customers, a common deployment
architecture is to have a DHCPv6 relay agent function located in the architecture is to have a DHCPv6 relay agent function located in the
ISP's Layer-3 customer edge device and separate, centralized DHCPv6 ISP's Layer-3 customer edge device and separate, centralized DHCPv6
server infrastructure. [RFC8415] describes the functionality of a server infrastructure. [RFC8415] describes the functionality of a
skipping to change at page 3, line 28 skipping to change at page 3, line 27
The mechanisms for a relay to inject routes (including aggregated The mechanisms for a relay to inject routes (including aggregated
ones), on its network-facing interface based on prefixes learnt from ones), on its network-facing interface based on prefixes learnt from
a server via DHCP-PD are out of scope of the document. a server via DHCP-PD are out of scope of the document.
Multi-hop relaying is also not considered as the functionality is Multi-hop relaying is also not considered as the functionality is
solely required by a DHCP relay agent that is co-located with the solely required by a DHCP relay agent that is co-located with the
first-hop router that the DHCPv6 client requesting the prefix is first-hop router that the DHCPv6 client requesting the prefix is
connected to. connected to.
The behavior defined in [RFC7283] is also applicable for DHCv6-PD- The behavior for handling unknown messages defined in Section 19. of
relay deployments. [RFC8415] is also applicable for relay deployments.
2. Terminology 2. Terminology
2.1. General 2.1. General
This document uses the terminology defined in [RFC8415], however when This document uses the terminology defined in [RFC8415], however when
defining the functional elements for prefix delegation [RFC8415], defining the functional elements for prefix delegation [RFC8415],
Section 4.2 defines the term 'delegating router' as: Section 4.2 defines the term 'delegating router' as:
"The router that acts as a DHCP server and responds to requests "The router that acts as a DHCP server and responds to requests
skipping to change at page 4, line 11 skipping to change at page 4, line 9
forwarding DHCPv6 messages containing IA_PD/IAPREFIX forwarding DHCPv6 messages containing IA_PD/IAPREFIX
options between the client and server. The options between the client and server. The
delegating relay does not implement a DHCPv6 server delegating relay does not implement a DHCPv6 server
function. The delegating relay is also responsible function. The delegating relay is also responsible
for routing traffic for the delegated prefixes. for routing traffic for the delegated prefixes.
Where the term 'relay' is used on its own within this document, it Where the term 'relay' is used on its own within this document, it
should be understood to be a delegating relay, unless specifically should be understood to be a delegating relay, unless specifically
stated otherwise. stated otherwise.
In CableLabs DOCSIS environments, the Cable Modem Termination System
(CMTS) would be considered a delegating relay with respect to
Customer Premises Devices (CPEs). A Broadband Network Gateway (BNG)
in a DSL based access network may be a delegating relay if it does
not implement a local DHCPv6 server function.
[RFC8415] defines the 'DHCP server', (or 'server') as: [RFC8415] defines the 'DHCP server', (or 'server') as:
"A node that responds to requests from clients. It may or may not "A node that responds to requests from clients. It may or may not
be on the same link as the client(s). Depending on its be on the same link as the client(s). Depending on its
capabilities, if it supports prefix delegation it may also feature capabilities, if it supports prefix delegation it may also feature
the functionality of a delegating router. the functionality of a delegating router."
This document serves the deployment cases where a DHCPv6 server is This document serves the deployment cases where a DHCPv6 server is
not located on the same link as the client (necessitating the not located on the same link as the client (necessitating the
delegating relay). The server supports prefix delegation and is delegating relay). The server supports prefix delegation and is
capable of leasing prefixes to clients, but is not responsible for capable of leasing prefixes to clients, but is not responsible for
other functions required of a delegating router, such as managing other functions required of a delegating router, such as managing
routes for the delegated prefixes. routes for the delegated prefixes.
The term 'requesting router' has previously been used to describe the The term 'requesting router' has previously been used to describe the
DHCP client requesting prefixes for use. This document adopts the DHCP client requesting prefixes for use. This document adopts the
skipping to change at page 5, line 26 skipping to change at page 5, line 28
"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 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. This document uses these keywords not capitals, as shown here. This document uses these keywords not
strictly for the purpose of interoperability, but rather for the strictly for the purpose of interoperability, but rather for the
purpose of establishing industry-common baseline functionality. As purpose of establishing industry-common baseline functionality. As
such, the document points to several other specifications (preferably such, the document points to several other specifications (preferably
in RFC or stable form) to provide additional guidance to implementers in RFC or stable form) to provide additional guidance to implementers
regarding any protocol implementation required to produce a DHCP regarding any protocol implementation required to produce a DHCP
relaying router that functions successfully with prefix delegation. relaying router that functions successfully with prefix delegation.
3. Problems Observed with Existing Delegating Relays Implementations 3. Problems Observed with Existing Delegating Relay Implementations
The following sections of the document describe problems that have The following sections of the document describe problems that have
been observed with delegating relay implementations in commercially been observed with delegating relay implementations in commercially
available devices. available devices.
3.1. DHCP Messages not being Forwarded by the Delegating relay 3.1. DHCP Messages not being Forwarded by the Delegating Relay
Delegating relay implementations have been observed not to forward Delegating relay implementations have been observed not to forward
messages between the client and server. This generally occurs if a messages between the client and server. This generally occurs if a
client sends a message which is unexpected by the delegating relay. client sends a message which is unexpected by the delegating relay.
For example, the delegating router already has an active PD lease For example, the delegating router already has an active PD lease
entry for an existing client on a port. A new client is connected to entry for an existing client on a port. A new client is connected to
this port and sends a solicit message. The delegating relay then this port and sends a Solicit message. The delegating relay then
drops the solicit messages until it receives either a DHCP release drops the Solicit messages until it receives either a DHCP Release
message from the original client, or the existing lease times out. message from the original client, or the existing lease times out.
This causes a particular problem when a client device needs to be This causes a particular problem when a client device needs to be
replaced due to a failure. replaced due to a failure.
In addition to dropping messages, in some cases the delegating relay In addition to dropping messages, in some cases the delegating relay
will generate error messages and send them to the client, e.g. will generate error messages and send them to the client, e.g.
'NoBinding' messages being sent in the event that the delegating 'NoBinding' messages being sent in the event that the delegating
relay does not have an active delegated prefix lease. relay does not have an active delegated prefix lease.
3.2. Delegating Relay Loss of State on Reboot 3.2. Delegating Relay Loss of State on Reboot
For proper routing of client's traffic, the delegating relay requires For proper routing of client traffic, the delegating relay requires a
a corresponding routing table entry for each active prefix delegated corresponding routing table entry for each active prefix delegated to
to a connected client. A delegating router which does not store this a connected client. A delegating router which does not store this
state persistently across reboots will not be able to forward traffic state persistently across reboots will not be able to forward traffic
to client's delegated leases until the state is re-established to client's delegated leases until the state is re-established
through new DHCP messages. through new DHCP messages.
3.3. Multiple Simultaneous Delegated Prefixes for a Single DUID on a 3.3. Multiple Delegated Prefixes for a Single Client
Single Client
[RFC8415] allows for a client to include more than one instance of [RFC8415] allows for a client to include more than one instance of
OPTION_IA_PD in messages in order to request multiple prefix OPTION_IA_PD in messages in order to request multiple prefix
delegations by the server. If configured for this, the server delegations by the server. If configured for this, the server
supplies one instance of OPTION_IAPREFIX for each received instance supplies one (or more) instance of OPTION_IAPREFIX for each received
of OPTION_IA_PD, each containing information for a different instance of OPTION_IA_PD, each containing information for a different
delegated prefix. delegated prefix.
In some delegating relay implementations, only a single delegated In some delegating relay implementations, only a single delegated
prefix per-DUID is supported. In those cases only one IPv6 route for prefix per-DUID is supported. In those cases only one IPv6 route for
only one of the delegated router is installed; meaning that other one of the delegated prefixes is installed; meaning that other
prefixes delegated to a client are unreachable. prefixes delegated to a client are unreachable.
3.4. Dropping Messages from Devices with Duplicate MAC addresses and 3.4. Dropping Messages from Devices with Duplicate MAC addresses and
DUIDs DUIDs
It is an unfortunate operational reality that client devices with It is an unfortunate operational reality that client devices with
duplicate MAC addresses and/or DUIDs exist and have been deployed. duplicate MAC addresses and/or DUIDs exist and have been deployed.
In this situation, the operational costs of locating and swapping out In this situation, the operational costs of locating and swapping out
such devices are prohibitive. such devices are prohibitive.
Delegating relays have been observed to restrict forwarding client Delegating relays have been observed to restrict forwarding client
messages originating from one client DUID to a single interface. In messages originating from one client DUID to a single interface. In
this case if the same client DUID appears from a second client on this case if the same client DUID appears from a second client on
another interface while there is already an active lease, messages another interface while there is already an active lease, messages
originating from the second client are dropped causing the second originating from the second client are dropped causing the second
client to be unable to obtain a prefix delegation. client to be unable to obtain a prefix delegation.
It should be noted that in some access networks, the MAC address and/
or DUID are used as part of device identification and authentication.
In such networks, enforcing MAC address/DUID uniqueness is a
necessary function and not considered a problem.
4. Requirements for Delegating Relays 4. Requirements for Delegating Relays
To resolve the problems described in Section 3 the following section To resolve the problems described in Section 3 the following section
of the document describes a set of functional requirements for the of the document describes a set of functional requirements for the
delegating relay. delegating relay.
4.1. General Requirements 4.1. General Requirements
G-1: The delegating router MUST forward messages bidirectionally G-1: The delegating router MUST forward messages bidirectionally
between the client and server without changing the contents between the client and server without changing the contents
of the message. of the message.
G-2: As described in Section 16 of [RFC8415], in the event that a G-2: As described in Section 16 of [RFC8415], in the event that a
received message contains a DHCPv6 option which the relay received message contains a DHCPv6 option which the relay
does not implement, the message MUST be forwarded. does not implement, the message MUST be forwarded.
G-3: The relay MUST allow for multiple prefixes to be delegated G-3: The relay MUST allow for multiple prefixes to be delegated
for the same client IA_PD. These delegations may have for the same client IA_PD. These delegations may have
different lifetimes. different lifetimes.
G-4: The relay MUST allow for multiple prefixes with separate G-4: The relay MUST allow for multiple prefixes (with or without
IA_PDs to be delegated to a single client connected to a separate IA_PDs) to be delegated to a single client connected
single interface, identified by its DHCPv6 Client Identifier to a single interface, identified by its DHCPv6 Client
(DUID). Identifier (DUID).
G-5: The relay MUST allow the same client identifier (DUID) to G-5: If a device has multiple interfaces that implement a
have active delegated prefix leases on more than one delegating relay function, the device SHOULD allow the same
interface simultaneously. This is to allow client devices client identifier (DUID) to have active delegated prefix
leases on more than one interface simultaneously, unless
client DUID uniqueness is necessary for the functioning or
security of the network. This is to allow client devices
with duplicate DUIDs to function on separate broadcast with duplicate DUIDs to function on separate broadcast
domains. domains.
G-6: The maximum number of simultaneous prefixes delegated to a G-6: The maximum number of simultaneous prefixes delegated to a
single client MUST be configurable. single client MUST be configurable.
G-7: The relay MUST implement a mechanism to limit the maximum G-7: The relay MUST implement a mechanism to limit the maximum
number of active prefix delegations on a single port for all number of active prefix delegations on a single port for all
client identifiers and IA_PDs. This value SHOULD be client identifiers and IA_PDs. This value MUST be
configurable. configurable.
G-8: The delegating relay MUST synchronize the lifetimes of active G-8: It is RECOMMENDED that delegating relays support at least 8
prefix delegation leases with server. active delegated leases per client device and use this as the
default limit.
G-9: The delegating relay MUST update the lease lifetimes based on
the Client Reply messages it forwards to the client and only
expire the delegated prefixes when the valid lifetime has
elapsed.
G-10: On receipt of a Release message from the client, the
delegating relay MUST expire the active leases for each of
the IA_PDs in the message.
4.2. Routing Requirements 4.2. Routing Requirements
R-1: The relay MUST maintain a local routing table that is R-1: The relay MUST maintain a local routing table that is
dynamically updated with prefixes and the associated next- dynamically updated with prefixes and the associated next-
hops as they are delegated to clients. When a delegated hops as they are delegated to clients. When a delegated
prefix is released or expires, the associated route MUST be prefix is Released or expires, the associated route MUST be
removed from the relay's routing table. removed from the relay's routing table.
R-2: The relay MUST provide a mechanism to dynamically update R-2: The relay MUST provide a mechanism to dynamically update
access control lists permitting ingress traffic sourced from access control lists permitting ingress traffic sourced from
clients' delegated prefixes. This is to implement anti- client delegated prefixes. This is to implement anti-
spoofing as described in [BCP38]. spoofing as described in [BCP38].
R-3: The relay MAY provide a mechanism to dynamically advertise R-3: The relay MAY provide a mechanism to dynamically advertise
delegated prefixes into an routing protocol as they are delegated prefixes into an routing protocol as they are
learnt. When a delegated prefix is released or expires, the learnt. When a delegated prefix is released or expires, the
delegated route MUST be withdrawn from the routing protocol. delegated route MUST be withdrawn from the routing protocol.
The mechanism using which the routes are inserted and deleted The mechanism by which the routes are inserted and deleted is
is out of the scope of this document. out of the scope of this document.
R-4: If the relay has an existing route for a delegated prefix via
an interface, and receives ingress traffic on this interface
with a destination address from the delegated prefix (not
configured on the relay), then it MUST be dropped.
4.3. Service Continuity Requirements 4.3. Service Continuity Requirements
S-1: In the event that the relay is restarted, active client S-1: In the event that the relay is restarted, active client
prefix delegations will be lost. This may result in clients prefix delegations will be lost. This may result in clients
becoming unreachable. In order to mitigate this problem, it becoming unreachable. In order to mitigate this problem, it
is RECOMMENDED that the relay implements either of the is RECOMMENDED that the relay implements either of the
following: following:
The relay MAY implement DHCPv6 bulk lease query as * The relay MAY implement DHCPv6 bulk lease query as defined
defined in [RFC5460]. in [RFC5460].
The relay SHOULD store active prefix delegations in * The relay SHOULD store active prefix delegations in
persistent storage so they can be re-read after the persistent storage so they can be re-read after the
reboot. reboot.
S-2: If a client's next-hop link-local address becomes unreachable S-2: If a client's next-hop link-local address becomes unreachable
(e.g., due to a link-down event on the relevant physical (e.g., due to a link-down event on the relevant physical
interface), routes for the client's delegated prefixes MUST interface), routes for the client's delegated prefixes MUST
be retained by the delegating relay unless they are released be retained by the delegating relay unless they are released
or removed due to expiring DHCP timers. This is to re- or removed due to expiring DHCP timers. This is to re-
establish routing for the delegated prefix if the client establish routing for the delegated prefix if the client
next-hop becomes reachable without the relay needing to be next-hop becomes reachable without the delegated prefixes
re-learnt. needing to be re-learnt.
S-3: The relay MAY implement DHCPv6 active lease query as defined S-3: The relay MAY implement DHCPv6 active lease query as defined
in [RFC7653] to keep the local lease database in sync with in [RFC7653] to keep the local lease database in sync with
the DHCPv6 server. the DHCPv6 server.
4.4. Operational Requirements 4.4. Operational Requirements
O-1: The relay SHOULD implement an interface allowing the operator O-1: The relay SHOULD implement an interface allowing the operator
to view the active delegated prefixes. This SHOULD provide to view the active delegated prefixes. This SHOULD provide
information about the delegated lease and client details such information about the delegated lease and client details such
as client identifier, next-hop address, connected interface, as client identifier, next-hop address, connected interface,
and remaining lifetimes. and remaining lifetimes.
O-2: The relay SHOULD provide a method for the operator to clear O-2: The relay SHOULD provide a method for the operator to clear
active bindings for an individual lease, client or all active bindings for an individual lease, client or all
bindings on a port. bindings on a port.
O-3: To facilitate troubleshooting of operational problems between O-3: To facilitate troubleshooting of operational problems between
the delegating relay and other elements, it is RECOMMENDED the delegating relay and other elements, it is RECOMMENDED
that the delegating relay's system time is synchronised with that a time synchronization protocol is used by the
the network. delegating routers and DHCP servers.
5. Acknowledgements 5. Acknowledgements
The authors of this document would like to thank Bernie Volz for his The authors of this document would like to thank Bernie Volz for his
valuable comments. valuable comments.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
skipping to change at page 10, line 17 skipping to change at page 10, line 35
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
8.2. Informative References 8.2. Informative References
[BCP38] IETF, "Network Ingress Filtering: Defeating Denial of [BCP38] IETF, "Network Ingress Filtering: Defeating Denial of
Service Attacks which employ IP Source Address Spoofing Service Attacks which employ IP Source Address Spoofing
https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38. https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38.
[RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014,
<https://www.rfc-editor.org/info/rfc7283>.
[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged [RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged
between Servers and Relay Agents", RFC 8213, between Servers and Relay Agents", RFC 8213,
DOI 10.17487/RFC8213, August 2017, DOI 10.17487/RFC8213, August 2017,
<https://www.rfc-editor.org/info/rfc8213>. <https://www.rfc-editor.org/info/rfc8213>.
Authors' Addresses Authors' Addresses
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
Landgrabenweg 151 Landgrabenweg 151
skipping to change at page 11, line 4 skipping to change at page 11, line 19
Email: naveen.sarma@gmail.com Email: naveen.sarma@gmail.com
Martin Hunek Martin Hunek
Technical University of Liberec Technical University of Liberec
Studentska 1402/2 Studentska 1402/2
Liberec, L 46017 Liberec, L 46017
CZ CZ
Email: martin.hunek@tul.cz Email: martin.hunek@tul.cz
Richard Patterson Richard Patterson
Sky UK Ltd
1 Brick Lane
London E1 6PU
UK
Email: richard@helix.net.nz Email: richard.patterson@sky.uk
 End of changes. 38 change blocks. 
58 lines changed or deleted 87 lines changed or added

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