Internet Engineering Task Force                 Jun-ichiro itojun Hagino
INTERNET-DRAFT                                   IIJ Research Laboratory
Expires: January 19, 2002                                  Kazu YAMAMOTO
                                                 IIJ Research Laboratory
                                                           July 19, 2001


                 Requirements for IPv6 dialup operation
              draft-itojun-ipv6-dialup-requirement-01.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 January 19, 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 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: January 19, 2002               [Page 1]


DRAFT            Requirements for IPv6 dialup operation        July 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 difference with IPv4 dialup operation is the
distinction between static (non-roaming) clients and non-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 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).

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.


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.  There are three choices: (1) /64 to dialup point-to-
  point link itself, (2) /64 to dialup point-to-point link itself, with
  multilink subnet trick on customer side, (3) /48-64 to behind the
  customer router.

o Address allocation.  (1) Static assignment, or (2) dynamic assignment.

o Address allocation models.  There are three choices: (1) /64 to dialup
  point-to-point link itself, (2) /64 to dialup point-to-point link
  itself, with multilink subnet trick on customer side.  (3) /64 to
  behind the customer router, (4) /48 to behind the customer router,


HAGINO and YAMAMOTO     Expires: January 19, 2002               [Page 2]


DRAFT            Requirements for IPv6 dialup operation        July 2001

o Mechanism for address assignment.  (1) Assignment by paper, or (2)
  automated assignment by ICMPv6 prefix assignment portocol [Haberman,
  2000] , 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 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


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



HAGINO and YAMAMOTO     Expires: January 19, 2002               [Page 3]


DRAFT            Requirements for IPv6 dialup operation        July 2001

o Assign a /64 address to the interface behind the customer router.

       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 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)))


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


HAGINO and YAMAMOTO     Expires: January 19, 2002               [Page 4]


DRAFT            Requirements for IPv6 dialup operation        July 2001

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, 2000] .

     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 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
     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.


HAGINO and YAMAMOTO     Expires: January 19, 2002               [Page 5]


DRAFT            Requirements for IPv6 dialup operation        July 2001

     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.

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-


HAGINO and YAMAMOTO     Expires: January 19, 2002               [Page 6]


DRAFT            Requirements for IPv6 dialup operation        July 2001

  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.

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).


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).


HAGINO and YAMAMOTO     Expires: January 19, 2002               [Page 7]


DRAFT            Requirements for IPv6 dialup operation        July 2001

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
  (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.



HAGINO and YAMAMOTO     Expires: January 19, 2002               [Page 8]


DRAFT            Requirements for IPv6 dialup operation        July 2001

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).

o ICMPv6 prefix assignment protocol.  The draft for the protocol
  [Haberman, 2000] 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.







HAGINO and YAMAMOTO     Expires: January 19, 2002               [Page 9]


DRAFT            Requirements for IPv6 dialup operation        July 2001

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, 2000.
David B. Johnson and Charles Perkins, "Mobility Support in IPv6" in
draft-ietf-mobileip-ipv6-13.txt (November 2000). work in progress
material.

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.

Thaler, 2001.
Dave Thaler and Christian Huitema, "Multi-link Subnet Support in IPv6"
in draft-thaler-ipngwg-multilink-subnets-00.txt (May 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
Configuration Protocol for IPv6" in draft-ietf-dhc-dhcpv6exts-12.txt
(May 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.


HAGINO and YAMAMOTO     Expires: January 19, 2002              [Page 10]


DRAFT            Requirements for IPv6 dialup operation        July 2001

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


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).


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: January 19, 2002              [Page 11]