sorry that it is very late, here is a beta copy of our draft on
dialup PPP operation.
itojun
Internet Engineering Task Force Jun-ichiro itojun Hagino
INTERNET-DRAFT IIJ Research Laboratory
Expires: November 29, 2001 Kazu YAMAMOTO
IIJ Research Laboratory
May 29, 2001
Requirements for IPv6 dialup PPP operation
draft-itojun-ipv6-dialup-requirement-01beta.txt
Status of this Memo
This document is an Internet-Draft and 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 November 29, 2001.
Abstract
The memo tries to identify design choices in IPv6 dialup PPP services by
ISPs.
1. Problem domain
With the deployment of IPv6 [Deering, 1998] , it becomes more apparent
that we have different operational requirements in IPv6 dialup PPP
operation, from IPv4 dialup PPP operation. For example, it would be
desirable to see static address allocation, rather than dynamic address
allocation, whenever possible. With IPv4 this has been impossible due
to address space shortage, and IPCP [McGregor, 1992] dynamic address
allocation has been used. With IPv6 it is possible to perform static
address allocation from ISPs to downstream customers, as there's enough
address to spare.
HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 1]
DRAFT Requirements for IPv6 dialup PPP operation May 2001
The document tries to summarize possible design choices in IPv6 dialup
PPP operation. Actual operational practices should be documented
separately.
2. Design choices
2.1. The usage pattern
o Static clients. Computers located in home and offices do not usually
change its configurations, nor upstream ISPs. It would be desirable
to make a static address allocation in this case.
o Roaming clients. Roaming clients, like travelling users with a
portable computer, have different requirement from static clients. It
is not usually possible to make a static address allocation, as
travelling users may connet to multiple ISPs from different countries.
Users may be able to hide their location changes by using mobile-ip6
[Johnson, 2000] , however, mobile-ip6 concerns are outside of the
discussions of the document. Here we are discussing about actual
location of the user (care-of address in mobile-ip6 terminlogy).
2.2. Address space
It is desired to assign /48 address space, regardless from usage pattern
or size of the downstream site. If it is apparent that the customers
will have a single subnet behind them, /64 allocation may be desirable.
It is to make future renumbering in downstream site easier on ISP
change. /128 assignment MUST NOT be made, as it will promote IPv6-to-
IPv6 NAT.
The item is highly related to RIR address allocation recommendations.
2.3. Address allocation
o Static address allocation. ISPs will allocate a static address space
(/48) to a downstream customer, on contract time. There will be no
protocol involved in address allocation - allocation will be informed
by paper.
o Static address allocation, with some automation. It may be possible
to define a common protocol for configuring customer-side router(s)
from the upstream ISP, eliminating necessity of paper-based allocation
and configuration labor in the customer site. Note that router
renumbering protocol is not always suitable for this. Router
renumbering protocol assumes that the routers and control node to be
in the same administrative domain.
o Dynamic address allocation.
HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 2]
DRAFT Requirements for IPv6 dialup PPP operation May 2001
2.4. Where to assign address
o Assign address to ppp interface. The form assigns /128 to the
customer computer, or /64 onto the PPP link. The form of address
assignment should not be used, as it advocates IPv6-to-IPv6 NAT. In
the following diagram, "Lx" denotes link-local address, and "Gx"
denotes global address.
ISP router
|La, Ga
| ppp link
|Lb, Gb
Customer computer
o Assign address to the interface behind the customer router. The form
assigns /64 to the network segment behind customer router.
ISP router
|La
| ppp link
|Lb
Customer router
|Gb
==+=== Gx/64
In the cases where the customer has only a single computer, it is
possible to have virtual network segment behind the customer computer.
ISP router
|La
| ppp link
|Lb
Customer computer
|Gb
==+=== Gx/64 (VIRTUAL)
Note that, however, /64 assignment will make it harder for customer
site to evolve in the future. /64 assignment is not recommended.
o Assign address to the cloud behind the customer router (/48). In this
case, the upstream ISP has no idea about the topology in the customer
site. Actually, it is not necessary for the upstream ISP to know
about the address usage in the customer site. Static address
assignment is highly recommended in this case, as it is painful to
renumber the whole /48 cloud every time we reconnect the dialup PPP
link between the ISP and the customer site.
HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 3]
DRAFT Requirements for IPv6 dialup PPP operation May 2001
ISP router
|La
| ppp link
|Lb
Customer router
|Gb
(((Gx/48 cloud)))
2.5. Routing
o Static routing. ISPs will configure static route, pointing to the
customer site, for the address space assigned to the customer site.
Customer router (or customer computer) will install default route,
pointing to the ISP router via PPP link.
o Simple dynamic routing. ISPs can exchange routes by using simple
dynamic routing protocols like RIPng. This allows the customer site
to adapt to PPP link status better. This also makes it easier to
detect PPP link disconnection. If the ISP announces non-default
routes to the downstream customer, it may help downstream to configure
multihomed connectivity (connection to multiple upstream ISPs)
[Hagino, 2000] ISPs may want to filter out bogus routing announcements
from the downstream.
2.6. Portability of address space
Depending on address aggregation policy in an ISP, portability of
address space can vary very much. The aspect has tight (and rather
complex) interdependency with usage pattern.
o No portability. Suppose that the ISP X implements per-NOC/POP address
aggregation, inside the ISP. When the ISP X assigns a downstream
customer a /48 address space, the address space is from "Tokyo Japan"
aggregation block. ISP X will ask the customer to make a PPP dialup
call to specific phone number (for Tokyo POP). The customer will not
be able to use the address space when making PPP dialup connection
while he is in Osaka Japan.
o Portability inside an ISP cloud. Suppose that the ISP Y does not
implement per-NOC/POP address aggregation. A customer of ISP Y could
make a dialup PPP connection, from Tokyo Japan, or Osaka Japan.
However, to implement this, ISP Y pays significant cost for its own.
Internal routing table in ISP Y could be larger, and could be more
hard-to-manage, than the internal routing table in ISP X. ISP Y may
want to charge more monthly charge compared to ISP X.
o Portability across ISPs. It is possible to implement cross-ISP
address portability, by using appropriate tunnelling technology, or
special peering arrangement between two ISPs.
HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 4]
DRAFT Requirements for IPv6 dialup PPP operation May 2001
3. Protocols and additional needs
The section tries to diagnose existing protocols from dialup PPP
operation point of view.
3.1. Dynamic address space assignment
In IPv4 PPP, we have been using IPCP [McGregor, 1992] to negotiate and
assign an address to the downstream. In IPv6 PPP, the PPP layer do not
define address assignment protocols for the upstream ISP to the
customer. IPv6CP [Haskin, 1998] only negotiates interface identifiers
among two parties (i.e. link-local addresses). As discussed in the
seciton for the usage pattern, we would need to support roaming clients,
which would require a protocol/mechanism for dynamic address assignment.
As we would like to use /64 or /48 address space assignment (rather than
/128), the protocol needs to be capable of handing out address space,
instead of an address.
We have a couple of protocols and possibilities available for this
scenario. The following lists these protocols, as well as pros and cons
for each of them.
o Automatic prefix assignment
See [Haberman, 2000] .
ICMPv6-based, downstream-initiated.
Interactions with PPP: (1) Dialup connection establishment, LCP,
IPv6CP, PAP/CHAP. (2) Delegator query from customer, prefix
delegator from ISP. (3) Initial request from customer, prefix
delegated from ISP. (4) Customer propagates the prefix into the
site. (5) Custumer uses the ISP link. (6) Customer issues Prefix
return, prefix returned (7) Dialup link teardown.
Issues: (1) Recovery on abnormal PPP link termination. (2)
Authentication. Reuse MD5 (PAP/CHAP secret) as AH/ESP keys? For
PPP link, can we assume there's no wiretappers? (3) Can a customer
request the same prefix again? Protocol-wise, we can do this. How
do we resolve conflicts if the ISP cannot satisfy the demand? (4)
Prefix propagation within customer site. RA for /64 (easy), router
renumber for /48? (difficult). (5) IANA type/code assignment.
o Router renumbering
With router renumbering protocol [Crawford, 2000] , we can replace
subnet numbers configured onto multiple multiple routers in a site.
Therefore, one may wonder if it is possible to use the protocol for
dynamic address space assignment from an ISP to customers.
However, the protocol is useful only for renumbering a single site
(administrative domain), and is not suitable for dialup prefix
assignment.
HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 5]
DRAFT Requirements for IPv6 dialup PPP operation May 2001
The protocol assumes that we renubmer a single site, where
reachability is guaranteed among routers and the issuer of Prefix
Control Operations (PCOs), using site-local address. The
assumption does not hold for dialup case, as an ISP and customers
are considered as distinct sites, and it is possible that there are
collisions of site-local subnet numbers. Also, the protocol uses
shared IPsec secret between all the routers and the issuer of PCOs.
Normally ISP customers will not want to share IPsec authentication
key for their routers, with the upstream ISP.
o DHCPv6
Older DHCPv6 draft [Bound, 2000] had an DHCPv6 extension type for
passing a subnet prefix from a DHCPv6 server to a client. The
draft was not clear enough as to how we should be using the
extension (like what kind of topology is assumed, what is the
assumptions against the client, and such). The extension was
dropped from more recent drafts, so it is not possible to use this
approach.
o Extensions to PPP
At this moment there is no PPP extension defined for IPv6 address
space assignment. From the past discussions, it seems that the
community is not in favor of extending PPP protocol for IPv6
address space assignment. PPP already has too many extensions and
negotiation protocols with it. Also, if we declare IPv6 address
space assignment as an extension to PPP, we will not be able to use
it for IPv6 connectivity over other means (like tunnels [Gilligan,
2000] ).
3.2. User/address management within ISP
o Static configurations onto routers. This one is the easiest to
implement, but does not scale enough for realworld operations.
o RADIUS. See [Aboba, 2001]
4. Security considerations
The document talks about no security issues.
References
Deering, 1998.
S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification" in RFC2460 (December 1998). ftp://ftp.isi.edu/in-
notes/rfc2460.txt.
HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 6]
DRAFT Requirements for IPv6 dialup PPP operation May 2001
McGregor, 1992.
G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)" in
RFC1332 (May 1992). ftp://ftp.isi.edu/in-notes/rfc1332.txt.
Johnson, 2000.
David B. Johnson and Charles Perkins, "Mobility Support in IPv6" in
draft-ietf-mobileip-ipv6-13.txt (November 2000). work in progress
material.
Hagino, 2000.
Jun-ichiro Hagino, "IPv6 multihoming support at site exit routers" in
draft-ietf-ipngwg-ipv6-2260-00.txt (June 2000). work in progress
material.
Haskin, 1998.
D. Haskin and E. Allen, "IP Version 6 over PPP" in RFC2472 (December
1998). ftp://ftp.isi.edu/in-notes/rfc2472.txt.
Haberman, 2000.
B. Haberman and J. Martin, "Automatic Prefix Delegation Protocol for
Internet Protocol Version 6 (IPv6)" in draft-haberman-ipngwg-auto-
prefix-00.txt (November 2000). work in progress material.
Crawford, 2000.
Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000).
ftp://ftp.isi.edu/in-notes/rfc2894.txt.
Bound, 2000.
J. Bound, M. Carney, and C. Perkins, "Extensions for the Dynamic Host
Configuration Protocol for IPv6" in draft-ietf-dhc-dhcpv6exts-12.txt
(May 2000). work in progress material.
Gilligan, 2000.
R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and
Routers" in RFC2893 (August 2000). ftp://ftp.isi.edu/in-
notes/rfc2893.txt.
Aboba, 2001.
Bernard Aboba, Glen Zorn, and Dave Mitton, "RADIUS and IPv6" in draft-
aboba-radius-ipv6-07.txt (February 2001). work in progress material.
Change history
None.
Acknowledgements
00 -> 01
Analysis for existing protocols (user/address management, prefix
assignment).
HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 7]
DRAFT Requirements for IPv6 dialup PPP operation May 2001
Author's address
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku,Tokyo 101-0054, JAPAN
Tel: +81-3-5259-6350
Fax: +81-3-5259-6351
Email: [EMAIL PROTECTED]
Kazu YAMAMOTO
Research Laboratory, Internet Initiative Japan Inc.
(for postal address, see above)
Email: [EMAIL PROTECTED]
HAGINO and YAMAMOTO Expires: November 29, 2001 [Page 8]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
