INTERNET-DRAFT                                              Y. Shirasaki
Expires: October, 2004                                       S. Miyakawa
                                                             T. Yamasaki
                                                      NTT Communications
                                                           A. Takenouchi
                                                                     NTT
                                                          April 27, 2004

        A Model of IPv6/IPv4 Dual Stack Internet Access Service
                draft-shirasaki-dualstack-service-04.txt

Status of this Memo

   This memo provides information to the Internet community. It does not
   specify an Internet standard of any kind. This memo is in full
   conformance with all provisions of Section 10 of RFC2026.

   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.''

   To view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   Distribution of this memo is unlimited.

   The internet-draft will expire in 6 months.  The date of expiration
   will be October 26, 2004.

Abstract

   This memo shows an example of how to provide IPv6 / IPv4 dual stack
   services to home users.  In order to simplify user setup, these
   services should have a mechanism to configure IPv6 specific
   parameters automatically.  We focus on two basic parameters, the
   prefix assigned to the user and the addresses of IPv6 DNS servers,
   and specify the way to deliver them to Customer Premises Equipments
   (CPE) automatically.

   This memo is a digest of the user network interface specification of
   NTT communications' dual stack ADSL access service.




Shirasaki, et al.        Expires - October 2004                 [Page 1]


INTERNET-DRAFT              Dual stack access                 April 2004


1. Introduction

   This memo describes two topics. One is the architecture of IPv6/IPv4
   dual stack access service. The other is the automatic configuration
   function for IPv6 specific parameters.

   The architecture is mainly targeted at a leased line ADSL service for
   home users. It assumes that there is a Point-to-Point Protocol (PPP)
   logical link between CPE and Provider Edge (PE). In order to exclude
   factors which are specific to access lines from this architecture, we
   only specify PPP and its upper layers.  To satisfy [RFC3177], the
   length of prefix which is delegated to CPE is /48, but /64 is also a
   possible option.


   In this architecture, IPv6/IPv4 dual stack service is specified as
   follows.

     o IPv6 and IPv4 connectivities are provided over a single PPP
       logical link.

     o IPv6 connectivity is independent of IPv4 connectivity.  IPV6CP
       and IPCP work independently over a single PPP logical link.

   Figure 1 shows the outline of the service architecture. NTT
   Communications is providing a commercial service based on this
   architecture since the Summer 2002.

          |                                             _____________
   [HOST]-+ +-----------+               +----------+   /             \
          | | Customer  |   ADSL line   | Provider |  | ISP core and  |
          +-+ Premises  +---------------+   Edge   |--| The internet  |
          | | Equipment | to subscriber +-----+----+   \_____________/
   [HOST]-+ +-----------+                     |         |   |
          |                             +-----+------+  | +-+----------+
                                        | AAA server |  | | DNS server |
                                        +------------+  | +------------+
                                                      +-+--------------+
                                                      | NTP server etc.|
                                                      +----------------+

   Figure 1: Dual stack access service architecture

   The automatic configuration function aims at simplification of user
   setup.  Usually, users have to configure at least two IPv6 specific
   parameters, prefix(es) assigned to them and IPv6 DNS servers'
   addresses.  The function is composed of two sub-functions as below.




Shirasaki, et al.        Expires - October 2004                 [Page 2]


INTERNET-DRAFT              Dual stack access                 April 2004


     o Delegation of prefix(es) to be used in the user site

     o Notification of IPv6 DNS server addresses, and/or other server
       addresses

   Section 2 of this memo details user network interface. Section 3
   describes an example of connection sequence.

2. User Network Interface

   In this section, details of the user network interface specification
   are described. Only PPP over Ethernet (PPPoE) and its upper layers
   are mentioned. The other layers such as Ethernet and lower layers are
   out of scope.  IPv4 related parameter configuration is also out of
   scope.

