Internet DRAFT - draft-toutain-softwire-point6box
draft-toutain-softwire-point6box
Network Working Group L. Toutain
Internet-Draft B. Stevant
Expires: July 30, 2006 GET/ENST Bretagne
F. Dupont
CELAR
D. Binet
FT R&D
January 26, 2006
The Point6Box Approach
draft-toutain-softwire-point6box-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Point6Box is an add-on equipment which brings IPv6 connectivity
to home and SME in a non-intrusive way. It is a deployment tool
which will be replaced by IPv6 native service in term.
Toutain, et al. Expires July 30, 2006 [Page 1]
Internet-Draft Point6Box January 2006
1. Motivation
IPv6 is nowadays implemented in many components such as core network,
operating systems and even in several applications, but end-to-end
IPv6 connectivity is still missing, especially because very few
Internet Access Providers (IAP) offer for IPv6 connectivity and
prefixes allocation. The IETF and some companies have defined and/or
developed transitions tools like: 6to4, Tunnel Broker or Teredo, but
these tools concern either experimented users or do not offer all the
IPv6 benefits (always-on, machine to machine communications,...) to
build applications. Furthermore, some of these solutions may also
lead to some security threat.
In this document we present the Point6Box and its counterpart the
Point6 Provider Edge (PEv6), two equipments that bring IPv6
connectivity to home and SME (Small and Medium Enterprise). This
experiment has been launched by the Point6 project in 2005 and fills
some of the requirements of the "hub and spoke" problem described by
the Softwires working group [ID.problemstatement]. This document
gives a short overview of the motivation, architecture and protocols
used to solve the problem.
The Point6Box is an add-on equipment that can be connected to any
CPEv4 or router in order to bring IPv6 connectivity and
functionalities in a non-intrusive way. It is important to note that
our goal is to fill missing gaps and not to specialize an equipment
for IPv6 connectivity. Progressively, when IAP routers and CPE
(Customer Premise Equipment) will become IPv6 aware, these
functionalities will be included into equipments.
Several usages and objectives have been identified in this project:
o allow IPv6 connectivity for devices connected in a SME and Home
network, in a very easy way, nearly without configuration from the
user,
o locate IPv6 functionalities on stand-alone and cheap equipment to
avoid to rely on desktop computers. Since IPv6 implies to be
always-on, the Point6Box has not to be switched off.
o allow the introduction of IPv6 demonstrators on existing IPv4
network infrastructure. For instance, this allows an R&D division
to add features to existing products and to make demonstration to
business units.
o anticipate new usages. The connectivity offered by the Point6Box
is very close to native access. Currently, new applications such
as machine to machine communication relying on auto-configuration
features and service discovery can be tested.
o manage an IPv6 network to discover missing features and debugging
existing software to improve quality and reduce exploitation
costs. Experiences learned during the transition phase must be
Toutain, et al. Expires July 30, 2006 [Page 2]
Internet-Draft Point6Box January 2006
directly reused when IPv6 will be run on native infrastructures.
o use open source software for CPE and PE and extend functionalities
when needed.
o use only fully standardized protocols, such as L2TP [RFC2661],
PPP, etc.
o be able to run over any IPv4 infrastructures (any NAT solutions)
to provide a a transition tool to IAPs compliant with future
native access architecture.
2. Technical description
Technically, the Point6Box can be viewed as an IPv6 router with only
one Ethernet port plugged into an IPv4 router. Through this port,
the Point6Box will establish connectivity to an IPv6 Provider Edge.
The tunnel is made over L2TP, which provides three main
characteristics:
o L2TP messages are carried over UDP to offer NAT-traversal
capabilities,
o PPP is used to carry IPv6 frames, so we can rely on built-in
authentication and configuration mechanisms, and have very easy
interaction with AAA servers.
o LPC sub-protocol may be used to detect when a tunnel is down, for
instance due to an IPv4 address renumbering
The Point6Box removes the L2TP encapsulation and forwards incoming
IPv6 packets on the link. Generally SME or Home routers interfaces
are bridged with an IEEE 802.11 network, so every equipment connected
to that network will receive Router Advertisements. IPv6 traffic
generated by these equipments will be routed through the Point6Box.
IPv4 traffic will continue to be NATed by the IPv4 edge router.
The Point6 Provider Edge is connected to the IPv6 backbone. It
includes the server part and can be connected to an AAA database to
allow authorization and monitoring. The following picture describes
the service architecture.
Toutain, et al. Expires July 30, 2006 [Page 3]
Internet-Draft Point6Box January 2006
/---------------------------\ CPEv6
| +--------------+ | DHVPv6 +-----+
| /....>| DHCPv6 relay |<........................>| P |
| . +--------------+ | CPEv4 | o | |
| . | L2TP IPv6 | | L2TP +-----+ | i | |-- X
| . | server |=======================b=== n B | |
| v +--------------+ | @@ @@ | r| | t o | |
| +--------+ ^ | @ @@ @ | N i|-| 6 x | |-- Y
| | DHCPv6 | | |--@ IPv4 @------| A d| +-----+ |
| | server | | | @ @@ @ | T g| |
| +--------+ | | @@ @@ PEv4 | e|----------|
\-------------|-------------/ +-----+ RA-> |-- Z
| PEv6 |
+--------+ | clients
| RADIUS | | RADIUS
| server |<-/
+--------+ IPv4/v6 ISP Customer
Figure 1: Service Architecture
During the initialization part, the Point6Box establishes a PPP
peering with the PEv6 through the IPv4 Internet. Parameters required
for the configuration of the Point6Box are the IPv4 address of this
PE and a login/password. The PEv6 replies with a PPP/CHAP challenge
and the Point6Box authenticates itself. The PEv6 queries an AAA
server to validate the user authorization.
AAA and DNS servers will play an important role in network
management. Since only the end system will create addresses, a
provider must offer an IPv6 network with prefixes. The AAA server is
used to centralize information concerning the user. When the AAA
server authenticates the user, it returns a positive acknowledgment
and the information concerning the account. We have currently
identified three main parameters:
o Delegated prefix [ID.delegated]: It is allocated by the provider
to the site network. The minimal length can be a commercial
agreement between the user and the provider. It may vary between
48 and 64 bits regarding the SME/home network topology or the
policy the user has with its provider. The prefix allocation is
centralized on the AAA server. This allows the provider to get a
centralized vision of the mapping between users and allocated
prefixes, but the allocation made by the AAA server must have the
following properties: stability over time and aggregation in the
provider core network.
o DNS service: It is used in the traditional way to find the address
from name and vice-versa.
Toutain, et al. Expires July 30, 2006 [Page 4]
Internet-Draft Point6Box January 2006
o DNS domain: In this domain the user can register some equipments
through DNS Dynamic Update. The default name could be something
like user-login.provider.net.
Both ends of the IPv6 tunnel are configured with link-local
addresses, and global addresses (for administration purposes). Then,
the Point6Box sends a DHCPv6 [RFC3315] request to get the account
parameters. The reply contains a prefix (64 bit long (aka. /64) or
shorter) [RFC3633] and other parameters previously returned by the
AAA server.
Auto-configuration of the SME/Home network is a major feature to
rapidly spread IPv6. If the SME/Home network includes several
routers configuration for IPv4 requires technical skills. We have
study several approaches to offer internal routers configuration (see
[AINA2005]). In this proposal, we focus on DHCPv6 because it does
not require any modification, even if this approach is less efficient
in case of multi-homing .
The Point6Box includes a DHCPv6 server to answer the requests inside
the domain. The static parameters such as DNS resolver and the DNS
domain are given to other routers and a pool of /64 prefixes is a
constructed based on the prefix received from the provider. An
internal router will execute the following algorithm, when one of its
interface gets configured through the Neighbor Discovery (ND)
[RFC2461] [RFC2462] protocol:
o The router sends DHCPv6 requests for a /64 prefix (the interaction
with ND as explained in [AINA2005] is used to detect loops or dual
prefixes allocation),
o The router waits for answers from the Point6Box containing the
prefix and other parameters,
o The router assigns prefixes to interfaces. It starts unicast and
multicast routing and a DHCPv6 relay. The relay functionality is
used to allow downstream routers to talk with the DHCPv6 server.
At this point, the internal routers are configured, the equipment
addresses can be setup through standard Neighbor Discovery protocol
and other parameters through DHCPv6. Names and services discovery
becomes an important feature in auto-configured networks since
addresses cannot be a priori guessed. It is not clear if DNS is the
appropriate answer, more experimentation have to be done. In a first
approach, we propose to study the Dynamic Update, and offer this
service in the provider network. Every host wanting to register to
the DNS, has received through DHCPv6 the domain name and the resolver
address and can run a script to register its addresses in the direct
and reverse DNS. The provider may prevent misleading usage by
filtering prefixes.
Toutain, et al. Expires July 30, 2006 [Page 5]
Internet-Draft Point6Box January 2006
3. PEv6 Architecture overview
On the CPEv6 equipment, the interaction between different protocols
is relatively simple and in sequence. The L2TP tunnel is open, then
a response to the challenge is sent, followed by a ND router
solicitation and a DHCPv6 request. The interactions between
protocols are more complex on the PEv6 equipment.
The PEv6 waits for L2TP connection. The L2TP service is not
protected by a shared secret, since this secret will have to be
shared between all the customers and will not prevent from a DoS
attack.
When a CPEv6 opens a tunnel, PPP is activated on that tunnel and a
challenge is sent and a response is expected. The response contains
the challenge, the answer to the challenge and the customer identity.
The PEv6 forwards these values to an AAA (RADIUS [RFC2865] today)
server. Currently on our experimentation, the response from the AAA
server is just used to accept or not the connection. This should be
enhanced in the future and the AAA will return more attributes like
delegated prefix and other parameters.
Note that the value of the delegated prefix must be as stable as
possible, but must depend on the PE location to allow aggregation in
the IPv6 core network. So if a customer moves its Point6Box from one
place to another, he may not receive the same delegated prefix.
The PEv6 receives user-specific IPv6 parameters from the AAA server
during access authentication. It cannot send them directly using the
PPP/IPv6CP protocol since only Link Local prefixes are negotiated.
The PEv6 has to save information returned by the AAA server and to
provide them later to the client during DHCPv6 negotiation
When the CPEv6 requests DHCPv6 parameters, a mapping must be
established between the DUID used by DHCPv6 to identify CPE and
information returned by AAA identified by user name. To allow
this mapping, a DHCPv6 Relay function is added for each active L2TP
tunnel. This relay adds RRAO (Relay agent RADIUS Attribute Option
[ID.rrao]) information containing user name to the request anf
forwards it to the DHCPv6 server.
Since the Point6Box service should maintain for a prefix a mid-term
stability, prefix assignments to users are saved in a lease database.
The DHCPv6 server may also use attributes provided by RRAO to decide
which prefix pool is to be used for this particular user based on
information from AAA.
The PEv6 needs to know what prefixes are allocated, for instance for
Toutain, et al. Expires July 30, 2006 [Page 6]
Internet-Draft Point6Box January 2006
route injection. Today the information is snooped by the DHCPv6
relay because the right mechanism [ID.notagent] was published after
the code was developed.
4. Transition
As stated before, the goal of the Point6Box is not to install IPv6
services on a new equipment. The goal of the Point6Box is to
disappear when full connectivity will be established. During that
time, the Point6Box will have helped to debug existing
implementations, to explore new ways of managing IPv6 networks and to
develop missing applications. One possible transition scenario is
the integration of Point6Box software into existing CPE, and continue
to tunnel IPv6 until all the provider network has been updated to
manage natively IPv6. At this time, complete transition will mean
merging of IPv4 and IPv6 AAA databases.
5. Scenarios and future plans
Several scenarios have been identified for a current use of the
Point6Box:
o offer an easy IPv6 connectivity. The non-intrusive introduction
of IPv6 in existing network, will help to demonstrate the benefits
of IPv6 (global addresses, auto-configuration, always on,...)
without modifying existing architecture. In France, lots of
providers are offering triple play services. IPv6 access is
incompatible with this offer due to implementation limitation.
Using an IPv6 CPE instead of the provider box currently implies
loosing television or telephony offers. Point6Box approach allows
users to continue to access to all their services and to get an
IPv6 connectivity. In that way, the user and the provider may
test new services.
o deploy the IPv6 in a private network. A company specialized in
digital signages has to install display devices in hotels, shops
and supermarkets. The use of IPv4 is complex since display
equipments are behind a NAT. The media server, which contains the
contents update, cannot contact directly the equipments. With
IPv6 each equipment has a global and stable address. The media
server can send in real time the contents updates. The Point6Box
approach will simplify the deployment of such services:
1. an authenticated tunnel will be set to the media server
2. IPv6 auto-configuration routers and hosts properties will
allow equipments to be simply plugged on the network without
special configuration.
This scenario does not require a full Internet connectivity, since
it focuses on a closed group of users. Security features are not
blocking, since the Point6Box can strongly authenticate itself to
the PEv6.
Toutain, et al. Expires July 30, 2006 [Page 7]
Internet-Draft Point6Box January 2006
o Experiment new usages: IPv6 network will not be managed in the
same way as an IPv4 networks: providers will allocate prefixes
instead of addresses, equipments like television set will have an
IPv6 address, ... This will lead to other paradigms on
networking. The Point6Box may help to find innovative usages,
adapt or develop new protocols and services. We currently
investigate in network auto-configuration, service discovery,
securing auto-configuration and automatic filtering of IPv6
Point6Box is a good experimental platform to implement research
results.
We are also working in mobility features especially in header
compression to limit the impact of tunneling overhead on low
bandwidth links as wireless networks. This could help to demonstrate
new services even when the wireless infrastructure is IPv4 only.
6. Acknowledgments
The Point6Box development has been made on by a Point6 team (founded
by the Brittany Region Council, GET/ENST Bretagne and IRISA/INRIA).
This work will not have been possible without the support of Etienne
Gallet de Santerre, Herve Le Goff, Yannick Skrzypacz. We would also
like to thank the Point6Boxes used by some of the authors to edit
this document with IPv6.
7. Security Considerations
The Point6Box approach uses only already existing protocols so should
not introduce new security issues.
8. References
8.1 Normative References
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
Toutain, et al. Expires July 30, 2006 [Page 8]
Internet-Draft Point6Box January 2006
December 2003.
8.2 Informative References
[AINA2005]
Chelius, G., Fleury, E., and L. Toutain, "No
Administration Protocol (NAP) for IPv6 Router Auto-
Configuration", AINA 2005 IEEE 19th International
Conference on Advanced Information Networking and
Applications, March 2005.
[ID.delegated]
"RADIUS Delegated-IPv6-Prefix Attribute".
[ID.notagent]
Droms, R., Volz, B., and O. Troan, "DHCP Relay Agent
Assignment Notification Option",
draft-ietf-dhc-dhcpv6-agentopt-delegate-00.txt (work in
progress), July 2006.
[ID.problemstatement]
Li, X., Durand, A., Miyakawa, S., Palet, J., Parent, F.,
and D. Ward, "Softwire Problem Statement",
draft-ietf-softwire-problem-statement-00.txt (work in
progress), December 2005.
[ID.rrao] Wing Cheong Lau, "DHCPv6 Relay agent RADIUS Attribute
Option", draft-ietf-dhc-v6-relay-radius-01.txt (work in
progress), August 2005.
[RFC2461] "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] "IPv6 Stateless Address Autoconfiguration", RFC 2462,
December 1998.
[RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", RFC 4057,
June 2005.
Toutain, et al. Expires July 30, 2006 [Page 9]
Internet-Draft Point6Box January 2006
Authors' Addresses
Laurent Toutain
GET/ENST Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Fax: +33 2 99 12 70 30
Email: Laurent.Toutain@enst-bretagne.fr
Bruno Stevant
GET/ENST Bretagne
2 rue de la Chataigneraie
CS 17607
35576 Cesson-Sevigne Cedex
France
Fax: +33 2 99 12 70 30
Email: Bruno.Stevant@enst-bretagne.fr
Francis Dupont
CELAR
Email: Francis.Dupont@point6.net
David Binet
FT R&D
Email: David.Binet@francetelecom.com
Toutain, et al. Expires July 30, 2006 [Page 10]
Internet-Draft Point6Box January 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Toutain, et al. Expires July 30, 2006 [Page 11]
