Gateway-Initiated 4over6 Deployment
draft-chen-softwire-gw-init-4over6-01

Abstract

Gateway-Initiated 4over6 (GI-4over6) is a variant of 4over6 mechanisms which include Public 4over6 ([I-D.ietf-softwire-public-4over6]) and Lightweight 4over6 ([I-D.cui-softwire-b4-translated-ds-lite]), and it's designed to satisfy the certain tunnel-based access scenario. The GI-4over6 extends the On-Link Client Relay Agent (LCRA) that is defined in [I-D.ietf-dhc-dhcpv4-over-ipv6] and thus makes it enabled to help gateway device perform 4over6 CE function described in [I-D.ietf-softwire-public-4over6], and lwB4 function described in [I-D.cui-softwire-b4-translated-ds-lite], while the public IPv4 addresses (and available ports) are assigned to the end hosts that behind the gateway device.

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 October 13, 2013.

Copyright Notice

Copyright (c) 2013 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.

Table of Contents

• 1. Overview
• 2. Requirements Language
• 3. Terminology
• 4. GI-4over6 Architecture
• 5. 4over6 Gateway Behaviors
• 5.1. Public 4over6 Mode
• 5.2. Lightweight 4over6 Mode
• 6. Relative Considerations
• 6.1. Consideration for IPv4 Gateway of Customer End Hosts
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Overview

Gateway-Initiated 4over6 (GI-4over6) is a variant of 4over6 mechanisms which include Public 4over6 ([I-D.ietf-softwire-public-4over6]) and Lightweight 4over6 ([I-D.cui-softwire-b4-translated-ds-lite]), and it's designed to satisfy the certain tunnel-based access scenario.

[I-D.ietf-dhc-dhcpv4-over-ipv6] describes a way for communication between traditional DHCPv4 clients with DHCPv4 servers over IPv6-only transport. The On-Link Client Relay Agent (LCRA) defined in the draft can serve any DHCPv4 client on the same link.

If the 4over6 tunnel initiator is the gateway device, and if the DHCP client on the end host behind the gateway device wants to communicate with the remote DHCP server on the tunnel concentrator, and get IPv4 provision from the tunnel concentrator directly, the gateway device must perform the LCRA function to relay the DHCP messages between the end hosts and the remote DHCP server. When it comes to the lightweight 4over6 scenario, if the end host cannot perform as a lwB4, but still wants to get an public IPv4 address, then the data plane function of lwB4 must be performed by the gateway device, and the LCRA on the gateway must extract the port-set information (i.e. the DHCP Port-Set Option defined in [I-D.sun-dhc-port-set-option]) from the DHCP response from the DHCP server, and help the gateway device maintains the state of binding between the identifier of the end host and the port-set.

2. 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 [RFC2119].

3. Terminology

This document uses the terms defined in [I-D.ietf-dhc-dhcpv4-over-ipv6], [I-D.ietf-softwire-public-4over6], [I-D.cui-softwire-b4-translated-ds-lite] and [I-D.sun-dhc-port-set-option].

The other terms used are described as follows:

Customer End Host: The end host in the customer IPv4 network behinds the 4over6 Gateway. It should perform as a DHCP client and communicate with DHCP server on the tunnel concentrator through DHCPv4 over IPv6 mechanism.

4over6 Gateway: The gateway device located at the border of the customer IPv4 network and the IPv6 ISP network. In the Public 4over6 scenario, the 4over6 Gateway should perform the 4over6 CE function. And in the Lightweight 4over6 scenario, the 4over6 Gateway should act as the LwB4.

4over6 Tunnel Concentrator: The border router located between the IPv6 ISP network and the Internet. In the Public 4over6 scenario, the 4over6 Tunnel Concentrator refers to 4over6 CE. And in the Lightweight 4over6 scenario, the 4over6 Tunnel Concentrator refers to LwAFTR.

EX-LCRA: The LCRA with the extended function described in the document. It is assumed to be co-located with the 4over6 Gateway. It could be deployed in ohter ways depending on the actual deployment requirements, and they are out of the scope of this document.

4. GI-4over6 Architecture

