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


               Requirements for IPv6 dialup PPP operation
              draft-itojun-ipv6-dialup-requirement-00.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.''


     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     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 13, 2001.


Abstract

The memo tries to identify design choices in IPv6 dialup PPP services by
ISPs.


.  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: January 13, 2001               [Page 1]

DRAFT          Requirements for IPv6 dialup PPP operation      July 2000

The document tries to summarize possible design choices in IPv6 dialup
PPP operation.  Actual operational practices should be documented
separately.


.  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 notebook
  PC, 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.

2.2.  Address space

It is desired to assign /48 address space, regardless from usage pattern
or size of the downstream site.  It is to make future renumbering in
downstream site easier on ISP change.  /128 assignment MUST NOT be made,
as it will advocate IPv6-to-IPv6 NAT.

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.

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.





HAGINO and YAMAMOTO     Expires: January 13, 2001               [Page 2]

DRAFT          Requirements for IPv6 dialup PPP operation      July 2000

       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.

       ISP router
         |La
         | ppp link
         |Lb
       Customer router
         |Gb
       (((Gx/48 cloud)))







HAGINO and YAMAMOTO     Expires: January 13, 2001               [Page 3]

DRAFT          Requirements for IPv6 dialup PPP operation      July 2000

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.


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

McGregor, 1992.
G. McGregor, "The PPP Internet Protocol Control Protocol (IPCP)" in
RFC1332 (May 1992). ftp://ftp.isi.edu/in-notes/rfc1332.txt.

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.


Change history

None.


Acknowledgements

(not yet)







HAGINO and YAMAMOTO     Expires: January 13, 2001               [Page 4]

DRAFT          Requirements for IPv6 dialup PPP operation      July 2000

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 13, 2001               [Page 5]