Configuration option for RFC 8138
draft-thubert-roll-turnon-rfc8138-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Pascal Thubert | ||
| Last updated | 2019-05-23 | ||
| Replaced by | draft-ietf-roll-turnon-rfc8138, draft-ietf-roll-turnon-rfc8138, draft-ietf-roll-turnon-rfc8138, RFC 9035 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-thubert-roll-turnon-rfc8138-00
ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems
Updates: 6550 (if approved) May 23, 2019
Intended status: Standards Track
Expires: November 24, 2019
Configuration option for RFC 8138
draft-thubert-roll-turnon-rfc8138-00
Abstract
This document complements RFC 8138 and dedicates a bit in the RPL
configuration option to indicate whether RFC 8138 compression should
be used within the RPL instance. When the bit is not set, source
nodes that support RFC 8138 should refrain from using the compression
unless the information is superseded by configuration.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Thubert Expires November 24, 2019 [Page 1]
Internet-Draft Enabling RFC 8138 May 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 2
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
6. Security Considerations . . . . . . . . . . . . . . . . . . . 3
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 3
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 3
8.1. Normative References . . . . . . . . . . . . . . . . . . 3
8.2. Informative References . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
The transition to [RFC8138] in a network can only be done when all
nodes support the specification. In a mixed case with both
RFC8138-capable and non-capable nodes, the compression should be
turned off.
This document complements RFC 8138 and dedicates a bit in the RPL
configuration option to indicate whether RFC 8138 compression should
be used within the RPL instance. When the bit is not set, source
nodes that support RFC 8138 should refrain from using the compression
unless the information is superseded by configuration.
2. BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Updating RFC 6550
RPL defines a configuration option that is registered to IANA in
section 20.14. of [RFC6550]. This specification defines a new flag
"Enable RFC8138 Compression" (T) that is encoded in one of the
reserved control bits in the option. The new flag is set to turn on
the use of the compression of RPL artifacts with RFC 8138.
Thubert Expires November 24, 2019 [Page 2]
Internet-Draft Enabling RFC 8138 May 2019
4. Operation
A node that supports this specification SHOULD source packets in the
compressed form using [RFC8138] if the new T flag is set in the RPL
configuration option from its parents. Failure to do so will result
in larger packets, yields higher risks of loss and may cause a
fragmentation.
A node that supports this specification SHOULD refrain from sourcing
packets in the compressed form using [RFC8138] if the T flag is
reset. This behaviour can be overridden by a configuration of the
node in order to cope with intermediate implementations of the root
that support [RFC8138] but not this specification and cannot set the
T flag.
Regardless of the setting of the bit, the node MUST forward a packet
in the form it was received, compressed or uncompressed.
5. IANA Considerations
This specification updates the "Registry for the DODAG Configuration
Option Flags" that was created for [RFC6550] as follows:
+---------------+---------------------------------+-------------+
| Bit number | Suggested value | Defined in |
+---------------+---------------------------------+-------------+
| 2 (suggested) | Turn on RFC8138 Compression (T) | This RFC |
+---------------+---------------------------------+-------------+
Table 1: New DODAG Configuration Option Flag
6. Security Considerations
No specific threat was identified with this specification.
7. Acknowledgments
8. References
8.1. Normative References
[RFC2119] Bradner, S., "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
IPv6 provides global end to end IP reachability. To access services
hosted in the home network with IPv6 addresses, end users prefer to
use names instead of long and complex IPv6 addresses.
CPEs are already providing IPv6 connectivity to the home network and
generally provide IPv6 addresses or prefixes to the nodes of the home
network. This makes the CPEs a good candidate to manage binding
between names and IP addresses of the nodes. In addition, [RFC7368]
recommends that home networks be resilient to connectivity disruption
from the ISP. This requires that a dedicate device inside the home
network manage bindings between names and IP addresses of the nodes
and builds the DNS Homenet Zone. All this makes the CPE the natural
candidate for setting the DNS(SEC) zone file of the home network.
CPEs are usually low powered devices designed for the home network,
but not for heavy traffic. As a result, hosting an authoritative DNS
service on the Internet may expose the home network to resource
exhaustion, which may isolate the home network from the Internet and
affect the services hosted by the CPEs, thus affecting the overall
home network communications.
Migault (Ed), et al. Expires November 5, 2015 [Page 3]
Internet-Draft Outsourcing Authoritative Naming Service May 2015
In order to avoid resource exhaustion, this document describes an
architecture that outsources the authoritative naming service of the
home network. More specifically, the DNS(SEC) Homenet Zone built by
the CPE is outsourced to Public Authoritative Servers. These servers
publish the corresponding DN(SEC) Public Zone on the Internet.
Section 4.1 describes the architecture. In order to keep the
DNS(SEC) Public Zone up-to-date Section 5 describes how the DNS(SEC)
Homenet Zone and the DN(SEC) Public Zone can be synchronized. The
proposed architecture aims at deploying DNSSEC and the DNS(SEC)
Public Zone is expected to be signed with a secure delegation. The
zone signing and secure delegation can be performed either by the CPE
or by the Public Authoritative Servers. Section 6 discusses these
two alternatives. Section 7 discusses multiple views aspects and
provide guidance to avoid them. Section 8 discusses the case of the
reverse zone. Section 9 discusses how renumbering should be handled.
Finally, Section 10 and Section 11 respectively discuss privacy and
security considerations when outsourcing the DNS Homenet Zone.
3. Terminology
- Customer Premises Equipment: (CPE) is the router providing
connectivity to the home network. It is configured and managed
by the end user. In this document, the CPE MAY also host
services such as DHCPv6. This device MAY be provided by the
ISP.
- Registered Homenet Domain: is the Domain Name associated to the
home network.
- DNS Homenet Zone: is the DNS zone associated to the home network.
This zone is set by the CPE and essentially contains the
bindings between names and IP addresses of the nodes of the
home network. In this document, the CPE does neither perform
any DNSSEC management operations such as zone signing nor
provide an authoritative service for the zone. Both are
delegated to the Public Authoritative Server. The CPE
synchronizes the DNS Homenet Zone with the Public Authoritative
Server via a hidden primary / secondary architecture. The
Public Authoritative Server MAY use specific servers for the
synchronization of the DNS Homenet Zone: the Public
Authoritative Name Server Set as public available name servers
for the Registered Homenet Domain.
- DNS Homenet Reverse Zone: The reverse zone file associated to the
DNS Homenet Zone.
- Public Authoritative Server: performs DNSSEC management
operations as well as provides the authoritative service for
Migault (Ed), et al. Expires November 5, 2015 [Page 4]
Internet-Draft Outsourcing Authoritative Naming Service May 2015
the zone. In this document, the Public Authoritative Server
synchronizes the DNS Homenet Zone with the CPE via a hidden
primary / secondary architecture. The Public Authoritative
Server acts as a secondary and MAY use specific servers called
Public Authoritative Name Server Set. Once the Public
Authoritative Server synchronizes the DNS Homenet Zone, it
signs the zone and generates the DNSSEC Public Zone. Then the
Public Authoritative Server hosts the zone as an authoritative
server on the Public Authoritative Primary(ies).
- DNSSEC Public Zone: corresponds to the signed version of the DNS
Homenet Zone. It is hosted by the Public Authoritative Server,
which is authoritative for this zone, and is reachable on the
Public Authoritative Primary(ies).
- Public Authoritative Primary(ies): are the visible name server
hosting the DNSSEC Public Zone. End users' resolutions for the
Homenet Domain are sent to this server, and this server is a
primary for the zone.
- Public Authoritative Name Server Set: is the server the CPE
synchronizes the DNS Homenet Zone. It is configured as a
secondary and the CPE acts as primary. The CPE sends
information so the DNSSEC zone can be set and served.
- Reverse Public Authoritative Primary(ies): are the visible name
server hosting the DNS Homenet Reverse Zone. End users'
resolutions for the Homenet Domain are sent to this server, and
this server is a primary for the zone.
- Reverse Public Authoritative Name Server Set: is the server the
CPE synchronizes the DNS Homenet Reverse Zone. It is
configured as a secondary and the CPE acts as primary. The CPE
sends information so the DNSSEC zone can be set and served.
4. Architecture Description
This section describes the architecture for outsourcing the
authoritative naming service from the CPE to the Public Authoritative
Primary(ies). Section 4.1 describes the architecture, Section 4.2
and Section 4.3 illustrate this architecture and shows how the
DNS(SEC) Homenet Zone should be built by the CPE, as well as lists
the necessary parameters the CPE needs to outsource the authoritative
naming service. These two section are informational and non
normative.
Migault (Ed), et al. Expires November 5, 2015 [Page 5]
Internet-Draft Outsourcing Authoritative Naming Service May 2015
4.1. Architecture Overview
Figure 1 provides an overview of the architecture.
The home network is designated by the Registered Homenet Domain Name
-- example.com in Figure 1. The CPE builds the DNS(SEC) Homenet Zone
associated to the home network. How the DNS(SEC) Homenet Zone is
built is out of the scope of this document. The CPE may host and
involve multiple services like a web GUI, DHCP [RFC6644] or mDNS
[RFC6762]. These services may coexist and may be used to populate
the DNS Homenet Zone. This document assumes the DNS(SEC) Homenet
Zone has been populated with domain names that are intended to be
publicly published and that are publicly reachable. More
specifically, names associated to services or devices that are not
expected to be reachable from outside the home network or names bound
to non globally reachable IP addresses MUST NOT be part of the
DNS(SEC) Homenet Zone.
Once the DNS(SEC) Homenet Zone has been built, the CPE does not host
the authoritative naming service for it, but instead outsources it to
the Public Authoritative Servers. The Public Authoritative Servers
take the DNS(SEC) Homenet as an input and publishes the DNS(SEC)
Public Zone. In fact the DNS(SEC) Homenet Zone and the DNS(SEC)
Public Zone have different names as they may be different. If the
CPE does not sign the DNS Homenet Zone, for example, the Public
Authoritative Servers may instead sign it on behalf of the CPE.
Figure 1 provides a more detailed description of the Public
Authoritative Servers, but overall, it is expected that the CPE
provides the DNS(SEC) Homenet Zone, the DNS(SEC) Public Zone is
derived from the DNS(SEC) Homenet Zone and published on the Internet.
As a result, DNS(SEC) queries from the DNS(SEC) Resolvers on the
Internet are answered by the Public Authoritative Server and do not
reach the CPE. Figure 1 illustrates the case of the resolution of
node1.example.com.
Migault (Ed), et al. Expires November 5, 2015 [Page 6]
Internet-Draft Outsourcing Authoritative Naming Service May 2015
home network +-------------------+ Internet
| |
| CPE |
| | +----------------------+
+-------+ |+-----------------+| | Public Authoritative |
| | || DNS(SEC) Homenet|| | Servers |
| node1 | || Zone || |+--------------------+|
| | || || ||DNS(SEC) Public Zone||
+-------+ || Homenet Domain ||=========|| ||
|| Name || ^ || (example.com) ||
node1.\ || (example.com) || | |+--------------------+|
example.com |+-----------------+| | +----------------------+
+-------------------+ | ^ |
Synchronization | |
| |
DNSSEC resolution for node1.example.com | v
+----------------------+
| |
| DNSSEC Resolver |
| |
+----------------------+
Figure 1: Homenet Naming Architecture Description
The Public Authoritative Servers are described in Figure 2. The
Public Authoritative Name Server Set receives the DNS(SEC) Homenet
Zone as an input. The received zone may be transformed to output the
DNS(SEC) Public Zone. Various operations may be performed here,
however this document only considers zone signing as potential
operation. This could occur only when the CPE outsources this
operation to the Public Authoritative Name Server Set. On the other
hand, if the CPE signs the DNSSEC Homenet Zone itself, the zone it
collected by the Public Authoritative Name Server Set and directly
transferred to the Public Authoritative Primary. Implications of
such policy are detailed in Section 6 and Section 7.
Migault (Ed), et al. Expires November 5, 2015 [Page 7]
Internet-Draft Outsourcing Authoritative Naming Service May 2015
Internet
+--------------------------------------------------------+
| Public Authoritative Servers |
+--------------------------------------------------------+
+----------------------+ +----------------------+
| | | |
| Public Authoritative | | Public Authoritative |
| Name Server Set | | Primaries |
| | | |
| +------------------+ | X | +------------------+ |
| | DNS(SEC) Homenet | | ^ | | DNS(SEC) Public | |
=========>| | Zone | | | | | Zone | |
^ | | | | | | | | |
| | | (example.com) | | | | | (example.com) | |
| | +------------------+ | | | +------------------+ |
| +----------------------+ | +----------------------+
| Homenet to Public Zone
Synchronization transformation
from the CPE
Figure 2: Public Authoritative Servers Description
4.2. Example: DNS(SEC) Homenet Zone
This section is not normative and intends to illustrate how the CPE
builds the DNS(SEC) Homenet Zone.
As depicted in Figure 1 and Figure 2, the DNS(SEC) Public Zone is
hosted on the Public Authoritative Primaries, whereas the DNS(SEC)
Homenet Zone is hosted on the CPE. Motivations for keeping these two
zones identical are detailed in Section 7, and this section considers
that the CPE builds the zone that will be effectively published on
the Public Authoritative Primaries. In other words "Homenet to
Public Zone transformation" is the identity.
In that case, the DNS Homenet Zone should configure its Name Server
RRset (NS) and Start of Authority (SOA) with the ones associated to
the Public Authoritative Primaries. This is illustrated in Figure 3.
public.primary.example.net is the FQDN of the Public Authoritative
Primaries, and IP1, IP2, IP3, IP4 are the associated IP addresses.
Then the CPE should add the different new nodes that enter the home
network, remove those that should be removed and sign the DNS Homenet
Zone.
Migault (Ed), et al. Expires November 5, 2015 [Page 8]
"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>.
Thubert Expires November 24, 2019 [Page 3]
Internet-Draft Enabling RFC 8138 May 2019
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[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>.
8.2. Informative References
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
Author's Address
Pascal Thubert (editor)
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254
FRANCE
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Thubert Expires November 24, 2019 [Page 4]