Lightweight 4over6 deployment with DHCPv4 over DHCPv6
draft-liu-softwire-lw4over6-dhcp-deployment-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Cong Liu , Qi Sun | ||
| Last updated | 2013-07-15 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-liu-softwire-lw4over6-dhcp-deployment-00
Network Working Group C. Liu
Internet-Draft Q. Sun
Intended status: Informational Tsinghua University
Expires: January 16, 2014 July 15, 2013
Lightweight 4over6 deployment with DHCPv4 over DHCPv6
draft-liu-softwire-lw4over6-dhcp-deployment-00
Abstract
Lightweight 4over6 is designed to support several dynamic
provisioning protocols. This document discusses how to deploy
Lightweight 4over6 using DHCPv4 over DHCPv6 as the provisioning
protocol.
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 January 16, 2014.
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.
Liu & Sun Expires January 16, 2014 [Page 1]
Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Deployment Considerations . . . . . . . . . . . . . . . . . . 2
3.1. lwB4 Consideration . . . . . . . . . . . . . . . . . . . 3
3.2. lwAFTR Consideration . . . . . . . . . . . . . . . . . . 3
4. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 3
4.1. Model 1 . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Model 2 . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Model 3 . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Carrying lwB4's IPv6 address . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Lightweight 4over6 [I-D.ietf-softwire-lw4over6] is a mechanism which
provides IPv4 access over IPv6 network for hub-and-spoke softwire
architecture using IPv4-in-IPv6 tunneling mechanism. In Lightweight
4over6, Lightweight B4 (lwB4) is assigned a port-restricted IPv4
address or a full IPv4 address by using dynamic IPv4 address
provisioning protocol or static configuration. Lightweight AFTR
(lwAFTR) maintains per subscriber binding consisting of the lwB4's
IPv6 address and its assigned IPv4 address and port set. The binding
table is synchronized with the IPv4 address provisioning process.
DHCPv4 over DHCPv6 [I-D.ietf-dhc-dhcpv4-over-dhcpv6] defines two new
DHCPv6 messages for IPv4 configuration across IPv6 networks:
BOOTREQUESTV6 and BOOTREPLYV6. DHCPv4 messages are put into BOOTP
Message Option using the two new DHCPv6 messages for transportation.
This document discusses how to deploy Lightweight 4over6 using DHCPv4
over DHCPv6 as the IPv4 address provisioning protocol. It mainly
focus on the deployment scenarios and binding table maintaining
issues.
2. Terminology
Terminology defined in [I-D.ietf-dhc-dhcpv4-over-dhcpv6] and
[I-D.ietf-softwire-lw4over6] is used extensively in this document.
3. Deployment Considerations
When deploying Lightweight 4over6 with DHCPv4 over DHCPv6, DHCPv4
over DHCPv6 client function is implemented on the lwB4. lwB4/DHCPv4
-over-DHCPv6 client sends BOOTREQUESTV6 message to either the well-
Liu & Sun Expires January 16, 2014 [Page 2]
Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013
known multicast or directly to the 4o6 Server's IPv6 address in order
to obtain IPv4 address.
In this document, we assume lwAFTR maintains the binding table
dynamically through DHCP process. This means that lwAFTR is co-
located with either a DHCP 4o6 Server, or a DHCPv6 relay agent which
is on the link from the DHCP client to the 4o6 Server.
When lwAFTR is the next-hop of lwB4, it's meaningless to set up IPv4
-in-IPv6 tunnel between lwB4 and lwAFTR, so we ignore this case in
this document.
3.1. lwB4 Consideration
When lwB4/DHCPv4-over-DHCPv6 client uses multicast to send
BOOTREQUESTV6 message, the service provider deploys a DHCPv6 relay
agent which is an one-hop neighbour of lwB4 to relay DHCPv6 messages.
If the DHCP 4o6 Server is not used as lwB4's DHCPv6 server, the relay
agent should be updated to support the separation of 4o6 Server and
DHCPv6 only server as described in section 7 of
[I-D.ietf-dhc-dhcpv4-over-dhcpv6].
When lwB4/DHCPv4-over-DHCPv6 client sends BOOTREQUESTV6 message using
unicast, it needs to obtain the IPv6 address of the DHCP 4o6 Server
before the DHCPv4-over-DHCPv6 process. This address is conveyed by
OPTION_4O6_SERVERS defined in [I-D.ietf-dhc-dhcpv4-over-dhcpv6].
DHCPv4 over DHCPv6 does not prohibit a client without any global IPv6
address to obtain IPv4 address by using multicast. However, the
binding table in AFTR can not be updated if the DHCPv4-over-DHCPv6
packet does not contain lwB4's global IPv6 address, so lwB4 must
obtain global IPv6 address before it starts DHCPv4-over-DHCPv6
process. Section 5 of this document discusses how to carry lwB4's
global IPv6 address in BOOTREQUESTV6 message.
3.2. lwAFTR Consideration
No matter whether the lwAFTR works as a DHCPv6 relay or a DHCP 4o6
Server, it has to extract the DHCPv4 message from the BOOTP Message
Option. lwAFTR uses the information and the global IPv6 address to
update the binding table. Section 5 of this document discusses how
to get the global IPv6 address of lwB4.
4. Deployment Models
There are 3 possible models of the deployment of lwAFTR:
Model 1: lwAFTR is co-located with DHCP 4o6 Server as well as the
Liu & Sun Expires January 16, 2014 [Page 3]
Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013
DHCPv4 server engine of the 4o6 Server
Model 2: lwAFTR is co-located with DHCPv6 relay agent
Model 3: lwAFTR is co-located with DHCP 4o6 Server's v6 part, and
the DHCPv4 server engine is a separate device
When a service provider deploys multiple lwAFTRs, he may have the
requirement of sharing one DHCP 4o6 server among multiple lwAFTRs.
Model 2 and Model 3 supports this usage.
4.1. Model 1
In Model 1, lwAFTR is co-located with a complete DHCP 4o6 Server.
Figure 1 illustrates the architecture of this model.
The lwB4, as a DHCP client, can send the BOOTREQUESTV6 message using
multicast as is described in [RFC3315]. The packets may be relayed
toward the lwAFTR/4o6 Server.
When lwB4 uses unicast to send BOOTREQUESTV6 message, it employs the
IPv6 address conveyed through the 4o6 Servers Address Option
[I-D.ietf-dhc-dhcpv4-over-dhcpv6]. The IPv6 address is that of the
lwAFTR/4o6 Server.
+-------------+
| DHCPv6 |
| Relay Agent |
| (optional) |
+------+------+
+----------+ | +----------+ +----------+
| lwB4/ | | | lwAFTR/ | | IPv4 |
| DHCP +------+-----------------+ 4o6 +---+ Internet |
| Client | IPv4-in-IPv6 tunnel | Server | | |
+----------+ +----------+ +----------+
Figure 1: Model 1
4.2. Model 2
In Model 2, lwAFTR is co-located with a DHCPv6 relay agent. It is
configured with the 4o6 Server's IPv6 address as the destination
address. Figure 2 illustrates the architecture of this model.
When lwB4 uses multicast to send BOOTREQUESTV6 message, the one-hop
neighbour relay agent is configured with the IPv6 address of the
Liu & Sun Expires January 16, 2014 [Page 4]
Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013
lwAFTR/relay agent and relays DHCPv4-over-DHCPv6 packages to lwAFTR/
relay agent.
When lwB4 uses unicast to send BOOTREQUESTV6 message, the destination
address it obtains is the lwAFTR's/relay agent's IPv6 address.
//We are not sure whether a DHCPv6 client should send messages
directly to a relay agent or not.
+-------------+
| DHCPv6 |
| Relay Agent |
| (optional) |
+------+------+
+----------+ | +-------------+ +----------+
| lwB4/ | | | lwAFTR/ | | IPv4 |
| DHCP +------+-----------------+ DHCPv6 +---+ Internet |
| Client | IPv4-in-IPv6 tunnel | Relay Agent | | |
+----------+ +------+------+ +----------+
|
+----+-----+
| 4o6 |
| Server |
+----------+
Figure 2: Model 2
4.3. Model 3
In Model 3, lwAFTR is co-located with a DHCP 4o6 Server, but the
DHCPv4 server engine of the 4o6 Server is a separate device. Figure
3 illustrates the architecture of this model. The behavior of lwB4
and one-hop neighbour relay agent is the same as that in Model 1.
Section 8 of [I-D.ietf-dhc-dhcpv4-over-dhcpv6] describes that the
DHCPv4 server engine can be a separate DHCPv4 server instance, but
does not provide how to implement that and how does a 4o6 Server
communicate with the engine. In this model we suggest the DHCPv4
server engine to be a regular standalone DHCPv4 server.
Liu & Sun Expires January 16, 2014 [Page 5]
Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013
+-------------+
| DHCPv6 |
| Relay Agent |
| (optional) |
+------+------+
+----------+ | +-------------+ +----------+
| lwB4/ | | | lwAFTR/ | | IPv4 |
| DHCP +------+-----------------+ 4o6 +---+ Internet |
| Client | IPv4-in-IPv6 tunnel | Server | | |
+----------+ | (v6) | +----------+
+------+------+
|
+--------+--------+
| 4o6 |
| Server |
| (DHCPv4 engine) |
+-----------------+
Figure 3: Model 3
5. Carrying lwB4's IPv6 address
The lwB4 is expected to send the BOOTREQUESTV6 message using the
lwB4's global IPv6 address, so that lwAFTR can update the binding
table with this information. When lwB4 sends BOOTREQUESTV6 message
by unicast, the source address of the packet can be used as the
client's global IPv6 address. However, this can not be achieved when
lwB4 sends BOOTREQUESTV6 message by multicast because Section 16 of
[RFC3315] defines that the DHCP client must use a link-local address
when using multicast.
There are two possible solutions for this problem: (1) force lwB4/
DHCPv4-over-DHCPv6 client not to use multicast, or (2) Put a DHCPv6
option which contains the global IPv6 address of lwB4 into the
BOOTREQUESTV6 message.
We recommend solution (2) as the address carrying method to fit more
deployment scenarios. The DHCPv6 option to be used may be an
existing option or a new defined option.
6. Security Considerations
TBD
7. Normative References
[I-D.ietf-dhc-dhcpv4-over-dhcpv6]
Liu & Sun Expires January 16, 2014 [Page 6]
Internet-Draft lw4over6 deployment with DHCPv4oDHCPv6 July 2013
Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I.
Farrer, "DHCPv4 over DHCPv6 Transport", draft-ietf-dhc-
dhcpv4-over-dhcpv6-00 (work in progress), April 2013.
[I-D.ietf-softwire-lw4over6]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the DS-Lite
Architecture", draft-ietf-softwire-lw4over6-00 (work in
progress), April 2013.
[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.
Authors' Addresses
Cong Liu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: gnocuil@gmail.com
Qi Sun
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: sunqi@csnet1.cs.tsinghua.edu.cn
Liu & Sun Expires January 16, 2014 [Page 7]