| Network Working Group | M.P. Andrews |
| Internet-Draft | ISC |
| Intended status: Standards Track | May 10, 2011 |
| Expires: November 11, 2011 |
6to4 DHCP Relay Router Option
draft-andrews-v6ops-6to4-router-option-02
Provides a DHCP 6to4 Relay Router option.
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 11, 2011.
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.
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.
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].
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 option in the reply MUST NOT be used as a indication that the client should use 6to4. It is only a instruction to the client of how it should do 6to4 if it is otherwise configured to use 6to4.
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.
The 6to4RRO SHOULD be requested even if a 6to4 relay router has been manually configured. This is done so that the CPE can see if 6to4 needs to be disabled if it is moved between networks. Returned values other than 0.0.0.0 MAY be ignored.
CPE equipement MAY have a configuration knob to disable requesting the 6to4RRO. This knob MUST default to OFF.
Provides a way to distribute load independent of the routing table.
Using a unicast adddress rather than a anycast address allows for reliable reassembly of the IPv4 encapsulating packet.
Provides a way to supply 6to4 decapsulation service which is unlikely to leak to unexpected clients.
6rd [RFC5969] works well as a replacement for 6to4 when the ISP controls the CPE equipment and is willing to deploy 6rd border routers. 6rd does not work so well as a replacement if any these conditions are not met for logistical reasons and may require parallel deployment with 6to4 until the CPE equipement is updated.
6rd requires active participation of the ISP. 6to4 does not.
6rd does not provide a signal to tell the CPE/host not to use 6to4.
The 6to4RRO can often be deployed without requiring additional vendor support with existing equipment.
6to4RRO should not be seen as a reason to not support 6rd in CPE/hosts. 6to4RRO and 6rd have different deployment senarios.
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 enterprises network.
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 to stop clients using IPv4 addresses which will not work with 6to4.
IANA is requested to allocate a DHCP option code point.
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.
| [RFC1918] | Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J. 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. |
| [RFC5969] | Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. |