2.1. Below the IP Layer

   The service uses PPP connection and Challenge Handshake
   Authentication Protocol (CHAP) authentication to identify each CPE.
   Both CPE and PE handle both IPCP [RFC1661] and IPV6CP [RFC2472]
   identically / simultaneously over a single PPP connection. It means
   either CPE or PE can open/close any Network Control Protocol (NCP)
   session anytime without any side-effect for each other. It is
   intended that users can choose between three services, IPv4 only,
   IPv6 only and IPv4/IPv6 dual stack.  A CPE connected to an ADSL line
   discovers a PE with PPPoE mechanism [RFC2516].

   Note that because CPE and PE can negotiate only their interface
   identifiers with IPV6CP, PE and CPE can use only link-local scope
   addresses before the prefix delegation mechanism, described below, is
   run.

2.2. IP Layer

   After IPV6CP negotiation, the CPE initiates a prefix delegation
   request.  The PE chooses global-scope prefix for the CPE with
   information from an Authentication, Authorization, and Accounting
   (AAA) server or local prefix pools, and delegates the prefix to the
   CPE.  Once the prefix is delegated, the prefix is subnetted and
   assigned to the local interfaces of the CPE. The CPE begins sending
   router advertisement of the prefixes on each links. Eventually hosts
   can acquire global-scope prefixes through conventional IPv6 stateless
   [RFC2462] or stateful auto-configuration mechanisms [RFC3315] etc,
   and become to communicate using global-scope addresses.

2.3. Prefix Delegation




Shirasaki, et al.        Expires - October 2004                 [Page 3]


INTERNET-DRAFT              Dual stack access                 April 2004


   PE delegates prefixes to CPE by DHCPv6 [RFC3315] with prefix
   delegation options [RFC3633]. The model of sequence for prefix
   delegation is as follows:


     o A CPE requests prefix(es) from a PE by sending a DHCPv6 Solicit
       message which has a link-local source address negotiated by
       IPV6CP, mentioned in the previous section, and includes an IA_PD
       option.

     o An AAA server notifies prefix(es) to the PE, or the PE chooses
       prefix(es) from its local pool and the PE returns an Advertise
       message which contains an IA_PD option and IA_PD Prefix options.
       The prefix-length in the IA_PD Prefix option is 48.

     o The CPE chooses prefix(es) and sends a Request message containing
       an IA_PD option and IA_PD Prefix options for chosen prefix(es)
       back to the PE.

     o The PE confirms the prefix(es) in the Request message and returns
       a Reply message.

   If IPV6CP is terminated or restarted by any reason, CPE must initiate
   a Rebind/Reply message exchange as described in [RFC3633].

2.4. Address Assignment

   CPE assigns global-scope /64 prefixes subnetted from the delegated
   prefix to its downstream interfaces. In the case where the delegated
   prefix has infinite lifetimes, the preferred and valid lifetimes of
   assigned /64 prefixes should be their default values in [RFC2461].

   Because a link-local address is already assigned to CPE's upstream
   interface, global-scope address assignment for that interface is
   optional.

2.5. Routing

   CPE and PE use static routing between them, and no routing protocol
   traffic is necessary.

   CPE configures its PPPoE logical interface or the link-local address
   of PE as IPv6 default gateway automatically after the prefix
   delegation exchange.

   When CPE receives packets which are destined for the addresses in the
   delegated /48 prefix, CPE must not forward the packets to a PE.  CPE
   should return ICMPv6 Destination Unreachable message to a source



Shirasaki, et al.        Expires - October 2004                 [Page 4]


INTERNET-DRAFT              Dual stack access                 April 2004


   address or silently discard the packets, when the original packet is
   destined for the unassigned prefix in the delegated prefix.  (e.g.
   CPE should install a reject route or null interface as next hop for
   the delegated prefix.)

