draft-ietf-dhc-dhcpv6-pd-relay-requirements-04.txt   draft-ietf-dhc-dhcpv6-pd-relay-requirements-05.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 N. Kottapalli
Expires: June 3, 2021 Benu Networks Expires: 8 July 2021 Benu Networks
M. Hunek M. Hunek
Technical University of Liberec Technical University of Liberec
R. Patterson R.P. Patterson
Sky UK Ltd Sky UK Ltd
November 30, 2020 January 2021
DHCPv6 Prefix Delegating Relay Requirements DHCPv6 Prefix Delegating Relay Requirements
draft-ietf-dhc-dhcpv6-pd-relay-requirements-04 draft-ietf-dhc-dhcpv6-pd-relay-requirements-05
Abstract Abstract
This memo describes operational problems that are known to occur when This document describes operational problems that are known to occur
using DHCPv6 relays with Prefix Delegation. These problems can when using DHCPv6 relays with Prefix Delegation. These problems can
prevent successful delegation and result in routing failures. To prevent successful delegation and result in routing failures. To
address these problems, this memo provides necessary functional address these problems, this document provides necessary functional
requirements for operating DHCPv6 relays with Prefix Delegation. requirements for operating DHCPv6 relays with Prefix Delegation.
It is recommended that any network operator that is using DHCPv6 It is recommended that any network operator that is using DHCPv6
prefix delegation with relays should ensure that these requirements prefix delegation with relays should ensure that these requirements
are followed on their networks. are followed on their networks.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 June 3, 2021. This Internet-Draft will expire on 5 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
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 Relay 3. Problems Observed with Existing Delegating Relay
Implementations . . . . . . . . . . . . . . . . . . . . . . . 5 Implementations . . . . . . . . . . . . . . . . . . . . . 5
3.1. DHCP Messages not being Forwarded by the Delegating 3.1. DHCP Messages not being Forwarded by the Delegating
Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 5 3.2. Delegating Relay Loss of State on Reboot . . . . . . . . 6
3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6 3.3. Multiple Delegated Prefixes for a Single Client . . . . . 6
3.4. Dropping Messages from Devices with Duplicate MAC 3.4. Dropping Messages from Devices with Duplicate MAC addresses
addresses and DUIDs . . . . . . . . . . . . . . . . . . . 6 and DUIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5. Forwarding Loops between Client and Relay . . . . . . . . 6 3.5. Forwarding Loops between Client and Relay . . . . . . . . 7
4. Requirements for Delegating Relays . . . . . . . . . . . . . 7 4. Requirements for Delegating Relays . . . . . . . . . . . . . 7
4.1. General Requirements . . . . . . . . . . . . . . . . . . 7 4.1. General Requirements . . . . . . . . . . . . . . . . . . 7
4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8 4.2. Routing Requirements . . . . . . . . . . . . . . . . . . 8
4.3. Service Continuity Requirements . . . . . . . . . . . . . 9 4.3. Service Continuity Requirements . . . . . . . . . . . . . 9
4.4. Operational Requirements . . . . . . . . . . . . . . . . 9 4.4. Operational Requirements . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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
DHCPv6 relay and Section 19.1.3 mentions this deployment scenario, DHCPv6 relay and Section 19.1.3 mentions this deployment scenario,
but does not provide detail for all of the functional requirements but does not provide details for all of the functional requirements
that the relay needs to fulfill to operate deterministically in this that the relay needs to fulfill to operate deterministically in this
deployment scenario. deployment scenario.
A DHCPv6 relay agent for prefix delegation is a function commonly A DHCPv6 relay agent for prefix delegation is a function commonly
implemented in routing devices, but implementations vary in their implemented in routing devices, but implementations vary in their
functionality and client/server inter-working. This can result in functionality and client/server inter-working. This can result in
operational problems such as messages not being forwarded by the operational problems such as messages not being forwarded by the
relay or un-reachability of the delegated prefixes. This document relay or un-reachability of the delegated prefixes. This document
provides a set of requirements for devices implementing a relay provides a set of requirements for devices implementing a relay
function for use with prefix delegation. function for use with prefix delegation.
skipping to change at page 3, line 29 skipping to change at page 3, line 39
Multi-hop DHCPv6 relaying is not affected. The requirements in this Multi-hop DHCPv6 relaying is not affected. The requirements in this
document are solely applicable to the DHCP relay agent co-located document are solely applicable to the DHCP relay agent co-located
with the first-hop router that the DHCPv6 client requesting the with the first-hop router that the DHCPv6 client requesting the
prefix is connected to, so no changes to any subsequent relays in the prefix is connected to, so no changes to any subsequent relays in the
path are needed. path are needed.
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,
defining the functional elements for prefix delegation [RFC8415], when defining the functional elements for prefix delegation
Section 4.2 defines the term 'delegating router' as: [RFC8415], 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
for delegated prefixes." for delegated prefixes."
This document is concerned with deployment scenarios in which the This document is concerned with deployment scenarios in which the
DHCPv6 relay and DHCPv6 server functions are separated, so the term DHCPv6 relay and DHCPv6 server functions are separated, so the term
'delegating router' is not used. Instead, a new term is introduced 'delegating router' is not used. Instead, a new term is introduced
to describe the relaying function: to describe the relaying function:
Delegating relay A delegating relay acts as an intermediate device, Delegating relay A delegating relay acts as an intermediate device,
forwarding DHCPv6 messages containing IA_PD/IAPREFIX forwarding DHCPv6 messages containing IA_PD and
options between the client and server. The IAPREFIX 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 In CableLabs DOCSIS environments, the Cable Modem Termination System
(CMTS) would be considered a delegating relay with respect to (CMTS) would be considered a delegating relay with respect to
skipping to change at page 6, line 26 skipping to change at page 6, line 50
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
one of the delegated prefixes 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 operational reality that client devices with duplicate MAC It is an operational reality that client devices with duplicate MAC
addresses and/or DUIDs exist and have been deployed. In this addresses and/or DUIDs exist and have been deployed. In some
situation, the operational costs of locating and swapping out such networks, the operational costs of locating and swapping out such
devices are prohibitive. 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/ It should be noted that in some access networks, the MAC address and/
or DUID are used as part of device identification and authentication. or DUID are used as part of device identification and authentication.
In such networks, enforcing MAC address/DUID uniqueness is a In such networks, enforcing MAC address/DUID uniqueness is a
necessary function and not considered a problem. necessary function and not considered a problem.
3.5. Forwarding Loops between Client and Relay 3.5. Forwarding Loops between Client and Relay
If the client loses information about a prefix that it is delegated If the client loses information about an active prefix lease it has
while the lease entry and associated route is still active in the been delegated while the lease entry and associated route is still
delegating relay, then the relay will forward traffic to the client active in the delegating relay, then the relay will forward traffic
which the client will return to the relay (which is the client's to the client which the client will return to the relay (which is the
default gateway (learned via an RA)). The loop will continue until client's default gateway (learned via an RA)). The loop will
either the client is successfully re-provisioned via DHCP, or the continue until either the client is successfully re-provisioned via
lease ages out in the relay. DHCP, or the lease ages out in the relay.
4. Requirements for Delegating Relays 4. Requirements for Delegating Relays
To resolve the problems described in Section 3 and pre-empt other To resolve the problems described in Section 3 and pre-empt other
undesirable behavior, the following section of the document describes undesirable behavior, the following section of the document describes
a set of functional requirements for the delegating relay. a set of functional requirements for the delegating relay.
In addition, relay implementers are reminded that [RFC8415] makes it In addition, relay implementers are reminded that [RFC8415] makes it
clear that relays MUST forward packets that either contain message clear that relays MUST forward packets that either contain message
codes (Section 19 of [RFC8415]) it may not understand, or contain codes (Section 19 of [RFC8415]) it may not understand, or contain
skipping to change at page 8, line 6 skipping to change at page 8, line 29
G-6: The relay MUST implement a mechanism to limit the maximum G-6: 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 MUST be client identifiers and IA_PDs. This value MUST be
configurable. configurable.
G-7: It is RECOMMENDED that delegating relays support at least 8 G-7: It is RECOMMENDED that delegating relays support at least 8
active delegated leases per client device and use this as the active delegated leases per client device and use this as the
default limit. default limit.
G-8: The delegating relay MUST update the lease lifetimes based on G-8: The delegating relay MUST update the lease lifetimes based on
the Client Reply messages it forwards to the client and only the client's reply messages it forwards to the client and
expire the delegated prefixes when the valid lifetime has only expire the delegated prefixes when the valid lifetime
elapsed. has elapsed.
G-9: On receipt of a Release message from the client, the G-9: On receipt of a Release message from the client, the
delegating relay MUST expire the active leases for each of delegating relay MUST expire the active leases for each of
the IA_PDs in the message. 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 leases and the associated next-hops dynamically updated with leases and the associated next-hops
as they are delegated to clients. When a delegated prefix is as they are delegated to clients. When a delegated prefix is
skipping to change at page 8, line 35 skipping to change at page 9, line 13
R-3: The relay MUST provide a mechanism to dynamically update R-3: The relay MUST provide a mechanism to dynamically update
ingress filters permitting ingress traffic sourced from ingress filters permitting ingress traffic sourced from
client delegated leases and blocking packets from invalid client delegated leases and blocking packets from invalid
source prefixes. This is to implement anti-spoofing as source prefixes. This is to implement anti-spoofing as
described in [BCP38]. The delegating relay's ingress filter described in [BCP38]. The delegating relay's ingress filter
entry MUST use the same prefix length for the delegated entry MUST use the same prefix length for the delegated
prefix as given in the IA_PD. prefix as given in the IA_PD.
R-4: The relay MAY provide a mechanism to dynamically advertise R-4: The relay MAY provide a mechanism to dynamically advertise
delegated leases into a routing protocol as they are learned. delegated leases into a routing protocol as they are learned.
When a delegated lease is released or expires, the delegated If such a mechanism is implemented, when a delegated lease is
route MUST be withdrawn from the routing protocol. The released or expires, the delegated route MUST be withdrawn
mechanism by which the routes are inserted and deleted is out from the routing protocol. The mechanism by which the routes
of the scope of this document. are inserted and deleted is out of the scope of this
document.
R-5: To prevent routing loops, the relay SHOULD implement a R-5: To prevent routing loops, the relay SHOULD implement a
configurable policy to drop potential looping packets configurable policy to drop potential looping packets
received on any DHCP-PD client facing interfaces. received on any DHCP-PD client facing interfaces.
The policy SHOULD be configurable on a per-client or per- The policy SHOULD be configurable on a per-client or per-
destination basis. destination basis.
Looping packets are those with a destination address in a Looping packets are those with a destination address in a
prefix delegated to a client connected to that interface, as prefix delegated to a client connected to that interface, as
skipping to change at page 10, line 19 skipping to change at page 10, line 47
The authors of this document would like to thank Bernie Volz, Ted The authors of this document would like to thank Bernie Volz, Ted
Lemon, and Michael Richardson for their valuable comments. Lemon, and Michael Richardson for their valuable comments.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Security Considerations 7. Security Considerations
This document does not add any new security considerations beyond This document does not add any new security considerations beyond
those mentioned in Section 22 of [RFC8213]. those mentioned in Section 4 of [RFC8213] and Section 22 of
[RFC8415].
If the delegating relay implements [BCP38] filtering, then the If the delegating relay implements [BCP38] filtering, then the
filtering rules will need to be dynamically updated as delegated filtering rules will need to be dynamically updated as delegated
prefixes are leased. prefixes are leased.
[RFC8213] describes a method for securing traffic between the relay [RFC8213] describes a method for securing traffic between the relay
agent and server by sending DHCP messages over an IPsec tunnel. In agent and server by sending DHCP messages over an IPsec tunnel. It
this case the IPsec tunnel is functionally the server-facing is RECOMMENDED that this is implemented by the delegating relay.
interface and DHCPv6 message snooping can be carried out as
described. It is RECOMMENDED that this is implemented by the Failure to implement requirement G-6 may have specific security
delegating relay. implications, such as a resource depletion attack on the relay.
The operational requirements in Section Section 4.4 may introduce
additional security considerations. It is RECOMMENDED that the
operational security practices described in [RFC4778] are
implemented.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC4778] Kaeo, M., "Operational Security Current Practices in
Internet Service Provider Environments", RFC 4778,
DOI 10.17487/RFC4778, January 2007,
<https://www.rfc-editor.org/info/rfc4778>.
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
DOI 10.17487/RFC5460, February 2009, DOI 10.17487/RFC5460, February 2009,
<https://www.rfc-editor.org/info/rfc5460>. <https://www.rfc-editor.org/info/rfc5460>.
[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 [RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6
Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, Active Leasequery", RFC 7653, DOI 10.17487/RFC7653,
October 2015, <https://www.rfc-editor.org/info/rfc7653>. October 2015, <https://www.rfc-editor.org/info/rfc7653>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged
between Servers and Relay Agents", RFC 8213,
DOI 10.17487/RFC8213, August 2017,
<https://www.rfc-editor.org/info/rfc8213>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"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,
<https://www.rfc-editor.org/rfc/rfc2827>.
[DOCSIS_3.1] [DOCSIS_3.1]
CableLabs, "MAC and Upper Layer Protocols Interface CableLabs, "MAC and Upper Layer Protocols Interface
Specification", DOCSIS 3.1, January, 2017", Specification", DOCSIS 3.1, January, 2017",
<https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>. <https://apps.cablelabs.com/specification/CM-SP-MULPIv3.>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged
between Servers and Relay Agents", RFC 8213,
DOI 10.17487/RFC8213, August 2017,
<https://www.rfc-editor.org/info/rfc8213>.
[TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS) [TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS)
Requirements Document, August, 2004", Requirements Document, August, 2004",
<https://www.broadband-forum.org/download/TR-092.pdf>. <https://www.broadband-forum.org/download/TR-092.pdf>.
Authors' Addresses Authors' Addresses
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
Landgrabenweg 151 Landgrabenweg 151
Bonn, NRW 53227 53227 Bonn
DE Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
Naveen Kottapalli Naveen Kottapalli
Benu Networks Benu Networks
300 Concord Road 154 Middlesex Turnpike
Billerica, MA 01821 Burlington, MA 01803
US United States of America
Email: naveen.sarma@gmail.com Email: nkottapalli@benunets.com
Martin Hunek Martin Hunek
Technical University of Liberec Technical University of Liberec
Studentska 1402/2 Studentska 1402/2
Liberec, L 46017 46017 Liberec
CZ Czechia
Email: martin.hunek@tul.cz Email: martin.hunek@tul.cz
Richard Patterson Richard Patterson
Sky UK Ltd Sky UK Ltd
1 Brick Lane 1 Brick Lane
London E1 6PU London
UK E1 6PU
United Kingdom
Email: richard.patterson@sky.uk Email: richard.patterson@sky.uk
 End of changes. 35 change blocks. 
83 lines changed or deleted 96 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/