Subject: dialup PPP (material for interim meeting)

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 30 May 2001 14:44:28 +0900

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-masked]

     Kazu YAMAMOTO
     Research Laboratory, Internet Initiative Japan Inc.
     (for postal address, see above)
     Email: [email-masked]

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-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Wed, 30 May 2001 02:56:20 -0400 (EDT)

itojun,

Got it.  I will down load to my laptop we really need this for IPv6.
WOrst case maybe we can get dave, brian, or rich to make it available for
attendees......

/jim