draft-ietf-homenet-naming-architecture-dhc-options-07.txt   draft-ietf-homenet-naming-architecture-dhc-options-08.txt 
Homenet D. Migault Homenet D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track R. Weber Intended status: Standards Track R. Weber
Expires: October 21, 2020 Akamai Expires: April 25, 2021 Akamai
T. Mrugalski T. Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
C. Griffiths C. Griffiths
W. Cloetens W. Cloetens
April 19, 2020 Deutsche Telekom
October 22, 2020
DHCPv6 Options for Home Network Authoritative Naming Service DHCPv6 Options for Home Network Naming Authority
draft-ietf-homenet-naming-architecture-dhc-options-07 draft-ietf-homenet-naming-architecture-dhc-options-08
Abstract Abstract
This document defines DHCPv6 options so any agnostic Homnet Naming This document defines DHCPv6 options so any agnostic Homnet Naming
Authority (HNA) can automatically proceed to the appropriate Authority (HNA) can automatically proceed to the appropriate
configuration and outsource the authoritative naming service for the configuration and outsource the authoritative naming service for the
home network. In most cases, the outsourcing mechanism is home network. In most cases, the outsourcing mechanism is
transparent for the end user. transparent for the end user.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 41
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 October 21, 2020. This Internet-Draft will expire on April 25, 2021.
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 16 skipping to change at page 2, line 17
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4 4. Payload Description . . . . . . . . . . . . . . . . . . . . . 5
4.1. Client Public Key Option . . . . . . . . . . . . . . . . 5 4.1. Client Public Key Option . . . . . . . . . . . . . . . . 5
4.2. Distribution Master Option . . . . . . . . . . . . . . . 5 4.2. Registered Homenet Domain Option . . . . . . . . . . . . 5
4.3. Reverse Synchronization Server Option . . . . . . . . . . 6 4.3. Distribution Master Option . . . . . . . . . . . . . . . 6
5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1. Supported Transport . . . . . . . . . . . . . . . . . 6
5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 4.4. Reverse Distribution Master Server Option . . . . . . . . 7
5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7 5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 8
5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 8
5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations" . . . . . . . . . . . . . . . . . . 8 7. Security Considerations" . . . . . . . . . . . . . . . . . . 9
7.1. DNSSEC is recommended to authenticate DNS hosted data . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Channel between the HNA and ISP DHCP Server MUST be 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
secured . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.3. HNAs are sensitive to DoS . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Scenarios and impact on the End User . . . . . . . . 11
9. Scenarios and impact on the End User . . . . . . . . . . . . 9 Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 11
10. Base Scenario . . . . . . . . . . . . . . . . . . . . . . . . 9 B.1. Third Party Registered Homenet Domain . . . . . . . . . . 11
10.1. Third Party Registered Homenet Domain . . . . . . . . . 9 B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 12
10.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 10 B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12
10.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Terminology 1. Terminology
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 "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 3, line 16 skipping to change at page 3, line 14
o Client Public Key: designates a public key generated by the HNA o Client Public Key: designates a public key generated by the HNA
and used as an authentication credential for the HNA. and used as an authentication credential for the HNA.
2. Introduction 2. Introduction
[I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet [I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet
Naming Authority (HNA) outsources the Public Homenet Zone to an Naming Authority (HNA) outsources the Public Homenet Zone to an
Outsourcing Infrastructure. Outsourcing Infrastructure.
In most cases the setting of the relation between the HNA and the This document shows how an ISP can provision automatically the HNA
Outsourcing Infrastructure is not fully automated and involves the with an DNS Outsourcing Infrastructure (DOI). Most likely the DOI
end user. More specifically, the Outsourcing Infrastructure needs to will be - at least partly be - managed or provided by its ISP, but
be able to authenticate the HNA as well as needs to ensure the HNA other cases may envision the ISP storing some configuration so the
owns the Registered Homenet Domain. As a result, the Outsourcing homenet becomes resilient to HNA replacement.
Infrastructure is likely to be provided by a registrar.
This document describes DHCPv6 options that leverage a relation The ISP delegates the home network an IP prefix it owns as well as
between the ISP and an end user to fully automated these steps. This the associated reverse zone.
enables an end user to provide the home network configuration to the The ISP is well aware of the owner of that prefix, and as such
DHCPv6 server, so an HNA can outsource without any configuration. In becomes a natural candidate for hosting the Homenet Reverse Zone -
this case, outsourcing is achieved with zero-config and is resilient that is the Reverse Distribution Master (RDM) and potentially the
to HNA change. This may provide the ability for an ISP to provide a Reverse Public Authoritative Servers.
default outsourcing service to its customers, however this service
can be used by the end user for any specific Homenet registered
domain, not just the ones provided by the ISP and as such benefits
the end user.
The overall principle is that the HNA advertises the DHCPv6 server of In addition, the ISP often identifies the home network with a name.
its Public Key. This Public Key will be used by the HNA for the In most cases, the name is used by the ISP for its internal network
authentication during the TLS key exchange between the HNA and the management operations and is not a name the home network owner has
Distribution Master (DM) of the Public Homenet Zone and the Reverse registered to. The ISP may thus leverage such infrastructure and
Homenet Zone. Note that a specific relation between the DHCPv6 provide the homenet a specific domain name designated as per
server and the DM is required. When the DHCPv6 server is managed by [I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered
the ISP, such relation exist between DHCPv6 server and the DM of the Domain. Similarly to the reverse zone, the ISP is well aware of who
Reverse Homenet Zone. Such relation may also exist - but not owns that domain name and may become a natural candidate for hosting
necessarily - between the DHCPv6 server and the DM of the Public the Homenet Zone - that is the Distribution Master (DM) and the
Homenet Zone. The DHCHv6 server provides the HNA the FQDN and Public Public Authoritative Servers.
Keys of the respective DMs.
This document assumes the link between the HNA and the DHCPv6 server This document describes DHCPv6 options so the HNA can advertise the
is trustworthy for example using [I-D.ietf-dhc-sedhcpv6]. ISP its identity via a Client Public Key. The ISP internally
associates the Registered Homenet Domains with that key - that is to
the DM and RDM. The ISP provides the Registered Homenet Domain,
necessary information on the DM and the RDM so the HNA can manage and
upload the Public Homenet Zone and the Reverse Public Homenet Zone as
described in [I-D.ietf-homenet-front-end-naming-delegation].
The use of DHCPv6 options makes the configuration completely
transparent to the end user and provides a similar level of trust as
the one used to provide the IP prefix. The link between the HNA and
the DHCPv6 server may benefit from additional security for example by
using [I-D.ietf-dhc-sedhcpv6].
3. Protocol Overview 3. Protocol Overview
This section illustrates how a HNA receives the necessary information This section illustrates how a HNA receives the necessary information
via DHCPv6 options to outsource its authoritative naming service on via DHCPv6 options to outsource its authoritative naming service to
the Outsourcing Infrastructure. For the sake of simplicity, this the DOI. For the sake of simplicity, and similarly to
section assumes that the DHCPv6 server is able to communicate to the [I-D.ietf-homenet-front-end-naming-delegation], this section assumes
various DNS servers and to provide them the public key associated that the HNA and the home network DHCPv6 client are collocated on the
with the HNA. Once each server got the public key, the HNA can CPE. Note also that this is not mandatory and specific
proceed to transactions in an authenticated and secure way. communications between the HNA and the DHCPv6 client only are needed.
In addition, this section assumes the responsible entity for the
DHCPv6 server is able to configure the DM and RDM. In our case, this
means a Registered Homenet Domain can be associated to a Client
Public Key.
This scenario has been chosen as it is believed to be the most This scenario has been chosen as it is believed to be the most
popular scenario. This document does not ignore scenarios where the popular scenario. This document does not ignore scenarios where the
DHCP Server does not have privileged relations with the DM. DHCP Server does not have privileged relations with the DM or RDM.
These cases are discussed latter in Appendix A. Such scenarios do
These cases are discussed latter in Section 9. Such scenario does
not necessarily require configuration for the end user and can also not necessarily require configuration for the end user and can also
be zero-config. be zero-config.
The scenario is as follows: The scenario considered in this section is as follows:
o 1) The HNA provides its Client Public Key to the DHCP Server using 1. The HNA is willing to outsource the Public Homenet Zone or
a Client Public Key Option (OPTION_PUBLIC_KEY) and includes the Homenet Reverse Zone and configures its DHCP Client to provide
following option codes in its its Option Request Option (ORO): the its Client Public Key to the DHCP Server using a Client Public
Distribution Master Option (OPTION_DM) and the Reverse Key Option (OPTION_PUBLIC_KEY).
Distribution Master Option (OPTION_REVERSE_DM). In addition, it also requests the DHCP Client to include in its
Option Request Option (ORO) the Registered Homnet Domain Option
(OPTION_REGISTERED_DOMAIN), the Distribution Master Option
(OPTION_DIST_MASTER) and the Reverse Distribution Master Option
(OPTION_REVERSE_DIST_MASTER) option codes.
o 2) The DHCP Server makes the Client Public Key available to the DM 2. The DHCP Server updates as indicated by the ORO, the DM and RDM,
servers, so the HNA can secure its DNS transactions. How the and associate the Registered Domain with the Client Public Key.
Client Public Key is transmitted to the various DNS servers is out
of scope of this document. Note that the Client Public Key alone
is not sufficient to perform the authentication and the key should
be, for example, associated with an identifier, or the concerned
domain name. How the binding is performed is out of scope of the
document. It can be a centralized database or various bindings
may be sent to the different servers.
o 3) The DHCP Server responds to the HNA with the requested DHCPv6 3. The DHCP Server responds to the HNA with the requested DHCPv6
options, i.e. the Distribution Master Option (OPTION_DM) and the options, i.e. OPTION_DIST_MASTER) and OPTION_REVERSE_DIST_MASTER.
Reverse Distribution Master Option (OPTION_REVERSE_DM). The DHCP Client transmits the information to the HNA.
o 4) Once the Homenet Zone has been set, the HNA uploads the zone to 4. The HNA is able to get authenticated by the DM and the RDM. The
the respective DMs. HNA builds the Homenet Zone ( resp. the Homenet Reverse Zone) and
proceed as described in
[I-D.ietf-homenet-front-end-naming-delegation].
4. Payload Description 4. Payload Description
This section details the payload of the DHCPv6 options. This section details the payload of the DHCPv6 options.
4.1. Client Public Key Option 4.1. Client Public Key Option
The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client
Public Key that is used to authenticate the HNA. This option is Public Key that is used to authenticate the HNA. This option is also
defined in [I-D.ietf-dhc-sedhcpv6]. defined in [I-D.ietf-dhc-sedhcpv6].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_PUBLIC_KEY | option-len | | OPTION_PUBLIC_KEY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
/ Public Key Data / / Public Key Data /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{ #fig-public-key title="Client Public Key Option"} Figure 1: Client Public Key Option
o option-code (16 bits): OPTION_PUBLIC_KEY, the option code for the o option-code (16 bits): OPTION_PUBLIC_KEY, the option code for the
Client Public Key Option (TBD1). Client Public Key Option (TBD1).
o option-len (16 bits): length in octets of the option-data field as o option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
o Client Public Key Data: contains the Client Public Key. The format o Client Public Key Data: contains the Client Public Key. The format
is the DNSKEY RDATA format as defined in [RFC4034]. is the DNSKEY RDATA format as defined in [RFC4034].
4.2. Distribution Master Option 4.2. Registered Homenet Domain Option
The Synchronization Server Option (OPTION_SYNC_SERVER) provides The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the
information necessary for the HNA to upload the Homenet Zone to the FQDN associated to the home network.
Synchronization Server. Finally, the option provides the
authentication methods that are available to perform the upload. The 0 1 2 3
upload is performed via a DNS primary / secondary architecture or DNS 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
updates. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_REGISTERED_DOMAIN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Registered Homenet Domain /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Client Public Key Option
o option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code
for the Registered Homenet Domain (TBD2).
o option-len (16 bits): length in octets of the option-data field as
described in [RFC3315].
o Registered Homenet Domain (varaiable): the FQDN registered for the
homenet
4.3. Distribution Master Option
The Distributed Master Option (OPTION_DIST_MASTER) provides the HNA
to FQDN of the DM as well as the transport protocol for the
transaction between the HNA and the DM.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DIST_MASTER | option-len | | OPTION_DIST_MASTER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Port | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ DM FQDN / / Distribution Master FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{ #fig-name-srv-set title="Synchronization Server Option"}
o option-code (16 bits): OPTION_SYNC_SERVER, the option code for the Figure 3: Distribution Master Option
Synchronization Server Option (TBD2).
o option-code (16 bits): OPTION_DIST_MASTER, the option code for the
DM Option (TBD3).
o option-len (16 bits): length in octets of the option-data field as o option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
o Server Port (16 bits): defines the port the Synchronization Server o Supported Transport (16 bits): defines the supported transport by
is listening. When multiple transport layers may be used, a the DM. Each bit represents a supported transport, and a DM MAY
single and unique Server Port value applies to all the transport indicate the support of multiple modes. The bit for DoT MUST be
layers. In the case of DNS for example, Server Port value set.
considers DNS exchanges using UDP and TCP.
o Synchronization Server FQDN (variable): the FQDN of the o Distribution Master FQDN (variable): the FQDN of the DM.
Synchronization Server.
4.3. Reverse Synchronization Server Option 4.3.1. Supported Transport
The Reverse Synchronization Server Option The Supported Transport filed of the DHCPv6 option indicates the
(OPTION_REVERSE_SYNC_SERVER) provides information necessary for the supported transport protocol. Each bit represents a specific
HNA to upload the Homenet Zone to the Synchronization Server. The transport mechanism. The bit sets to 1 indicates the associated
option provides the authentication methods that are available to transport protocol is supported. The corresponding bits are assigned
perform the upload. The upload is performed via a DNS primary / as described in Figure 4.
secondary architecture or DNS updates.
Bit | Transport Protocol | Reference
----+--------------------+-----------
0 | DNS over TLS |
1 | DNS over HTTPS |
2-7 | unallocated |
Figure 4: Supported Protocols
4.4. Reverse Distribution Master Server Option
The Reverse Distribution Master Server Option
(OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as
well as the transport protocol for the transaction between the HNA
and the DM.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_DIST_MASTER | option-len | | OPTION_REVERSE_DIST_MASTER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Port | | | Supported Transport | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
/ Reverse DM FQDN / / Reverse Distribution Master FQDN /
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reverse Synchronization Server Option Figure 5: Reverse Distribution Master Option
o option-code (16 bits): OPTION_REVERSE_SYNC_SERVER, the option code o option-code (16 bits): OPTION_REVERSE_DIST_MASTER, the option code
for the Reverse Synchronization Server Option (TBD3). for the Reverse Distribution Master Option (TBD4).
o option-len (16 bits): length in octets of the option-data field as o option-len (16 bits): length in octets of the option-data field as
described in [RFC3315]. described in [RFC3315].
o Server Port (16 bits): defines the port the Synchronization Server o Supported Transport (16 bits): defines the supported transport by
is listening. the DM. Each bit represents a supported transport, and a DM MAY
indicate the support of multiple modes. The bit for DoT MUST be
set.
o Reverse Synchronization Server FQDN (variable): The FQDN of the o Reverse Distribution Master FQDN (variable): the FQDN of the RDM.
Reverse Synchronization Server.
5. DHCP Behavior 5. DHCP Behavior
5.1. DHCPv6 Server Behavior 5.1. DHCPv6 Server Behavior
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in
regards to option assignment. As a convenience to the reader, we regards to option assignment. As a convenience to the reader, we
mention here that the server will send option foo only if configured mention here that the server will send option foo only if configured
with specific values for foo and if the client requested it. In with specific values for foo and if the client requested it. In
particular, when configured the DHCP Server sends the Zone Template particular, when configured the DHCP Server sends the Registered
Option, Synchronization Server Option, Reverse Synchronization Server Homenet Domain Option, Distribution Master Option, the Reverse
Option when requested by the DHCPv6 client by including necessary Distribution Master Option when requested by the DHCPv6 client by
option codes in its ORO. including necessary option codes in its ORO.
The DHCP Server may receive a Client Public Key Option The DHCP Server may receive a Client Public Key Option
(OPTION_PUBLIC_KEY) from the HNA. Upon receipt of this DHCPv6 (OPTION_PUBLIC_KEY) from the HNA. Upon receipt of this DHCPv6
option, the DHCP Server SHOULD acknowledge the reception of the option, the DHCP Server SHOULD acknowledge the reception of the
Client Public Key Option as described and communicate this credential Client Public Key Option as described and communicate this credential
to the available DM and Reverse DM unless not configured to do so. to the available DM and RDM unless not configured to do so.
A HNA may update its Client Public Key by sending a new value in the A HNA may update its Client Public Key by sending a new value in the
Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes
the link between the HNA and the DHCP Server is considered the link between the HNA and the DHCP Server is considered
authenticated and trusted. The server SHOULD process received Client authenticated and trusted. The server SHOULD process received Client
Public Key Option sent by the client unless not configured to do so. Public Key Option sent by the client unless not configured to do so.
5.2. DHCPv6 Client Behavior 5.2. DHCPv6 Client Behavior
The DHCPv6 client SHOULD send a Client Public Key Option The DHCPv6 client SHOULD send a Client Public Key Option
(OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key (OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key
authenticates the HNA. authenticates the HNA.
The DHCPv6 client sends a ORO with the necessary option codes: Zone The DHCPv6 client sends a ORO with the necessary option codes:
Template Option, Synchronization Server Option and Reverse Registered Homenet Domain Option, Distribution Master Option, the
Synchronization Server Option. Reverse Distribution Master Option.
Upon receiving a DHCP option described in this document in the Reply Upon receiving a DHCP option described in this document in the Reply
message, the HNA SHOULD publish the zone as described in message, the HNA SHOULD proceed as described in
[I-D.ietf-homenet-front-end-naming-delegation]. [I-D.ietf-homenet-front-end-naming-delegation].
5.3. DHCPv6 Relay Agent Behavior 5.3. DHCPv6 Relay Agent Behavior
There are no additional requirements for the DHCP Relay agents. There are no additional requirements for the DHCP Relay agents.
6. IANA Considerations 6. IANA Considerations
The DHCP options detailed in this document is: * OPTION_CLIENT_KEY: The DHCP options detailed in this document are: * OPTION_CLIENT_KEY:
TBD1 * OPTION_REGISTERED_DOMAIN: TBD2 * OPTION_SYNC_SERVER: TBD3 * TBD1 * OPTION_REGISTERED_DOMAIN: TBD2 * OPTION_DIST_MASTER: TBD3 *
OPTION_REVERSE_SYNC_SERVER: TBD4 OPTION_REVERSE_DIST_MASTER: TBD4
The document also requests a Supported Transport Registry:
7. Security Considerations"
7.1. DNSSEC is recommended to authenticate DNS hosted data
It is recommended that the (Reverse) Homenet Zone is signed with
DNSSEC. The zone may be signed by the HNA or by a third party. We
recommend the zone to be signed by the HNA, and that the signed zone
is uploaded.
7.2. Channel between the HNA and ISP DHCP Server MUST be secured
The channel MUST be secured because the HNA provides authentication
credentials. Unsecured channel may result in HNA impersonation
attacks.
The document considers that the channel between the HNA and the ISP
DHCP Server is trusted. More specifically, the HNA is authenticated
and the exchanged messages are protected. The current document does
not specify how to secure the channel. [RFC3315] proposes a DHCP
authentication and message exchange protection, [RFC4301], [RFC7296]
propose to secure the channel at the IP layer.
7.3. HNAs are sensitive to DoS Bit | Transport Protocol | Reference
----+--------------------+-----------
0 | DNS over TLS |
1 | DNS over HTTPS |
2-7 | unallocated |
HNA have not been designed for handling heavy load. The HNA are 7. Security Considerations"
exposed on the Internet, and their IP address is publicly published
on the Internet via the DNS. This makes the Home Network sensitive
to Deny of Service Attacks. The resulting outsourcing architecture
is described in [I-D.ietf-homenet-front-end-naming-delegation]. This
document shows how the outsourcing architecture can be automatically
set.
8. Acknowledgments 8. Acknowledgments
We would like to thank Marcin Siodelski and Bernie Volz for their We would like to thank Marcin Siodelski and Bernie Volz for their
comments on the design of the DHCPv6 options. We would also like to comments on the design of the DHCPv6 options. We would also like to
thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their
remarks on the architecture design. The designed solution has been remarks on the architecture design. The designed solution has been
largely been inspired by Mark Andrews's document largely been inspired by Mark Andrews's document
[I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We
also thank Ray Hunter for its reviews, its comments and for also thank Ray Hunter for its reviews, its comments and for
suggesting an appropriated terminology. suggesting an appropriated terminology.
9. Scenarios and impact on the End User 9. References
9.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[I-D.andrews-dnsop-pd-reverse]
Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", draft-andrews-dnsop-pd-
reverse-02 (work in progress), November 2013.
[I-D.ietf-dhc-sedhcpv6]
Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), February 2017.
[I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Weber, R., Richardson, M., Hunter, R.,
Griffiths, C., and W. Cloetens, "Outsourcing Home Network
Authoritative Naming Service", draft-ietf-homenet-front-
end-naming-delegation-11 (work in progress), April 2020.
[I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010.
Appendix A. Scenarios and impact on the End User
This section details various scenarios and discuss their impact on This section details various scenarios and discuss their impact on
the end user. the end user. This section is not normative and limits the
description of a limited scope of scenarios that are assumed to be
representative. Many other scenarios may be derived from these.
10. Base Scenario Appendix B. Base Scenario
The base scenario is the one described in Section 3. It is typically The base scenario is the one described in Section 3 in which an ISP
the one of an ISP that manages the DHCP Server, and all DNS servers. manages the DHCP Server, the DM and RDM.
The end user subscribes to the ISP (foo), and at subscription time The end user subscribes to the ISP (foo), and at subscription time
registers for example.foo as its Registered Homenet Domain registers for example.foo as its Registered Homenet Domain
example.foo. example.foo.
When the HNA is plugged (at least the first time), it provides its When the HNA is plugged (at least the first time), it provides its
Client Public Key to the DHCP Server. In this scenario, the DHCP Client Public Key to the DHCP Server. In this scenario, the DHCP
Server and the DNS Servers are managed by the ISP so the DHCP Server Server, DM and RDM are managed by the ISP so the DHCP Server and as
can provide authentication credentials of the HNA to enable secure such can provide authentication credentials of the HNA to enable
authenticated transaction with the DM and the Reverse DM. secure authenticated transaction with the DM and the Reverse DM.
The main advantage of this scenario is that the naming architecture The main advantage of this scenario is that the naming architecture
is configured automatically and transparently for the end user. The is configured automatically and transparently for the end user. The
drawbacks are that the end user uses a Registered Homenet Domain drawbacks are that the end user uses a Registered Homenet Domain
managed by the ISP and that it relies on the ISP naming managed by the ISP and that it relies on the ISP naming
infrastructure. infrastructure.
10.1. Third Party Registered Homenet Domain B.1. Third Party Registered Homenet Domain
This section considers the case when the end user wants its home This section considers the case when the end user wants its home
network to use example.com as a Registered Homenet Domain instead of network to use example.com not managed by her ISP (foo) as a
example.foo that has been assigned by the ISP. We also suppose that Registered Homenet Domain.
example.com is not managed by the ISP. This section still consider the ISP manages the home network and
still provides example.foo as a Registered Homenet Domain.
This can also be achieved without any configuration. When the end When the end user buys the domain name example.com, it may request to
user buys the domain name example.com, it may request to redirect the redirect the name example.com to example.foo using static redirection
name example.com to example.foo using static redirection with CNAME with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME
[RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME
[I-D.sury-dnsext-cname-dname]. [I-D.sury-dnsext-cname-dname].
This configuration is performed once when the domain name example.com This configuration is performed once when the domain name example.com
is registered. The only information the end user needs to know is is registered. The only information the end user needs to know is
the domain name assigned by the ISP. Once this configuration is done the domain name assigned by the ISP. Once this configuration is done
no additional configuration is needed anymore. More specifically, no additional configuration is needed anymore. More specifically,
the HNA may be changed, the zone can be updated as in Section 10 the HNA may be changed, the zone can be updated as in Appendix B
without any additional configuration from the end user. without any additional configuration from the end user.
The main advantage of this scenario is that the end user benefits The main advantage of this scenario is that the end user benefits
from the Zero Configuration of the Base Scenario Section 10. Then, from the Zero Configuration of the Base Scenario Appendix B. Then,
the end user is able to register for its home network an unlimited the end user is able to register for its home network an unlimited
number of domain names provided by an unlimited number of different number of domain names provided by an unlimited number of different
third party providers. third party providers.
The drawback of this scenario may be that the end user still rely on The drawback of this scenario may be that the end user still rely on
the ISP naming infrastructure. Note that the only case this may be the ISP naming infrastructure. Note that the only case this may be
inconvenient is when the DNS Servers provided by the ISPs results in inconvenient is when the DNS Servers provided by the ISPs results in
high latency. high latency.
10.2. Third Party DNS Infrastructure B.2. Third Party DNS Infrastructure
This scenario considers that the end user uses example.com as a This scenario considers that the end user uses example.com as a
Registered Homenet Domain, and does not want to rely on the Registered Homenet Domain, and does not want to rely on the
authoritative servers provided by the ISP. authoritative servers provided by the ISP.
In this section we limit the outsourcing to the DM and Public In this section we limit the outsourcing to the DM and Public
Authoritative Server(s) to a third party. The Reverse Public Authoritative Server(s) to a third party. The Reverse Public
Authoritative Server(s) and Reverse Synchronization Server remain Authoritative Server(s) and the RDM remain managed by the ISP as the
managed by the ISP as the IP prefix is managed by the ISP. IP prefix is managed by the ISP.
Outsourcing DM and Public Authoritative Server(s) requires: Outsourcing to a third party DM can be performed in the following
ways:
1. Updating the DHCP Server Information. One can imagine a GUI 1. Updating the DHCP Server Information. One can imagine a GUI
interface that enables the end user to modify its profile interface that enables the end user to modify its profile
parameters. Again, this configuration update is done once-for- parameters. Again, this configuration update is done once-for-
ever. ever.
2. Upload the authentication credential of the HNA, that is the 2. Upload the configuration of the DM to the HNA. In some cases,
Client Public Key of the HNA, to the third party. Unless we use the provider of the CPE hosting the HNA may be the registrar and
specific mechanisms, like communication between the DHCP Server provide the CPE already configured. In other cases, the CPE may
and the third party, or a specific token that is plugged into the request the end user to log into the registrar to validate the
HNA, this operation is likely to be performed every time the HNA ownership of the Registered Homenet Domain and agree on the
is changed, and every time the Client Public Key generated by the necessary credentials to secure the communication between the HNA
HNA is changed. and the DM. As described in
[I-D.ietf-homenet-front-end-naming-delegation], such settings
The main advantage of this scenario is that the DNS infrastructure is could be performed in an almost automatic way as to limit the
completely outsourced to the third party. Most likely the Client necessary interactions with the end user.
Public Key that authenticate the HNA needs to be configured for every
HNA. Configuration is expected to be HNA live-long.
10.3. Multiple ISPs B.3. Multiple ISPs
This scenario considers a HNA connected to multiple ISPs. This scenario considers a HNA connected to multiple ISPs.
Suppose the HNA has been configured each of its interfaces Suppose the HNA has been configured each of its interfaces
independently with each ISPS as described in Section 10. Each ISP independently with each ISPS as described in Appendix B. Each ISP
provides a different Registered Homenet Domain. The HNA Client provides a different Registered Homenet Domain. The HNA Client
Public Key may be shared between the HNA and the multiple ISPs. Public Key may be shared between the HNA and the multiple ISPs.
The protocol and DHCPv6 options described in this document are fully The protocol and DHCPv6 options described in this document are fully
compatible with a HNA connected to multiple ISPs with multiple compatible with a HNA connected to multiple ISPs with multiple
Registered Homenet Domains. However, the HNA should be able to Registered Homenet Domains. However, the HNA should be able to
handle different Registered Homenet Domains. This is an handle different Registered Homenet Domains. This is an
implementation issue which is outside the scope of the current implementation issue which is outside the scope of the current
document. document.
If a HNA is not able to handle multiple Registered Homenet Domains, If a HNA is not able to handle multiple Registered Homenet Domains,
the HNA may remain connected to multiple ISP with a single Registered the HNA may remain connected to multiple ISP with a single Registered
Homenet Domain. In this case, the one party is chosen to host the Homenet Domain. In this case, one entity is chosen to host the
Registered Homenet Domain. Registered Homenet Domain. This entity may be one of the ISP or a
third party. Note that having multiple ISPs can be motivated for
bandwidth aggregation, or connectivity fail-over. In the case of
connectivity fail-over, the fail-over concerns the access network and
a failure of the access network may not impact the core network where
the DM Server and Public Authoritative Primaries are hosted. In that
sense, choosing one of the ISP even in a scenario of multiple ISPs
may make sense. However, for sake of simplicity, this scenario
assumes that a third party has been chosen to host the Registered
Homenet Domain. Configuration is performed as described in
Appendix B.1 and Appendix B.2.
This entity may be one of the ISP or a third party. Note that having With the configuration described in Appendix B.1, the HNA is expect
multiple ISPs can be motivated for bandwidth aggregation, or
connectivity fail-over. In the case of connectivity fail-over, the
fail-over concerns the access network and a failure of the access
network may not impact the core network where the DM Server and
Public Authoritative Primaries are hosted. In that sense, choosing
one of the ISP even in a scenario of multiple ISPs may make sense.
However, for sake of simplicity, this scenario assumes that a third
party has be chosen to host the Registered Homenet Domain. The DNS
settings for each ISP is described in Section 10.1 and Section 10.2.
With the configuration described in Section 10.1, the HNA is expect
to be able to handle multiple Homenet Registered Domain, as the third to be able to handle multiple Homenet Registered Domain, as the third
party redirect to one of the ISPs Servers. With the configuration party redirect to one of the ISPs Servers. With the configuration
described in Section 10.2, DNS zone are hosted and maintained by the described in Appendix B.2, DNS zone are hosted and maintained by the
third party. A single DNS(SEC) Homenet Zone is built and maintained third party. A single DNS(SEC) Homenet Zone is built and maintained
by the HNA. This latter configuration is likely to match most HNA by the HNA. This latter configuration is likely to match most HNA
implementations. implementations.
The protocol and DHCPv6 options described in this document are fully The protocol and DHCPv6 options described in this document are fully
compatible with a HNA connected to multiple ISPs. To configure or compatible with a HNA connected to multiple ISPs. To configure or
not and how to configure the HNA depends on the HNA facilities. not and how to configure the HNA depends on the HNA facilities.
Section 10 and Section 10.1 require the HNA to handle multiple Appendix B and Appendix B.1 require the HNA to handle multiple
Registered Homenet Domain, whereas Section 10.2 does not have such Registered Homenet Domain, whereas Appendix B.2 does not have such
requirement. requirement.
11. References
11.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
<https://www.rfc-editor.org/info/rfc2181>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<https://www.rfc-editor.org/info/rfc4034>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
<https://www.rfc-editor.org/info/rfc6672>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References
[I-D.andrews-dnsop-pd-reverse]
Andrews, M., "Automated Delegation of IP6.ARPA reverse
zones with Prefix Delegation", draft-andrews-dnsop-pd-
reverse-02 (work in progress), November 2013.
[I-D.ietf-dhc-sedhcpv6]
Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D.
Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work
in progress), February 2017.
[I-D.ietf-homenet-front-end-naming-delegation]
Migault, D., Weber, R., Richardson, M., Hunter, R.,
Griffiths, C., and W. Cloetens, "Outsourcing Home Network
Authoritative Naming Service", draft-ietf-homenet-front-
end-naming-delegation-10 (work in progress), March 2020.
[I-D.sury-dnsext-cname-dname]
Sury, O., "CNAME+DNAME Name Redirection", draft-sury-
dnsext-cname-dname-00 (work in progress), April 2010.
Authors' Addresses Authors' Addresses
Daniel Migault Daniel Migault
Ericsson Ericsson
8275 Trans Canada Route 8275 Trans Canada Route
Saint Laurent, QC 4S 0B6 Saint Laurent, QC 4S 0B6
Canada Canada
EMail: daniel.migault@ericsson.com EMail: daniel.migault@ericsson.com
Ralf Weber Ralf Weber
Akamai Akamai
EMail: ralf.weber@nominum.com EMail: ralf.weber@akamai.com
Tomek Mrugalski Tomek Mrugalski
Internet Systems Consortium, Inc. Internet Systems Consortium, Inc.
950 Charter Street 950 Charter Street
Redwood City 94063 Redwood City 94063
US US
EMail: tomasz.mrugalski@gmail.com EMail: tomasz.mrugalski@gmail.com
Chris Griffiths Chris Griffiths
EMail: cgriffiths@gmail.com EMail: cgriffiths@gmail.com
Wouter Cloetens Wouter Cloetens
Deutsche Telekom
EMail: wouter.cloetens@softathome.com EMail: wouter.cloetens@external.telekom.de
 End of changes. 70 change blocks. 
283 lines changed or deleted 296 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/