Network Working Group C. Xie Internet-Draft Q. Sun Intended status: Informational China Telecom Expires: August 29, 2013 S. Jiang Huawei Technologies Co., Ltd February 25, 2013 Use case of IPv6 prefix semantics for operators draft-sun-v6ops-semantic-usecase-01 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 August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Xie, et al. Expires August 29, 2013 [Page 1] Internet-Draft Semantic use case February 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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 3. A use case for Semantic Prefix . . . . . . . . . . . . . . . . 6 3.1. Level-1 semantics . . . . . . . . . . . . . . . . . . . . 6 3.2. Level-2 semantics . . . . . . . . . . . . . . . . . . . . 7 4. Benifits of Semantic Use Case . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Xie, et al. Expires August 29, 2013 [Page 2] Internet-Draft Semantic use case February 2013 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. The semantics are mainly used in a local region within an operator. 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. Network Device management In order to achieve easy management for network devices, operators will usually apply a simple and specific numbering policy for network devices. Besides, special-purpose security policies may be enforced for network devices other than for customers and service platforms. For example, when encountering a simple threat model from some subscribers' address block, operators may only filter the specific subscribers' address block other than the whole addresses network devices and service platforms. As a result, separated and specialized address space for network device will help to identify the network device among numerous addresses and apply policy accordingly. 2. Differentiated user management In operator's network, different kinds of customers may have different requirements for service provisioning. 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. In particular, semantic prefix would be quite useful for identifying subscriber's priority in downstream traffic across large-scale regions where subscriber's profile is difficult to syncronize. 3. High-priority service guarantee Xie, et al. Expires August 29, 2013 [Page 3] Internet-Draft Semantic use case February 2013 Operators may provide their own ISP brokered services, .e.g. video streaming, IPTV, VOIP, etc, which usually have higher priority guarantee rent their IDC to third-party service platform, offering high priority services, .e.g. video streaming, VOIP, etc. 4. 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 services. In this case, semantic embedded in the IPv6 address will be very helpful to implement service-based routing. 5. Security Control For security requirement, operators need to take control and identify of certain devices/customers in a quick manner. 6. 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. The semantic bits should be defined after an operator have got its IPv6 address pool. The embedded semantic bits should be carefully designed. Firstly, the number of bits which can be used to carry semantic information. Secondly, some sementics may easily raise the implementation complexity on host and network devices. So careful considerations and tradeoff should be taken in semantic design. [I-D.jiang-semantic-prefix] has listed some semantics which may be useful to network operators. In this document, we provide a use case to use some selected semantics, achieving enhanced network management and service provisioning ability with limited impact on existing network infrustructure. [Note: Further use cases could be added to reflect other requirements and implementation possibility.] 2. How to design the semantic bits Depending on the IPv6 address space that network operators received from IANA or upstream network service providers, the number of Xie, et al. Expires August 29, 2013 [Page 4] Internet-Draft Semantic use case February 2013 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: o 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. o The number of semantics should be limited. According to the above analysis, the number of semantic bits left for operators is quite limited. Therefore, network operator should only use necessary semantics when they can bring benefits, especially IP-layer policy, e.g. policy routing, access control and filtering, QoS, network measurement, etc. Network operators should be very careful to plan and manage the semantic field, and should self- restrict NOT to put too many semantic into prefix. So that they may avoid trap themselves into very complicated management issues. o Semantic overlap should be largely avoided . Any potential scenarios that a given address may be mapped two or more semantic prefixes might be harmful. Otherwise, if one subscriber is allocated with multiple semantics, context-based semantic selection mechanism must been introduced which might increase the complexity in device/hosts. In our use case, either the source address or the destination address only belongs to one semantic so as to simplify address selection process. o The design of semantic bits should be scalable and stable from the long-term. It should reflect the general potential network strategy and policies in the future and should be defined in highly abstracted way since there might be quite a lot of unknown emerging services. o Different size of addressing space should be planned carefully for different semantics. Since different semantics usually consumes Xie, et al. Expires August 29, 2013 [Page 5] Internet-Draft Semantic use case February 2013 different size of address space, operators should plan the size of address space according to the service model for different semantics. 3. A use case for Semantic Prefix As mentioned in section one, operators may have multiple requirements to use semantics. These requirements are largely falling into two categories: the first one is related to the network device features, while the second one is related to services provision and subscriber identification. The functional usage of the semantics for the two categories are quite different. For example, the semantics for the first category does not need to carry QoS related information, but may need to reflect network architecture of the operator; while the semantics in the second category should reflect the QoS requirements of the given subscriber/service. With this in mind, in our use case, the semantics are defined hierarchically, in which the first level is to define the function types of the prefixes, and the second level is to define the further usage within that specific prefix type. 3.1. Level-1 semantics Level-1 semantics can be used to define the function types of the prefixes. Function type (FT): the value of this field is to indicate the functional usage of this prefix. The typical types for operators include network device, subscriber and service. The following is the example of FT value. Xie, et al. Expires August 29, 2013 [Page 6] Internet-Draft Semantic use case February 2013 IPv6 Prefix +--------+--------+------------------------------------------------+ | | FT | | +--------+--------+------------------------------------------------+ / \ / \ +--------------+-------+ |000: network device | |001: service platform| |010: service platform| |011: subscriber | |100: subscriber | |101: subscriber | |110: reserved | +----------------------+ Figure 1: FT Value Example In this example, one prefix type may have multiple FT values. For example, FT value of the subscriber prefix can be 010,011,100,101,110,111, The portion of each type should be estimated according to the actual requirements for operators. With the above FT defintion, the whole IPv6 addressing space is firstly divided into three parts(as in the following figure). +----------------------------------------------------------------+ | IPv6 Addressing Space | +------------------------+--------------------+------------------+ | Subscriber | Service Platform | Network Device | | Addressing | Addressing | Addressing | | Space | Space | Space | +--------+--------+----------------------------------------------+ Figure 2: Addressing Space Division 3.2. Level-2 semantics Level-2 semantics is to define more detailed usage in different Function Types (addressing space). 1. Network Device Type (NDT) Network Device Type (NDT) is to indicate different types of network devices. Normally, one operator may have multiple networks, e.g.backbone network, mobile network, ISP brokered service network, etc. Using NDT field to indicate specific network within an operator may help to apply some routing policies. Besied, implementing the Xie, et al. Expires August 29, 2013 [Page 7] Internet-Draft Semantic use case February 2013 NDT field in the left-most bits means that a single, simple access- control list implemented across all networking devices would be enough to enforce effective traffic segregation. The Locator field is put behind NDT to indicate the region of a certain device. One example is shown in the following figure: IPv6 Prefix +--------+--------+------+-----------------------------------------+ | | FT(000)| NDT | Locator | Network Device bits | +--------+--------+------+-----------------------------------------+ / \ / \ +------------+----+ |000: Network 1 | |001: Network 1 | |010: Network 2 | |011: Network 2 | |100: Network 2 | |101: Network 2 | |110: Network 2 | +-----------------+ Figure 3: NDT Value Example 2. Subscriber type (ST) Subscriber type is to indicate different types of subscribers, e.g. wireline broadband subscriber, mobile subscriber, enterprise, WiFi, etc. This type of prefix is allocated to end users. 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. Here, the Locator will reflect the different regions of a subscriber, and is put before ST for better routing aggregation. One example is shown in the following figure: Xie, et al. Expires August 29, 2013 [Page 8] Internet-Draft Semantic use case February 2013 IPv6 Prefix +--------+--------+---------------+------+-------------------------+ | | FT(011)| Locator | ST | Subscriber bits | +--------+--------+---------------+------+-------------------------+ / \ / \ +----------+------------+--------------------------+ |0000: broadband access subscriber (high priority) | |0001: broadband access subscriber(medium priority)| |0010: broadband access subscriber (low priority) | |0011: broadband access subscriber (low priority) | |0100: mobile subscriber(high priority) | |0101: mobile subscriber (medium priority) | |0110: mobile subscriber (low priority) | |0111: mobile subscriber (low priority) | |1001: enterprise | |1000: enterprise | |1010: WiFi subscriber | |1011: WiFi subscriber | |110-111: Reserved | +--------------------------------------------------+ Figure 4: ST Value Example 3. Platform Type(PT) Platform type is to indicate typical service platforms offered by operators. This field may have scalability problem since there are numerous types of services in the further . It is recommended that only aggregated service platform types (e.g. according to service priority) should be defined in this field. This type of prefix is usually allocated to service platforms in operator's data center. One example is shown in the following figure: Xie, et al. Expires August 29, 2013 [Page 9] Internet-Draft Semantic use case February 2013 IPv6 Prefix +--------+--------+---------------+------+-------------------------+ | | FT(001)| Locator | PT | Platform bits | +--------+--------+---------------+------+-------------------------+ / \ / \ +----------+------------+---------------+ |000: high priority service platform | |001: high priority service platform | |001: medium priority service platform | |010: medium priority service platform | |011: medium priority service platform | |100: low priority service platform | |101: low priority service platform | |110~111: reserved | +---------------------------------------+ Figure 5: PT Value Example 4. Benifits of Semantic Use Case The following describes a few benifits (and non-exhaustive) of above semantic use case for an operator: 1. Easy network device management. With the combinition of FT, NDT and Locator, network devices from different regions can be easily identified. Besides, network-based routing policies can also be enforced with NDT. 2. Bi-directional subscriber quality of service guarantee. Since ST is consistent with the overall communication process for a subscriber, bi-directional quality of service guarantee can be easily achieved for cross-region communication. 3. Fine-Grained user and service control. Normally, ST is located in the source address of a subscriber, and PT is located in the destination address for upstream traffic. Therefore, with a simple combination of ST and PT, fine-Grained service control can be applied to subscribers (e.g. high priority broadband access subscriber with high priority service platform). 4. Service-based Routing. With the definition of ST, different routing policies can be applied according to ST field. Other requirements listed in section one can also be achieved in this use case. Xie, et al. Expires August 29, 2013 [Page 10] Internet-Draft Semantic use case February 2013 5. IANA Considerations This document has no actions for IANA. 6. Security Considerations Embedding semantics in prefix is actually exposing more information of packets explicit. These informations may also provide convenient for malicious attackers to track or attack certain type of packets. When networks announce their local prefix semantics to their peer networks, it may increase the vulnerable risk. 7. Acknowledgements Authors would like to show sincere appreciation to Erik Nygren, Joel Jaeggli, Owen DeLong for their comments and suggestions. 8. References 8.1. Normative References [I-D.jiang-semantic-prefix] Jiang, S., Sun, Q., and I. Farrer, "A Framework for Semantic IPv6 Prefix and Gap Analysis", draft-jiang-semantic-prefix-04 (work in progress), January 2013. [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. 8.2. Informative References [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. Xie, et al. Expires August 29, 2013 [Page 11] Internet-Draft Semantic use case February 2013 [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. [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: bingxuere@gmail.com Sheng Jiang Huawei Technologies Co., Ltd No.156 Beiqing Road Beijing 100095 P.R. China Email: jiangsheng@huawei.com Xie, et al. Expires August 29, 2013 [Page 12]