One document matched: draft-lee-6man-ra-dslite-00.txt
6man Working Group Y. Lee
Internet-Draft Comcast
Intended status: Standards Track M. Boucadair
Expires: April 1, 2011 France Telecom
September 28, 2010
IPv6 RA Option for DS-Lite AFTR Element
draft-lee-6man-ra-dslite-00
Abstract
This document specifies a new optional extension to IPv6 Router
Advertisement to allow IPv6 routers to advertise DS-Lite AFTR
addresses to IPv6 hosts. The provisioning of the AFTR information 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 1, 2011.
Copyright Notice
Lee & Boucadair Expires April 1, 2011 [Page 1]
Internet-Draft RA for AFTR Element September 2010
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. Neighour 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 & Boucadair Expires April 1, 2011 [Page 2]
Internet-Draft RA for AFTR Element September 2010
1. Introduction
Dual-Stack Lite [I-D.ietf-softwire-dual-stack-lite] is an IPv6
transition technique that provides IPv4 connectivity service to IPv6-
enabled hosts. In DS-Lite framework, the B4 element must tunnel the
IPv4-in-IPv6 datagrams to the AFTR in the provider network. As
currently defined in Softwire WG, B4 element learns the AFTR address
from DHCPv6 [I-D.ietf-softwire-ds-lite-tunnel-option] and RADIUS
[I-D.maglione-softwire-dslite-radius-ext].
The provisioning of the AFTR information to connecting hosts is
mandatory for the delivery of IPv4 connectivity services in the
context of DS-Lite deployment. As an analogy with IPv6 connectivity
provisioning, the AFTR information is similar to both the assignment
of an IPv6 address and a default IPv6 route. Indeed, when no AFTR
information is provisioned to a requesting hosts, 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 distribute
the AFTR addresses 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.
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 memo, we define a new AFTR RA option so that a B4
element can learn a set of AFTRs from the RA.
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 DHCP 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
server regardless of whether the "O" flag is set in the RA or not.
Lee & Boucadair Expires April 1, 2011 [Page 3]
Internet-Draft RA for AFTR Element September 2010
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 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 IPv6 addresses of AFTR elements. This new
option advertises an available list of AFTR elements. This option
follows the procedures defined in [RFC4861]. AFTR element is only
useful for B4 elements, ordinary IPv6 host must ignore this option.
The IPv6 host with B4 element implemented may learn a list of AFTR
elements in this option. When the option contains multiple
addresses, the B4 element configures and prioritize the AFTR elements
based on local policy.
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. Neighour 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. [RFC2119] shows the AFTR Element
Option format.
Lee & Boucadair Expires April 1, 2011 [Page 4]
Internet-Draft RA for AFTR Element September 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 & Boucadair Expires April 1, 2011 [Page 5]
Internet-Draft RA for AFTR Element September 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
TBD
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 & Boucadair Expires April 1, 2011 [Page 6]
Internet-Draft RA for AFTR Element September 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 customer traffic to a given SBC (or P-CSCF) node.
Various solutions to balance customer 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. This logic is not natively supported
by DHCPv6 servers and brings additional complexity to the DHCPv6
server.
o DHCPv6 server returns a generic FQDN of AFTR nodes. A DNS-based
load balancing is implemented during the resolution of the FQDN.
One of the drawbacks of this alternative is it does not guarantee
that the same AFTR will be assigned to a requesting client. In
particular, the load balancing system must redirect a client to an
AFTR where it has installed previous static port bindings;
otherwise two distinct external IPv4 addresses will be used to
represent the same client.
o DHCPv6 returns a geographical domain search name which will be
used to redirect the client to a given AFTR. The drawback of this
option is that the DHCPv6 server needs to correlate the AFTR
information with an identifier of the requesting customer.
o The DHCPv6 agent relay can insert locally configured information
when responding back to a connecting client. This processing can
be simplified if the RA mode is used to convey the AFTR
information. The DHCPv6 agent relay has not to inspect the
content of all received DHCP messages from the connecting clients
Lee & Boucadair Expires April 1, 2011 [Page 7]
Internet-Draft RA for AFTR Element September 2010
(indeed, some of these clients may not be DS-Lite serviced and
therefore the agent rely should not blindly insert the AFTR
information).
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 or local
FQDN when sending RAs to attached hosts. The configuration of the
information to be inserted in RA messages can be achieved using
already deployed tools.
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
Lee & Boucadair Expires April 1, 2011 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 03:16:53 |