idnits 2.17.1 draft-sun-v6ops-semantic-usecase-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.jiang-semantic-prefix]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 25, 2013) is 4072 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4291' is mentioned on line 171, but not defined == Unused Reference: 'RFC0768' is defined on line 449, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 452, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 459, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC2661' is defined on line 467, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 475, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-jiang-semantic-prefix-04 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Xie 3 Internet-Draft Q. Sun 4 Intended status: Informational China Telecom 5 Expires: August 29, 2013 S. Jiang 6 Huawei Technologies Co., Ltd 7 February 25, 2013 9 Use case of IPv6 prefix semantics for operators 10 draft-sun-v6ops-semantic-usecase-01 12 Abstract 14 Embedding certain semantics into IPv6 addresses will bring a lot of 15 benifits for operators to simplify network management and apply 16 operations accordingly[I-D.jiang-semantic-prefix]. This memo 17 illustrates the use case of semantic bits from operator's point of 18 view, and provides considerations on how to design the semantic bits 19 in IPv6 address. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 29, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. How to design the semantic bits . . . . . . . . . . . . . . . 4 63 3. A use case for Semantic Prefix . . . . . . . . . . . . . . . . 6 64 3.1. Level-1 semantics . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Level-2 semantics . . . . . . . . . . . . . . . . . . . . 7 66 4. Benifits of Semantic Use Case . . . . . . . . . . . . . . . . 10 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 [I-D.jiang-semantic-prefix] introduces embedded semantics prefix 78 solution in IPv6 context. With more and more differentiated 79 requirements raising in the current Internet, service operators may 80 want to apply more complicated policies for different kinds of 81 customers and services. Policy control servers are introduced 82 gradually in fixed network operator and mobile network operator. 83 However, all of these policies can only take action based on 84 efficient packet identification of different sematics. 86 The semantics are mainly used in a local region within an operator. 87 Carrying semantic bits directly in IPv6 prefix is not only efficient 88 for routers to do packet identification, but also suitable for 89 operators. It provides an easy access and trustable fundamental for 90 packet differentiated treatment. 92 For operators, several motivations to use semantic prefixes are as 93 follows: 95 1. Network Device management 97 In order to achieve easy management for network devices, operators 98 will usually apply a simple and specific numbering policy for network 99 devices. Besides, special-purpose security policies may be enforced 100 for network devices other than for customers and service platforms. 101 For example, when encountering a simple threat model from some 102 subscribers' address block, operators may only filter the specific 103 subscribers' address block other than the whole addresses network 104 devices and service platforms. As a result, separated and 105 specialized address space for network device will help to identify 106 the network device among numerous addresses and apply policy 107 accordingly. 109 2. Differentiated user management 111 In operator's network, different kinds of customers may have 112 different requirements for service provisioning. For example, 113 broadband access subscribers usually have lower priority than 114 enterprise customers. And even for broadband access subscribers, 115 different priorities can also be further divided to apply 116 differentiated policy, e.g. bandwidth limit, etc. In particular, 117 semantic prefix would be quite useful for identifying subscriber's 118 priority in downstream traffic across large-scale regions where 119 subscriber's profile is difficult to syncronize. 121 3. High-priority service guarantee 122 Operators may provide their own ISP brokered services, .e.g. video 123 streaming, IPTV, VOIP, etc, which usually have higher priority 124 guarantee rent their IDC to third-party service platform, offering 125 high priority services, .e.g. video streaming, VOIP, etc. 127 4. Service-based Routing 129 Service-based routing usually has close relationship with operator's 130 network architecture. For example, some operators have distinct core 131 networks for different kinds of services. As a result, operators may 132 offer different routing policy for specific service platforms 133 .e.g.video streaming, VOIP, etc. Different routing policies may also 134 apply to high priority services. In this case, semantic embedded in 135 the IPv6 address will be very helpful to implement service-based 136 routing. 138 5. Security Control 140 For security requirement, operators need to take control and identify 141 of certain devices/customers in a quick manner. 143 6. Easy measurement and statistic 145 The semantic prefix provides explicit identifiers for measurement and 146 statistic. They are as simple as checking certain bits of address in 147 each packets. 149 The semantic bits should be defined after an operator have got its 150 IPv6 address pool. The embedded semantic bits should be carefully 151 designed. Firstly, the number of bits which can be used to carry 152 semantic information. Secondly, some sementics may easily raise the 153 implementation complexity on host and network devices. So careful 154 considerations and tradeoff should be taken in semantic design. 156 [I-D.jiang-semantic-prefix] has listed some semantics which may be 157 useful to network operators. In this document, we provide a use case 158 to use some selected semantics, achieving enhanced network management 159 and service provisioning ability with limited impact on existing 160 network infrustructure. 162 [Note: Further use cases could be added to reflect other requirements 163 and implementation possibility.] 165 2. How to design the semantic bits 167 Depending on the IPv6 address space that network operators received 168 from IANA or upstream network service providers, the number of 169 arbitrary bits in prefix is different. For now, this document only 170 discusses unicast address within IP Version 6 Addressing Architecture 171 [RFC4291]. 173 The following are some guidelines for operators to design the 174 semantic bits: 176 o Determine the number of semantic bits. Typically, ISPs with 177 millions subscribers would have /16 ~ /24 address space. It 178 allows 40~48 arbitrary bits in prefix to be set by network 179 operators (assuming the network is not strictly managed by 180 DHCPv6). However, many ISPs plan to assign /56 or even /48 for 181 subscribers, the arbitrary bits are reduced to 22~40. 182 Furthermore, within the arbitrary bits, the locator function of IP 183 address should be ensured first. Enough consideration should be 184 given for future expanding. Some address space may be wasted in 185 aggregation. For a Semantic Prefix Domain that organizes several 186 millions subscribers with a continuous IPv6 address block, 24 bits 187 for locator function is a minimum safe allocation. Hence, it is 188 recommended to use 4~12 bits in prefix for embedded semantics. 190 o The number of semantics should be limited. According to the above 191 analysis, the number of semantic bits left for operators is quite 192 limited. Therefore, network operator should only use necessary 193 semantics when they can bring benefits, especially IP-layer 194 policy, e.g. policy routing, access control and filtering, QoS, 195 network measurement, etc. Network operators should be very 196 careful to plan and manage the semantic field, and should self- 197 restrict NOT to put too many semantic into prefix. So that they 198 may avoid trap themselves into very complicated management issues. 200 o Semantic overlap should be largely avoided . Any potential 201 scenarios that a given address may be mapped two or more semantic 202 prefixes might be harmful. Otherwise, if one subscriber is 203 allocated with multiple semantics, context-based semantic 204 selection mechanism must been introduced which might increase the 205 complexity in device/hosts. In our use case, either the source 206 address or the destination address only belongs to one semantic so 207 as to simplify address selection process. 209 o The design of semantic bits should be scalable and stable from the 210 long-term. It should reflect the general potential network 211 strategy and policies in the future and should be defined in 212 highly abstracted way since there might be quite a lot of unknown 213 emerging services. 215 o Different size of addressing space should be planned carefully for 216 different semantics. Since different semantics usually consumes 217 different size of address space, operators should plan the size of 218 address space according to the service model for different 219 semantics. 221 3. A use case for Semantic Prefix 223 As mentioned in section one, operators may have multiple requirements 224 to use semantics. These requirements are largely falling into two 225 categories: the first one is related to the network device features, 226 while the second one is related to services provision and subscriber 227 identification. 229 The functional usage of the semantics for the two categories are 230 quite different. For example, the semantics for the first category 231 does not need to carry QoS related information, but may need to 232 reflect network architecture of the operator; while the semantics in 233 the second category should reflect the QoS requirements of the given 234 subscriber/service. 236 With this in mind, in our use case, the semantics are defined 237 hierarchically, in which the first level is to define the function 238 types of the prefixes, and the second level is to define the further 239 usage within that specific prefix type. 241 3.1. Level-1 semantics 243 Level-1 semantics can be used to define the function types of the 244 prefixes. 246 Function type (FT): the value of this field is to indicate the 247 functional usage of this prefix. The typical types for operators 248 include network device, subscriber and service. 250 The following is the example of FT value. 252 IPv6 Prefix 253 +--------+--------+------------------------------------------------+ 254 | | FT | | 255 +--------+--------+------------------------------------------------+ 256 / \ 257 / \ 258 +--------------+-------+ 259 |000: network device | 260 |001: service platform| 261 |010: service platform| 262 |011: subscriber | 263 |100: subscriber | 264 |101: subscriber | 265 |110: reserved | 266 +----------------------+ 268 Figure 1: FT Value Example 270 In this example, one prefix type may have multiple FT values. For 271 example, FT value of the subscriber prefix can be 272 010,011,100,101,110,111, The portion of each type should be estimated 273 according to the actual requirements for operators. 275 With the above FT defintion, the whole IPv6 addressing space is 276 firstly divided into three parts(as in the following figure). 278 +----------------------------------------------------------------+ 279 | IPv6 Addressing Space | 280 +------------------------+--------------------+------------------+ 281 | Subscriber | Service Platform | Network Device | 282 | Addressing | Addressing | Addressing | 283 | Space | Space | Space | 284 +--------+--------+----------------------------------------------+ 286 Figure 2: Addressing Space Division 288 3.2. Level-2 semantics 290 Level-2 semantics is to define more detailed usage in different 291 Function Types (addressing space). 293 1. Network Device Type (NDT) 295 Network Device Type (NDT) is to indicate different types of network 296 devices. Normally, one operator may have multiple networks, 297 e.g.backbone network, mobile network, ISP brokered service network, 298 etc. Using NDT field to indicate specific network within an operator 299 may help to apply some routing policies. Besied, implementing the 300 NDT field in the left-most bits means that a single, simple access- 301 control list implemented across all networking devices would be 302 enough to enforce effective traffic segregation. The Locator field 303 is put behind NDT to indicate the region of a certain device. 305 One example is shown in the following figure: 307 IPv6 Prefix 308 +--------+--------+------+-----------------------------------------+ 309 | | FT(000)| NDT | Locator | Network Device bits | 310 +--------+--------+------+-----------------------------------------+ 311 / \ 312 / \ 313 +------------+----+ 314 |000: Network 1 | 315 |001: Network 1 | 316 |010: Network 2 | 317 |011: Network 2 | 318 |100: Network 2 | 319 |101: Network 2 | 320 |110: Network 2 | 321 +-----------------+ 323 Figure 3: NDT Value Example 325 2. Subscriber type (ST) 327 Subscriber type is to indicate different types of subscribers, e.g. 328 wireline broadband subscriber, mobile subscriber, enterprise, WiFi, 329 etc. This type of prefix is allocated to end users. In particular, 330 further divisions can be taken on subscriber's priorities within one 331 type, e.g. golden broadband subscriber, silver broadband subscriber 332 and bronze broadband subscriber. This definition is based on 333 operator's local service model. 335 Here, the Locator will reflect the different regions of a subscriber, 336 and is put before ST for better routing aggregation. 338 One example is shown in the following figure: 340 IPv6 Prefix 341 +--------+--------+---------------+------+-------------------------+ 342 | | FT(011)| Locator | ST | Subscriber bits | 343 +--------+--------+---------------+------+-------------------------+ 344 / \ 345 / \ 346 +----------+------------+--------------------------+ 347 |0000: broadband access subscriber (high priority) | 348 |0001: broadband access subscriber(medium priority)| 349 |0010: broadband access subscriber (low priority) | 350 |0011: broadband access subscriber (low priority) | 351 |0100: mobile subscriber(high priority) | 352 |0101: mobile subscriber (medium priority) | 353 |0110: mobile subscriber (low priority) | 354 |0111: mobile subscriber (low priority) | 355 |1001: enterprise | 356 |1000: enterprise | 357 |1010: WiFi subscriber | 358 |1011: WiFi subscriber | 359 |110-111: Reserved | 360 +--------------------------------------------------+ 362 Figure 4: ST Value Example 364 3. Platform Type(PT) 366 Platform type is to indicate typical service platforms offered by 367 operators. This field may have scalability problem since there are 368 numerous types of services in the further . It is recommended that 369 only aggregated service platform types (e.g. according to service 370 priority) should be defined in this field. This type of prefix is 371 usually allocated to service platforms in operator's data center. 373 One example is shown in the following figure: 375 IPv6 Prefix 376 +--------+--------+---------------+------+-------------------------+ 377 | | FT(001)| Locator | PT | Platform bits | 378 +--------+--------+---------------+------+-------------------------+ 379 / \ 380 / \ 381 +----------+------------+---------------+ 382 |000: high priority service platform | 383 |001: high priority service platform | 384 |001: medium priority service platform | 385 |010: medium priority service platform | 386 |011: medium priority service platform | 387 |100: low priority service platform | 388 |101: low priority service platform | 389 |110~111: reserved | 390 +---------------------------------------+ 392 Figure 5: PT Value Example 394 4. Benifits of Semantic Use Case 396 The following describes a few benifits (and non-exhaustive) of above 397 semantic use case for an operator: 399 1. Easy network device management. With the combinition of FT, NDT 400 and Locator, network devices from different regions can be easily 401 identified. Besides, network-based routing policies can also be 402 enforced with NDT. 404 2. Bi-directional subscriber quality of service guarantee. Since ST 405 is consistent with the overall communication process for a 406 subscriber, bi-directional quality of service guarantee can be 407 easily achieved for cross-region communication. 409 3. Fine-Grained user and service control. Normally, ST is located 410 in the source address of a subscriber, and PT is located in the 411 destination address for upstream traffic. Therefore, with a 412 simple combination of ST and PT, fine-Grained service control can 413 be applied to subscribers (e.g. high priority broadband access 414 subscriber with high priority service platform). 416 4. Service-based Routing. With the definition of ST, different 417 routing policies can be applied according to ST field. 419 Other requirements listed in section one can also be achieved in this 420 use case. 422 5. IANA Considerations 424 This document has no actions for IANA. 426 6. Security Considerations 428 Embedding semantics in prefix is actually exposing more information 429 of packets explicit. These informations may also provide convenient 430 for malicious attackers to track or attack certain type of packets. 431 When networks announce their local prefix semantics to their peer 432 networks, it may increase the vulnerable risk. 434 7. Acknowledgements 436 Authors would like to show sincere appreciation to Erik Nygren, Joel 437 Jaeggli, Owen DeLong for their comments and suggestions. 439 8. References 441 8.1. Normative References 443 [I-D.jiang-semantic-prefix] 444 Jiang, S., Sun, Q., and I. Farrer, "A Framework for 445 Semantic IPv6 Prefix and Gap Analysis", 446 draft-jiang-semantic-prefix-04 (work in progress), 447 January 2013. 449 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 450 August 1980. 452 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 453 E. Lear, "Address Allocation for Private Internets", 454 BCP 5, RFC 1918, February 1996. 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 460 (IPv6) Specification", RFC 2460, December 1998. 462 8.2. Informative References 464 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 465 Extensions", RFC 2132, March 1997. 467 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 468 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 469 RFC 2661, August 1999. 471 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 472 "Remote Authentication Dial In User Service (RADIUS)", 473 RFC 2865, June 2000. 475 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 476 and M. Carney, "Dynamic Host Configuration Protocol for 477 IPv6 (DHCPv6)", RFC 3315, July 2003. 479 Authors' Addresses 481 Chongfeng Xie 482 China Telecom 483 Room 708, No.118, Xizhimennei Street 484 Beijing 100084 485 P.R. China 487 Email: sunqiong@ctbri.com.cn 489 Qiong Sun 490 China Telecom 491 Room 708, No.118, Xizhimennei Street 492 Beijing 100084 493 P.R. China 495 Email: bingxuere@gmail.com 497 Sheng Jiang 498 Huawei Technologies Co., Ltd 499 No.156 Beiqing Road 500 Beijing 100095 501 P.R. China 503 Email: jiangsheng@huawei.com