| DHC Working Group | W. Wang |
| Internet-Draft | L. Zhang |
| Intended status: Standards Track | X. Que |
| Expires: March 22, 2015 | BUPT University |
| L. Li | |
| Tsinghua University | |
| Y. Wang | |
| BUPT University | |
| September 18, 2014 |
Discovery of the IPv6 Prefix in 464XLAT
draft-wang-v6ops-xlat-prefix-discovery-00
The 464XLAT[RFC6877] provides a solution with limited IPv4 connectivity across an IPv6-only network. In the architecture, the CLAT must discover the PLAT-side translation IPv6 prefix. This document defines a mechanism for CLAT to learn the IPv6 prefix used for protocol translation on an access network.
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 March 22, 2015.
Copyright (c) 2014 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.
464XLAT describes an IPv4-over-IPv6 solution as one of the techniques for IPv4 service extension and encouragement of IPv6 deployment. The 464XLAT architecture uses IPv4/IPv6 translation standardized in [RFC6145] and [RFC6146]. It encourages the IPv6 transition by making IPv4 service reachable across IPv6-only networks and providing IPv6 and IPv4 connectivity to single-stack IPv4 or IPv6 servers and peers.
Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis [RFC7050] describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. But it is difficult and depends on DNS64.
This document defines a mechanism for CLAT to learn the IPv6 prefix used for protocol translation on an access network. One new DHCPv6 option is defined to inform the CLAT of the IPv6 prefix used for IPv6 address synthesis.
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].
In the 464XLAT architecture, the CLAT must discover the PLAT-side translation IPv6 prefix used as a destination of the PLAT. The CLAT will use this prefix as the destination of all translation packets that require stateful translation to the IPv4 Internet.
The CLAT implements OPTION_V6_PLATPREFIX, which is a DHCPv6 option containing the IPv6 prefix used as a destination of the PLAT. The client includes this option within the ORO option in its DHCPv6 request, indicates its support for the IPv6 prefix to the DHCP server.
OPTION_V6_PLATPREFIX is also implemented by the server to identify the client which support IPv6 prefix. With this option, the server informs the client of the IPv6 prefix used as a destination of the PLAT.
The following diagram shows the client/server message flow and how the DHCPv6 option OPTION_V6_PLATPREFIX is used. In each step, the relevant DHCPv6 message is given above the arrow and the OPTION_V6_PLATPREFIX below the arrow.
DHCPv6 Client DHCPv6 Server
| Solicit |
Step 1 |----------------------------------------------------->|
| ORO with OPTION_V6_PLATPREFIX |
| |
| ADVERTISE |
Step 2 |<-----------------------------------------------------|
| OPTION_V6_PLATPREFIX (platv6-prefix with |
| PLAT-side translation IPv6 prefix) |
| |
| REQUEST |
Step 3 |----------------------------------------------------->|
| OPTION_V6_PLATPREFIX (platv6-prefix with |
| CLAT-side translation IPv6 prefix) |
| |
| REPLY |
Step 4 |<-----------------------------------------------------|
| OPTION_V6_PLATPREFIX (platv6-prefix with |
| CLAT-side translation IPv6 prefix) |
| |
Figure 1: Server/Client Interaction Procedure
The DHCPv6 Server and Client MAY implement the OPTION_V6_PLATPREFIX. A Client that intends to dynamically discover the PLAT-side translation IPv6 prefix SHOULD include the code of OPTION_V6_PLATPREFIX in the ORO when it sends a Solicit message.
When a DHCPv6 server replies with a ADVERTISE message, it SHOULD include the platv6-prefix with PLAT-side transition IPv6 prefix. The OPTION_V6_PLATPREFIX is used by the server to inform the client of the PLAT-side transition IPv6 prefix.
When the client sends a REQUEST message, it SHOULD include the platv6-prefix with CLAT-side translation IPv6 prefix. The OPTION_V6_PLATPREFIX is used by the client to inform the server of the transition IPv6 prefix.
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_V6_PLATPREFIX | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| platv6-prelen | |
+-+-+-+-+-+-+-+-+ platv6-prefix .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TBA
This document defines one new DHCPv6 option, the OPTION_V6_PLATPREFIX option in Section 4.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [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. |