The Universal IPv6 Configuration Option
draft-troan-6man-universal-ra-option-04
Network Working Group T. Winters
Internet-Draft QA Cafe
Intended status: Standards Track O. Troan
Expires: 6 May 2021 cisco
2 November 2020
The Universal IPv6 Configuration Option
draft-troan-6man-universal-ra-option-04
Abstract
One of the original intentions for the IPv6 host configuration, was
to configure the network-layer parameters only with IPv6 ND, and use
service discovery for other configuration information. Unfortunately
that hasn't panned out quite as planned, and we are in a situation
where all kinds of configuration options are added to RAs and DHCP.
This document proposes a new universal option for RA and DHCP in a
self-describing data format, with the list of elements maintained in
an IANA registry, with greatly relaxed rules for registration.
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 6 May 2021.
Copyright Notice
Copyright (c) 2020 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
Winters & Troan Expires 6 May 2021 [Page 1]
Internet-Draft The Universal IPv6 Configuration Option November 2020
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
4. The Universal IPv6 Configuration option . . . . . . . . . . . 3
5. Implementation Guidance . . . . . . . . . . . . . . . . . . . 4
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8.1. Initial objects in the registry . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
10. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
This document proposes a new universal option for the Router
Advertisement IPv6 ND message [RFC4861] and DHCPv6 [RFC8415]. Its
purpose is to use the RA and DHCP messages as opaque carriers for
configuration information between an agent on a router or DHCP server
and host / host application.
DHCP is suited to give per-client configuration information, while
the RA mechanism advertises configuration information to all hosts on
the link. There is a long running history of "conflict" between the
two. The arguments go; there is less fate-sharing in DHCP, DHCP
doesn't deal with multiple sources of information, or make it more
difficult to change information independent of the lifetimes, RA
cannot be used to configure different information to different
clients and so on. And of course some options are only available in
RAs and some options are only available in DHCP.
While this proposal does not resolve the DHCP vs RA debate, it
proposes a solution to the problem of a very slow process of
standardizing new options, and the IETF spending an inordinate amount
of time arguing over new configuration options.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "*SHALL NOT*",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Winters & Troan Expires 6 May 2021 [Page 2]
Show full document text