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
On Wed, 30 May 2001, Jun-ichiro itojun Hagino wrote:
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
