idnits 2.17.00 (12 Aug 2021) /tmp/idnits17164/draft-jiang-v6ops-semantic-prefix-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 653 has weird spacing: '...Service bits ...' -- The document date (May 28, 2013) is 3279 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC5401' is defined on line 500, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Jiang, Ed. 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Informational Q. Sun 5 Expires: November 29, 2013 China Telecom 6 I. Farrer 7 Deutsche Telekom AG 8 Y. Bo 9 Huawei Technologies Co., Ltd 10 May 28, 2013 12 A Framework for Semantic IPv6 Prefix 13 draft-jiang-v6ops-semantic-prefix-03 15 Abstract 17 This document describes a framework method that network operations 18 may use their addresses. Network operators, who have large IPv6 19 address space, may choose to embedded some semantics into IPv6 20 addresses by assigning additional significance to specific bits 21 within the prefix. By embedded semantics into IPv6 prefixes, the 22 semantics of packets can be inspected easily. Routers and other 23 intermediary devices can easily apply relevant policies as required. 24 Packet-level differentiation can also enable flow-level and user- 25 level differentiation. Consequently, the network operators can 26 accordingly treat network packets differently and efficiently. The 27 management and maintenance of networks can be much simpler. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 29, 2013. 46 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Existing Approaches to Traffic Differentiation . . . . . . . 3 64 2.1. Differentiated Services . . . . . . . . . . . . . . . . . 3 65 2.2. Deep Packet Inspection . . . . . . . . . . . . . . . . . 4 66 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Technical Framework of Semantic IPv6 Prefix . . . . . . . . . 4 68 4.1. Justifcation for Semantics with the IPv6 Prefix . . . . . 5 69 4.2. The Semantic Prefix Domain . . . . . . . . . . . . . . . 6 70 4.3. The Embedded Semantics . . . . . . . . . . . . . . . . . 7 71 4.4. Network Operations Based on Semantic Prefix . . . . . . . 7 72 5. Potential Benefits . . . . . . . . . . . . . . . . . . . . . 8 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 7. Change Log (removed by RFC editor) . . . . . . . . . . . . . 9 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Appendix A. An ISP Semantic Prefix Example . . . . . . . . . . . 11 81 A.1. Function Type Semantic Bits . . . . . . . . . . . . . . . 12 82 A.2. Network Device Type Bits within Network Device Address 83 Space . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 A.3. Subscriber Type Bits within Subscriber Address Space . . 13 85 A.4. Service Platform Type Bits within Service Platform 86 Address Space . . . . . . . . . . . . . . . . . . . . . . 14 87 Appendix B. An Enterprise Semantic Prefix example . . . . . . . 15 88 Appendix C. A Multi-Prefix Semantic example . . . . . . . . . . 16 89 Appendix D. Gaps for complex semantic scenarios . . . . . . . . 17 90 D.1. Semantic Notification in the Network . . . . . . . . . . 17 91 D.2. Semantic Relevant Interactions between Hosts and the 92 Network . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 Appendix E. Topics for Future Work . . . . . . . . . . . . . . . 18 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 As the global Internet expands, it is being used for an increasingly 99 diverse range of services. These services place differentiated 100 requirements upon packet delivery networks meaning that Internet 101 Service Providers and enterprises need to be aware of more 102 information about each packet in order to best meet a specific 103 service's needs. 105 Within a specific prefix, source/destination location information is 106 used for routing decisions. However, user types, service types, 107 applications, security requirements, traffic identity types, quality 108 requirements and other criteria may also be relevant parameters which 109 a network operator may wish to use to treat packets differently and 110 efficiently. Packet-level differentiation can also be used for flow- 111 level and user-level differentiation. 113 However, almost all of the above mentioned criteria are not expressed 114 explicitly within an packet. Hence, it is difficult for network 115 operators to identify from packet level. 117 This informational document only discusses the usage of semantics 118 within a single network, or group of interconnected networks which 119 share a common addressing policy, referred to as a Semantic Prefix 120 Domain. 122 The informational document is NOT intended to suggest the 123 standardization of any common global semantics. 125 2. Existing Approaches to Traffic Differentiation 127 There are several existing approaches which have been developed that 128 can assist operators in identifying and marking traffic. These 129 solutions were mainly developed in the IPv4 era, where the IP address 130 is used as a host locator and little else. The limited capacity of a 131 32-bit IPv4 address provides very little room for encoding additional 132 information. Correspondingly, these approaches are indirect, 133 inefficient and expensive for operators. 135 2.1. Differentiated Services 137 Quality of Service (QoS) based on and Differentiated Services 138 [RFC2474] is a widely deployed framework specifying a simple, 139 scalable and coarse-grained mechanism for classifying and managing 140 network traffic. But in a service provider's network, DiffServ 141 codepoint (DSCP) values cannot be trusted when they are set by the 142 customer as these are arbitrary values. 144 In real-world scenarios, ISPs deploy "remarking" points at the 145 customer edge of their network, re-classifying received packets by 146 rewriting the DSCP field according to local policy using information 147 such as the source/destination address, IP protocol number and 148 transport layer source/destination ports. 150 The traffic classification process leads to increased packet 151 processing overhead and complexity at the edge of the service 152 provider's network. 154 The DSCP in the IPv6 header traffic class field allows 6-bits for 155 encoding service provider specific information related to the 156 contents of the packet. Whilst this is a useful part of an overall 157 packet differentiation architecture, the relative small number of 158 available bits (when compared to the available number of bits within 159 the service providers prefix) means that it cannot be used in 160 isolation. 162 2.2. Deep Packet Inspection 164 Deep Packet Inspection (DPI) may also be used by ISPs to learn the 165 characteristics of users packets. This involves looking into the 166 packet well beyond the network-layer header to identify the specific 167 application traffic type. Once identified, the traffic type can be 168 used as an input for setting the packet's DSCP or other actions. 170 But DPI is expensive both in processing costs and latency. The 171 processing costs means that dedicated infrastructure is necessary to 172 carry out the function. The incurred latency may be too much for use 173 with any delay/jitter sensitive applications. As a result, DPI is 174 difficult for large-scale deployment and it's usage is usually 175 limited to small and specific functions in the network. 177 3. Terminology 179 The following terms are used throughout this document: 181 Semantic Prefix: A flexible-length IPv6 prefix which embeds certain 182 semantics. 184 Semantic Prefix Domain: A portion of the Internet over which a 185 consistent semantic-prefix based policy is in operation. 187 Semantic Prefix Policy: A policy based on the embedded semantics 188 within IPv6 prefix. 190 4. Technical Framework of Semantic IPv6 Prefix 191 The IPv6 address can explicitly express semantics due to its large 192 address space. This can be used by network operators to embed 193 certain pre-defined semantics into an address so that intermediate 194 devices can easily apply relevant forwarding operations each packet 195 based solely on network layer source and destination address 196 information. 198 This document describes a technical framework for embedding semantics 199 into IPv6 prefixes so that network devices can process and forward 200 packets based on these semantics. This approach diverts much network 201 complexity to the planning and management of IPv6 address and IP 202 address based policies. It indeed simplifies the management of ISP 203 networks. 205 A network operator should first carefully plan/design its IPv6 206 address schema, in which useful semantics (see Section 4.3) are 207 embedded into prefix. It then delegates prefixes with correspondent 208 semantics to users. The users generate their IPv6 addresses based on 209 assigned prefixes. Then, when the IPv6 stack on the user devices 210 forms packets, the source addresses comprise compliance semantics. 211 The filters on the edge router drop packets which does not compliant 212 with assigned prefixes. 214 Semantic prefix definitions are only meaningful within a domain which 215 implements a single policy (see Section 4.2). Different service 216 providers may make very different choices regarding the specific 217 semantics which are relevant to their networks. Therefore, it is not 218 possible or desirable to attempt to standardize a general semantic 219 prefix policy. 221 Forwarding policies, security isolation and other network operations 222 (see Section 4.4) can be easily applied according to semantics, which 223 self-expressed by the source address of every packet. Also, the 224 semantics of the destination address may take in account if the 225 destination is in the same Semantic Prefix Domain or the peer 226 Semantic Prefix Domain whose semantics has been notified. 228 4.1. Justifcation for Semantics with the IPv6 Prefix 230 Although the interface identifier portion of an IPv6 address has 231 arbitrary bits and extension headers can carry significantly more 232 information, these fields can not be trusted by network operators. 233 Users may easily change the setting of interface identifier or 234 extension header in order to obtain undeserved priorities/privileges, 235 while servers or enterprise users may be much more self-restricted 236 since they are charged accordingly. 238 Prefix is almost the only thing a network operator can trust in an IP 239 packet. Semantic prefix approach does require the deployment of 240 access control filters. The packets with the noncompliance source 241 addresses should be filtered. The prefix is delegated by the network 242 and therefore the network is able to detect any undesired 243 modifications and filter the packet accordingly. This also makes it 244 possible for the service provider to increase the level of trust in a 245 customer-generated packet. If the packet has an incorrectly set 246 source or destination address, then a session will simply fail to 247 establish. 249 4.2. The Semantic Prefix Domain 251 A Semantic Prefix Domain is analogous to a Differentiated Services 252 Domain [RFC2474]. It can be described as a portion of the Internet 253 over which a consistent set of semantic-prefix-based policies are 254 administered in a coordinated fashion. Some of the characteristics 255 of a single Semantic Prefix Domain could represent include: 257 a. Administrative domains 259 b. Autonomous systems 261 c. Trust regions 263 d. Network technologies 265 e. Hosts 267 f. Routers 269 g. User groups 271 h. Services 273 i. Traffic groups 275 j. Applications 277 An enterprise Semantic Prefix Domain may span several physical 278 networks and traverse ISP networks. However, when an interim network 279 is traversed (such as when an intermediary ISP is used for 280 interconnectivity), the relevance of the semantics is limited to 281 network domains that share a common Semantic Prefix Policy. 283 The selection of semantics vary between different Semantic Prefix 284 Domains. Network operators should choose semantics according to 285 their network and service management needs. If an ISP has several 286 non-contiguous address blocks, they may be organized as a single 287 Semantic Prefix Domain if the same Semantic Prefix Policy is shared 288 across these non-contiguous address blocks. 290 A Semantic Prefix Domain has a set of pre-defined semantic 291 definitions, which are only meaningful locally. Without an efficient 292 semantics notification, exchanging mechanism or service agreement, 293 the definitions of semantics are only meaningful within local 294 Semantic Prefix Domain. Manual interactions between network 295 operators may also work out. However, this may involve trust models 296 among network operators. 298 Sharing semantic definition among Semantic Prefix Domains enables 299 more semantic based network operations. 301 4.3. The Embedded Semantics 303 The size of the operator assigned prefix means that there is 304 potentially much more scope for embedding semantics than has 305 previously been possible. The following list describes some 306 suggested semantics which may be useful to network operators besides 307 source/destination location: 309 a. User types 311 b. Applications 313 c. Security domain 315 d. Traffic identity types 317 e. Quality requirements 319 Consideration must also be given to the complexity that is created 320 within the semantic prefix policy. Whilst it may be desirable to 321 encode as much information within the prefix so that it is possible 322 to have a high level of granularity, this can come at the expense of 323 future addressing flexibility and could also lead to a high amount of 324 address wastage. In the same time, embedding too many semantics may 325 waste addressing space and induce semantic overlap. It should be 326 taken into careful consideration on semantics definition. 328 4.4. Network Operations Based on Semantic Prefix 330 Based on the explicit semantics from the addresses of every packet, 331 many network operations can be applied. Comparing with traditional 332 operations, these operations are easier to realize and stable. 333 Although the detailed operation are various depending on various 334 embedded semantics, the network operations based on semantic prefix 335 can be abstracted into following categories: 337 a. Statistic based on certain semantic. Any embedded semantic can 338 be set as a statistic condition. In other word, any embedded 339 semantic can be measured independently. 341 b. Differentiate packet processing. Many packet processing 342 operations can be applied based on the semantic differentiation, 343 such as queueing, path selection, forwarding to certain process 344 devices, etc. 346 c. Security isolation. A set of packet filters that are based on 347 semantic can fulfil network security isolation. 349 d. Access control. Resource access, authentication, service access 350 can be based on semantic directly. 352 e. Resource allocation. Resources, such as bandwidth, fast queue, 353 cache, etc., can be allocated or reserved for certain semantic 354 users/packets. 356 f. Virtualization. Within a Semantic Prefix Domain, it would be 357 easy to organize a virtual network, in which all the nodes have 358 been assigned same semantic identifier so that the packets from 359 them can be distinguished from other virtual networks. 361 5. Potential Benefits 363 Depending on embedded semantics, various beneficial scenarios can be 364 expected. 366 a. Simplified measurement and statistics gathering: the semantic 367 prefix provides explicit identifiers which can be used for 368 measurement and statistical information collection. This can be 369 achieved by checking certain bits of the source and/or 370 destination address in each packet. 372 b. Simplified flow control: by applying policies according to 373 certain bit values, packets carrying the same semantics in their 374 source/destination addresses can. 376 c. Service segregation: when service related information is encoded 377 within the semantic prefix, this can be used to create simple 378 access-control lists which can be applied uniformly across all 379 network devices. This means that it is easy to 381 d. Policy aggregation: the semantic prefix allows many policies to 382 be aggregated according to the same semantics within the policy 383 based routing system [RFC1104]. 385 e. Easy dynamic reconfiguration of semantic oriented policy: network 386 operators may want to dynamically change the policy actions that 387 are operated on certain semantic packets. The semantic prefix 388 allows such changes be operated easily, as only a small number of 389 consistent policy rules need to be updated on all devices within 390 the semantic prefix domain. 392 f. Application-aware routing: embedding application information into 393 IP addresses is the simplest way to realize application aware 394 routing. 396 g. Easy user behavior management: based on the user type reading 397 from the addresses, any improper user behaviors can be easy 398 detected and automatically handle by network policies. 400 h. Easy network resources access rights management: the 401 authentication of access right may already be embedded into the 402 addresses. Simple matching policies can filter improper access 403 requests. 405 i. Easy virtualization: virtual network based on any semantics can 406 be easily deployed using the semantic prefix mechanism. 408 6. IANA Considerations 410 This document has no IANA considerations. 412 7. Change Log (removed by RFC editor) 414 draft-jiang-v6ops-semantic-prefix-03: reword to emphasis this 415 mechanism is a (not the) method that network operators use their 416 addresses; add text to clarify the increased trust is actually from 417 the deployment of source address filter, which is a compliance 418 requirement by semantic prefix; restructure the document, move 419 examples and gap analysis into appendixes, reorganize most content 420 into a frame section; add summarized description for framework at the 421 beginning of Section 4; add description for network operations based 422 on semantic prefix; add a new coauthor who contributes an enterprise 423 semantic prefix network example; combine most of draft-sun-v6ops- 424 semantic-usecase into the draft as ISP example in appendix; 425 2013-5-28. 427 draft-jiang-v6ops-semantic-prefix-02: add new coauthor, re-organize 428 the content, and refine the English, 2013-1-31. 430 draft-jiang-v6ops-semantic-prefix-01: add the concept of hierarchical 431 Semantic Prefix Domain and more gap analysis, 2012-10-22. 433 draft-jiang-v6ops-semantic-prefix-00: resubmitted to v6ops WG. 434 Removed detailed examples and recommendations for semantics bits, 435 2012-10-15. 437 draft-jiang-semantic-prefix-01: added enterprise considerations and 438 scenarios, emphasizing semantics only for local meaning and no intend 439 to standardize any common global semantics, 2012-07-16. 441 draft-jiang-semantic-prefix-00: original version, 2012-07-09 443 8. Security Considerations 445 Embedding semantics in prefix is actually exposing more information 446 of packets explicit. These informations may also provide convenient 447 for malicious attackers to track or attack certain type of packets. 448 If networks announce their local prefix semantics to their peer 449 networks, it may also increase the vulnerable risk. 451 Prefix-based filters should be deployed, in order to protect against 452 address spoofing attacks or denial of service for packets with forged 453 source addresses. 455 9. Acknowledgements 457 Useful comments were made by Erik Nygren, Nick Hilliard, Ray Hunter, 458 David Farmer, Fred Baker, Joel Jaeggli, John Curran and other 459 participants in the V6OPS working group. 461 10. References 463 10.1. Normative References 465 [RFC1104] Braun, H., "Models of policy based routing", RFC 1104, 466 June 1989. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC2474] Nichols, K., Blake, S., Baker, F., and D.L. Black, 472 "Definition of the Differentiated Services Field (DS 473 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 474 1998. 476 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 477 and M. Carney, "Dynamic Host Configuration Protocol for 478 IPv6 (DHCPv6)", RFC 3315, July 2003. 480 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 481 Host Configuration Protocol (DHCP) version 6", RFC 3633, 482 December 2003. 484 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 485 Architecture", RFC 4291, February 2006. 487 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 488 Address Autoconfiguration", RFC 4862, September 2007. 490 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 491 "Default Address Selection for Internet Protocol Version 6 492 (IPv6)", RFC 6724, September 2012. 494 10.2. Informative References 496 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 497 Socket API for Source Address Selection", RFC 5014, 498 September 2007. 500 [RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker, 501 "Multicast Negative-Acknowledgment (NACK) Building 502 Blocks", RFC 5401, November 2008. 504 Appendix A. An ISP Semantic Prefix Example 506 This ISP semantic prefix example is abstracted from a real ISP 507 address architecture design. 509 Note: for now, this example only covers unicast address within IP 510 Version 6 Addressing Architecture [RFC4291]. 512 For ISPs, several motivations to use semantic prefixes are as 513 follows: 515 a. Network Device management: Separated and specialized address 516 space for network device will help to identify the network device 517 among numerous addresses and apply policy accordingly. 519 b. Differentiated user management: In ISPs' network, different kinds 520 of customers may have different requirements for service 521 provisioning. 523 c. High-priority service guarantee: Different priorities may be 524 divided into apply differentiated policy. 526 d. Service-based Routing: ISPs may offer different routing policy 527 for specific service platforms .e.g.video streaming, VOIP, etc. 529 e. Security Control: For security requirement, operators need to 530 take control and identify of certain devices/customers in a quick 531 manner. 533 f. Easy measurement and statistic: The semantic prefix provides 534 explicit identifiers for measurement and statistic. 536 These requirements are largely falling into two categories: some is 537 regarding to the network device features, and the others are related 538 to services provision and subscriber identification. The functional 539 usage of the semantics for the two categories are quite different. 540 Therefore, an ISP semantic IPv6 prefix example is designed as a two- 541 level hierarchical architecture, in which the first level is the 542 function types of prefixes, and the second level is the further usage 543 within an specific prefix type. 545 A.1. Function Type Semantic Bits 547 Function Type (FT): the value of this field is to indicate the 548 functional usage of this prefix. The typical types for operators 549 include network device, subscriber and service platform. 551 +--------+--------+------------------------------------------------+ 552 | | FT | | 553 +--------+--------+------------------------------------------------+ 554 / \ 555 +------------+------------+ 556 |000: network device | 557 |000~010: service platform| 558 |011~101: subscriber | 559 |110: reserved | 560 +-------------------------+ 562 Function Type Bits Example 564 Figure 1 566 The portion of each type should be estimated according to the actual 567 requirements for operators, in order to use the address space most 568 efficiently. Within the above FT design, the whole ISP IPv6 address 569 space is divided into four parts: the network device address space (1 570 /8 of total address space), the service platform address space (2/8 571 of total address space), the subscriber address space (3/8 of total 572 address space), and a reserved address space (1/8 of total address 573 space) for future usage. 575 A.2. Network Device Type Bits within Network Device Address Space 577 Network Device Type (NDT) indicates different types of network 578 devices. Normally, one operator may have multiple networks, 579 e.g.backbone network, mobile network, ISP brokered service network, 580 etc. Using NDT field to indicate specific network within an operator 581 may help to apply some routing policies. Locating NDT bits in the 582 left-most bits means that a single, simple access- control list 583 implemented across all networking devices would be enough to enforce 584 effective traffic segregation. The Locator field is followed behind 585 NDT. 587 +--------+--------+------+-----------------------------------------+ 588 | | FT(000)| NDT | Locator | Network Device bits | 589 +--------+--------+------+-----------------------------------------+ 590 / \ 591 / \ 592 +------------+-----+ 593 |000~001: SubNet 1| 594 |010~110: SubNet 2| 595 |111: Reserved| 596 +------------------+ 598 Network Device Type Bits Example 600 Figure 2 602 The portion of each subnet type should be estimated according to the 603 actual requirements for operators, in order to use the address space 604 most efficiently. Within the above NDT design, SubNet 1 is assigned 605 2/8 of the network device address space, SubNet 2 is assigned 5/8, 606 and 1/8 is reserved. 608 A.3. Subscriber Type Bits within Subscriber Address Space 610 Subscriber Type (ST) indicates different types of subscribers, e.g. 611 wireline broadband subscriber, mobile subscriber, enterprise, WiFi, 612 etc. This type of prefix is allocated to end users. Further, 613 division may be taken on subscriber's priorities within a certain 614 subscriber type. 616 The Locator field within subscriber address space is put before ST 617 for better routing aggregation. 619 +--------+--------+---------------+------+-------------------------+ 620 | | FT(011)| Locator | ST | Subscriber bits | 621 +--------+--------+---------------+------+-------------------------+ 622 / \ 623 / \ 624 +----------+------------+---------------+ 625 |0000~0011: broadband access subscriber | 626 |0100~0111: mobile subscriber | 627 |1000~1001: enterprise | 628 |1010~1011: WiFi subscriber | 629 |1100~1111: Reserved | 630 +---------------------------------------+ 632 Subscriber Type Bits Example 634 Figure 3 636 The portion of each subscriber type should be estimated according to 637 the actual requirements for operators, in order to use the address 638 space most efficiently. Within the above ST design, the broadband 639 access subscriber type is assigned 4/16 of the subscriber address 640 space, the mobile subscriber is assigned 4/16, enterprise type and 641 WiFi subscriber type are assigned 2/16 each, and 2/16 is reserved. 643 A.4. Service Platform Type Bits within Service Platform Address Space 645 Service Platform Type (SPT) indicates typical service platforms 646 offered by operators. This field may have scalability problem since 647 there are numerous types of services . It is recommended that only 648 aggregated service platform types should be defined in this field. 649 This type of prefix is usually allocated to service platforms in 650 operator's data center. 652 +--------+--------+---------------+------+-------------------------+ 653 | | FT(001)| Locator | SPT | Service bits | 654 +--------+--------+---------------+------+-------------------------+ 655 / \ 656 / \ 657 +----------+------------+---------------+ 658 |000~001: Self-running service platform | 659 |001~011: Tenant service platform | 660 |100~101: Independent service platform | 661 |110~111: Reserved | 662 +---------------------------------------+ 664 Service Platform Type Bits Example 666 Figure 4 668 The portion of each subnet type should be estimated according to the 669 actual requirements for operators, in order to use the address space 670 most efficiently. 672 Appendix B. An Enterprise Semantic Prefix example 674 This enterprise semantic prefix example is also abstracted from an 675 ongoing enterprise address architecture design. This example is 676 designed for a realtime video monitor network across a city region. 677 The semantic prefix solution is planning to be deployed along with a 678 strict authorization system. 680 Note: this example only covers unicast address within IP Version 6 681 Addressing Architecture [RFC4291]. 683 For this example, the below semantics are important for the network 684 operation and require different network behaviors. 686 a. Terminal type: there are two terminal types only: monitor cameras 687 or video receivers. They are estimated to have similar number. 688 Network devices use another different address space. 690 b. Geographic location: the city has been managed in a three-level 691 hierarchical regionalism: district, area and street. Each level 692 has less than 28 sub-regions. This can also be considered as a 693 replacement of topology locator within this specific network. 695 c. Authorization level: the network operator is planning to 696 administrate the authorization in three or four levels. An 697 receiver can access the cameras that are the same or lower 698 authorization level. 700 d. Civilian or police/government. 702 e. Device attribute: this indicates the attribute of a camera 703 device. The attribute is expressed in an abstract way, such as 704 road traffic, hospital, nursery, bank, airport, etc. The 705 abstracted attribute type is designed to be less than 64. 707 f. Receiver Attribute: this indicates the attribute of a video 708 receiver. The attribute is based on the receiver group, such as 709 police, firefighter, local security, etc. The attribute/receiver 710 group type is designed to be less than 128. 712 This example enterprise network has obtained a /32 address block from 713 ISP. There is another /48 dedicated for network devices. 715 The first bit is Terminal type, which indicates terminal type. 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | ISP assigned block | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |T| Geographic Locator | AL|C|Device Attr| Device Bit | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 A semantic prefix design example for cameras 726 Figure 5 728 3-level hierarchical geographic locator takes 15 bits (each level 5 729 bits, 32 sub-regions). Authorization level takes 2 bits and 1 bit 730 differentiates civilian or police/government. 6 bits is assigned for 731 device attribute. 733 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 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | ISP assigned block | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 |T| GeoLoc | AL|C|Receiver Attr| Topology Locator |ReceiverBit| 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 An semantic prefix design example for video receivers 742 Figure 6 744 The receiver is not as much as geographically distributed as cameras. 745 Therefore, Geographic locator is only detailed to district level. 746 Topology locator is needed for network forwarding and aggregation 747 within a district. It is assigned 10 bits. Authorization level bits 748 and civilian bit are the same with camera address space. Receive 749 attribute takes 7 bits, giving it is designed to be up to 128. 751 Appendix C. A Multi-Prefix Semantic example 753 A multiple-site enterprise may have been assigned several prefixes of 754 different lengths by its upstream ISPs. In this situation, in order 755 to create a single, contiguous Semantic Prefix Domain, it is 756 necessary to base the semantic prefix policy on the longest assigned 757 prefix to ensure that there in enough addressing space to encode a 758 consistent set of semantics across all of the assigned prefixes. 760 In this example, an enterprise has received a /38 address block for 761 one site (A) and a /44 for a second site (B) . They can be organized 762 in the same Semantic Prefix Domain. The most-left 18 (site A) and 12 763 (site B) bits are allocated as locator. It provides topology based 764 network aggregation. The 8 right-most bits (from bits 56 to 63) are 765 assigned as the semantic field. In this design, the multiple-site 766 enterprise that has been assigned two prefixes of different lengths 767 can be organized as the same Semantic Prefix Domain. The semantic 768 and the Semantic Prefix Domain can traverse the intermediate ISP 769 networks, or even public networks. 771 The similar situation may happen on ISPs in the future, when an ISP 772 used up its assigned address space, or built up multiple networks in 773 different places. 775 Appendix D. Gaps for complex semantic scenarios 777 The simplest semantic prefix model is to embed only abstracted user 778 type semantics into the prefix. Current network architectures can 779 support this as each subscriber is still assigned a single prefix, 780 while they are not notified the semantic within it. 782 In order to maximise the benefits of the semantic prefix design, 783 additional functions are needed to allow semantic relevant operations 784 in networks and semantic relevant interactions with hosts. 786 IPv6 provides a facility for multiple addresses to be configured on a 787 single interface. This creates a precondition for the approach that 788 user chooses addresses differently for different purposes/usages. 790 D.1. Semantic Notification in the Network 792 In order to manage semantic prefixes and their relevant network 793 actions, the network should be able to notify semantics along with 794 prefix delegation. 796 When an prefix is delegated using a DHCPv6 IA_PD [RFC3633], the 797 associated semantics should also be propagated to the requesting 798 router. This is particularly useful for autonomic process when a new 799 device is connected. 801 D.2. Semantic Relevant Interactions between Hosts and the Network 803 The more that semantics are embedded into a prefix, the more that 804 complicated functions are needed for semantic relevant interactions 805 between hosts and the network, such as prefix delegation, host 806 notification and address selections, etc. 808 In practice, a single host may belong to multiple semantics. This 809 means that several IPv6 addresses are configured on a single physical 810 interface and should be selected for use depending on the service 811 that a host wishes to access. A certain packet would only serve a 812 certain semantic. 814 The host's IPv6 stack must have a mechanism for understanding these 815 semantics in order to choose right source address when forming a 816 packet. If the embedded semantic is application relevant, 817 applications on the hosts should also be involved in the address 818 choosing process: the host IPv6 stack reports multiple available 819 addresses to the application through socket API (one example is "IPv6 820 Socket API for Source Address Selection" [RFC5014]). The application 821 then needs to apply the semantic logic so that it can correctly 822 select from the offered candidate addresses. 824 Although [RFC6724] provides an algorithm for source address 825 selection, some semantic prefix policies may conflict with this 826 algorithm. In this case, the source address selection mechanism may 827 also further supporting functions to be developed. 829 Appendix E. Topics for Future Work 831 There are several areas in which the semantic prefix could be 832 extended in order to increase the usefulness and applicability of the 833 concept. They are complementarity besides the main framework. These 834 are being described here as topics for possible future work. Each of 835 them may deserve a separated document for technical details. 837 - Dynamic Policy Configuration 839 Dynamic policy configuration would simplify the distribution of 840 policy across devices in the semantic prefix domain. New functions 841 or protocol extension are needed to enable dynamic changes to the 842 policy actions in operation on certain semantic packets. 844 - Semantics Announcements to peer networks 846 A network may announce all, or some of its Semantic Prefix Policy to 847 connected peer networks. This could be used to enable more dynamic 848 configuration and enable traffic from different semantic prefix 849 domains to traverse different networks whilst having the same 850 semantic prefix policy applied. To achieve this automatically by 851 message exchanging would require new functions or protocol 852 extensions. 854 - Extension of Prefix Semantics beyond the left-most 64-bits 856 The prefix concept refers here to the left-most bits in the IP 857 addresses delegated by the network management plane. The prefix 858 could be longer than 64-bits if the network operators strictly manage 859 the address assignment by using Dynamic Host Configuration Protocol 860 for IPv6 (DHCPv6) [RFC3315] (but in this case standard StateLess 861 Address AutoConfiguration - SLAAC [RFC4862] cannot be used). 863 Authors' Addresses 865 Sheng Jiang (editor) 866 Huawei Technologies Co., Ltd 867 Q14, Huawei Campus, No.156 BeiQing Road 868 Hai-Dian District, Beijing 100095 869 P.R. China 871 Email: jiangsheng@huawei.com 873 Qiong Sun 874 China Telecom 875 Room 708, No.118, Xizhimennei Street 876 Beijing 100084 877 P.R. China 879 Email: sunqiong@ctbri.com.cn 881 Ian Farrer 882 Deutsche Telekom AG 883 Bonn 53227 884 Germany 886 Email: ian.farrer@telekom.de 888 Yang Bo 889 Huawei Technologies Co., Ltd 890 Q21, Huawei Campus, No.156 BeiQing Road 891 Hai-Dian District, Beijing 100095 892 P.R. China 894 Email: boyang.bo@huawei.com