INTERNET-DRAFT Yasuhiro Shirasaki
Expires: August, 2003 Shin Miyakawa
Toshiyuki Yamasaki
Ayako Takenouchi
NTT Communications
February 24, 2003
A Model of IPv6/IPv4 Dual Stack Internet Access Service
draft-shirasaki-dualstack-service-00.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 August 24, 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
service 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 - August 2003 [Page 1]
INTERNET-DRAFT Dual stack access February 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
mainly targets at a leased line ADSL service for home users. It
assumes that there is a 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.
In this architecture, IPv6/IPv4 dual stack service is specified as
follows.
o IPv6 and IPv4 connectivity are provided over a single PPP logical
link.
o IPv6 connectivity is independent of IPv4 connectivity. IPV6CP and
IPCP works independently over a single PPP logical link.
Figure 1 shows the outline of the service architecture. NTT
Communications has been used 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 simplication 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 - August 2003 [Page 2]
INTERNET-DRAFT Dual stack access February 2003
o Delegation of prefix(es)
o Notification of IPv6 DNS server addresses
Section 3 of this memo details user network interface. Section 4
describes an example of connection sequence.
2. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119].
3. User Network Interface
In this section, details of the user network interface specification
are described. Only 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.
3.1. Sub-IP Layer
The service uses PPP connection and 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 NCP session anytime
without any side-effect for each other. It is intended that users can
choose 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].
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.
3.2. IP Layer
After IPV6CP negotiation, a CPE initiates prefix delegation request.
A PE chooses global-scope prefix for the CPE with information from
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
Shirasaki, et al. Expires - August 2003 [Page 3]
INTERNET-DRAFT Dual stack access February 2003
become to communicate using global-scope addresses.
3.3. Prefix Delegation
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 prefixes to a PE by sending DHCPv6 Solicit message
which has link-local source address negotiated by IPV6CP, mentioned
in the previous section, and includes IA_PD option.
o The PE chooses prefix(es) which is notified by AAA server or
choosen from PE's local pool and returns Advertise message which
contains IA_PD and IA_PD Prefix option. The prefix-length in the
IA_PD Prefix option is 48.
o CPE chooses prefix(es) and sends Request message containing IA_PD
option and IA_PD Prefix option for chosen prefix(es) back to PE.
o PE confirms the prefix(es) in the Request message and returns Reply
message.
Once IPV6CP is terminated or restarted by any reason, CPE MUST
initiate a Rebind/Reply message exchange as described in [PD].
3.4. Address Assignment
The CPE assigns global-scope prefixes subnetted from the delegated
prefix to its downstream interfaces with its length /64. Because
link-local address is already assigned to CPE's upstream interface,
global-scope address assignment for that interface is OPTIONAL.
3.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.
Shirasaki, et al. Expires - August 2003 [Page 4]
INTERNET-DRAFT Dual stack access February 2003
3.6. Obtaining Addresses of DNS Servers
The service provides IPv6 DNS cache servers in the ISP site as same
as IPv4 case. PE notifies the global unicast addresses of these
servers with Domain Name Server option, which is described in [OPT-
DNS], in Advertise/Reply message on the prefix delegation message
exchange.
3.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
Advertise/Reply message on the prefix delegation message exchange if
it is available.
3.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-rouer anycast address for the
delegated prefix.
4. 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 - August 2003 [Page 5]
INTERNET-DRAFT Dual stack access February 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
5. 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 - August 2003 [Page 6]
INTERNET-DRAFT Dual stack access February 2003
devices connected to user network for this problem should be
considered in the future.
6. Acknowledgements
Thanks for the input and review by Tatsuya Sato, Hideki Mouri,
Koichiro Fujimoto, Hiroki Ishibashi, Ralph Droms, Ole Troan, and
IPv6-ops-IAJapan members.
Normative References
[RFC3177]
IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations
to Sites", RFC 3177, September 2001.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC1661]
W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, July
1994
[RFC2472]
D. Haskin and E. Allen, "IP Version 6 over PPP", RFC 2472, December
1998.
[RFC2516]
L. Mamakos, "A Method for Transmitting PPP Over Ethernet (PPPoE)",
RFC 2516, February 1999.
[RFC2462]
Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[DHCPv6]
R. Droms, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
draft-ietf-dhc-dhcpv6-28 (work in progress), November 2002.
[PD] O. Troan and R. Droms, "IPv6 Prefix Options for DHCPv6", draft-
ietf-dhc-dhcpv6-opt-prefix-delegation-02 (work in progress),
February 2003.
[OPT-DNS]
R. Droms, "DNS Configuration options for DHCPv6", draft-ietf-dhc-
dhcpv6-opt-dnsconfig-02 (work in progress), October 2003.
Shirasaki, et al. Expires - August 2003 [Page 7]
INTERNET-DRAFT Dual stack access February 2003
[OPT-NTP]
A.K. Vijayabhaskar, "Time Configuration Options for DHCPv6", draft-
ietf-dhc-dhcpv6-opt-timeconfig-01 (work in progress), May 2002.
[OPT-SIP]
H. Schulzrinne and B. Volz, "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-00 (work in progress),
November 2002.
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
Author's Address
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 - August 2003 [Page 8]
INTERNET-DRAFT Dual stack access February 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 - August 2003 [Page 9]