idnits 2.17.1 draft-jiang-v6ops-semantic-prefix-04.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 -- The document date (July 15, 2013) is 3939 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: January 16, 2014 China Telecom 6 I. Farrer 7 Deutsche Telekom AG 8 Y. Bo 9 Huawei Technologies Co., Ltd 10 T. Yang 11 China Mobile 12 July 15, 2013 14 Analysis of Semantic Embedded IPv6 Address Schemas 15 draft-jiang-v6ops-semantic-prefix-04 17 Abstract 19 This informational document discusses the use of embedded semantics 20 within IPv6 address schemas. Network operators who have large IPv6 21 address space may choose to embed some semantics into their IPv6 22 addressing by assigning additional significance to specific bits 23 within the prefix. By embedding semantics into IPv6 prefixes, the 24 semantics of packets can be easily inspected. This can simplify the 25 packet differentiation process. However, semantic embedded IPv6 26 address schemas have their own operational cost and even potential 27 pitfalls. Some complex semantic embedded IPv6 address schemas may 28 also require new technologies in addition to existing Internet 29 protocols. 31 The document aims to understand the usage of semantic embedded IPv6 32 address schemas, and neutrally analyze on the associated advantages, 33 drawbacks and technical gaps for more complex address schemas. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 16, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Understanding of Semantic IPv6 Prefix Address Schema . . . . 4 71 3.1. Overview of Semantic IPv6 Prefix Address Schema . . . . . 4 72 3.2. Existing Approaches to Traffic Differentiation . . . . . 5 73 3.3. Justification for Semantics with the IPv6 Prefix . . . . 6 74 3.4. The Semantic Prefix Domain . . . . . . . . . . . . . . . 7 75 3.5. The Embedded Semantics . . . . . . . . . . . . . . . . . 8 76 3.6. Network Operations Based on Semantic Prefixes . . . . . . 8 77 4. Potential Benefits . . . . . . . . . . . . . . . . . . . . . 9 78 5. Potential Drawbacks . . . . . . . . . . . . . . . . . . . . . 10 79 6. Gaps for complex semantic prefix scenarios . . . . . . . . . 11 80 6.1. Semantic Notification in the Network . . . . . . . . . . 11 81 6.2. Semantic Relevant Interactions between Hosts and the 82 Network . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 6.3. Additional Technical Extensions . . . . . . . . . . . . . 12 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 85 8. Change Log (removed by RFC editor) . . . . . . . . . . . . . 13 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 90 11.2. Informative References . . . . . . . . . . . . . . . . . 15 91 Appendix A. An ISP Semantic Prefix Example . . . . . . . . . . . 15 92 A.1. Function Type Semantic Bits . . . . . . . . . . . . . . . 16 93 A.2. Network Device Type Bits within Network Device Address 94 Space . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 A.3. Subscriber Type Bits within Subscriber Address Space . . 17 96 A.4. Service Platform Type Bits within Service Platform 97 Address Space . . . . . . . . . . . . . . . . . . . . . . 18 98 Appendix B. An Enterprise Semantic Prefix example . . . . . . . 19 99 Appendix C. A Multi-Prefix Semantic example . . . . . . . . . . 20 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 102 1. Introduction 104 As the global Internet expands, it is being used for an increasingly 105 diverse range of services. These services place differentiated 106 requirements upon packet delivery networks meaning that Internet 107 Service Providers and enterprises need to be aware of more 108 information about each packet in order to best meet a specific 109 service's needs. Dividing a network into different subnets according 110 to different semantics is already widely existing today, mostly 111 motivated by either topological aspects, logical user/device groups, 112 and/or trust/security domains. 114 In order to inspect the semantics of packets so that they can be 115 treated differently, some network operators have chosen to embed 116 semantics into IPv6 prefixes. Routers and other intermediary devices 117 can easily apply relevant policies as required. User types, service 118 types, applications, security requirements, traffic identity types, 119 quality requirements and other criteria may be used according to how 120 a network operator may want to differentiate its services. Packet- 121 level differentiation can also enable flow-level and user-level 122 differentiation. Consequently, the network operators can treat 123 network packets differently and efficiently. It is believed this 124 mechanism can simplify the management and maintenance of networks. 126 However, semantic embedded IPv6 address schemas come with their own 127 operational cost and even pitfalls. Some complex semantic embedded 128 IPv6 address schemas may also require technologies additional to 129 existing Internet protocols. 131 While network operators, who already have large IPv6 address space 132 allocations, are free to plan and deploy addressing in their 133 preferred way (including semantic embedded IPv6 address schemas), it 134 is useful to analyze the benefits and drawbacks of a semantic 135 approach to addressing. 137 The document only discusses the usage of semantics within a single 138 network, or group of interconnected networks which share a common 139 addressing policy, referred to as a Semantic Prefix Domain. 141 This document does not intend to suggest the standardization of any 142 common global semantics. It does not intend to draw any conclusions, 143 either recommending this kind of address schemas or not. It aims to 144 provide network operators with relevant information to use in the 145 creation of their own addressing policy. 147 2. Terminology 149 The following terms are used throughout this document: 151 Semantic Prefix: A flexible-length IPv6 prefix which embeds certain 152 semantics. 154 Semantic Prefix Domain: A portion of the Internet over which a 155 consistent semantic-prefix based policy is in operation. 157 Semantic Prefix Policy: A policy based on the embedded semantics 158 within IPv6 prefix. 160 3. Understanding of Semantic IPv6 Prefix Address Schema 162 Some network operators (either ISPs or enterprise network operators), 163 who have large IPv6 address space, have chosen to embed certain pre- 164 defined semantics into their IPv6 address schemas by assigning 165 additional significance to specific bits within the prefix. The IPv6 166 addresses of each packet can then explicitly express semantics. 167 Consequently, intermediate devices can easily apply relevant packet 168 differentiating operations accordingly. This mechanism may divert 169 much network complexity to the planning and management of IPv6 170 addressing and IP address based policies. 172 For illustrations of how semantic prefixes could be applied in real- 173 world scenarios, Appendix A describes an ISP example semantic IPv6 174 prefix address schema; Appendix B introduces an enterprise semantic 175 IPv6 prefix example; and Appendix C introduces an enterprise example 176 in which a multiple-site enterprise network with several prefixes of 177 different lengths is organized as a single, contiguous Semantic 178 Prefix Domain. 180 3.1. Overview of Semantic IPv6 Prefix Address Schema 181 A network operator first plans their IPv6 address schema, in which 182 useful semantics (see Section 3.5) are embedded into prefix. They 183 then delegate prefixes with the corresponding semantics to users. 184 The users generate their IPv6 addresses based on assigned prefixes. 185 Then, when the IPv6 stack on the user devices forms packets, the 186 source addresses comprise compliance semantics. For trust reasons, 187 the filters on the edge router may drop packets which are not 188 compliant with assigned prefixes. 190 The embedded semantics are only meaningful within a network domain 191 which implements a single policy (see Section 3.4). Different 192 service providers may make very different choices regarding the 193 specific semantics which are relevant to their networks. Therefore, 194 it is not possible or even desirable to attempt to standardize a 195 general semantic prefix policy. 197 Forwarding policies, access control lists, policy-based routing, 198 security isolation and other network operations (see Section 3.6) can 199 be easily applied according to semantics, which are self-expressed by 200 the source address of every packet. Also, the semantics of the 201 destination address may be taken in account if the destination is in 202 the same Semantic Prefix Domain or the peer Semantic Prefix Domain 203 whose semantics has been notified. 205 3.2. Existing Approaches to Traffic Differentiation 207 There are several existing approaches which have been developed that 208 can assist operators in identifying and marking traffic. These 209 solutions were mainly developed in the IPv4 era, where the IP address 210 is used as a host locator and little else. The limited capacity of a 211 32-bit IPv4 address provides very little room for encoding additional 212 information. Correspondingly, these approaches are indirect, 213 inefficient and expensive for operators. 215 3.2.1. Differentiated Services 217 Quality of Service (QoS) based on and Differentiated Services 218 [RFC2474] is a widely deployed framework specifying a simple and 219 scalable coarse-grained mechanism for classifying and managing 220 network traffic. But in a service provider's network, DiffServ 221 codepoint (DSCP) values cannot be trusted when they are set by the 222 customer as these are arbitrary values. 224 In real-world scenarios, ISPs deploy "remarking" points at the 225 customer edge of their network, re-classifying received packets by 226 rewriting the DSCP field according to local policy using information 227 such as the source/destination address, IP protocol number and 228 transport layer source/destination ports. 230 The traffic classification process leads to increased packet 231 processing overhead and complexity at the edge of the service 232 provider's network. 234 DSCP mechanism abstracts all the semantics into a single-dimension 235 service classes. This abstract processing has lost a lot of semantic 236 information, which providers want to inspect for every packet, then 237 process the packet accordingly. 239 The DSCP in the IPv6 header traffic class field allows 6-bits for 240 encoding service provider specific information related to the 241 contents of the packet. Whilst this is a useful part of an overall 242 packet differentiation architecture, the relative small number of 243 available bits (when compared to the available number of bits within 244 the service providers prefix) means that it cannot be used in 245 isolation. 247 3.2.2. Deep Packet Inspection 249 Deep Packet Inspection (DPI) may also be used by ISPs to learn the 250 characteristics of users packets. This involves looking into the 251 packet well beyond the network-layer header to identify the specific 252 application traffic type. Once identified, the traffic type can be 253 used as an input for setting the packet's DSCP or other actions. 255 But DPI is expensive both in processing costs and latency. The 256 processing costs means that dedicated infrastructure is necessary to 257 carry out the function. The incurred latency may be too much for use 258 with any delay/jitter sensitive applications. As a result, DPI is 259 difficult for large-scale deployment and it's usage is usually 260 limited to small and specific functions in the network. In short, it 261 is not scalable, and cannot support realtime network operations. 263 3.3. Justification for Semantics with the IPv6 Prefix 265 Although the interface identifier portion of an IPv6 address has 266 arbitrary bits and extension headers can carry significantly more 267 information, these fields can not be trusted by network operators. 268 Users may easily change the setting of interface identifier or 269 extension headers in order to obtain undeserved priorities/ 270 privileges, while servers or enterprise users may be much more self- 271 restricted since they are charged accordingly. 273 With proper access control filters deployed, the prefix can be 274 trusted by the network operators and is simple to inspect in the IP 275 header of a packet. The packets with the noncompliance source 276 addresses should be filtered. The prefix is delegated by the network 277 and therefore the network is able to detect any undesired 278 modifications and filter the packet accordingly. This also makes it 279 possible for the service provider to increase the level of trust in a 280 customer-generated packet. If the packet has an source or 281 destination address which is outside of the network operator's policy 282 then a session will simply fail to establish. 284 3.4. The Semantic Prefix Domain 286 A Semantic Prefix Domain is a portion of the Internet over which a 287 consistent set of semantic-prefix-based policies are administered in 288 a coordinated fashion. It is analogous to a Differentiated Services 289 Domain [RFC2474]. Some of the characteristics that a single Semantic 290 Prefix Domain could represent include: 292 a. Administrative domains 294 b. Autonomous systems 296 c. Trust regions 298 d. Network technologies 300 e. Hosts 302 f. Routers 304 g. User groups 306 h. Services 308 i. Traffic groups 310 j. Applications 312 A Semantic Prefix Domain has a set of pre-defined semantic 313 definitions, which are only meaningful locally. Without an efficient 314 semantics notification, exchanging mechanism or service agreement, 315 the definitions of semantics are only meaningful within local 316 Semantic Prefix Domain. Agreements on definitions between network 317 operators could be made. However, this may involve trust models 318 among network operators. Sharing semantic definition among Semantic 319 Prefix Domains enables more semantic based network operations. 321 An enterprise Semantic Prefix Domain may span several physical 322 networks and traverse ISP networks. However, when an interim network 323 is traversed (such as when an intermediary ISP is used for 324 interconnectivity), the relevance of the semantics is limited to 325 network domains that share a common Semantic Prefix Policy. 327 If an ISP has several non-contiguous address blocks, they may be 328 organized as a single Semantic Prefix Domain if the same Semantic 329 Prefix Policy is shared across these non-contiguous address blocks. 331 3.5. The Embedded Semantics 333 The size of the operator assigned prefix means that there is 334 potentially much more scope for embedding semantics than has 335 previously been possible. The following list describes some 336 suggested semantics which may be useful to network operators besides 337 source/destination location: 339 a. User types 341 b. Applications 343 c. Security domain 345 d. Traffic identity types 347 e. Quality requirements 349 f. Geo-location 351 The selection of semantics varies among different network operators. 352 They may choose one or more semantics to be embedded into their IPv6 353 address schemas, depending on what is important for them and what may 354 trigger packet differentiation processes in their networks. The 355 selection criterion and the impact of each choice are out of scope of 356 this document. 358 3.6. Network Operations Based on Semantic Prefixes 360 From the explicit semantics contained within the addresses of each 361 packet, many network operations can be applied. Compared with 362 traditional operations, these operations are easier to realize and 363 stable. Although detailed operation vary depending on various 364 embedded semantics, the network operations based on semantic prefix 365 can be abstracted into following categories: 367 a. Statistic based on certain semantic. Any embedded semantic can 368 be set as a statistic condition. In other words, any embedded 369 semantic can be measured independently. 371 b. Differentiate packet processing. Many packet processing 372 operations can be applied based on the semantic differentiation, 373 such as queueing, path selection, forwarding to certain process 374 devices, etc. 376 c. Security isolation. A set of packet filters that are based on 377 semantic can fulfil network security isolation. 379 d. Access control. Resource access, authentication, service access 380 can be directly based on semantics. 382 e. Resource allocation. Resources, such as bandwidth, fast queue, 383 caching, etc., can be allocated or reserved for certain semantic 384 users/packets. 386 f. Virtualization. Within a Semantic Prefix Domain, organizing 387 virtual networks is simplified by assigning all the nodes the 388 same semantic identifier so that the packets from them can be 389 distinguished from other virtual networks. 391 It should also be noticed that these operations do not have to be 392 processed on the same single device. They may be separated among 393 network devices. In other words, if there are multiple semantics in 394 a Semantics Prefix Domain, various semantics may be understood and 395 treated on different network devices. It is not necessary for all 396 network devices in such domain to capable of understanding all 397 semantics. 399 4. Potential Benefits 401 Depending on various embedded semantics, different beneficial 402 scenarios can be expected. 404 a. Semantic prefix address schema provides a directly and explicitly 405 mechanism for packet inspection. It improves the inspecting 406 efficiency on IPv6 network devices. 408 b. Simplified measurement and statistics gathering: the semantic 409 prefix provides explicit identifiers which can be used for 410 measurement and statistical information collection. This can be 411 achieved by checking certain bits of the source and/or 412 destination address in each packet. 414 c. Simplified flow control: by applying policies according to 415 certain bit values, packets carrying the same semantics in their 416 source/destination addresses can. 418 d. Service segregation: when service related information is encoded 419 within the semantic prefix, this can be used to create simple 420 access-control lists which can be applied uniformly across all 421 network devices. Security zones are such typical services that 422 need to be segregated. 424 e. Policy aggregation: the semantic prefix allows many policies to 425 be aggregated according to the same semantics within the policy 426 based routing system [RFC1104]. 428 f. Easy dynamic reconfiguration of semantic oriented policy: network 429 operators may want to dynamically change the policy actions that 430 are operated on certain semantic packets. The semantic prefix 431 allows such changes be operated easily, as only a small number of 432 consistent policy rules need to be updated on all devices within 433 the semantic prefix domain. 435 g. Application-aware routing: embedding application information into 436 IP addresses is the simplest way to realize application aware 437 routing. 439 h. Easy user behavior management: based on the user type reading 440 from the addresses, any improper user behaviors can be easy 441 detected and automatically handle by network policies. 443 i. Easy network resources access rights management: the 444 authentication of access right may already be embedded into the 445 addresses. Simple matching policies can filter improper access 446 requests. 448 j. Easy virtualization: virtual network based on any semantics can 449 be easily deployed using the semantic prefix mechanism. 451 5. Potential Drawbacks 453 a. Address consumption caused by lower address utility rate. 454 Embedding semantics into IPv6 addresses causes the network to use 455 more of the address space that it normally would. The wastage 456 comes from aligning. 1) A small addressing requirement for a 457 separate type may get the same large address space as a large 458 addressing requirement. 2) The number of types in each semantic 459 has to align to 2^n, for example, 5 types uses to take 3 bits in 460 the prefix. 462 Network operators should be aware they may not get more addresses 463 because they have allocated their assigned address block(s) for 464 semantic use without the addresses actually being in use - 465 leading to a lower address utility rate. Although the current 466 Regional Internet Registry (RIR) policies do not disallow such 467 address usage, such usage has not been taken into account in 468 calculating reasonable addressing quotients. 470 b. Complexity that is created within the semantic prefix policy. 471 Encoding too many semantics into prefixes can come at the expense 472 of future addressing flexibility. At the same time, embedding 473 too many semantics may induce semantic overlap. Careful 474 consideration should be taken with semantics definition. 476 c. The risk of privacy/information leakage. The semantics in the 477 address may be guessable, or leaked to outside the organisation. 478 Therefore, some information of either subscribers or networks may 479 be leaked, too. 481 d. Burdening the host OS. In some complex semantic prefix 482 scenarios, the semantics prefix mechanism puts extra burden on 483 the originator. In such scenarios, host devices are given 484 multiple IPv6 prefixes and required to choose correctly. When 485 forming a packet, the originator of packets (normally the host 486 OS) has to pick the right address/prefix according to the 487 semantics to access a service. 489 e. In order to perform policies based on trusted user/prefix, tight/ 490 strict access control filter linked with prefix assignment is 491 requested. It is the filter who makes sure the prefix right. 492 The filter should link back to other states of the user, like 493 user authentication, etc, in order to match the packet to its 494 properties and check whether it is mapped to right semantics or 495 not. 497 6. Gaps for complex semantic prefix scenarios 499 The simplest semantic prefix model is to embed only abstracted user 500 type semantics into the prefix. Current network architectures can 501 support this semantic prefix model, in which each subscriber is still 502 assigned a single prefix, while they are not notified the semantic 503 embedded in the prefix. 505 In order to fulfill more benefits of the semantic prefix design, 506 additional functions are needed to allow semantic relevant operations 507 in networks and semantic relevant interactions with hosts. 509 IPv6 provides a facility for multiple addresses to be configured on a 510 single interface. This creates a precondition for the approach that 511 user chooses addresses differently for different purposes/usages. 513 6.1. Semantic Notification in the Network 515 In order to manage semantic prefixes and their relevant network 516 actions, the network should be able to notify semantics along with 517 prefix delegation. 519 When an prefix is delegated using a DHCPv6 IA_PD [RFC3633], the 520 associated semantics should also be propagated to the requesting 521 router. This is particularly useful for autonomic process when a new 522 device is connected. 524 6.2. Semantic Relevant Interactions between Hosts and the Network 526 The more that semantics are embedded into a prefix, the more 527 complicated functions are needed for semantic relevant interactions 528 between hosts and the network, such as prefix delegation, host 529 notification, address selections, etc. 531 In practice, a single host may belong to multiple semantics. This 532 means that several IPv6 addresses are configured on a single physical 533 interface and should be selected for use depending on the service 534 that a host wishes to access. A certain packet would only serve a 535 certain semantic. 537 The host's IPv6 stack must have a mechanism for understanding these 538 semantics in order to select the right source address when forming a 539 packet. If the embedded semantic is application relevant, 540 applications on the hosts should also be involved in the address 541 choosing process: the host IPv6 stack reports multiple available 542 addresses to the application through socket API (one example is "IPv6 543 Socket API for Source Address Selection" [RFC5014]). The application 544 then needs to apply the semantic logic so that it can correctly 545 select from the offered candidate addresses. 547 Although [RFC6724] provides an algorithm for source address 548 selection, some semantic prefix policies may conflict with this 549 algorithm. In this case, source address selection mechanisms may 550 need further supporting functions to be developed. 552 6.3. Additional Technical Extensions 554 There are several areas in which the semantic prefix could be 555 extended in order to increase the usefulness and applicability of the 556 semantic prefix address schema. They are listed here for future 557 study. Currently, their feasibility, usefulness and applicability 558 are not carefully studied yet. 560 - Dynamic Policy Configuration 562 Dynamic policy configuration would simplify the distribution of 563 policy across devices in the semantic prefix domain. New functions 564 or protocol extension are needed to enable dynamic changes to the 565 policy actions in operation on certain semantic packets. 567 - Semantics Announcements to peer networks 569 A network may announce all, or some of its Semantic Prefix Policy to 570 connected peer networks. This could be used to enable more dynamic 571 configuration and enable traffic from different semantic prefix 572 domains to traverse different networks whilst having the same 573 semantic prefix policy applied. To achieve this automatically by 574 message exchanging would require new functions or protocol 575 extensions. 577 - Extension of Prefix Semantics beyond the left-most 64 bits 579 The prefix concept refers here to the left-most bits in the IP 580 addresses delegated by the network management plane. The prefix 581 could be longer than 64-bits if the network operators strictly manage 582 the address assignment by using Dynamic Host Configuration Protocol 583 for IPv6 (DHCPv6) [RFC3315] (but in this case standard StateLess 584 Address AutoConfiguration - SLAAC [RFC4862] cannot be used). 586 - Organizing consumer/home networks according to semantics 588 Consumers or subscribers are currently assigned /48 or /56 prefixes. 589 They have bits, which may also count the right-most 64 bits too, to 590 organize their networks into subnets. These subnets may be organized 591 according to some semantics that are meaningful for the user himself. 592 In such scenario, the user acts as the network operator for his own 593 network. Some additional tecnologies/functions may be needed to make 594 such organizing and follow-up management efficient. 596 7. IANA Considerations 598 This document has no IANA considerations. 600 8. Change Log (removed by RFC editor) 602 draft-jiang-v6ops-semantic-prefix-04: add new pitfalls section; 603 restructure to be a neatrul analysis document; 2013-07-15. 605 draft-jiang-v6ops-semantic-prefix-03: reword to emphasis this 606 mechanism is a (not the) method that network operators use their 607 addresses; add text to clarify the increased trust is actually from 608 the deployment of source address filter, which is a compliance 609 requirement by semantic prefix; restructure the document, move 610 examples and gap analysis into appendixes, reorganize most content 611 into a frame section; add summarized description for framework at the 612 beginning of Section 3; add description for network operations based 613 on semantic prefix; add a new coauthor who contributes an enterprise 614 semantic prefix network example; combine most of draft-sun-v6ops- 615 semantic-usecase into the draft as ISP example in appendix; 616 2013-5-28. 618 draft-jiang-v6ops-semantic-prefix-02: add new coauthor, re-organize 619 the content, and refine the English, 2013-1-31. 621 draft-jiang-v6ops-semantic-prefix-01: add the concept of hierarchical 622 Semantic Prefix Domain and more gap analysis, 2012-10-22. 624 draft-jiang-v6ops-semantic-prefix-00: resubmitted to v6ops WG. 625 Removed detailed examples and recommendations for semantics bits, 626 2012-10-15. 628 draft-jiang-semantic-prefix-01: added enterprise considerations and 629 scenarios, emphasizing semantics only for local meaning and no intend 630 to standardize any common global semantics, 2012-07-16. 632 draft-jiang-semantic-prefix-00: original version, 2012-07-09 634 9. Security Considerations 636 Embedding semantics in prefix is actually exposing more information 637 of packets explicit. These informations may also provide convenient 638 for malicious attackers to track or attack certain type of packets. 639 If networks announce their local prefix semantics to their peer 640 networks, it may also increase the vulnerable risk. 642 Prefix-based filters should be deployed, in order to protect against 643 address spoofing attacks or denial of service for packets with forged 644 source addresses. 646 10. Acknowledgements 648 Useful comments were made by Erik Nygren, Dan Wing, Nick Hilliard, 649 Ray Hunter, David Farmer, Fred Baker, Joel Jaeggli, John Curran, Tim 650 Chown, Ted Lemon, Owen DeLong, Lorenzo Colitti, George Michaelson, 651 Joel Halpern, Vizdal Ales, Bless Roland, Manning Bill, Manfred Albert 652 and other participants in the V6OPS working group. 654 11. References 656 11.1. Normative References 658 [RFC1104] Braun, H., "Models of policy based routing", RFC 1104, 659 June 1989. 661 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 662 "Definition of the Differentiated Services Field (DS 663 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 664 1998. 666 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 667 and M. Carney, "Dynamic Host Configuration Protocol for 668 IPv6 (DHCPv6)", RFC 3315, July 2003. 670 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 671 Host Configuration Protocol (DHCP) version 6", RFC 3633, 672 December 2003. 674 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 675 Architecture", RFC 4291, February 2006. 677 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 678 Address Autoconfiguration", RFC 4862, September 2007. 680 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 681 "Default Address Selection for Internet Protocol Version 6 682 (IPv6)", RFC 6724, September 2012. 684 11.2. Informative References 686 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 687 Socket API for Source Address Selection", RFC 5014, 688 September 2007. 690 Appendix A. An ISP Semantic Prefix Example 692 This ISP semantic prefix example is abstracted from a real ISP 693 address architecture design. 695 Note: for now, this example only covers unicast address within IP 696 Version 6 Addressing Architecture [RFC4291]. 698 For ISPs, several motivations to use semantic prefixes are as 699 follows: 701 a. Network Device management: Separated and specialized address 702 space for network device will help to identify the network device 703 among numerous addresses and apply policy accordingly. 705 b. Differentiated user management: In ISPs' network, different kinds 706 of customers may have different requirements for service 707 provisioning. 709 c. High-priority service guarantee: Different priorities may be 710 divided into apply differentiated policy. 712 d. Service-based Routing: ISPs may offer different routing policy 713 for specific service platforms .e.g.video streaming, VOIP, etc. 715 e. Security Control: For security requirement, operators need to 716 take control and identify of certain devices/customers in a quick 717 manner. 719 f. Easy measurement and statistic: The semantic prefix provides 720 explicit identifiers for measurement and statistic. 722 These requirements are largely falling into two categories: some is 723 regarding to the network device features, and the others are related 724 to services provision and subscriber identification. The functional 725 usage of the semantics for the two categories are quite different. 726 Therefore, an ISP semantic IPv6 prefix example is designed as a two- 727 level hierarchical architecture, in which the first level is the 728 function types of prefixes, and the second level is the further usage 729 within an specific prefix type. 731 A.1. Function Type Semantic Bits 733 Function Type (FT): the value of this field is to indicate the 734 functional usage of this prefix. The typical types for operators 735 include network device, subscriber and service platform. 737 +--------+--------+------------------------------------------------+ 738 | | FT | | 739 +--------+--------+------------------------------------------------+ 740 / \ 741 +------------+------------+ 742 |000: network device | 743 |000~010: service platform| 744 |011~101: subscriber | 745 |110: reserved | 746 +-------------------------+ 748 Function Type Bits Example 750 Figure 1 752 The portion of each type should be estimated according to the actual 753 requirements for operators, in order to use the address space most 754 efficiently. Within the above FT design, the whole ISP IPv6 address 755 space is divided into four parts: the network device address space (1 756 /8 of total address space), the service platform address space (2/8 757 of total address space), the subscriber address space (3/8 of total 758 address space), and a reserved address space (1/8 of total address 759 space) for future usage. 761 A.2. Network Device Type Bits within Network Device Address Space 763 Network Device Type (NDT) indicates different types of network 764 devices. Normally, one operator may have multiple networks, 765 e.g.backbone network, mobile network, ISP brokered service network, 766 etc. Using NDT field to indicate specific network within an operator 767 may help to apply some routing policies. Locating NDT bits in the 768 left-most bits means that a single, simple access- control list 769 implemented across all networking devices would be enough to enforce 770 effective traffic segregation. The Locator field is followed behind 771 NDT. 773 +--------+--------+------+-----------------------------------------+ 774 | | FT(000)| NDT | Locator | Network Device bits | 775 +--------+--------+------+-----------------------------------------+ 776 / \ 777 / \ 778 +------------+-----+ 779 |000~001: SubNet 1| 780 |010~110: SubNet 2| 781 |111: Reserved| 782 +------------------+ 784 Network Device Type Bits Example 786 Figure 2 788 The portion of each subnet type should be estimated according to the 789 actual requirements for operators, in order to use the address space 790 most efficiently. Within the above NDT design, SubNet 1 is assigned 791 2/8 of the network device address space, SubNet 2 is assigned 5/8, 792 and 1/8 is reserved. 794 A.3. Subscriber Type Bits within Subscriber Address Space 796 Subscriber Type (ST) indicates different types of subscribers, e.g. 797 wireline broadband subscriber, mobile subscriber, enterprise, WiFi, 798 etc. This type of prefix is allocated to end users. Further, 799 division may be taken on subscriber's priorities within a certain 800 subscriber type. 802 The Locator field within subscriber address space is put before ST 803 for better routing aggregation. 805 +--------+--------+---------------+------+-------------------------+ 806 | | FT(011)| Locator | ST | Subscriber bits | 807 +--------+--------+---------------+------+-------------------------+ 808 / \ 810 / \ 811 +----------+------------+---------------+ 812 |0000~0011: broadband access subscriber | 813 |0100~0111: mobile subscriber | 814 |1000~1001: enterprise | 815 |1010~1011: WiFi subscriber | 816 |1100~1111: Reserved | 817 +---------------------------------------+ 819 Subscriber Type Bits Example 821 Figure 3 823 The portion of each subscriber type should be estimated according to 824 the actual requirements for operators, in order to use the address 825 space most efficiently. Within the above ST design, the broadband 826 access subscriber type is assigned 4/16 of the subscriber address 827 space, the mobile subscriber is assigned 4/16, enterprise type and 828 WiFi subscriber type are assigned 2/16 each, and 2/16 is reserved. 830 A.4. Service Platform Type Bits within Service Platform Address Space 832 Service Platform Type (SPT) indicates typical service platforms 833 offered by operators. This field may have scalability problem since 834 there are numerous types of services . It is recommended that only 835 aggregated service platform types should be defined in this field. 836 This type of prefix is usually allocated to service platforms in 837 operator's data center. 839 +--------+--------+---------------+------+-------------------------+ 840 | | FT(001)| Locator | SPT | Service bits | 841 +--------+--------+---------------+------+-------------------------+ 842 / \ 843 / \ 844 +----------+------------+---------------+ 845 |000~001: Self-running service platform | 846 |001~011: Tenant service platform | 847 |100~101: Independent service platform | 848 |110~111: Reserved | 849 +---------------------------------------+ 851 Service Platform Type Bits Example 853 Figure 4 855 The portion of each subnet type should be estimated according to the 856 actual requirements for operators, in order to use the address space 857 most efficiently. 859 Appendix B. An Enterprise Semantic Prefix example 861 This enterprise semantic prefix example is also abstracted from an 862 ongoing enterprise address architecture design. This example is 863 designed for a realtime video monitor network across a city region. 864 The semantic prefix solution is planning to be deployed along with a 865 strict authorization system. 867 Note: this example only covers unicast address within IP Version 6 868 Addressing Architecture [RFC4291]. 870 For this example, the below semantics are important for the network 871 operation and require different network behaviors. 873 a. Terminal type: there are two terminal types only: monitor cameras 874 or video receivers. They are estimated to have similar number. 875 Network devices use another different address space. 877 b. Geographic location: the city has been managed in a three-level 878 hierarchical regionalism: district, area and street. Each level 879 has less than 28 sub-regions. This can also be considered as a 880 replacement of topology locator within this specific network. 882 c. Authorization level: the network operator is planning to 883 administrate the authorization in three or four levels. An 884 receiver can access the cameras that are the same or lower 885 authorization level. 887 d. Civilian or police/government. 889 e. Device attribute: this indicates the attribute of a camera 890 device. The attribute is expressed in an abstract way, such as 891 road traffic, hospital, nursery, bank, airport, etc. The 892 abstracted attribute type is designed to be less than 64. 894 f. Receiver Attribute: this indicates the attribute of a video 895 receiver. The attribute is based on the receiver group, such as 896 police, firefighter, local security, etc. The attribute/receiver 897 group type is designed to be less than 128. 899 This example enterprise network has obtained a /32 address block from 900 ISP. There is another /48 dedicated for network devices. 902 The first bit is Terminal type, which indicates terminal type. 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | ISP assigned block | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 |T| Geographic Locator | AL|C|Device Attr| Device Bit | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 A semantic prefix design example for cameras 913 Figure 5 915 3-level hierarchical geographic locator takes 15 bits (each level 5 916 bits, 32 sub-regions). Authorization level takes 2 bits and 1 bit 917 differentiates civilian or police/government. 6 bits is assigned for 918 device attribute. 920 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 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | ISP assigned block | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |T| GeoLoc | AL|C|Receiver Attr| Topology Locator |ReceiverBit| 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 An semantic prefix design example for video receivers 929 Figure 6 931 The receiver is not as much as geographically distributed as cameras. 932 Therefore, Geographic locator is only detailed to district level. 933 Topology locator is needed for network forwarding and aggregation 934 within a district. It is assigned 10 bits. Authorization level bits 935 and civilian bit are the same with camera address space. Receive 936 attribute takes 7 bits, giving it is designed to be up to 128. 938 Appendix C. A Multi-Prefix Semantic example 940 A multiple-site enterprise may have been assigned several prefixes of 941 different lengths by its upstream ISPs. In this situation, in order 942 to create a single, contiguous Semantic Prefix Domain, it is 943 necessary to base the semantic prefix policy on the longest assigned 944 prefix to ensure that there in enough addressing space to encode a 945 consistent set of semantics across all of the assigned prefixes. 947 In this example, an enterprise has received a /38 address block for 948 one site (A) and a /44 for a second site (B) . They can be organized 949 in the same Semantic Prefix Domain. The most-left 18 (site A) and 12 950 (site B) bits are allocated as locator. It provides topology based 951 network aggregation. The 8 right-most bits (from bits 56 to 63) are 952 assigned as the semantic field. In this design, the multiple-site 953 enterprise that has been assigned two prefixes of different lengths 954 can be organized as the same Semantic Prefix Domain. The semantic 955 and the Semantic Prefix Domain can traverse the intermediate ISP 956 networks, or even public networks. 958 The similar situation may happen on ISPs in the future, when an ISP 959 used up its assigned address space, or built up multiple networks in 960 different places. 962 Authors' Addresses 964 Sheng Jiang (editor) 965 Huawei Technologies Co., Ltd 966 Q14, Huawei Campus, No.156 BeiQing Road 967 Hai-Dian District, Beijing 100095 968 P.R. China 970 Email: jiangsheng@huawei.com 972 Qiong Sun 973 China Telecom 974 Room 708, No.118, Xizhimennei Street 975 Beijing 100084 976 P.R. China 978 Email: sunqiong@ctbri.com.cn 980 Ian Farrer 981 Deutsche Telekom AG 982 Bonn 53227 983 Germany 985 Email: ian.farrer@telekom.de 987 Yang Bo 988 Huawei Technologies Co., Ltd 989 Q21, Huawei Campus, No.156 BeiQing Road 990 Hai-Dian District, Beijing 100095 991 P.R. China 993 Email: boyang.bo@huawei.com 994 Tianle Yang 995 China Mobile 996 32, Xuanwumenxi Ave. Xicheng District 997 Beijing 100053 998 China 1000 Email: yangtianle@chinamobile.com