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]