The general architecture of GI-4over6 is illustrated as Figure 1. The Customer End Host in the Customer IPv4 Network could be an IPv4 or dual-stack host. The 4over6 Gateway is a dual-stack gateway device provided by the ISP, and has been already enabled to support EX-LCRA.

                                           
  +------------------+           +-------------------------+
  | +----------+     |           |                         |
  | | Customer |   +-+-----------+-+                     +-+-------------+   +----------+
  | | End Host +---+ 4over6        | IPv4-in-IPv6 tunnel | 4over6 Tunnel |   |          |
  | +----------+   | Gateway       |=====================| Concentrator  +---+ Internet |
  | +----------+   | (with EX-LCRA)|                     | (with TSV)    |   |          |
  | | Customer +---+               |  IPv6 ISP Network   +-+-------------+   +----------+
  | | End Host |   +-+-----------+-+                       |
  | +----------+     |           |                         |
  | Customer IPv4    |           +-------------------------+
  | Network          |          
  +------------------+           
    

Figure 1 GI-4over6 Architecture

There are two major scenarios: Public 4over6 Scenario and Lightweight 4over6 Scenario. We assume that in both of the scenario the Customer End Host needs to get public IPv4 access, and the DHCP client on the Customer End Host has to stay traditional (i.e. without any extension to support DHCPv4 over IPv6 transport or Port-Set Option). Hence the actual 4over6 tunnel initiator should be the 4over6 Gateway. And in both scenarios, we assume that there is a 4over6 tunnel that has been established already between the 4over6 Gateway and the 4over6 Tunnel Concentrator.

5. 4over6 Gateway Behaviors

The 4over6 Gateway should act differently in the two major scenarios, which means that the 4over6 Gateway has 2 modes of behaviors. We name them with Public 4over6 Mode and Lightweight 4over6 Mode. The EX-LCRA MUST function in either of the two modes at the same time, depending on the actual scenario it is in.

5.1. Public 4over6 Mode

In the Public 4over6 Scenario, the 4over6 Gateway must perform the 4over6 CE function on the data plane. The Customer End Hosts should get the full public IPv4 addresses directly from the TSV, not any other DHCP server. Therefore, the EX-LCRA must perform the LCRA function described in the Section 6 of [I-D.ietf-dhc-dhcpv4-over-ipv6].

Note that if there is a Port-Set Option in any of the DHCP message going through, the EX-LCRA MUST discard the message.

5.2. Lightweight 4over6 Mode

In the Lightweight 4over6 Scenario, the 4over6 Gateway must perform the LwB4 function on the data plane. The Customer End Hosts should get the public IPv4 addresses and available ports from the TSV, not any other DHCP server. In this case, the EX-LCRA must perform the LCRA function described in the Seciton 6 of [I-D.ietf-dhc-dhcpv4-over-ipv6], and the EX-LCRA MUST also handle the Port-Set Option of the DHCP messages.

For the DHCPDISCOVER message sent by Customer End Host, the EX-LCRA MUST add the Option Code of the Port-Set Option into the DHCP Parameter Request List Option (Option Code 55) of the message.

For the DHCPOFFER message sent by TSV, the EX-LCRA MUST extract the Port-Set Option from the message, and store the match of Client Identifier and the values of Port Set Index and Port Set Mask of the Port-Set Option in a binding table. The EX-LCRA MAY erase the Port-Set Option from the DHCPOFFER message then. Note that if the received DHCPOFFER message doesn't include the Port-Set Option, the EX-LCRA MUST discard the message.

For the DHCPREQUEST message sent by Customer End Host, the EX-LCRA should look into the binding table and search for the Client Identifier carried by the message. If there is an entry that matches, the EX-LCRA should get the values of the Port Set Index and Port Set Mask from the entry, and add the Port-Set Option with theses values into the DHCPREQUEST message.

For the DHCPACK message sent by TSV, the EX-LCRA MUST extract the Port-Set Option from the message, and look into the binding table and search for the Client Identifier carried by the message. If there is an entry that matches, the EX-LCRA should update the values of the Port Set Index and Port Set Mask of the entry with the values of the corresponding field of the Port-Set Option in the DHCPACK message, and enable the binding on the data plane of the 4over6 Gateway.

6. Relative Considerations

6.1. Consideration for IPv4 Gateway of Customer End Hosts

As the TSV is co-located with the 4over6 Tunnel Concentrator and is not in the local IPv4 network, it may not include the correct IPv4 address of the 4over6 Gateway in the DHCP Router Option (Option Code 3), which is the actual gateway and access entrance for the Customer End Hosts. Thus the outbound IPv4 sessions on the Customer End Host may fail because of the lack of default gateway information. In order to get rid of this issue, the EX-LCRA may modify the value of the DHCP Router Option of the DHCP response messages from the remote DHCP server, and input the IPv4 address of the 4over6 Gateway on the LAN side as the value of the DHCP Router Option, when the messages are going to pass through.

7. Security Considerations

The security considerations of the document is well described in all the references, and the document raises barely new security issues.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses