Internet DRAFT - draft-donley-dhc-cer-id-option
draft-donley-dhc-cer-id-option
Network Working Group C. Donley
Internet-Draft M. Kloberdans
Intended status: Informational CableLabs
Expires: August 16, 2015 J. Brzozowski
Comcast
C. Grundemann
ISOC
February 12, 2015
Customer Edge Router Identification Option
draft-donley-dhc-cer-id-option-05
Abstract
Addressing mechanisms supporting DHCPv6 Prefix Delegation in home
networks such as those described in CableLabs' eRouter specification
and the HIPnet Internet-Draft require identification of the customer
edge router (CER) as the demarcation between the customer network and
the service provider network. This document reserves a DHCPv6 option
to identify the CER.
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 http://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 August 16, 2015.
Copyright Notice
Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Donley, et al. Expires August 16, 2015 [Page 1]
Internet-Draft cer-id-option February 2015
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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. CER Identification Option . . . . . . . . . . . . . . . . . . 2
3. CER-ID Compatibility . . . . . . . . . . . . . . . . . . . . 3
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
7.1. Normative References . . . . . . . . . . . . . . . . . . 4
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Some addressing mechanisms supporting DHCPv6 Prefix Delegation in
home networks such as those described in
[I-D.grundemann-homenet-hipnet] and [EROUTER] require identification
of the customer edge router as the demarcation between the customer
network and the service provider network. For prefix delegation
purposes, it is desirable for other routers within the home to know
which device is the CER so that the customer home network only
requests a single prefix from the ISP DHCPv6 server, and efficiently
distributes this prefix within the home. CER-ID is a 128-bit string
that optionally represents an IPV6 address, or another arbitrary
number. The CER-ID maybe treated as a hint to be used with border
detection methods. This document reserves a DHCPv6 option to be used
to identify the CER.
1.1. Requirements Language
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].
2. CER Identification Option
A Customer Edge Router (CER) sets the CER_ID to the IPv6 address of
its LAN interface. If it has more than one LAN IPv6 address, it
selects one of its LAN or other non-WAN IPv6 addresses to be used as
the CER_ID. An ISP server does not respond with the CER_ID or sets
Donley, et al. Expires August 16, 2015 [Page 2]
Internet-Draft cer-id-option February 2015
the CER_ID to ::. Such a response or lack of response indicates to
the DHCPv6 client that it is the CER.
The format of the CER Identification option is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CER_ID |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CER_ID (TBD).
option-len 36
CER_ID value IPv6 address of CER or ::
Figure 1.
A DHCPv6 client SHOULD include the CER Identification option code in
an Option Request option [RFC3315] in its DHCP Solicit messages.
The DHCPv6 server MAY include the CER Identification option in any
response it sends to a client that has included the CER
Identification option code in an Option Request option. The CER
Identification option is sent in the main body of the message to
client, not as a sub-option in, e.g., an IA_NA, IA_TA
[RFC3315]option.
When sending the CER Identification option, the DHCPv6 server MUST
set the CER_ID value to either one of its IPv6 addresses, another
identifier, or ::. If a device does not receive the CER
Identification Option or receives a CER ID of :: from the DHCPv6
server, it MUST include one of its Globally Unique IPv6 addresses
(unless another identifier is used), in the CER_ID value in response
to DHCPv6 messages received by its DHCPv6 server that contains the
CER Identification option code in an Option Request option. If the
device has only one LAN interface, it SHOULD use its LAN IPv6 address
as the CER_ID value. If the device has more than one LAN interface,
it SHOULD use the lowest Globally Unique address.
3. CER-ID Compatibility
CER-ID explicitly indicates that a gateway is, or is not, the
demarcation point between public and private networks by containing a
reachable IPv6 address, other identifier or a double colon '::'
Donley, et al. Expires August 16, 2015 [Page 3]
Internet-Draft cer-id-option February 2015
(double colon indicates that the CER-ID sender is NOT the edge
router), and as a complement, can be applied to various border
definitions and detection methods such as:
o I.D. Draft-IETF-Homenet-Arch-16 [I-D.ietf-homenet-arch]
o I.D. Draft-Grundemann-homenet-HIPnet-01
[I-D.grundemann-homenet-hipnet]
o I.D. Draft-IETF-Kline-Homenet-Default-Perimeter-01
[I-D.kline-default-perimeter]
o Others, including manual configuration
4. IANA Considerations
IANA is requested to assign an option code from the "DHCP Option
Codes" Registry for OPTION_CER_ID. IANA is also requested to
maintain a list of authentication options.
5. Security Considerations
The security of a home network is an important consideration. Both
the HIPNet [I-D.grundemann-homenet-hipnet] and Homenet
[I-D.ietf-homenet-arch] approaches change the operational model of
the home network vs. today's IPv4-only paradigm. Specifically, these
networks eliminate NAT inside the home network (and only enable it
for IPv4 at the edge router, if required), support global
addressability of devices, and thus need to consider firewall and/or
filter support in various home routers. As the security profile of
these home routers can shift based on their position in the network
(e.g., edge vs. internal), security can be severely compromised if
routers misidentify their border and mistakenly reduce or eliminate
firewall rules. If the CER-ID option is used as part of the border
detection algorithm, it becomes a natural, but not the only place to
enact firewall, NAT, Prefix Delegation and other functions in the
home network. Further security is provided using the mechanisms
defined in RFC 3315, DHCP for IPv6.
6. Acknowledgements
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Donley, et al. Expires August 16, 2015 [Page 4]
Internet-Draft cer-id-option February 2015
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
7.2. Informative References
[EROUTER] CableLabs, "CableLabs IPv4 and IPv6 eRouter Specification
(CM-SP-eRouter-I12-131120)", April 2014.
[I-D.grundemann-homenet-hipnet]
Grundemann, C., Donley, C., Brzozowski, J., Howard, L.,
and V. Kuarsingh, "A Near Term Solution for Home IP
Networking (HIPnet)", draft-grundemann-homenet-hipnet-01
(work in progress), February 2013.
[I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"IPv6 Home Networking Architecture Principles", draft-
ietf-homenet-arch-16 (work in progress), June 2014.
[I-D.kline-default-perimeter]
Kline, E., "Default Border Definition", draft-kline-
default-perimeter-01 (work in progress), November 2012.
Authors' Addresses
Chris Donley
CableLabs
858 Coal Creek Cir.
Louisville, CO 80027
US
Email: c.donley@cablelabs.com
Michael Kloberdans
CableLabs
858 Coal Creek Cir
Louisville, CO 80027
US
Email: m.kloberdans@cablelabs.com
Donley, et al. Expires August 16, 2015 [Page 5]
Internet-Draft cer-id-option February 2015
John Brzozowski
Comcast
1306 Goshen Parkway
West Chester, PA 19380
US
Email: john_brzozowski@cable.comcast.com
Chris Grundemann
ISOC
Denver CO
Email: cgrundemann@gmail.com
Donley, et al. Expires August 16, 2015 [Page 6]
