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]