Internet Engineering Task Force Jun-ichiro itojun Hagino
INTERNET-DRAFT IIJ Research Laboratory
Expires: May 6, 2002 Kazu YAMAMOTO
IIJ Research Laboratory
November 6, 2001
Requirements for IPv6 dialup operation
draft-itojun-ipv6-dialup-requirement-02.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 May 6, 2002.
Abstract
The memo tries to identify design choices in IPv6 dialup services by
ISPs. We also supply a couple of scenarios as design prototypes for ISP
IPv6 dialup services.
1. Problem domain
With the deployment of IPv6 [Deering, 1998] , it becomes more apparent
that we have different operational requirements in IPv6 dialup
operation, from IPv4 dialup operation. For example, it would be
desirable to see static address allocation, rather than dynamic address
allocation, whenever possible. With the IPv4 PPP this has been
impossible due to address space shortage, and IPCP [McGregor, 1992]
dynamic address allocation has been used. With IPv6 PPP and other
dialup connectivity, it is possible to perform static address allocation
from ISPs to downstream customers, as there's enough address to spare.
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 1]
DRAFT Requirements for IPv6 dialup operation November 2001
The document tries to summarize possible design choices in IPv6 dialup
operation. By saying "dialup", we mean any non-permanent point-to-point
layer 2 connectivity, including PPP, dynamically-configured IPv6-over-
IPv4 tunnels, and PPPoE. Some of the discussions may go into layer 2
protocol details.
2. The usage pattern
One of the important differences with IPv4 dialup operation is the
distinction between static (non-roaming) clients and roaming clients.
Because we have more address space to spare, and we would like to
advocate static IPv6 address assignment to leaf sites (so that they can
run servers at ease), we would like to differentiate static (non-
roaming) clients from roaming clients.
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 in different countries.
Users may be able to hide their location changes by using mobile-ip6
[Johnson, 2001] , 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).
Note, however, due to the recent deployment of always-on connectivity
(like xDSL), we may not need to model static (non-roaming) clients as
dialup downstreams. We may be able to model them as permanent
connectivity downstreams.
3. Design choices for customer network
The section tries to list possible choices in IPv6 dialup services.
Here is a short summary of the section, given in bottom-up (customer
side to ISP side) order. Note that these choices are not independent
with each other.
o Address space.
o Address allocation. (1) Static assignment, or (2) dynamic assignment.
o Address allocation models. There are three choices: (1) /48 to behind
the customer router, (2) /64 to behind the customer router, (3) /64 to
dialup point-to-point link itself, with multilink subnet trick on
customer side. (4) /64 to dialup point-to-point link itself,
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 2]
DRAFT Requirements for IPv6 dialup operation November 2001
o Mechanism for address assignment. (1) Assignment by paper, or (2)
automated assignment by ICMPv6 prefix assignment protocol [Haberman,
2001] , or (3) automated assignment by router advertisement over
dialup point-to-point link.
3.1. 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.
3.2. Address allocation
o Static address allocation. ISPs will allocate a static address space
(/48) to a downstream customer, at contract time.
o Dynamic address allocation. ISPs will allocate an address space (/48
or /64) to a downstream customer on the fly.
3.3. Address allocation models
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 link
between the ISP and the customer site.
ISP router
|La
| point-to-point link
|Lb
Customer router
|Gb
(((Gx/48 cloud)))
o Assign a /64 address to the interface behind the customer router.
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 3]
DRAFT Requirements for IPv6 dialup operation November 2001
ISP router
|La
| point-to-point 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
| point-to-point 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 a /64 address space to point-to-point interface. The
downstream user uses a router capable of handling multi-link subnet
[Thaler, 2001] and uses the same /64 prefix for point-to-point link as
well as the interface behind the customer router. The case looks
exactly the same as the previous from the ISP point of view.
ISP router
|La, Ga
| point-to-point link (Gx/64)
|Lb, Gb
Customer router
|Gc
==+=== Gx/64
o Assign a /64 address space to point-to-point interface. 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
| point-to-point link (Gx/64)
|Lb, Gb
Customer computer
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 4]
DRAFT Requirements for IPv6 dialup operation November 2001
3.4. Mechanism for address assignment
Let us take PPP as an example. 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 Address assignment by paper
When there is no need for dynamic assignment, we can inform the
customer address prefix at contract time by paper.
o Automatic prefix assignment
See [Haberman, 2001] .
ICMPv6-based, downstream-initiated. Is not specific to PPP. For
assigning an IPv6 prefix to behind the customer routers. Can
support both /64 and /48 assignments.
Interactions with PPP would be like this: (1) Dialup connection
establishment, LCP, IPv6CP, PAP/CHAP. (2) Delegator query from
customer, prefix delegator response 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.
The protocol can be used for both dynamic address allocation cases,
as well as static address allocation cases. For static address
allocation cases, we would use the protocol as an initialization
mechamism for the customer side.
Issues: (1) Recovery on abnormal link termination. (2)
Authentication. Reuse MD5 (PAP/CHAP secret) as AH/ESP keys? What
if we can assume there's no wiretappers for the layer 2? (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. (6) Standardization and deployment. (7) If we are to
use the protocol for static address allocation cases, we need to
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 5]
DRAFT Requirements for IPv6 dialup operation November 2001
define routers' behavior when ISP router and the customer router
did not agree about the address prefix.
o Router advertisement on point-to-point link
Router advertisement is defined in RFC2461 [Narten, 1998] and
RFC2462 [Thomson, 1998] .
Works if we are to assign a /64 address space to point-to-point
interface. ISP router should transmit router advertisement packets
onto the point-to-point link.
Issues: (1) This advocates IPv6 NAT as the customer can assign
global IPv6 address to only a single device.
o RA on point-to-point link, with multi-link subnet
Router advertisement is defined in RFC2461 [Narten, 1998] and
RFC2462 [Thomson, 1998] . Multi-link subnet mechanism is defined
in a draft by Dave Thaler [Thaler, 2001] .
Works if we are to assign a /64 address prefix to point-to-point
interface, and the customer router reuses the prefix to the
interface behind it. ISP router should transmit router
advertisement packets onto the point-to-point link. Customer
router has to support multi-link subnet mechanism.
Issues: (1) We have much fewer operational experiences for multi-
link subnet mechanism (if any), than normal IPv6 forwarding.
Operational experiences has to be gathered before using this
approach in the wild. (2) The use of multi-link subnet mechanism
could make customer routers different from other IPv6 routers. Is
it worthwhile to doing so, than picking other mechanisms? (3)
Standardization and deployment of multi-link subnet mechanism. (4)
See [Thaler, 2001] for other issues regarding to multi-link subnet.
We have considered the following approaches, but dropped them after
discussions: router renumbering [Crawford, 2000] , DHCPv6 subnet prefix
extension [Bound, 2000] existed in older DHCPv6 drafts, extensions to
PPP (Yoshinobu Inoue in pppext working group meeting, IETFxx).
4. Design choices within the ISP
o Routing between the ISP and customers. (1) Static, or (2) run a
routing protocol (RIPng, BGP, whatever).
o Mechanism for user-address mapping. (1) RADIUS in ISP, or (2) static
assignment.
o Other considerations. Address portability within ISP, issues with ISP
roaming, and others.
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 6]
DRAFT Requirements for IPv6 dialup operation November 2001
4.1. Routing between the ISP and customers
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 the dialup 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 the dialup link status better. This also makes it easier
to detect disconnection of the dialup link. 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, 2001] ISPs may want to filter out bogus routing
announcements from the downstream.
4.2. Mechanism for user-address mapping
o Static configurations onto routers. This one is the easiest to
implement, but does not scale enough for realworld operations.
o RADIUS. See separate draft [Aboba, 2001] for details.
4.3. 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. Also, the aspect can be
influenced by layer 1/2 limitations, like phone number aggregation
services provided by PSTN operators for modem connections.
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 dialup call
to specific phone number (for Tokyo POP). The customer will not be
able to use the address space when making 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 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 (like exchanging IGP
routes between the two).
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 7]
DRAFT Requirements for IPv6 dialup operation November 2001
5. Scenarios
5.1. Simple dialup IPv6 service for static customers
The section presents a design of very simple dialup IPv6 service for
static (non-roaming) customers, which has minimal requirements to the
ISP routers as well as customer routers. This will not scale too much,
however, it is possible to operate the service without special support
from IPv6 routers (except for, for example, IPv6CP [Haskin, 1998]
support in PPP case).
o The service is for static (non-roaming) clients, who would connect
from their home.
o Static /48 address space, assigned to behind of the customer router.
o A /48 address space is informed to a customer using a paper at
contract time. The customer needs to configure their router manually.
o Configure layer 2 as well as ISP router ports, so that a customer is
guaranteed to get connected to a specific port on a specific ISP
router. Example: for modem connectivity, tell the customer to use
specific PSTN phone number. As a result, there will be no IGP changes
on customer connection. It also means that we need to prepare the
same number of dialup interfaces as the number of the customers.
o Use static routing between customer and ISP routers.
o Configure ISP routers statically, with /48 routing entries for
customers.
5.2. Scalable dialup IPv6 service for static customers
The example is an extension to the previous one. The design is more
widely deployable and manageable. There are two requirements to the
router devices: ICMPv6 prefix assignment protocol support, and RADIUS
database support.
o Inform the address space to customers, using ICMPv6 prefix assignment
protocol, on first-time connection. This way, customers do not need
to configure routers on their own. The ISP router and the customer
routers need to support ICMPv6 prefix assignment protocol. There are
other items to consider though: (1) On re-connection, we need to
decide what kind of behavior should we take, when address prefix
mismatches between ISP router and customer routers. (2) For customer
routers, how should we configure RA outputs for customer subnets? Do
we want to automate it, or let customers override it?
o Use RADIUS database to maintain mapping between /48 prefixes and
customer IDs. On dialup connection establishment, ISP routers would
contact RADIUS database to decide which /48 should it use. There will
be certain IGP routing announcement changes on customer connection
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 8]
DRAFT Requirements for IPv6 dialup operation November 2001
(for example, a new /48 advertisement to IGP cloud).
5.3. Dialup IPv6 service for roaming customers
The section presents a design of dialup IPv6 service, for roaming
customers. It requires both ends (ISP routers and customer routers) to
support ICMPv6 prefix assignment protocol.
o The service is for roaming clients, who would connect to the ISP while
they are on travel.
o Dynamic /64 address space, assigned to behind of the customer router
(= laptop). The /64 prefix will change every time the client will re-
connect to the ISP. The behavior is not desirable for static (non-
roaming) clients, hence it is discouraged for static clients to use
the type of service.
o A /64 address space is informed to a customer using ICMPv6 prefix
assignment protocol. The customer router (= laptop) needs to
configure the prefix to an interface behind of the router.
o /64 prefixes can be assigned to ISP routers statically prior to the
conneciton. There will be no RADIUS interaction regarding to address
prefix assignment, since the addrss prefix is not related to the
customers. There will be no IGP changes on customer connection.
o Use static routing between customer and ISP routers.
6. To be updated
o Clarify RADIUS requirements on Cross-ISP roaming cases.
o Issues with monitoring, and/or support. Example: ISPs would like to
issue ICMPv6 echo request to customer device. Therefore, they need to
know one of the global IPv6 addresses on customer device. How will it
be possible? Relationship with temporary addresses?
o Conflict resolution rules/failure model, when the ISP and the customer
did not agree about the prefix to be used, on ICMPv6 prefix delegation
negotiation.
o More scenarios?
7. Security considerations
There are a couple of places in this document, where we would need to
check the authenticity of the clients:
o On layer 2 connection establishment (like PPP LCP).
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 9]
DRAFT Requirements for IPv6 dialup operation November 2001
o ICMPv6 prefix assignment protocol. The draft for the protocol
[Haberman, 2001] suggests the use of IPsec, however, it gives no
indication as to how we should manage or propagate IPsec keys.
These items has to be considered carefully when the readers deploy
dialup IPv6 connectivity services.
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.
McGregor, 1992.
G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)" in
RFC1332 (May 1992). ftp://ftp.isi.edu/in-notes/rfc1332.txt.
Johnson, 2001.
David B. Johnson and Charles Perkins, "Mobility Support in IPv6" in
draft-ietf-mobileip-ipv6-14.txt (July 2001). work in progress material.
Haberman, 2001.
B. Haberman and J. Martin, "Automatic Prefix Delegation Protocol for
Internet Protocol Version 6 (IPv6)" in draft-haberman-ipngwg-auto-
prefix-01.txt (July 2001). work in progress material.
Thaler, 2001.
Dave Thaler and Christian Huitema, "Multi-link Subnet Support in IPv6"
in draft-thaler-ipngwg-multilink-subnets-01.txt (July 2001). 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.
Narten, 1998.
T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP
Version 6 (IPv6)" in RFC2461 (December 1998). ftp://ftp.isi.edu/in-
notes/rfc2461.txt.
Thomson, 1998.
S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in
RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt.
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
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 10]
DRAFT Requirements for IPv6 dialup operation November 2001
Configuration Protocol for IPv6" in draft-ietf-dhc-dhcpv6exts-12.txt
(May 2000). work in progress material.
Hagino, 2001.
Jun-ichiro Hagino and Hal Snyder, "IPv6 multihoming support at site exit
routers" in RFC3178 (October 2001). ftp://ftp.isi.edu/in-
notes/rfc3178.txt.
Aboba, 2001.
B. Aboba, G. Zorn, and D. Mitton, "RADIUS and IPv6" in RFC3162 (August
2001). ftp://ftp.isi.edu/in-notes/rfc3162.txt.
Change history
00 -> 01
Analysis for existing protocols (user/address management, prefix
assignment).
Based on the discussions we had in ipngwg interim meeting (Seattle,
June 2001), selected a couple of protocols. Drop the world "PPP"
from the title, as the problem seems generic to any dialup IPv6
operation (not just for PPP).
01 -> 02
Update references. Typo fixes.
Acknowledgements
The authors would like to thank those who have commented on earlier
versions of the draft, including ISP operators who participated on
NSPIXP6 (Tokyo IPv6 intenret exchange).
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: itojun@iijlab.net
Kazu YAMAMOTO
Research Laboratory, Internet Initiative Japan Inc.
(for postal address, see above)
Email: kazu@iijlab.net
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 11]
DRAFT Requirements for IPv6 dialup operation November 2001
HAGINO and YAMAMOTO Expires: May 6, 2002 [Page 12]