Network Working Group C. Xie Internet-Draft Q. Sun Intended status: Informational China Telecom Expires: April 18, 2013 October 15, 2012 ISP Semantic use case draft-sun-semantic-usecase-00 Abstract Embedding certain semantics into IPv6 addresses will bring a lot of benifits for operators to simplify network management and apply operations accordingly[I-D.jiang-semantic-prefix]. This memo illustrates the use case of semantic bits from operator's point of view, and provides considerations on how to design the semantic bits in IPv6 address. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 18, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Xie & Sun Expires April 18, 2013 [Page 1] Internet-Draft Semantic use case October 2012 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. How to design the semantic bits . . . . . . . . . . . . . . . . 4 2.1. Guidelines to define the semantic bits . . . . . . . . . . 4 2.2. Typical types of semantics . . . . . . . . . . . . . . . . 5 2.3. How to determine the placement of semantics bits . . . . . 6 2.4. Semantic Design Example . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Xie & Sun Expires April 18, 2013 [Page 2] Internet-Draft Semantic use case October 2012 1. Introduction [I-D.jiang-semantic-prefix] introduces embedded semantics prefix solution in IPv6 context. With more and more differentiated requirements raising in the current Internet, service operators may want to apply more complicated policies for different kinds of customers and services. Policy control servers are introduced gradually in fixed network operator and mobile network operator. However, all of these policies can only take action based on efficient packet identification of different sematics. Carrying semantic bits directly in IPv6 prefix is not only efficient for routers to do packet identification, but also suitable for operators. It provides an easy access and trustable fundamental for packet differentiated treatment. For operators, several motivations to use semantic prefixes are as follows: 1. Device management In order to achieve easy management for network devices, operators will usually apply a simple numbering policy for network devices. Besides, special-purpose security policies may be taken for devices other than from customers and service platforms. As a result, seperated address space for network device will help to identify the network device among numours addresses and apply policy according. 2. Differentiated user management In operator's network, different kinds of customers may have different priorities. For example, broadband access subscribers usually have lower priority than enterprise customers. And even for broadband access subscribers, different priorities can also be further divided to apply differentiated policy, e.g. bandwidth limit, etc. 3. Service-based Routing Service-based routing usually has close relationship with operator's network architecture. For example, some operators have distinct core networks for different kinds of services. As a result, operators may offer different routing policy for specific service platforms .e.g. video streaming, VOIP, etc. Different routing policies may also apply to high priority subscribers. 4. Security Control Xie & Sun Expires April 18, 2013 [Page 3] Internet-Draft Semantic use case October 2012 For security requirement, operators need to take control and identify of certain devices/customers in a quick manner. 5. Easy measurement and statistic The semantic prefix provides explicit identifiers for measurement and statistic. They are as simple as checking certain bits of address in each packets. 2. How to design the semantic bits The embedded semantic bits should be carefully designed since they are limited resources allocated to operators. In this section, we discuss the guidelines for operators to define the semantic bits, typical types of semantics, considerations on the placement of semantics bits, and also give an example to illustrate our considerations. 2.1. Guidelines to define the semantic bits Depending on the IPv6 address space that network operators received from IANA or upstream network service providers, the number of arbitrary bits in prefix is different. For now, this document only discusses unicast address within IP Version 6 Addressing Architecture [RFC4291]. The following are some guidelines for operators to design the semantic bits: 1. Determine the number of semantic bits. Typically, ISPs with millions subscribers would have /16 ~ /24 address space. It allows 40~48 arbitrary bits in prefix to be set by network operators (assuming the network is not strictly managed by DHCPv6). However, many ISPs plan to assign /56 or even /48 for subscribers, the arbitrary bits are reduced to 22~40. Furthermore, within the arbitrary bits, the locator function of IP address should be ensured first. Enough consideration should be given for future expanding. Some address space may be wasted in aggregation. For a Semantic Prefix Domain that organizes several millions subscribers with a continuous IPv6 address block, 24 bits for locator function is a minimum safe allocation. Hence, it is recommended to use 4~12 bits in prefix for embedded semantics. 2. The number of semantics should be limited. According to the above analysis, the number of semantic bits left for operators is quite limited. Therefore, it is recommended network operator Xie & Sun Expires April 18, 2013 [Page 4] Internet-Draft Semantic use case October 2012 only use necessary semantics when they can bring benefits to network operations, especially IP-layer policy, e.g. policy routing, access control and filtering, QoS, network measurement, etc. The network operators should be very careful to plan and manage the semantic field. The network operators should self- restrict NOT to put too many semantic into prefix. So that they may avoid trap themselves into very complicated management issues. 3. Semantic overlap should be avoided for packet. Any potential scenarios that a given packet may be mapped two or more semantic prefixes are considered harmful. And for each individual semantic, it is also recommended that one device/host can only belong to one semantic. 4. The design of semantic bits should be scalable and stable from the long-term. It should reflect the general potential network policies in the future and should be defined in highly abstracted way since there might be quite a lot of unknown emerging services. 5. Different size of addressing space should be planned carefully for different sementics. Since different semantics usually consumes different size of address space, operators should plan the size of address space according to the service model for different semantics. 2.2. Typical types of semantics The typical types of semantics for operators are listed as follows: 1. Device type: indicating network device, subscriber or service platform, etc. 2. Subscriber type: indicating different types of subscribers for operators, e.g. broadband access subscriber, mobile access subscriber, enterprise, WiFi, etc. In particular, further divisions can be taken on subscriber's priorities within one type, e.g. golden broadband subscriber, silver broadband subscriber and bronze broadband subscriber. This definition is based on operator's local service model. 3. Service type: indicating typical services offered by operators. This field may have scalbility problem since there are numerous types of services in the further. It is recommended that only aggregated service types (e.g. according to service priority) should be defined in this field. Xie & Sun Expires April 18, 2013 [Page 5] Internet-Draft Semantic use case October 2012 2.3. How to determine the placement of semantics bits The placement of semantic bits should be carefully designed. Specifically, based on the usage of semantics, we can further divide the type of semantics into local-semantic and global-semantic. The local-semantic is only used within one operator, while global- semantic can be distributed among different operators. For example, for the above semantics, device type can be regarded as a global- semantic which can be used by other operators to do access control or filtering, and can be distributed via global routing system. However, subscriber type and service type only concerns with the service model within one operator. It is recommended that global-semantic fields should be placed in the most left bits of the prefix so that different operators may control the prefix simplier. The locator function should be placed in the lower place followed by local-semantics. 2.4. Semantic Design Example 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IANA assigned block |Global-S| locator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | locator (Cont.) | Local-Semantic|Subscriber bits| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Semantic Design Example The above figure represents an ISP semantic prefix example. In this example, the semantic prefix domain have a /20 IPv6 address space. It should serve over one million users. Then 4 bits are allocated to global-semantics bits to indicate the type of device. The next 24 most- left bits are allocated as locator. It serves network aggregation of topology based. The 8 most- right bits are subscriber bits. It means /56 prefix is assigned to subscribers. 8 bits (from bit 44 to 51) are assigned as local semantic field. A further detailed example, combing user type, service type, VPNs, and application virtual overlay networks, the local-semantic field can be assigned like blow (presented in octet): 00 Normal individual user with normal internet access services 01 High-end individual user with normal internet access services Xie & Sun Expires April 18, 2013 [Page 6] Internet-Draft Semantic use case October 2012 02 High-end individual user with secure internet access services 03~07 Reserved 3. IANA Considerations 4. Security Considerations TBD 5. Acknowledgements TBD 6. References 6.1. Normative References [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 6.2. Informative References [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. Xie & Sun Expires April 18, 2013 [Page 7] Internet-Draft Semantic use case October 2012 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Authors' Addresses Chongfeng Xie China Telecom Room 708, No.118, Xizhimennei Street Beijing 100084 P.R. China Email: sunqiong@ctbri.com.cn Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100084 P.R. China Email: sunqiong@ctbri.com.cn Xie & Sun Expires April 18, 2013 [Page 8]