One document matched: draft-shirasaki-dualstack-service-01.txt

Differences from draft-shirasaki-dualstack-service-00.txt





INTERNET-DRAFT                                              Y. Shirasaki
Expires: December, 2003                                      S. Miyakawa
                                                             T. Yamasaki
                                                           A. Takenouchi
                                                      NTT Communications
                                                           June 10, 2003

        A Model of IPv6/IPv4 Dual Stack Internet Access Service
                draft-shirasaki-dualstack-service-01.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 December 9, 2003.

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 mechanism to configure IPv6 specific parameters
   automatically.  We focus on two basic parameters, prefix and
   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 - December 2003                [Page 1]

INTERNET-DRAFT              Dual stack access                  June 2003


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.

   Here are some antecedents of the architecture.  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 of 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) and IPv6 DNS servers' addresses. The function
   is composed of two sub-functions as below.




Shirasaki, et al.        Expires - December 2003                [Page 2]

INTERNET-DRAFT              Dual stack access                  June 2003


     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 layer are
   mentioned. The other layers such as Ethernet and lowers are out of
   scope.  IPv4 related parameter configuration is also out of scope.

2.1. Sub-IP Layer

   The service uses PPP connection and Challenge Handshake
   Authentication Protocol (CHAP) authentication to identify each CPE.
   Both CPE and PE handles both IPCP [RFC1661] and IPV6CP [RFC2472]
   identically / simultaneously over a single PPP connection. It means
   both CPE and 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].

   A CPE must reply with LCP Echo-Reply when it is in the LCP Opened
   state and receives LCP Echo-Request as described in [RFC1661].

   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 prefix delegation mechanism described below.

2.2. IP Layer

   After IPV6CP negotiation, a CPE initiates prefix delegation request.
   A 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 local
   interfaces of CPE. 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 [DHCPv6] etc, and become to communicate
   using global-scope addresses.

2.3. Prefix Delegation



Shirasaki, et al.        Expires - December 2003                [Page 3]

INTERNET-DRAFT              Dual stack access                  June 2003


   PE delegates prefixes to CPE by DHCPv6 [DHCPv6] with prefix
   delegation options [PD]. 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 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 [PD].

2.4. Address Assignment

   CPE assigns global-scope /64 prefixes subnetted from the delegated
   prefix to its downstream interfaces.  Because 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. It reduces traffic of
   routing protocol between them.

   When CPE receives packets which are destined for the delegated
   prefix, CPE must not forward the packets to a PE. CPE should return
   ICMPv6 Destination Unreachable message to a source address or
   silently discard the packets.

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

2.6. Obtaining Addresses of DNS Servers

   The service provides IPv6 recursive DNS servers in the ISP site.  PE



Shirasaki, et al.        Expires - December 2003                [Page 4]

INTERNET-DRAFT              Dual stack access                  June 2003


   notifies the global unicast addresses of these servers with Domain
   Name Server option, which is described in [OPT-DNS], in
   Advertise/Reply messages on the prefix delegation message exchange.

2.7. Miscellaneous Information

   PE may notify other IPv6 enabled server addresses such as Network
   Time Protocol servers [OPT-NTP], SIP servers [OPT-SIP], 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 to subnet-router anycast address for the
   delegated prefix.

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.























Shirasaki, et al.        Expires - December 2003                [Page 5]

INTERNET-DRAFT              Dual stack access                  June 2003


   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

   Though the threat of DHCP is a kind of man-in-the-middle, the
   architecture uses point-to-point link as layer 2 and communication
   between PE and CPE is protected by layer 2 security.

   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



Shirasaki, et al.        Expires - December 2003                [Page 6]

INTERNET-DRAFT              Dual stack access                  June 2003


   devices connected to user network for this problem should be
   considered in the future.

5. Acknowledgements

   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.

[DHCPv6]
     Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
     draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002.

[PD] Troan, O. and Droms, R., "IPv6 Prefix Options for DHCPv6", draft-
     ietf-dhc-dhcpv6-opt-prefix-delegation-04 (work in progress), June
     2003.

[OPT-DNS]
     Droms, R., "DNS Configuration options for DHCPv6", draft-ietf-dhc-
     dhcpv6-opt-dnsconfig-03 (work in progress), February 2003.

[OPT-NTP]
     Vijayabhaskar, A.K., "Time Configuration Options for DHCPv6",
     draft-ietf-dhc-dhcpv6-opt-timeconfig-02 (work in progress),
     February 2003.



Shirasaki, et al.        Expires - December 2003                [Page 7]

INTERNET-DRAFT              Dual stack access                  June 2003


[OPT-SIP]
     Schulzrinne, H. and Volz, B., "DHCPv6 Options for SIP Servers",
     draft-ietf-sip-dhcpv6-01 (work in progress), November 2002.

Informative References

[PD-Req]
     Miyakawa, S., "Requirements for IPv6 prefix delegation", draft-
     ietf-ipv6-prefix-delegation-requirement-01 (work in progress),
     February 2003.

Appendix

   Note that current NTT communications' service is running based on
   following old or expired I-Ds at this time. The service specification
   will be no sooner updated than these I-Ds become RFC.

     o draft-ietf-dhc-dhcp6-26.txt

     o draft-troan-dhcpv6-opt-prefix-delegation-01.txt

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









Shirasaki, et al.        Expires - December 2003                [Page 8]

INTERNET-DRAFT              Dual stack access                  June 2003


   Ayako Takenouchi
   NTT Communications Corporation
   Tokyo Opera City Tower 21F
   3-20-2 Nishi-Shinjuku, Shinjuku-ku
   Tokyo 163-1421, Japan
   E-mail: ayako.takenouchi@ntt.com













































Shirasaki, et al.        Expires - December 2003                [Page 9]

PAFTECH AB 2003-20262026-04-24 08:42:25