Network Working Group M. Andrews
Internet-Draft ISC
Intended status: Standards Track May 9, 2011
Expires: November 10, 2011
6to4 DHCP Relay Router Option
draft-andrews-v6ops-6to4-router-option-01
Abstract
Provides a DHCP 6to4 Relay Router option.
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 November 10, 2011.
Copyright Notice
Copyright (c) 2011 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
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.
Andrews Expires November 10, 2011 [Page 1]
Internet-Draft 6to4 DHCP Relay Router Option May 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
2. 6to4 Relay Router Option . . . . . . . . . . . . . . . . . . . 3
3. CPE Equipment . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Deployment Senarios . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Enterprise Deployment . . . . . . . . . . . . . . . . . . . 4
4.2. ISP Deployment . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Andrews Expires November 10, 2011 [Page 2]
Internet-Draft 6to4 DHCP Relay Router Option May 2011
1. Introduction
Using 6to4 [RFC3056] currently requires manual configuration of the
relay router or the use of a anycast relay router [RFC3068]. The
latter has a number of well known issues (add reference).
This document attempts to address some of those issues by providing a
method for clients to discover the address of a 6to4 relay router.
It is expected that the 6to4 relay router will be managed and that it
will be topologically close to the client thereby reducing some of
the issues with using public anycast relay routers.
Additionally not all IPv4 address allocated to clients are suitable
for use with 6to4. Whether they be [RFC1918] address, or other
addresses behind a NAT, or are behind a firewall which blocks 6to4
encapsulted traffic. This document provides a method for the DHCP
server operator to signal that the address being returned is not
suitable for use with 6to4.
1.1. Reserved Words
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 [RFC2119].
2. 6to4 Relay Router Option
The 6to4 DHCP Relay Router Option (6to4RRO) has code TBD and consists
of a single IPv4 address specifing the IPv4 address of the 6to4 relay
router. Setting the relay router address to 0.0.0.0 indicates that
6to4 will not work for returned lease address.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | 4 | relay router ~
+---------------+---------------+---------------+---------------+
~ address |
+-------------------------------+
The presence of a 6to4RRO in a reply MUST NOT be used as a indication
that the client should use 6to4. It is only a instruction to client
of how it should do 6to4 if it is otherwise configured to use 6to4.
Andrews Expires November 10, 2011 [Page 3]
Internet-Draft 6to4 DHCP Relay Router Option May 2011
3. CPE Equipment
CPE equipment SHOULD be configured to request the 6to4RRO option if
6to4 has been enabled. If 0.0.0.0 is returned in response to the
6to4RRO option the CPE SHOULD disable 6to4 and withdraw any
advertised 6to4 prefixes.
4. Deployment Senarios
4.1. Enterprise Deployment
To prevent accidental 6to4 tunnels a enterprise would set 6to4RRO to
0.0.0.0. This is intended to turn off mobile clients that have
accidently left 6to4 enabled when connecting to the enterpises
network.
4.2. ISP Deployment
ISPs, with a IPv6 connection to the public Internet, would set
6to4RRO to point to 6to4 relay routers run by the ISP. This will
provide their customers with a managed 6to4 routers which are
topologically close to the client. If the ISP does not have IPv6
connectivity it SHOULD NOT set the 6to4RRO option unless it knows the
addresses it it returning will not work with 6to4.
If the ISP is returning a IPv4 addresses which will be subject to
network address translation, regardless of whether they have IPv6
connectivity or not, it SHOULD set the returned 6to4RRO option to
0.0.0.0. This is intended stop clients using IPv4 addresses which
will not work with 6to4.
5. IANA Considerations
IANA is requested to allocate a DHCP option code point.
6. Security Considerations
A rogue DHCP server advertising this option can cause 6to4 traffic to
be redirected anywhere in the world.
Setting the returned address to 0.0.0.0 can be used to deny 6to4
service when it would otherwise work.
Andrews Expires November 10, 2011 [Page 4]
Internet-Draft 6to4 DHCP Relay Router Option May 2011
7. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
Author's Address
Mark P. Andrews
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
US
Email: marka@isc.org
Andrews Expires November 10, 2011 [Page 5]