Internet DRAFT - draft-kuwabara-softwire-ipv6-via-l2tpv2
draft-kuwabara-softwire-ipv6-via-l2tpv2
INTERNET-DRAFT D. Kuwabara
Y, Shirasaki
S. Miyakawa
Expires: December, 2006 NTT Communications
June 19, 2006
A Model of IPv6 Internet Access Service via L2TPv2 Tunnel
draft-kuwabara-softwire-ipv6-via-l2tpv2-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 December 19, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo covers two topics: a brief summary of NTT Communications'
commercial IPv6 service named "OCN IPv6", and a digest of the
architecture, which includs the user network interface specification
and some service specific parameters, of the service.
For NTT Communications' commercial IPv6 access service, IPv6 tunnel
is created over the exiting IPv4 network by Layer two tunneling
protocol [RFC2661]. By using L2TP, almost all the problems, which is
Kuwabara, et al. Expires - December 2006 [Page 1]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
described in Softwire Problem Statement [I-D. ietf-softwire-problem-
statement] , is solved. The NTT Communications service and the
architecture is one of a commercial grade solution example for
softwire problem statement.
1. Introduction
This memo covers two topics: a brief summary of NTT Communications'
commercial IPv6 service named "OCN IPv6", and a digest of the
architecture, which includs the user network interface specification
and some service specific parameters, of the service.
For NTT Communications' commercial IPv6 access service, IPv6 tunnel
is created over the exiting IPv4 network by L2TP. So the service and
the architecture is one of a commercial grade solution for softwire
problem statement [I-D. ietf-softwire-problem-statement].
1.1 Terminology
In addition to the terminology defined in Softwire Problem Statement,
following terminology are used in this memo.
"OCN IPv6"
The name of NTT Communications' commercial IPv6 access service
for home users.
Home Gateway
Existing piece of equipment that connects the home network to
the provider network. If not otherwise specified, Home Gateway
is a NAT-Box.
CPE
If not otherwise specified, CPE is same as Home Gateway in this
memo.
Server
Server is a Softwire Concentrator (SC), LNS of L2TP and DHCPv6
Server. And server is the box in which these function is
implemented .
Client
Client is a Softwire Initiator (SI), LAC and remote system of
L2TP and DHCPv6 client. And client is the box in which these
function is implemented.
Kuwabara, et al. Expires - December 2006 [Page 2]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
2. About "OCN IPv6" Service
2.1. "OCN IPv6" Features
"OCN IPv6" has following features.
"OCN IPv6" provide Global IPv6 Networks connectivity to home users.
- "OCN IPv6" customers can use two /64 global scope prefixes at
the same time. One /64 prefix is a fixed prefix and the other
prefix is assigned from a prefix pool. NTT Communications
assumes that "OCN IPv6" customers use this fixed prefix for home
network, and when the customer is in remote site, the customer
jumps into his home network using the pooled prefix.
NAT-Traversal Capabilities.
- For "OCN IPv6", IPv6 tunnel is created over the exiting IPv4
network by L2TP. All L2TP control messages and L2TP data packets
are encapsulated with UDP. So if clients are under the NAT-Box,
a softwire is established easily.
The User Authentication
- "OCN IPv6" authenticate the customer based upon user-id and
password over PPP Challenge Handshake Authentication Protocol
(CHAP)[RFC1994].
The Automatic Configuration Function
- In order to simplify user setup, "OCN IPv6" uses Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315] with the
prefix delegation options [RFC3633].
- The client chooses an IPv6 address from the delegated /64
prefix, and the client sets the address on suitable interface
automatically.
- The client sets IPv6 default gateway to the PPP logical
interface automatically.
- The client sends Router Advertisement (RA) [RFC2461] on a
suitable physical interface, if other network appliances and/or
home appliances require IPv6 connectivity [RFC2462].
The Client Software for "OCN IPv6"
- NTT Communications provides the client software which runs on
Windows XP sp2. And anyone can download this software freely.
Kuwabara, et al. Expires - December 2006 [Page 3]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
2.2. Network Structure of Home Networks
There are three typical Network Structure which are shown in the
following figures.
___________________
/Private IPv4 Network\ +------------+
: : | AAA Server |
: : +-------+----+
: [ HOST ]----+ : +---+ __________ |
: | : | | / Global \ +-------+-------+
: [ HOST ]----+--:-+CPE+-| IPv4 cloud |-+ Server |
: | : | | \__________/ +-------+-------+
: | : +---+ |
: | : ______|______
: [ Client ]-+ : / Global \
: (Global IPv6 Address): | IPv6 Cloud |
: : \______________/
\____________________/
[ figure 1 : Case 1]
Case 1: Figure 1 shows that a client is in private IPv4 network which
is provided by CPE (Home Gateway).
If the client and the server connect successfully, the client
chooses a suitable IPv6 address from the /64 prefix which is
delegated from the server and sets the address on a suitable
interface. And it is possible for the client to select the
interface not only a physical interface but also a logical
interface such a PPP interface or a loop-back interface.
In this case, the client acts as an IPv4/IPv6 dual stack host.
Kuwabara, et al. Expires - December 2006 [Page 4]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
___________________
/Private IPv4 Network\ +---------------+
: & : | AAA Server |
: Global IPv6 Network : +-------+-------+
: : +---+ __________ |
: : | | / Global \ +-------+-------+
: [ HOST ]----+--:-+CPE+-| IPv4 cloud |-+ Server |
: | : | | \__________/ +-------+-------+
: [ HOST ]----+ : +---+ |
: | : ______|______
: [ Client ]-+ : / Global \
: : | IPv6 Cloud |
: : \______________/
\____________________/
[ figure 2 : Case 2]
Case 2: Figure 2 shows that a client is in private IPv4 network which
is provided by CPE (Home Gateway).
The difference between figure 1 and figure 2 is the client acts
as an IPv6 router. But the client is a host from the IPv4 point
of view.
If the client and the server connect successfully, the client
chooses a suitable IPv6 address from the /64 prefix which is
delegated from the server and sets the address on the interface
to which the client sends RAs .
Kuwabara, et al. Expires - December 2006 [Page 5]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
___________________
/Private IPv4 Network\ +---------------+
: & : | AAA Server |
: Global IPv6 Network : +-------+-------+
: : +----------+ __________ |
: : | CPE | / Global \ +-------+-------+
: [ HOST ]----+--:-+ & +-| IPv4 cloud |-+ Server |
: | : | Client | \__________/ +-------+-------+
: [ HOST ]----+ : +----------+ |
: | : ______|______
: [ HOST ]----+ : / Global \
: : | IPv6 Cloud |
: : \______________/
\____________________/
[ figure 3 : Case 3 ]
Case 3: Figure 3 shows that CPE (Home Gateway) supports both IPv4 and
IPv6, and client functions are implemented in the same box.
If the the client and the server connect successfully ,the
client chooses a suitable IPv6 address from the /64 prefix
which is delegated from the Server and sets the address on the
downstream interface.
In this case, the client acts as a IPv4/IPv6 dual stack router.
Kuwabara, et al. Expires - December 2006 [Page 6]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
3. The User Network Interface Specification of "OCN IPv6"
"OCN IPv6" is based on the premise that IPv4 connectivity have been
established before the client try to create softwire. So, it is out
of scope that how to establish physical connection and/or IPv4
connection in this memo.
Figure 4 shows the protocol stack of "OCN IPv6".
+---------------+ +---------------+
| Client | <-- INTERFACE --> | Server |
+---------------+ +---------------+
:~~~~~~~~~~~~~~:
: ( Payload ) :
+==============+
| IPv6 |
+--------------+
| PPP |
+--------------+
| L2TPv2 |
+--------------+
| UDP |
+--------------+
| IPv4 |
+==============+
: (L2 and PHY) :
:..............:
[ figure 4 ]
To implement this protocol stack, the client and the server run the
following three steps.
1st step: L2TP phase
Creat the virtual path by using the L2TP method.
2nd step: PPP phase
Point-to-Point connection is established between the client
and the server over the established L2TP virtual path.
3rd step: Prefix delegation phase
The server delegates a /64 prefix to the client, and the
client sets IPv6 address and sets the IPv6 default route. And
if required, the client start sending RAs to its downstream.
Kuwabara, et al. Expires - December 2006 [Page 7]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
3.1 L2TP phase:
"OCN IPv6" L2TP phase is compliant with L2TP [RFC2661]. All L2TP
packets are encapsulated by UDP to offer NAT-traversal capabilities.
Some service-specific parameters and functions are as follows:
- "OCN IPv6" does not support "Tunnel Authentication" and "Hiding of
AVP Attribute Values" functions of L2TP.
- L2TP specification describes that the client's FQDN is suitable
for the "Hostname AVP" in the L2TP SCCRQ messages, but the client
does not always have FQDN. So, the client puts the user-id ,which
is given from the NTT Communications, into "Hostname AVP" in the
SCCRQ messages of L2TP.
- The client must not create multiple PPP sessions into one L2TP
tunnel. So there is one PPP session per one L2TP tunnel.
- It is not necessary for the client to support "Outgoing Call"
described in L2TP specification.
3.2 PPP phase:
A Point-to-Point connection is established over L2TP virtual path
between the client and the server. This phase is compliant with
Point-to-Point Protocol [RFC1661] and IPV6CP which is described in IP
version 6 over PPP [RFC2472].
The authentication method of the "OCN IPv6" is user-id/password based
authentication by applying CHAP at this phase. And the client must
support IPV6CP as Network Configuration Protocol (NCP) . The client
does not have to support IPCP [RFC1332] as NCP.
3.3 Prefix Delegation phase:
3.3.1 Prefix Delegation
The server delegates prefixes to the client using Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315] with the prefix
delegation options [RFC3633]. The sequence for prefix delegation is
as follows:
- The client requests prefix(es) from the server by sending a DHCPv6
Solicit message that has a link-local source address negotiated by
IPV6CP, mentioned in the previous section, and includes an IA_PD
option.
- An AAA server provides a prefix to the server or the server chooses
a prefix from its local pool, and the server returns an Advertise
message that contains an IA_PD option and IA_PD Prefix options. The
prefix-length in the IA_PD Prefix option is 64. IA_PD option and
Kuwabara, et al. Expires - December 2006 [Page 8]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
IA_PD Prefix options for the chosen prefix back to the server.
- The server confirms the prefix in the Request message in a Reply
message. If IPV6CP is terminated or restarted by any reason, the
client must initiate a Rebind/Reply message exchange as described
in [RFC3633].
3.3.2 Address Assignment
The client chooses a suitable IPv6 address from the delegated /64
prefix and sets the address on a suitable interface.
If the client wants to act as an IPv6 router, the client assigns the
address to its downstream physical interface. And if the client acts
as an IPv4/IPv6 dual stack host, it is also possible for the client
to assign the address to a logical interface such as a loop-back
interface or a PPP interface.
3.3.3 Routing
The client and the server use static routing between them, and no
routing protocol traffic is necessary. The client configures its PPP
logical interface or the link-local address of the server as the IPv6
default gateway, automatically before (or after) the prefix
delegation exchange.
When the client receives packets that are destined for the addresses
in the delegated /64 prefix, the client must not forward the packets
to the server . The client should return ICMPv6 Destination
Unreachable message to a source address or silently discard the
packets, when the original packet is destined for the unassigned
prefix in the delegated prefix.
3.3.4 Obtaining Addresses of DNS Servers
The service provides IPv6 recursive DNS servers in the ISP site. The
server notifies the global unicast addresses of these servers with
the Domain Name Server option that is described in [RFC3646], in
Advertise/Reply messages on the prefix delegation message exchange.
Devices connected to user network may learn a recursive DNS server
address with the mechanism described in [RFC3736].
The client may serve as a local DNS proxy server and include its
address in the DNS server address list. This is easy to implement,
because it is analogous to IPv4 SOHO router (192.168.0.1 is a DNS
proxy server and a default router in most sites).
Kuwabara, et al. Expires - December 2006 [Page 9]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
3.3.5 Miscellaneous Information
The server may notify other IPv6-enabled server addresses, such as
Network Time Protocol servers [RFC4075], SIP servers [RFC3319], etc.,
in an Advertise/Reply message on the prefix delegation message
exchange, if those are available.
Kuwabara, et al. Expires - December 2006 [Page 10]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
3.4 An Example of Connection Sequence
A Client A Server
| |
|---------SCCRQ-------->| \
|<--------SCCRQ---------| |
|---------SCCCN-------->| |
|<---------ZLB----------| | L2TP Path Establishment Phase
|----------ICRQ-------->| | (L2TP)
|<---------ICRP---------| |
|----------ICCN-------->| |
|<---------ZLB----------| /
| |
|---Configure-Request-->| \
|<--Configure-Request---| | PPP Link Establishment Phase
|<----Configure-Ack-----| | (LCP) over L2TP Path
|-----Configure-Ack---->| /
|<------Challenge-------| \
|-------Response------->| | PPP Authentication Phase (CHAP)
|<-------Success--------| / over L2TP Path
|---Configure-Request-->| \
|<--Configure-Request---| | PPP NCP Phase
|<----Configure-Ack-----| | (IPV6CP) over L2TP Path
|-----Configure-Ack---->| /
| |
+---+--------------------+ |
| Set IPv6 default route | |
| to the PPP Interface | |
+---+--------------------+ |
|--------Solicit------->| \
|<------Advertise-------| | DHCPv6 on a PPP logical link
|--------Request------->| | over L2TP Path
|<--------Reply---------| /
+---+--------------------+ |
|Set IPv6 Address | |
|on a suitable Interface | |
+---+--------------------+ |
| |
+---+--------------------+ |
| Enable IPv6 Packet | |
| Forwarding (optional) | |
+---+--------------------+ |
| |
+---+--------------------+ |
| Send RA (optional) | |
+---+--------------------+ |
| |
[ Figure 5 ]
Kuwabara, et al. Expires - December 2006 [Page 11]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
3.5 An Example of Disconnection Sequence
A Client A Server
| |
|----DHCPv6 Release---->| \
| | | A Delegated Prefix Release Phase
|<---DHCPv6 Reply-------| /
| |
| |
|---Terminate-Request-->| \
| | | PPP Terminate Phase.
|<----Terminate-Ack-----| /
| |
| |
|------StopCCN -------->| \
| | | Clear L2TP Virtual Path
|<------ ZLB-Ack -------| /
| |
[ Figure 6 ]
3.6 Keep-Alive Functions
In order to maintain L2TP and PPP connection , the client and the
sever exchange both "Hello" / "ZLB" messages of L2TP and "lcp-echo-
request" / "lcp-echo-reply" messages of PPP periodically with each
other.
To exchange keep-alive messages is also useful for updating the NAT
state-table and/or Firewall state-table which is implemented on Home
Gateway , when the client is in the private IPv4 network.
4. Service specific parameters.
In this section, some "OCN IPv6" specific parameters and the default
values are described.
4.1 The Parameters of Keep-Alive functions
- L2TP Hello interval:
o Every 60 seconds.
- LCP echo request interval:
o Every 30 seconds by default.
o This parameter is configurable from 10 seconds to 60 seconds.
Kuwabara, et al. Expires - December 2006 [Page 12]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
4.2 MTU of PPP logical interface over L2TP.
This parameter is configurable from 1280 bytes, which is minimum MTU
of IPv6, to 1500 bytes. 1390 bytes is the default value.
4.3 The Parameters of RAs .
When the client acts as IPv6 router, the parameters of RAs are as
follows.
- Max RA interval:
o 30 seconds by default.
- Valid Life Time:
o 180 seconds by default.
- Preferred Life Time:
o 90 seconds by default.
When the server delegates a prefix to the client from its local pool,
the client does not always get the same prefix. These parameters are
useful, when the client, which acts as IPv6 router, want to announce
that the prefix does not work anymore and a new prefix is available
to the downstream network appliances.
5. A Future Plan
The server may send RAs on PPP logical link over L2TP for the client
which does not have to be the IPv6 router.
If this function is implemented, the client ,which acts as an
IPv4/IPv6 host only, can connect to IPv6 network more easily.
6. Security Considerations
The "OCN IPv6" approach uses only already existing protocols so
should not introduce new security issues.
7. Acknowledgments
Thanks a lot for the support to our new service from Yuka Kamizuru,
Takeshi Tomochika, Nguyen Huu Bach and Ole Troan.
8 Reference
Kuwabara, et al. Expires - December 2006 [Page 13]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
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.
[I-D.ietf-softwire-problem-statement]
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.
[RFC1994]
Simpson,W. "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996
[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.
[RFC2461]
Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP
Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2462]
Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC3633]
Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC1661]
Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1661, July
1994.
Kuwabara, et al. Expires - December 2006 [Page 14]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
[RFC2472]
Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[RFC1332]
McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)",
RFC 1332, May 1992.
[RFC3646]
Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3736]
Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
Service for IPv6", RFC 3736, April 2004.
[RFC4075]
Kalusivalingam, V., "Simple Network Time Protocol (SNTP)
Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC3319]
Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol
(DHCPv6) Options for Session Initiation Protocol (SIP) Servers",
RFC 3319, July 2003.
8.2 Information References
[RF4241]
Shirasaki, Y., Miyakawa, S., Yamasaki, T., and Takenouchi, A., "A
Model of IPv6/IPv4 Dual Stack Internet Access Service", RFC 4241,
December 2005.
[I-D.draft-toutain--softwire-point6box]
Toutain, L., Stevant, B., Dupont, F. and Binet, D., "The Point6Box
Approach", draft-toutain-softwire-point6box-00.txt, January 2006.
Kuwabara, et al. Expires - December 2006 [Page 15]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
Authors' Addresses
Dai Kuwabara
NTT Communications Corporation
Tokyo Opera City Tower 21F
3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
Email: dai@nttv6.jp
Yasuhiro Shirasaki
NTT Communications Corporation
Tokyo Opera City Tower 21F
3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
Email: yasuhiro@nttv6.jp
Shin Miyakawa, Ph. D
NTT Communications Corporation
Tokyo Opera City Tower 21F
3-20-2 Nishi-Shinjuku, Shinjuku-ku
Tokyo 163-1421, Japan
Email: miyakawa@nttv6.jp
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.
Kuwabara, et al. Expires - December 2006 [Page 16]
INTERNET-DRAFT IPv6 Access service via L2TPv2 Tunnel June 2006
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.
Kuwabara, et al. Expires - December 2006 [Page 17]