2.6. Obtaining Addresses of DNS Servers

   The service provides IPv6 recursive DNS servers in the ISP site.  PE
   notifies the global unicast addresses of these servers with Domain
   Name Server option, which is described in [RFC3646], in
   Advertise/Reply messages on the prefix delegation message exchange.

   Devices connected to user network may know recursive DNS server
   address with the mechanism described in [RFC3736].

   The CPE may serve as a local DNS proxy server and include its address
   into the DNS server address list. This is easy to implement, because
   it is an analogy of IPv4 SOHO router (192.168.0.1 is a DNS proxy
   server and a default router in most sites).

2.7. Miscellaneous Information

   PE may notify other IPv6 enabled server addresses such as Network
   Time Protocol servers [OPT-NTP], SIP servers [RFC3319], etc.  in an
   Advertise/Reply messages on the prefix delegation message exchange if
   those are available.

2.8. Connectivity Monitoring

   ICMPv6 Echo Request will be sent to user network for connectivity
   monitoring in the service. CPE must return single IPv6 Echo Reply
   packet when it receives ICMPv6 Echo Request packet. The health check
   packets are destined for subnet-router anycast address for the
   delegated prefix.

   The old document of APNIC IPv6 address assignment policy required
   that APNIC could ping the subnet anycast address to check an address
   usage.

   To achieve this requirement, for example, once the prefix
   3ffe:ffff:ffff::/48 is delegated, the CPE must reply to the ICMPv6
   Echo Request destined for 3ffe:ffff:ffff:: anytime while IPV6CP and
   DHCPv6-PD for upstream is up.  Because some implementations couldn't
   reply when 3ffe:ffff:ffff::/64 was assigned to its downstream
   physical interface and the interface is down, such implementation
   should assign 3ffe:ffff:ffff::/64 for loopback interface, which is
   always up, and 3ffe:ffff:ffff:1::/64, 3ffe:ffff:ffff:2::/64, etc. for
   physical interfaces.



Shirasaki, et al.        Expires - October 2004                 [Page 5]


INTERNET-DRAFT              Dual stack access                 April 2004


3. An Example of Connection Sequence

   Following figure is an example of normal link-up sequence from start
   of PPPoE to start of IPv6/IPv4 communications.  IPv4 communication
   becomes available after IPCP negotiation.  IPv6 communication with
   link-local scope addresses becomes possible after IPV6CP negotiation.
   IPv6 communication with global-scope addresses becomes possible after
   prefix delegation and conventional IPv6 address configuration
   mechanism. IPCP is independent of IPV6CP and prefix delegation.

   CPE                      PE
    |                       |
    |----------PADI-------->| \
    |<---------PADO---------|  | PPPoE
    |----------PADR-------->|  | Discovery Stage
    |<---------PADS---------| /
    |                       |
    |---Configure-Request-->| \
    |<--Configure-Request---|  | PPP Link Establishment Phase
    |<----Configure-Ack-----|  | (LCP)
    |-----Configure-Ack---->| /
    |                       |
    |<------Challenge-------| \
    |-------Response------->|  | PPP Authentication Phase (CHAP)
    |<-------Success--------| /
    |                       |
    |---Configure-Request-->| \
    |<--Configure-Request---|  |
    |<----Configure-Nak-----|  | PPP Network Layer Protocol Phase
    |<----Configure-Ack-----|  | (IPCP)
    |---Configure-Request-->|  |
    |<----Configure-Ack-----| /
    |                       |
    |---Configure-Request-->| \
    |<--Configure-Request---|  | PPP Network Layer Protocol Phase
    |<----Configure-Ack-----|  | (IPV6CP)
    |-----Configure-Ack---->| /
    |                       |
    |--------Solicit------->| \
    |<------Advertise-------|  | DHCPv6
    |--------Request------->|  |
    |<--------Reply---------| /
    |                       |

   Figure 2: An example of connection sequence

4. Security Considerations




Shirasaki, et al.        Expires - October 2004                 [Page 6]


