idnits 2.17.1 draft-lepape-6man-prefix-metadata-00.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 3937 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-dhc-dhcpv4-over-ipv6' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 514, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-bhandari-dhc-class-based-prefix-04 == Outdated reference: A later version (-09) exists of draft-ietf-dhc-dhcpv4-over-ipv6-06 == Outdated reference: A later version (-04) exists of draft-jiang-v6ops-semantic-prefix-03 == Outdated reference: A later version (-01) exists of draft-troan-homenet-sadr-00 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Le Pape 3 Internet-Draft S. Bhandari 4 Intended status: Informational Cisco Systems 5 Expires: January 16, 2014 I. Farrer 6 Deutsche Telekom AG 7 July 15, 2013 9 IPv6 Prefix Meta-data and Usage 10 draft-lepape-6man-prefix-metadata-00 12 Abstract 14 This document presents a method for applications to influence the 15 IPv6 source selection algorithm used by the IP stack in a host. To 16 do so, IPv6 prefixes are associated with meta-data when configured by 17 the network. This meta-data allows the network to describe the 18 purpose and properties of the prefix enabling applications to make 19 intelligent decision when selecting a prefix. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 16, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1.1. Home networks . . . . . . . . . . . . . . . . . . . . 3 64 1.1.2. Mobile networks . . . . . . . . . . . . . . . . . . . 4 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Considerations . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1. Prefix meta-data propogation . . . . . . . . . . . . . . 7 68 3.2. Configuring Applications . . . . . . . . . . . . . . . . 7 69 3.3. Application to network stack communication . . . . . . . 8 70 3.4. Default Address Selection . . . . . . . . . . . . . . . . 8 71 3.5. Scope of Prefix Color . . . . . . . . . . . . . . . . . . 8 72 3.5.1. Local scoping . . . . . . . . . . . . . . . . . . . . 9 73 3.5.2. Local scoping with fuzzy matching . . . . . . . . . . 9 74 3.5.3. Global scoping . . . . . . . . . . . . . . . . . . . 9 75 3.6. Compatibility with Existing Implementations . . . . . . . 9 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 79 7. Change History (to be removed prior to publication as an RFC) 10 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 8.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Appendix A. Prototype notes . . . . . . . . . . . . . . . . . . 12 84 A.1. Homenet prototype implementation notes . . . . . . . . . 12 85 A.1.1. Video provider service . . . . . . . . . . . . . . . 12 86 A.1.2. Prefix Color delegation . . . . . . . . . . . . . . . 12 87 A.1.3. Configuring Applications . . . . . . . . . . . . . . 13 88 A.1.4. Android DHCPv6 . . . . . . . . . . . . . . . . . . . 14 89 A.1.5. Application to network stack communication . . . . . 14 90 A.1.6. Android kernel . . . . . . . . . . . . . . . . . . . 15 91 A.1.7. Limitations of the current prototype . . . . . . . . 16 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 97 IPv6 provides not only a larger address space than IPv4, but also 98 allows host interfaces to have more than one IPv6 address of the same 99 or different scope(s). When multiple prefixes are assigned to one or 100 more network interfaces each of the prefixes can have a specific 101 property and purpose associated with it. For example: In a mobile 102 network, a mobile device can be assigned a prefix from its home 103 network and another from the visiting network that it is currently 104 attached to. Another example is a public WLAN hotspot configured 105 with two prefixes offering Internet access. One is free, but low- 106 quality, whilst the other is charged and offers service level 107 guarantees. 109 A prefix may have well defined properties that are universal and have 110 additional meta-data associated with it in order to communicate the 111 prefixes local significance. When multiple prefixes are provisioned 112 to the host, this additional information allows the host and 113 applications to make more intelligent decisions about the best IPv6 114 address to select when sourcing connections. 116 This document introduces the motivations and considerations for 117 having additional meta-data associated with a prefix and also 118 proposes a format for the meta-data itself. 120 The underlying assumption is that a endpoint or an application has 121 multiple prefixes to choose from. Typically this means either the 122 endpoint has multiple interfaces or an interface has been configured 123 with multiple prefixes. This specification does not make a 124 distinction between these alternatives. 126 1.1. Motivation 128 In this section, the motivation for attaching meta-data to IPv6 129 prefixes is described in the context of both mobile and home 130 networks. The meta-data helps to distinguish an IPv6 prefix and aids 131 with the selection of the prefix by different applications. 133 1.1.1. Home networks 135 In a fixed network environment, the homenet CPE may also function as 136 both a DHCPv6 client (requesting IA_PD(s)) and a DHCPv6 server 137 allocating prefixes from delegated prefix(es) to downstream home 138 network hosts. Some service providers may wish to delegate multiple 139 globally unique prefixes to the CPE for use by different services 140 classes and traffic types. 142 Motivations for this include: 144 o Using source prefix to identify the service class / traffic type 145 that is being transported. The source prefix may then reliably be 146 used as a parameter for differentiated services or other purposes. 147 E.g. [I-D.jiang-v6ops-semantic-prefix] 149 o Using the specific source prefix as a host identifier for other 150 services. 152 o In multi-homed environments, a single homenet LAN may have 153 multiple globally unique prefixes provided by the different 154 service providers. In this scenario, correct source address 155 selection is fundamental to successfully establishing connections. 156 E.g. [I-D.troan-homenet-sadr] 158 Any host which is configured with multiple prefixes must perform a 159 source address selection process when initiating a connection. Any 160 client that has multiple globally unique prefixes only has source and 161 destination longest-prefix matching policy [RFC6724] in order to make 162 this selection. For cases such as those listed above, longest-prefix 163 matching can not assist the client in selecting the correct source 164 address to use. Addition information is needed to assist the client 165 in making the correct source address selection. 167 1.1.2. Mobile networks 169 In mobile network architecture, a mobile node can be associated with 170 multiple IPv6 prefixes belonging to different domains. E.g. home 171 address prefix, care of address prefix (as specified in [RFC3775]). 172 The delegated prefixes may be topologically local and some may be 173 remote prefixes anchored on a global anchor, but available to the 174 local anchor by means of tunnel setup in the network between the 175 local and global anchor. Some prefixes may be local with low latency 176 characteristics suitable for voice call break-out, some may have 177 global mobility support. 179 So, the prefixes have different properties and it is necessary for 180 the application using the prefix to learn about this property in 181 order to use it intelligently. An example is determining if the 182 prefix is a home address or care of address or other network 183 characteristics that can be offered. 185 2. Overview 187 The mechanism that is described in this document describes two 188 different types of meta data which can be used in different ways: 190 Prefix Properties Provides a method for an application to "hint" 191 required source address properties to the kernel. 192 These properties are universal and expressed as a 193 set of flags. 195 Prefix Color Provides an arbitrary color value to prefixes (of 196 local significance) enabling an application to 197 request a source prefix with a specific color. 199 These two meta data types are described in more detail below. 201 Prefix Properties functions as follows: 203 o The client receives multiple prefixes, with relevant Prefix 204 Property meta-data attached to each prefix 206 o Prefix property aware applications running on the client have a 207 policy defining that they prefer prefixes that have specific 208 properties. 210 o On initiating a connection, the Prefix Property aware application 211 passes the required prefix properties to the kernel along with the 212 connect request 214 o The kernel checks the requested properties against the available 215 prefixes. If a match is found, the matching prefix is passed back 216 to the application 218 o The application uses the returned prefix when making the call to 219 the socket API to create the connection 221 o If no prefix matching the requested properties is available, then 222 the kernel uses [RFC6724] for source address selection as normal 224 Prefix property offers well defined universally understood 225 information about the prefix. Example properties include whether a 226 prefix can provide Internet reachability, if the prefix offers 227 application specific Internet service level, if the prefix usage is 228 free/charged, if the prefix offers security guarantees etc. This is 229 maintained as a global registry. 231 Prefix Coloring functions as follows: 233 o The client receives multiple prefixes, with relevant meta-data 234 attached 236 o Color aware applications running on the client are provisioned 237 with policy telling them which prefix color to request 239 o On initiating a connection, the meta data aware application passes 240 the required prefix color to the kernel along with the connect 241 request 243 o The kernel takes this color and selects the prefix matching the 244 requested color and passes this back to the application 246 o The application uses the returned prefix when making the call to 247 the socket API to create the connection 249 Prefix colour conveys information of the prefix that is of relevance 250 to the network where the prefix is provisioned and application using 251 it. Example usage of prefix color include color that is provisioned 252 to offer better video application experience. The prefix color is 253 defined as a 16 bit numerical value. 255 Figure 1 illustrates a typical network with different components that 256 can add, understand and use the meta-data attached to a prefix. 258 o Mobile or ISP Network - Provisioned with prefixes that offer 259 specific network characteristic. e.g. prefixes that do not have 260 internet reach but can offer quality of service required for 261 better video application experience. Includes address delegation 262 server that associate prefixes with this information, selects and 263 offers this information during prefix delegation 265 o Home/Mobile gateway - Learns or determines characteristic of the 266 prefix and propagates it along with prefix delegation. e.g. 267 Determines if the prefix is locally anchored or learns the prefix 268 meta-data from the ISP prefix delegation server and includes this 269 information in prefix delegation to endpoints 271 o Endpoint network stack - Learns the additional information 272 associated with the prefix and offers interface to applications 273 for listing and selecting the available prefixes 275 o Prefix selection policy - Either embedded in the application/ 276 endpoint or learnt from a server that helps choose the prefix with 277 specific characteristic for the application based on predetermined 278 service agreement between the application/endpoint/application 279 service provider and network service provider 281 o Applications - That can utilize the prefix with specific 282 characteristic for enhanced application user experience e.g. On 283 demand video application, by choosing the prefix with appropriate 284 prefix selection policy while connecting and delivering the 285 application over the network 287 This prefix meta-data could be further extended to have more 288 attributes such as the administrative domain of the prefix. 290 +----------------------+ +------------------------+ 291 | | | | 292 | Application | | | 293 | prefix | | ISP 1, ..., n | 294 | policy | | | 295 | | | | 296 +----------------------+ +------------------------+ 297 : | | 298 : | | 299 : |---n---| 300 +--------------+ | | 301 | Endpoint | | | 302 | application | | | 303 +- - - - - - - + +------------------+ 304 | Endpoint | | | 305 | networking |---------------| Home Gateway/ | 306 | stack | | Mobile Gateway | 307 +--------------+ +------------------+ 309 Figure 1 311 3. Considerations 313 3.1. Prefix meta-data propogation 315 The prefix meta-data can be delivered using DHCPv6 prefix delegation 316 and address allocation as elaborated in 317 [I-D.bhandari-dhc-class-based-prefix] or via IPv6 Neighbour discovery 318 (ND) as defined in [I-D.korhonen-6man-prefix-properties]. 320 3.2. Configuring Applications 322 Applications supporting multiple prefixes obtain the prefixes from 323 the host kernel along with their meta-data. 325 The policy can then be contained either locally (e.g. If the 326 application is intended only for use within a specific network, 327 linked to a particular ISP comes prepackages with prefix color to 328 use), or be contained on a remote policy server. The mechanism used 329 to exchange the meta-data information and selection between 330 application/host with a remote server is beyond the scope of this 331 document. 333 3.3. Application to network stack communication 335 Once an application has determined the appropriate property and color 336 for its use it has to communicate with the network stack to select 337 the prefix. The host internal data structures need to be extended 338 with the 'prefix property' and the 'prefix color' information 339 associated to the learnt prefix and configured addresses. How this 340 is accomplished is host implementation specific. It is also a host 341 implementation issue how an application can learn or query both 342 properties and color of an address or a prefix. One possibility is 343 to provide such information through the socket API extensions. Other 344 possibilities include the use of e.g., ioctl() or NetLink [RFC3549] 345 extensions or by using the IPv6 address scope [RFC4007]. 347 Discussion point: Should prefix property and color be mutually 348 exclusive? This would avoid complexities which takes precedence 349 when one prefix matches color and another matches property. 350 Possibly a prefix may be advertised with both, but the application 351 can only request property or color. 353 3.4. Default Address Selection 355 [RFC6724] provides a mechanism for selecting which source address to 356 use, in the absence of an application or upper layer protocol's 357 explicit choice of a legal destination or source address. 359 The use of prefix meta-data allows an application to express property 360 preferences through socket API extensions, meaning that when used for 361 creating a socket, [RFC6724] source address selection is not 362 required. 364 If a higher layer protocol or application does not include a prefix 365 property preference when making a create socket request, then source 366 address selection according to [RFC6724] is followed as normal. 368 3.5. Scope of Prefix Color 370 Since a home can be connected to multiple ISPs, it is possible that 371 it receives multiple prefixes with the same color from different 372 ISPs. Since the application coloring policy is not received with the 373 color, multiple ISPs may use different coloring policy for a single 374 color. For example: One ISP could use color 50 for video whilst a 375 second ISP is using color 50 for audio. 377 This section presents some alternatives to handle this problem. 379 3.5.1. Local scoping 381 A locally scoped color is a value which is selected by the network 382 and application providers with no central registry. In a multi homed 383 network, this may result in two providers selecting the same color 384 for different behaviors. A color translation could be performed to 385 ensure unique color at the device that connects to multiple 386 providers. 388 3.5.2. Local scoping with fuzzy matching 390 To avoid having to maintain multiple colors for each prefix for 391 translating the color, a specific algorithm can be used to determine 392 the new color from the old one on conflict. 394 For example, when a collision is detected, the new color value may be 395 incremented. Further, colors could be defined to be equally spaced 396 (e.g., 10s or 100s). 398 Many other encodings are possible as well, as long as obtaining the 399 original color communicated by the ISP may be recovered in the event 400 the application policy server requires this. 402 3.5.3. Global scoping 404 A globally scoped color avoids the need for responding to collisions. 405 This can be achieved by disambiguating the color by attaching the 406 domain that provisions the color to the prefix meta-data or by 407 assigning colors from a global registry that comes with the overhead 408 of maintaining such a registry. 410 3.6. Compatibility with Existing Implementations 412 The prefix meta-data mechanism that is described in this document 413 provides a way of improving source address selection over the 414 longest-prefix matching method used by [RFC6724]. 416 However, all IPv6 capable hosts deployed at the time of writing do 417 not have the capability of understanding and processing prefix meta- 418 data. This means that any new mechanism must be backwards compatible 419 with existing implementations. Also, clients which understand prefix 420 meta-data need to support applications which do not have meta-data 421 awareness. 423 There are a number of possible approaches that could be taken here. 424 The following list is included as ideas for further development: 426 o In DHCPv6 only clients which request prefixes with meta-data (e.g. 427 signalled through OPTION_ORO in the IA_NA or IA_PD request) will 428 receive them. 430 o In case of prefix delegated using IPv6 Neighbour discovery (ND) 431 both forms of prefix i.e with and without meta-data can be 432 offered. 434 o If an application makes a socket API request and does not include 435 meta-data as part of the request, follow [RFC6724] source address 436 selection, but remove any prefixes that have meta-data from the 437 list of candidate addresses. It follows that there should be a GU 438 prefix advertised that does not have any meta-data associated that 439 would act as the default choice for non prefix meta-data aware 440 clients and applications. 442 4. IANA Considerations 444 Should the global scoping for prefix color be chosen, a new registry 445 should be created by IANA to store colors. 447 5. Security Considerations 449 TBD 451 6. Acknowledgements 453 The authors would like to acknowledge review and guidance received 454 from 456 7. Change History (to be removed prior to publication as an RFC) 458 8. References 460 8.1. Normative References 462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 463 Requirement Levels", BCP 14, RFC 2119, March 1997. 465 8.2. Informative References 467 [I-D.bhandari-dhc-class-based-prefix] 468 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 469 Thiebaut, L., and J. Korhonen, "DHCPv6 class based 470 prefix", draft-bhandari-dhc-class-based-prefix-04 (work in 471 progress), February 2013. 473 [I-D.ietf-dhc-dhcpv4-over-ipv6] 474 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 475 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in 476 progress), March 2013. 478 [I-D.jiang-v6ops-semantic-prefix] 479 Jiang, S., Sun, Q., Farrer, I., and Y. Bo, "A Framework 480 for Semantic IPv6 Prefix", draft-jiang-v6ops-semantic- 481 prefix-03 (work in progress), May 2013. 483 [I-D.korhonen-6man-prefix-properties] 484 Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. 485 Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- 486 properties-02 (work in progress), July 2013. 488 [I-D.troan-homenet-sadr] 489 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 490 Address Dependent Routing (SADR)", draft-troan-homenet- 491 sadr-00 (work in progress), February 2013. 493 [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, 494 "Linux Netlink as an IP Services Protocol", RFC 3549, July 495 2003. 497 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 498 Host Configuration Protocol (DHCP) version 6", RFC 3633, 499 December 2003. 501 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 502 in IPv6", RFC 3775, June 2004. 504 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 505 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 506 March 2005. 508 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 509 More-Specific Routes", RFC 4191, November 2005. 511 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 512 Address Autoconfiguration", RFC 4862, September 2007. 514 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 515 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 516 May 2008. 518 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 519 "Default Address Selection for Internet Protocol Version 6 520 (IPv6)", RFC 6724, September 2012. 522 Appendix A. Prototype notes 524 A.1. Homenet prototype implementation notes 526 This section provides the implementation details of a prototype video 527 application on Android for a Galaxy Nexus device developed for the 528 home network. 530 A.1.1. Video provider service 532 A possible use of this prefix coloring is a video service, which 533 requires the network to guarantee a minimal throughput for streaming 534 video. A prefix could be colored by the ISP to indicate that traffic 535 sourced from that prefix will have a certain service level. Using 536 prefix coloring avoids having to set up a separate network for this 537 usage, or implement QoS traffic identification, classification and 538 marking. 540 An agreement could then be established between the video service 541 provider and the ISP, telling the video provider to use the specific 542 color when streaming video. In the following example, the color 50 543 was used. 545 A.1.2. Prefix Color delegation 547 The CPE routers request prefixes using prefix delegation [RFC3633] 548 with the OPTION_PREFIX_CLASS option 549 [I-D.bhandari-dhc-class-based-prefix]. This informs the upstream 550 provider that the CPE supports colored prefixes. If an ISP does not 551 support this option, it will be ignored, and the CPE will only get 552 colorless prefixes. Otherwise, the ISP returns multiple prefixes 553 each with their associated color. A color of '0' is identical to an 554 uncolored prefix, for application compatibility, as explained in 555 Appendix A.1.5. If the CPE does not support colored prefixes, the 556 ISP could decide to delegate a normally colored prefix as an 557 colorless one, though this means hosts will use this prefix according 558 to the default source address selection algorithm, and will not 559 associate any meaning to it. 561 Once the CPE receives those prefixes, it distributes them, along with 562 their color, using OSPF and the homenet protocols. 563 [I-D.troan-homenet-sadr] defines "Source Address Dependent Routing" 564 (SADR) which ensures that packets are routed based on their 565 destination as well as source address. SADR is necessary to ensure 566 that a multihomed network using provider aggregatable addresses will 567 send the packet out the right path to avoid violating the provider's 568 ingress filtering.To ensure that those prefixes keep their meaning, 569 Source Address Dependent Routing [I-D.troan-homenet-sadr] is 570 implemented and used. 572 Colored addresses are advertised to hosts through DHCPv6, to 573 associate the color to the address. Colorless addresses may be 574 distributed through DHCPv6 or through Router Advertisements. Hosts 575 supporting colored prefixes include the OPTION_PREFIX_CLASS, and 576 receive colored addresses. For legacy hosts, who do not include this 577 option, there are two possibilities : 579 o Those hosts can receive all available prefixes, including colored 580 ones, as uncolored. This allows a legacy host in a fully colored 581 homenet to still have access to IPv6. However, those hosts may 582 use prefixes for the wrong purposes. 584 o Those hosts can receive only colorless prefixes. This ensures 585 that a prefix will not be used for the wrong purpose. However, 586 hosts in a fully colored environment will not get access to IPv6. 587 This can however be what the ISP originally intended, for example 588 if the ISP does not provide access to the IPv6 Internet, but uses 589 IPv6 for wall gardened services, which their specific devices know 590 how to use. 592 A.1.3. Configuring Applications 594 Applications supporting multiple prefixes obtain the prefixes from 595 the host kernel, along with their color. 597 The policy can be contained either in a local database (e.g. If the 598 application is intended only for use within a specific network, 599 linked to a particular ISP), or be contained on a distant server. 601 For applications that do not contain a local database, an HTTP POST 602 request is sent to a predefined server using a colorless prefix. 603 This server, through means that are out of the scope of this 604 document, selects the most appropriate color for the URIs used by the 605 application. It then returns an XML document containing the mapping 606 between the URIs and the colors. URIs in this document MAY use wild 607 cards. 609 When the application is started, it sends the available prefixes and 610 their color to the video provider server which answers with a wild 611 card URI videos.example.com associated to color 50. In this example 612 application it receives: 614 615 616 617 *://audio.example.com/* 618 40 619 620 621 rtsp://video.example.com/* 622 50 623 624 626 The server is expected to know the application, and thus to list all 627 URIs that could be of use to the application. The application will 628 not ask the server if it has to contact an address not in the list 629 and will use the colorless prefix. This avoids an additional delay 630 when trying to contact an unlisted URI. 632 Example: While the application is browsing the video list, it is 633 using www.example.com, and thus the colorless prefix. However as 634 soon as a video is chosen, it starts streaming from 635 videos.example.com, and asks to connect to host videos.example.com 636 with color 50, indicating that it wishes to use the colored prefix. 638 A.1.4. Android DHCPv6 640 Considering that this prototype is being implemented on Android, the 641 first step is to get a running DHCPv6 client on Android, with support 642 for the OPTION_PREFIX_CLASS option. 644 The odhcp6c client, which already supports OPTION_PREFIX_CLASS, has 645 been ported to Android, and is set to run in parallel to the dhcpcd 646 client used for DHCP. The success of any of the two clients results 647 in the success of the WiFi connection, so as to support IPv6 only 648 networks. 650 This client configures the IPv6 addresses using calls to IP address, 651 which is modified to support the addition of a class option to set 652 the prefix color. 654 A.1.5. Application to network stack communication 655 Once an application has received the appropriate color for its use, 656 in this prototype it specifies the prefix it wishes to use by using 657 the IPv6 address scope [RFC4007]. When resolving this address, the 658 standard library then adds this information in the address 659 information it returns, using the scope field, allowing the kernel to 660 appropriately select the source IP when connecting. For this reason, 661 a color of 0 is identical to an colorless prefix. 663 In the example, when downloading from video.example.com, the 664 application would request a connection to video.example.com%50. 666 This allows the user to override the application's default simply by 667 specifying a color in the scope of the URI it is trying to access, 668 and requires little to no change in applications to support it. 669 Applications that allow scope ids do not need to be modified in order 670 to allow the user to use multiple prefixes (though it is then up to 671 the user to select its color). A web browser that allows scope id 672 would allow the user to add a color to the URI, without requiring any 673 modifications. 675 A.1.6. Android kernel 677 To reduce the amount of modifications needed by the applications to 678 support this prefix coloring, we need to avoid having to bind to the 679 address in the colored prefix before initiating the connection. The 680 kernel is expected to choose the correct source address when a 681 colored destination is used. 683 This implies storing the color in the kernel, along with the address, 684 which is done using a new attribute IFA_color to the netlink message 685 RTM_NEWADDR, used by ip address. Setting a colored prefix using 686 ioctls is not supported. 688 Since colors are put in the scope id part of the destination address, 689 we continue to use the scope element of the sockaddr_in6 structure to 690 store the color when sending connect messages to the kernel. The 691 scope is only used when considering local addresses, so we interpret 692 the presence of a scope on a non link-local address to be a color. 693 Colors can not be assigned to link-local addresses, but since they 694 are on the same link, source address shouldn't impact how the network 695 treats packets. When selecting the source address, we then discard 696 all addresses which do not have the correct color. 698 A.1.7. Limitations of the current prototype 700 It does not implement any duplicate color detection. Colors are 701 considered to be unique within the home, and to correspond to the 702 original color provided by the ISP. This is compatible with Global 703 scoping. No changes would be required to the host in order to 704 support Local scoping with fuzzy matching, but OSPF would need to 705 detect collisions, and the server would need to recalculate the 706 original color before making a decision. In this implementation, 707 hosts that do not support colors do not receive colored prefixes. 709 Authors' Addresses 711 Maico Le Pape 712 Cisco Systems 713 Paris 714 FR 716 Email: maico@maicolepape.org 718 Shwetha Bhandari 719 Cisco Systems 720 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 721 Bangalore, KARNATAKA 560 087 722 India 724 Email: shwethab@cisco.com 726 Ian Farrer 727 Deutsche Telekom AG 728 GTN-FM4, Landgrabenweg 151 729 Bonn 53227 730 Germany 732 Email: ian.farrer@telekom.de