6man Working Group Y. Lee
Internet-Draft Comcast
Intended status: Standards Track M. Boucadair
Expires: April 8, 2011 France Telecom
X. Xu
Huawei
October 5, 2010
IPv6 RA Option for DS-Lite AFTR Element
draft-lee-6man-ra-dslite-01
Abstract
This document specifies a new optional extension to IPv6 Router
Advertisement messages to allow IPv6 routers to advertise DS-Lite
AFTR addresses to IPv6 hosts (i.e., a default IPv6 route for DS-Lite
traffic). The provisioning of the AFTR address is crucial to access
IPv4 connectivity services in a DS-Lite context. Means to ensure
reliable delivery of this information to connecting hosts is a must.
Furthermore, this RA option can be used as a means to distribute DS-
Lite serviced customers among a set of deployed AFTRs without
requiring a central knowledge of the underlying topology and deployed
AFTRs.
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 RFC 2119 [RFC2119].
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 April 8, 2011.
Lee, et al. Expires April 8, 2011 [Page 1]
Internet-Draft RA for AFTR Element October 2010
Copyright Notice
Copyright (c) 2010 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Coexistence of RA Option and DHCPv6 Option . . . . . . . . . . 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Neighbour Discovery Extension . . . . . . . . . . . . . . . . . 4
6.1. AFTR Element Option . . . . . . . . . . . . . . . . . . . . 4
6.1.1. Procedure in IPv6 Host with B4 Implementation . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Load Balancing Use Case . . . . . . . . . . . . . . . 7
Appendix B. Scope . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Lee, et al. Expires April 8, 2011 [Page 2]
Internet-Draft RA for AFTR Element October 2010
1. Introduction
Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] provides a means
to guarantee IPv4 service continuity during the transition period
where global IPv4 addresses become a scarce resource. In the DS-Lite
framework, the B4 element tunnels the IPv4-in-IPv6 datagrams towards
one of the available AFTR entities deployed in the provider network.
The B4 element can learn the AFTR address by DHCPv6
[I-D.ietf-softwire-ds-lite-tunnel-option] or RADIUS
[I-D.maglione-softwire-dslite-radius-ext].
The provisioning of the AFTR information to connecting hosts
embedding B4 is mandatory for the delivery of IPv4 connectivity
services in the context of DS-Lite deployment. As an analogy with
native IPv6 connectivity provisioning, the AFTR information (i.e., IP
address or FQDN) can be seen as a default IPv6 route for DS-Lite
IPv4-in-IPv6 traffic. Indeed, when no AFTR information is
provisioned to a requesting host embedding a B4 element, no external
IPv4 address would be assigned and the IPv4 traffic won't be
delivered outside the local domain. In other terms, fail to
provision an AFTR to B4 element will break IPv4 connectivity.
Service providers need a reliable and flexible method to provision
the AFTR address(es) to the B4 elements in customers' premises. This
document describes a mechanism to use a new IPv6 RA Option to
advertise the AFTR address to the IPv6 hosts.
In the remaining part of the document, host is used for short to
denote a host embedding B4 element.
2. Motivation
A service provider may want to deploy DS-lite without using DHCP.
Auto-configuration [RFC4861] allows an IPv6 host to learn the IPv6
prefix and IPv6 default gateway solely from the Router Advertisement
(RA). In this document, we define a new AFTR RA option so that a B4
element can learn a set of AFTRs.
3. Coexistence of RA Option and DHCPv6 Option
The RA AFTR option and the DHCP option can be used together. When
the host receives a RA and the "O" flag is set in the RA, the host
may send a DHCPv6 request for AFTR provisioning. If the DHCP server
returns the DS-Lite tunnel option, the host may use the address in
the option. If the RA does not contain the AFTR option, the RA may
send the DHCP request to obtain the AFTR configuration from the DHCP
Lee, et al. Expires April 8, 2011 [Page 3]
Internet-Draft RA for AFTR Element October 2010
server regardless of whether the "O" flag is set in the RA or not.
4. Terminology
This document uses terms defined in
[I-D.ietf-softwire-dual-stack-lite]. In addition, we define the
following new terms:
o AFTR Option: IPv6 RA option to deliver AFTR information (e.g., IP
address) to IPv6 hosts.
o AFTR Element List: A data structure for managing AFTR Element
Information in the IPv6 protocol stack in addition to the Neighbor
Cache and Destination Cache for Neighbor Discovery.
5. Overview
This document defines a new ND option called AFTR option that
contains the list of addresses of AFTR element. This new option
advertises a list of available AFTR elements. This option follows
the procedures defined in [RFC4861]. This works the same way that
the hosts learn routers and prefixes. The AFTR element is only
useful for B4 elements, i.e.- ordinary IPv6 hosts must ignore this
option. The IPv6 host with B4 element implemented can learn a list
of AFTR elements thanks to this option.
The AFTR option can be sent along with other options in the same RA
message simultaneously. The router sending the AFTR option in RA
must be configured with the AFTR information. The information is
provisioned in the first-hop router of the B4 elements. The AFTR
option can be used on any network that supports ND.
6. Neighbour Discovery Extension
This AFTR configuration mechanism in this memo defines a new ND
option in Neighbor Discovery: The AFTR Element option.
6.1. AFTR Element Option
The AFTR Element Option contains one or more IPv6 addresses of the
AFTR elements. All of the addresses share the same lifetime value.
If a particular AFTR is configured to have different lifetime values,
a new AFTR option can be used. Figure 1 shows the AFTR Element
Option format.
Lee, et al. Expires April 8, 2011 [Page 4]
Internet-Draft RA for AFTR Element October 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Addresses of IPv6 AFTR Elements :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Where
o Type is the RA AFTR Option type
o Length is a 8-bit unsigned integer. The length of the option is
in unit of 8 octets.
o Reserved is for future use.
o Lifetime is a 16-bit unsigned integer. The lifetime associated
with the AFTR elements in units of seconds.
o Addresses of IPv6 AFTR Elements contain one or more 128-bit IPv6
addresses of the AFTR elements. The number of addresses is
determined by the Length field. That is, the number if addresses
is equal to (Length - 1) / 2.
6.1.1. Procedure in IPv6 Host with B4 Implementation
When the host receives the option via RA, it checks whether the
option is valid.
o If the AFTR option is valid, the host should copy the option's
value into the B4 configuration.
o If the AFTR option is invalid, the host must discard the option.
7. IANA Considerations
This document requests IANA to assign a new option code for:
Lee, et al. Expires April 8, 2011 [Page 5]
Internet-Draft RA for AFTR Element October 2010
o DS-Lite AFTR Address
8. Security Considerations
This document does not introduce any new security in addition to what
has been identified in [RFC4861] and
[I-D.ietf-softwire-dual-stack-lite].
9. Acknowledgements
Many thanks to C. Jacquenet for his review and comments.
10. References
10.1. Normative References
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
in progress), August 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
10.2. Informative References
[I-D.ietf-softwire-ds-lite-tunnel-option]
Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
draft-ietf-softwire-ds-lite-tunnel-option-05 (work in
progress), September 2010.
[I-D.maglione-softwire-dslite-radius-ext]
Maglione, R. and A. Durand, "RADIUS Extensions for Dual-
Stack Lite", draft-maglione-softwire-dslite-radius-ext-00
(work in progress), July 2010.
Lee, et al. Expires April 8, 2011 [Page 6]
Internet-Draft RA for AFTR Element October 2010
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
Appendix A. Load Balancing Use Case
[[Note: The content of this section is still under discussion between
authors.]]
Load balancing and traffic dimensioning is one of the hot topic to be
considered when deploying stateful devices such as AFTRs. Service
providers need means to distribute their DS-Lite serviced customers
among a set of AFTR devices without experiencing any congestion
neither traffic loss due to the overloading of a given AFTR while
free AFTR resources are available. This dimensioning task is not new
per se. In particular, VoIP service providers rely on DNS to
redirect customers traffic to a given SBC (or P-CSCF) node.
Various solutions to balance customers among a set of AFTRs can be
considered as follows:
o DHCPv6 server returns an IPv6 address of an AFTR based on a
identifier of the customer.
o DHCPv6 server returns a generic FQDN of AFTR nodes. A DNS-based
load balancing is implemented during the resolution of the FQDN.
o DHCPv6 returns a geographical domain search name which will be
used to redirect the client to a given AFTR. The DHCPv6 server
needs to correlate the AFTR information with an identifier of the
requesting customer.
o The DHCPv6 relay agent can insert locally configured information
when responding back to a connecting client.
o Etc.
As an alternative to these modes, RA can be used to implicitly
redirect DS-Lite serviced customers to a given AFTR without requiring
any use of a customer identifier. DHCPv6 servers are not modified.
Access routers can be configured to insert an IP address when sending
RAs to attached hosts. The configuration of the information to be
inserted in RA messages can be achieved using already deployed tools.
Lee, et al. Expires April 8, 2011 [Page 7]
Internet-Draft RA for AFTR Element October 2010
Appendix B. Scope
It was tempting to define a generic option which is an extension of
[RFC4191] to indicate a route which is used by IPv4-in-IPv6 traffic.
Since DS-Lite is the only technique which is required crossing a
stateful device after the de-capsulation. We decided to limit the
applicability scope of this option to DS-Lite.
Authors' Addresses
Yiu L. Lee
Comcast
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Mohamed Boucadair
France Telecom
Email: mohamed.boucadair@orange-ftgroup.com
URI: http://www.orange-ftgroup.com
Xiaohu Xu
Huawei
Email: xuxh@huawei.com
Lee, et al. Expires April 8, 2011 [Page 8]