INTERNET-DRAFT              Dual stack access                 April 2004


   In this architecture, PE and CPE trusts the point-to-point link
   between them, where one trusts that there is no man-in-the-middle,
   and trusts PPPoE authentication. Because of this, the DHCP
   authentication is not considered necessary and is not used.

   The service provides always-on global-scope prefix for users.  Each
   device connected to user network has global-scope addresses.  Without
   any packet filters, devices might be accessible from outside of the
   user network in that case.  CPE and each device involved in the
   service should have functionality against unauthorized accesses such
   as stateful inspection packet filter.  Relationship between CPE and
   devices connected to user network for this problem should be
   considered in the future.

5. Acknowledgments

   Thanks for the input and review by Tatsuya Sato, Hideki Mouri,
   Koichiro Fujimoto, Hiroki Ishibashi, Ralph Droms, Ole Troan, Pekka
   Savola, and IPv6-ops-IAJapan members.

Normative References

[RFC3177]
     IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations
     to Sites", RFC 3177, September 2001.

[RFC1661]
     Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1661, July
     1994

[RFC2472]
     Haskin, D. and Allen, E., "IP Version 6 over PPP", RFC 2472,
     December 1998.

[RFC2516]
     Mamakos, L., "A Method for Transmitting PPP Over Ethernet (PPPoE)",
     RFC 2516, February 1999.

[RFC2462]
     Thomson, S. and Narten, T.,  "IPv6 Stateless Address
     Autoconfiguration", RFC 2462, December 1998.

[RFC3315]
     Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
     RFC 3315, July 2003.

[RFC3633]
     Troan, O. and Droms, R., "IPv6 Prefix Options for Dynamic Host



Shirasaki, et al.        Expires - October 2004                 [Page 7]


INTERNET-DRAFT              Dual stack access                 April 2004


     Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

[RFC2461]
     Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for
     IP Version 6 (IPv6)", RFC 2461, December 1998.

[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.

[OPT-NTP]
     Vijayabhaskar, A.K., "Simple Network Time Protocol Configuration
     Option for DHCPv6", draft-ietf-dhc-dhcpv6-opt-sntp-00 (work in
     progress), November 2003.

[RFC3319]
     Schulzrinne, H. and Volz, B., "Dynamic Host Configuration Protocol
     (DHCPv6) Options for Session Initiation Protocol (SIP) Servers",
     RFC 3319, July 2003.

Informative References

[PD-Req]
     Miyakawa, S. and Droms, R., "Requirements for IPv6 prefix delega-
     tion", draft-ietf-ipv6-prefix-delegation-requirement-04 (work in
     progress), February 2004.





















Shirasaki, et al.        Expires - October 2004                 [Page 8]


INTERNET-DRAFT              Dual stack access                 April 2004


Authors' Addresses

   Yasuhiro Shirasaki
   NTT Communications Corporation
   Tokyo Opera City Tower 21F
   3-20-2 Nishi-Shinjuku, Shinjuku-ku
   Tokyo 163-1421, Japan
   E-mail: 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
   E-mail: miyakawa@nttv6.jp

   Toshiyuki Yamasaki
   NTT Communications Corporation
   1-1-6 Uchisaiwaicho, Chiyoda-ku
   Tokyo 100-8019, Japan
   E-mail: t.yamasaki@ntt.com

   Ayako Takenouchi
   NTT Cyber Solutions Laboratories, NTT Corporation
   3-9-11 Midori-Cho, Musashino-Shi
   Tokyo 180-8585, Japan
   E-mail: takenouchi.ayako@lab.ntt.co.jp
























Shirasaki, et al.        Expires - October 2004                 [Page 9]


INTERNET-DRAFT              Dual stack access                 April 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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



Shirasaki, et al.        Expires - October 2004                [Page 10]


INTERNET-DRAFT              Dual stack access                 April 2004


   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.













































Shirasaki, et al.        Expires - October 2004                [Page 11]