INTERNET-DRAFT Y. Shirasaki
Expires: April, 2004 S. Miyakawa
T. Yamasaki
A. Takenouchi
NTT Communications
October 15, 2003
A Model of IPv6/IPv4 Dual Stack Internet Access Service
draft-shirasaki-dualstack-service-02.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 April 14, 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 - April 2004 [Page 1]
INTERNET-DRAFT Dual stack access October 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.
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 - April 2004 [Page 2]
INTERNET-DRAFT Dual stack access October 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 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 - April 2004 [Page 3]
INTERNET-DRAFT Dual stack access October 2003
PE delegates prefixes to CPE by DHCPv6 [RFC3315] 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 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 [PD].
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 - April 2004 [Page 4]
INTERNET-DRAFT Dual stack access October 2003
address or silently discard the packets, when the original packet is
destined for the unassigned prefix in the delefated 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 [OPT-DNS], in
Advertise/Reply messages on the prefix delegation message exchange.
Devices connected to user network use the CPE as recursive DNS server
with the mechanism described in [WKSLDNS]. 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).
Issue: Because site-local unicast addresses, which is used in
[WKSLDNS], began to be deprecated, we need new standard mechanism to
discovery or communicate recursive DNS servers for devices connected
to user network.
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
Shirasaki, et al. Expires - April 2004 [Page 5]
INTERNET-DRAFT Dual stack access October 2003
always up, and 3ffe:ffff:ffff:1::/64, 3ffe:ffff:ffff:2::/64, etc. for
physical interfaces.
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
Shirasaki, et al. Expires - April 2004 [Page 6]
INTERNET-DRAFT Dual stack access October 2003
4. Security Considerations
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. 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.
[RFC3315]
Droms, R., "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
Shirasaki, et al. Expires - April 2004 [Page 7]
INTERNET-DRAFT Dual stack access October 2003
[PD] Troan, O. and Droms, R., "IPv6 Prefix Options for DHCPv6", draft-
ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in progress),
October 2003.
[RFC2461]
Narten, T., Nordmark, E. and Simpson, W., "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[OPT-DNS]
Droms, R., "DNS Configuration options for DHCPv6", draft-ietf-dhc-
dhcpv6-opt-dnsconfig-04 (work in progress), August 2003.
[WKSLDNS]
Durand, A., "Well known site local unicast addresses to communicate
with recursive DNS servers", draft-ietf-ipv6-dns-discovery-07.txt
(expired), October 2002.
[OPT-NTP]
Vijayabhaskar, A.K., "Time Configuration Options for DHCPv6",
draft-ietf-dhc-dhcpv6-opt-timeconfig-02 (work in progress),
February 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., "Requirements for IPv6 prefix delegation", draft-
ietf-ipv6-prefix-delegation-requirement-03 (work in progress),
August 2003.
Appendix
Note that current NTT communications' service was launched based on
following old or expired I-Ds. The service specification will be
updated after both have been published as RFCs.
o draft-ietf-dhc-dhcp6-26.txt
o draft-troan-dhcpv6-opt-prefix-delegation-01.txt
Shirasaki, et al. Expires - April 2004 [Page 8]
INTERNET-DRAFT Dual stack access October 2003
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 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 - April 2004 [Page 9]
INTERNET-DRAFT Dual stack access October 2003
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 (2003). 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 - April 2004 [Page 10]
INTERNET-DRAFT Dual stack access October 2003
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 - April 2004 [Page 11]