idnits 2.17.1 draft-jiang-semantic-prefix-06.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 3938 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-semantic-prefix-06 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 . . . . . . . . . . . . . . . . . . 15 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-semantic-prefix-04: add new pitfalls section; restructure 603 to be a neatrul analysis document; 2013-07-15. 605 draft-jiang-semantic-prefix-05: reword to emphasis this mechanism is 606 a (not the) method that network operators use their addresses; add 607 text to clarify the increased trust is actually from the deployment 608 of source address filter, which is a compliance requirement by 609 semantic prefix; restructure the document, move examples and gap 610 analysis into appendixes, reorganize most content into a frame 611 section; add summarized description for framework at the beginning of 612 Section 3; add description for network operations based on semantic 613 prefix; add a new coauthor who contributes an enterprise semantic 614 prefix network example; combine most of draft-sun-v6ops-semantic- 615 usecase into the draft as ISP example in appendix; 2013-5-28. 617 draft-jiang-semantic-prefix-04: add new coauthor, re-organize the 618 content, and refine the English, 2013-1-31. 620 draft-jiang-semantic-prefix-03: add the concept of hierarchical 621 Semantic Prefix Domain and more gap analysis, 2012-10-22. 623 draft-jiang-semantic-prefix-02: resubmitted to v6ops WG. Removed 624 detailed examples and recommendations for semantics bits, 2012-10-15. 626 draft-jiang-semantic-prefix-01: added enterprise considerations and 627 scenarios, emphasizing semantics only for local meaning and no intend 628 to standardize any common global semantics, 2012-07-16. 630 9. Security Considerations 632 Embedding semantics in prefix is actually exposing more information 633 of packets explicit. These informations may also provide convenient 634 for malicious attackers to track or attack certain type of packets. 635 If networks announce their local prefix semantics to their peer 636 networks, it may also increase the vulnerable risk. 638 Prefix-based filters should be deployed, in order to protect against 639 address spoofing attacks or denial of service for packets with forged 640 source addresses. 642 10. Acknowledgements 644 Useful comments were made by Erik Nygren, Dan Wing, Nick Hilliard, 645 Ray Hunter, David Farmer, Fred Baker, Joel Jaeggli, John Curran, Tim 646 Chown, Ted Lemon, Owen DeLong, Lorenzo Colitti, George Michaelson, 647 Joel Halpern, Vizdal Ales, Bless Roland, Manning Bill, Manfred Albert 648 and other participants in the V6OPS working group. 650 11. References 651 11.1. Normative References 653 [RFC1104] Braun, H., "Models of policy based routing", RFC 1104, 654 June 1989. 656 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 657 "Definition of the Differentiated Services Field (DS 658 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 659 1998. 661 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 662 and M. Carney, "Dynamic Host Configuration Protocol for 663 IPv6 (DHCPv6)", RFC 3315, July 2003. 665 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 666 Host Configuration Protocol (DHCP) version 6", RFC 3633, 667 December 2003. 669 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 670 Architecture", RFC 4291, February 2006. 672 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 673 Address Autoconfiguration", RFC 4862, September 2007. 675 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 676 "Default Address Selection for Internet Protocol Version 6 677 (IPv6)", RFC 6724, September 2012. 679 11.2. Informative References 681 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 682 Socket API for Source Address Selection", RFC 5014, 683 September 2007. 685 Appendix A. An ISP Semantic Prefix Example 687 This ISP semantic prefix example is abstracted from a real ISP 688 address architecture design. 690 Note: for now, this example only covers unicast address within IP 691 Version 6 Addressing Architecture [RFC4291]. 693 For ISPs, several motivations to use semantic prefixes are as 694 follows: 696 a. Network Device management: Separated and specialized address 697 space for network device will help to identify the network device 698 among numerous addresses and apply policy accordingly. 700 b. Differentiated user management: In ISPs' network, different kinds 701 of customers may have different requirements for service 702 provisioning. 704 c. High-priority service guarantee: Different priorities may be 705 divided into apply differentiated policy. 707 d. Service-based Routing: ISPs may offer different routing policy 708 for specific service platforms .e.g.video streaming, VOIP, etc. 710 e. Security Control: For security requirement, operators need to 711 take control and identify of certain devices/customers in a quick 712 manner. 714 f. Easy measurement and statistic: The semantic prefix provides 715 explicit identifiers for measurement and statistic. 717 These requirements are largely falling into two categories: some is 718 regarding to the network device features, and the others are related 719 to services provision and subscriber identification. The functional 720 usage of the semantics for the two categories are quite different. 721 Therefore, an ISP semantic IPv6 prefix example is designed as a two- 722 level hierarchical architecture, in which the first level is the 723 function types of prefixes, and the second level is the further usage 724 within an specific prefix type. 726 A.1. Function Type Semantic Bits 728 Function Type (FT): the value of this field is to indicate the 729 functional usage of this prefix. The typical types for operators 730 include network device, subscriber and service platform. 732 +--------+--------+------------------------------------------------+ 733 | | FT | | 734 +--------+--------+------------------------------------------------+ 735 / \ 736 +------------+------------+ 737 |000: network device | 738 |000~010: service platform| 739 |011~101: subscriber | 740 |110: reserved | 741 +-------------------------+ 743 Function Type Bits Example 745 Figure 1 747 The portion of each type should be estimated according to the actual 748 requirements for operators, in order to use the address space most 749 efficiently. Within the above FT design, the whole ISP IPv6 address 750 space is divided into four parts: the network device address space (1 751 /8 of total address space), the service platform address space (2/8 752 of total address space), the subscriber address space (3/8 of total 753 address space), and a reserved address space (1/8 of total address 754 space) for future usage. 756 A.2. Network Device Type Bits within Network Device Address Space 758 Network Device Type (NDT) indicates different types of network 759 devices. Normally, one operator may have multiple networks, 760 e.g.backbone network, mobile network, ISP brokered service network, 761 etc. Using NDT field to indicate specific network within an operator 762 may help to apply some routing policies. Locating NDT bits in the 763 left-most bits means that a single, simple access- control list 764 implemented across all networking devices would be enough to enforce 765 effective traffic segregation. The Locator field is followed behind 766 NDT. 768 +--------+--------+------+-----------------------------------------+ 769 | | FT(000)| NDT | Locator | Network Device bits | 770 +--------+--------+------+-----------------------------------------+ 771 / \ 772 / \ 773 +------------+-----+ 774 |000~001: SubNet 1| 775 |010~110: SubNet 2| 776 |111: Reserved| 777 +------------------+ 779 Network Device Type Bits Example 781 Figure 2 783 The portion of each subnet type should be estimated according to the 784 actual requirements for operators, in order to use the address space 785 most efficiently. Within the above NDT design, SubNet 1 is assigned 786 2/8 of the network device address space, SubNet 2 is assigned 5/8, 787 and 1/8 is reserved. 789 A.3. Subscriber Type Bits within Subscriber Address Space 790 Subscriber Type (ST) indicates different types of subscribers, e.g. 791 wireline broadband subscriber, mobile subscriber, enterprise, WiFi, 792 etc. This type of prefix is allocated to end users. Further, 793 division may be taken on subscriber's priorities within a certain 794 subscriber type. 796 The Locator field within subscriber address space is put before ST 797 for better routing aggregation. 799 +--------+--------+---------------+------+-------------------------+ 800 | | FT(011)| Locator | ST | Subscriber bits | 801 +--------+--------+---------------+------+-------------------------+ 802 / \ 803 / \ 804 +----------+------------+---------------+ 805 |0000~0011: broadband access subscriber | 806 |0100~0111: mobile subscriber | 807 |1000~1001: enterprise | 808 |1010~1011: WiFi subscriber | 809 |1100~1111: Reserved | 810 +---------------------------------------+ 812 Subscriber Type Bits Example 814 Figure 3 816 The portion of each subscriber type should be estimated according to 817 the actual requirements for operators, in order to use the address 818 space most efficiently. Within the above ST design, the broadband 819 access subscriber type is assigned 4/16 of the subscriber address 820 space, the mobile subscriber is assigned 4/16, enterprise type and 821 WiFi subscriber type are assigned 2/16 each, and 2/16 is reserved. 823 A.4. Service Platform Type Bits within Service Platform Address Space 825 Service Platform Type (SPT) indicates typical service platforms 826 offered by operators. This field may have scalability problem since 827 there are numerous types of services . It is recommended that only 828 aggregated service platform types should be defined in this field. 829 This type of prefix is usually allocated to service platforms in 830 operator's data center. 832 +--------+--------+---------------+------+-------------------------+ 833 | | FT(001)| Locator | SPT | Service bits | 834 +--------+--------+---------------+------+-------------------------+ 835 / \ 836 / \ 837 +----------+------------+---------------+ 838 |000~001: Self-running service platform | 839 |001~011: Tenant service platform | 840 |100~101: Independent service platform | 841 |110~111: Reserved | 842 +---------------------------------------+ 844 Service Platform Type Bits Example 846 Figure 4 848 The portion of each subnet type should be estimated according to the 849 actual requirements for operators, in order to use the address space 850 most efficiently. 852 Appendix B. An Enterprise Semantic Prefix example 854 This enterprise semantic prefix example is also abstracted from an 855 ongoing enterprise address architecture design. This example is 856 designed for a realtime video monitor network across a city region. 857 The semantic prefix solution is planning to be deployed along with a 858 strict authorization system. 860 Note: this example only covers unicast address within IP Version 6 861 Addressing Architecture [RFC4291]. 863 For this example, the below semantics are important for the network 864 operation and require different network behaviors. 866 a. Terminal type: there are two terminal types only: monitor cameras 867 or video receivers. They are estimated to have similar number. 868 Network devices use another different address space. 870 b. Geographic location: the city has been managed in a three-level 871 hierarchical regionalism: district, area and street. Each level 872 has less than 28 sub-regions. This can also be considered as a 873 replacement of topology locator within this specific network. 875 c. Authorization level: the network operator is planning to 876 administrate the authorization in three or four levels. An 877 receiver can access the cameras that are the same or lower 878 authorization level. 880 d. Civilian or police/government. 882 e. Device attribute: this indicates the attribute of a camera 883 device. The attribute is expressed in an abstract way, such as 884 road traffic, hospital, nursery, bank, airport, etc. The 885 abstracted attribute type is designed to be less than 64. 887 f. Receiver Attribute: this indicates the attribute of a video 888 receiver. The attribute is based on the receiver group, such as 889 police, firefighter, local security, etc. The attribute/receiver 890 group type is designed to be less than 128. 892 This example enterprise network has obtained a /32 address block from 893 ISP. There is another /48 dedicated for network devices. 895 The first bit is Terminal type, which indicates terminal type. 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | ISP assigned block | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 |T| Geographic Locator | AL|C|Device Attr| Device Bit | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 A semantic prefix design example for cameras 906 Figure 5 908 3-level hierarchical geographic locator takes 15 bits (each level 5 909 bits, 32 sub-regions). Authorization level takes 2 bits and 1 bit 910 differentiates civilian or police/government. 6 bits is assigned for 911 device attribute. 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | ISP assigned block | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 |T| GeoLoc | AL|C|Receiver Attr| Topology Locator |ReceiverBit| 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 An semantic prefix design example for video receivers 922 Figure 6 924 The receiver is not as much as geographically distributed as cameras. 925 Therefore, Geographic locator is only detailed to district level. 926 Topology locator is needed for network forwarding and aggregation 927 within a district. It is assigned 10 bits. Authorization level bits 928 and civilian bit are the same with camera address space. Receive 929 attribute takes 7 bits, giving it is designed to be up to 128. 931 Appendix C. A Multi-Prefix Semantic example 933 A multiple-site enterprise may have been assigned several prefixes of 934 different lengths by its upstream ISPs. In this situation, in order 935 to create a single, contiguous Semantic Prefix Domain, it is 936 necessary to base the semantic prefix policy on the longest assigned 937 prefix to ensure that there in enough addressing space to encode a 938 consistent set of semantics across all of the assigned prefixes. 940 In this example, an enterprise has received a /38 address block for 941 one site (A) and a /44 for a second site (B) . They can be organized 942 in the same Semantic Prefix Domain. The most-left 18 (site A) and 12 943 (site B) bits are allocated as locator. It provides topology based 944 network aggregation. The 8 right-most bits (from bits 56 to 63) are 945 assigned as the semantic field. In this design, the multiple-site 946 enterprise that has been assigned two prefixes of different lengths 947 can be organized as the same Semantic Prefix Domain. The semantic 948 and the Semantic Prefix Domain can traverse the intermediate ISP 949 networks, or even public networks. 951 The similar situation may happen on ISPs in the future, when an ISP 952 used up its assigned address space, or built up multiple networks in 953 different places. 955 Authors' Addresses 957 Sheng Jiang (editor) 958 Huawei Technologies Co., Ltd 959 Q14, Huawei Campus, No.156 BeiQing Road 960 Hai-Dian District, Beijing 100095 961 P.R. China 963 Email: jiangsheng@huawei.com 965 Qiong Sun 966 China Telecom 967 Room 708, No.118, Xizhimennei Street 968 Beijing 100084 969 P.R. China 971 Email: sunqiong@ctbri.com.cn 973 Ian Farrer 974 Deutsche Telekom AG 975 Bonn 53227 976 Germany 978 Email: ian.farrer@telekom.de 979 Yang Bo 980 Huawei Technologies Co., Ltd 981 Q21, Huawei Campus, No.156 BeiQing Road 982 Hai-Dian District, Beijing 100095 983 P.R. China 985 Email: boyang.bo@huawei.com 987 Tianle Yang 988 China Mobile 989 32, Xuanwumenxi Ave. Xicheng District 990 Beijing 100053 991 China 993 Email: yangtianle@chinamobile.com