Internet Engineering Task Force M. Le Pape Internet-Draft S. Bhandari Intended status: Informational Cisco Systems Expires: January 16, 2014 I. Farrer Deutsche Telekom AG July 15, 2013 IPv6 Prefix Meta-data and Usage draft-lepape-6man-prefix-metadata-00 Abstract This document presents a method for applications to influence the IPv6 source selection algorithm used by the IP stack in a host. To do so, IPv6 prefixes are associated with meta-data when configured by the network. This meta-data allows the network to describe the purpose and properties of the prefix enabling applications to make intelligent decision when selecting a prefix. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 16, 2014. Le Pape, et al. Expires January 16, 2014 [Page 1] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Home networks . . . . . . . . . . . . . . . . . . . . 3 1.1.2. Mobile networks . . . . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Considerations . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Prefix meta-data propogation . . . . . . . . . . . . . . 7 3.2. Configuring Applications . . . . . . . . . . . . . . . . 7 3.3. Application to network stack communication . . . . . . . 8 3.4. Default Address Selection . . . . . . . . . . . . . . . . 8 3.5. Scope of Prefix Color . . . . . . . . . . . . . . . . . . 8 3.5.1. Local scoping . . . . . . . . . . . . . . . . . . . . 9 3.5.2. Local scoping with fuzzy matching . . . . . . . . . . 9 3.5.3. Global scoping . . . . . . . . . . . . . . . . . . . 9 3.6. Compatibility with Existing Implementations . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 7. Change History (to be removed prior to publication as an RFC) 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Appendix A. Prototype notes . . . . . . . . . . . . . . . . . . 12 A.1. Homenet prototype implementation notes . . . . . . . . . 12 A.1.1. Video provider service . . . . . . . . . . . . . . . 12 A.1.2. Prefix Color delegation . . . . . . . . . . . . . . . 12 A.1.3. Configuring Applications . . . . . . . . . . . . . . 13 A.1.4. Android DHCPv6 . . . . . . . . . . . . . . . . . . . 14 A.1.5. Application to network stack communication . . . . . 14 A.1.6. Android kernel . . . . . . . . . . . . . . . . . . . 15 A.1.7. Limitations of the current prototype . . . . . . . . 16 Le Pape, et al. Expires January 16, 2014 [Page 2] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction IPv6 provides not only a larger address space than IPv4, but also allows host interfaces to have more than one IPv6 address of the same or different scope(s). When multiple prefixes are assigned to one or more network interfaces each of the prefixes can have a specific property and purpose associated with it. For example: In a mobile network, a mobile device can be assigned a prefix from its home network and another from the visiting network that it is currently attached to. Another example is a public WLAN hotspot configured with two prefixes offering Internet access. One is free, but low- quality, whilst the other is charged and offers service level guarantees. A prefix may have well defined properties that are universal and have additional meta-data associated with it in order to communicate the prefixes local significance. When multiple prefixes are provisioned to the host, this additional information allows the host and applications to make more intelligent decisions about the best IPv6 address to select when sourcing connections. This document introduces the motivations and considerations for having additional meta-data associated with a prefix and also proposes a format for the meta-data itself. The underlying assumption is that a endpoint or an application has multiple prefixes to choose from. Typically this means either the endpoint has multiple interfaces or an interface has been configured with multiple prefixes. This specification does not make a distinction between these alternatives. 1.1. Motivation In this section, the motivation for attaching meta-data to IPv6 prefixes is described in the context of both mobile and home networks. The meta-data helps to distinguish an IPv6 prefix and aids with the selection of the prefix by different applications. 1.1.1. Home networks In a fixed network environment, the homenet CPE may also function as both a DHCPv6 client (requesting IA_PD(s)) and a DHCPv6 server allocating prefixes from delegated prefix(es) to downstream home network hosts. Some service providers may wish to delegate multiple globally unique prefixes to the CPE for use by different services classes and traffic types. Le Pape, et al. Expires January 16, 2014 [Page 3] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 Motivations for this include: o Using source prefix to identify the service class / traffic type that is being transported. The source prefix may then reliably be used as a parameter for differentiated services or other purposes. E.g. [I-D.jiang-v6ops-semantic-prefix] o Using the specific source prefix as a host identifier for other services. o In multi-homed environments, a single homenet LAN may have multiple globally unique prefixes provided by the different service providers. In this scenario, correct source address selection is fundamental to successfully establishing connections. E.g. [I-D.troan-homenet-sadr] Any host which is configured with multiple prefixes must perform a source address selection process when initiating a connection. Any client that has multiple globally unique prefixes only has source and destination longest-prefix matching policy [RFC6724] in order to make this selection. For cases such as those listed above, longest-prefix matching can not assist the client in selecting the correct source address to use. Addition information is needed to assist the client in making the correct source address selection. 1.1.2. Mobile networks In mobile network architecture, a mobile node can be associated with multiple IPv6 prefixes belonging to different domains. E.g. home address prefix, care of address prefix (as specified in [RFC3775]). The delegated prefixes may be topologically local and some may be remote prefixes anchored on a global anchor, but available to the local anchor by means of tunnel setup in the network between the local and global anchor. Some prefixes may be local with low latency characteristics suitable for voice call break-out, some may have global mobility support. So, the prefixes have different properties and it is necessary for the application using the prefix to learn about this property in order to use it intelligently. An example is determining if the prefix is a home address or care of address or other network characteristics that can be offered. Le Pape, et al. Expires January 16, 2014 [Page 4] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 2. Overview The mechanism that is described in this document describes two different types of meta data which can be used in different ways: Prefix Properties Provides a method for an application to "hint" required source address properties to the kernel. These properties are universal and expressed as a set of flags. Prefix Color Provides an arbitrary color value to prefixes (of local significance) enabling an application to request a source prefix with a specific color. These two meta data types are described in more detail below. Prefix Properties functions as follows: o The client receives multiple prefixes, with relevant Prefix Property meta-data attached to each prefix o Prefix property aware applications running on the client have a policy defining that they prefer prefixes that have specific properties. o On initiating a connection, the Prefix Property aware application passes the required prefix properties to the kernel along with the connect request o The kernel checks the requested properties against the available prefixes. If a match is found, the matching prefix is passed back to the application o The application uses the returned prefix when making the call to the socket API to create the connection o If no prefix matching the requested properties is available, then the kernel uses [RFC6724] for source address selection as normal Prefix property offers well defined universally understood information about the prefix. Example properties include whether a prefix can provide Internet reachability, if the prefix offers application specific Internet service level, if the prefix usage is free/charged, if the prefix offers security guarantees etc. This is maintained as a global registry. Prefix Coloring functions as follows: Le Pape, et al. Expires January 16, 2014 [Page 5] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 o The client receives multiple prefixes, with relevant meta-data attached o Color aware applications running on the client are provisioned with policy telling them which prefix color to request o On initiating a connection, the meta data aware application passes the required prefix color to the kernel along with the connect request o The kernel takes this color and selects the prefix matching the requested color and passes this back to the application o The application uses the returned prefix when making the call to the socket API to create the connection Prefix colour conveys information of the prefix that is of relevance to the network where the prefix is provisioned and application using it. Example usage of prefix color include color that is provisioned to offer better video application experience. The prefix color is defined as a 16 bit numerical value. Figure 1 illustrates a typical network with different components that can add, understand and use the meta-data attached to a prefix. o Mobile or ISP Network - Provisioned with prefixes that offer specific network characteristic. e.g. prefixes that do not have internet reach but can offer quality of service required for better video application experience. Includes address delegation server that associate prefixes with this information, selects and offers this information during prefix delegation o Home/Mobile gateway - Learns or determines characteristic of the prefix and propagates it along with prefix delegation. e.g. Determines if the prefix is locally anchored or learns the prefix meta-data from the ISP prefix delegation server and includes this information in prefix delegation to endpoints o Endpoint network stack - Learns the additional information associated with the prefix and offers interface to applications for listing and selecting the available prefixes o Prefix selection policy - Either embedded in the application/ endpoint or learnt from a server that helps choose the prefix with specific characteristic for the application based on predetermined service agreement between the application/endpoint/application service provider and network service provider Le Pape, et al. Expires January 16, 2014 [Page 6] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 o Applications - That can utilize the prefix with specific characteristic for enhanced application user experience e.g. On demand video application, by choosing the prefix with appropriate prefix selection policy while connecting and delivering the application over the network This prefix meta-data could be further extended to have more attributes such as the administrative domain of the prefix. +----------------------+ +------------------------+ | | | | | Application | | | | prefix | | ISP 1, ..., n | | policy | | | | | | | +----------------------+ +------------------------+ : | | : | | : |---n---| +--------------+ | | | Endpoint | | | | application | | | +- - - - - - - + +------------------+ | Endpoint | | | | networking |---------------| Home Gateway/ | | stack | | Mobile Gateway | +--------------+ +------------------+ Figure 1 3. Considerations 3.1. Prefix meta-data propogation The prefix meta-data can be delivered using DHCPv6 prefix delegation and address allocation as elaborated in [I-D.bhandari-dhc-class-based-prefix] or via IPv6 Neighbour discovery (ND) as defined in [I-D.korhonen-6man-prefix-properties]. 3.2. Configuring Applications Applications supporting multiple prefixes obtain the prefixes from the host kernel along with their meta-data. The policy can then be contained either locally (e.g. If the application is intended only for use within a specific network, linked to a particular ISP comes prepackages with prefix color to Le Pape, et al. Expires January 16, 2014 [Page 7] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 use), or be contained on a remote policy server. The mechanism used to exchange the meta-data information and selection between application/host with a remote server is beyond the scope of this document. 3.3. Application to network stack communication Once an application has determined the appropriate property and color for its use it has to communicate with the network stack to select the prefix. The host internal data structures need to be extended with the 'prefix property' and the 'prefix color' information associated to the learnt prefix and configured addresses. How this is accomplished is host implementation specific. It is also a host implementation issue how an application can learn or query both properties and color of an address or a prefix. One possibility is to provide such information through the socket API extensions. Other possibilities include the use of e.g., ioctl() or NetLink [RFC3549] extensions or by using the IPv6 address scope [RFC4007]. Discussion point: Should prefix property and color be mutually exclusive? This would avoid complexities which takes precedence when one prefix matches color and another matches property. Possibly a prefix may be advertised with both, but the application can only request property or color. 3.4. Default Address Selection [RFC6724] provides a mechanism for selecting which source address to use, in the absence of an application or upper layer protocol's explicit choice of a legal destination or source address. The use of prefix meta-data allows an application to express property preferences through socket API extensions, meaning that when used for creating a socket, [RFC6724] source address selection is not required. If a higher layer protocol or application does not include a prefix property preference when making a create socket request, then source address selection according to [RFC6724] is followed as normal. 3.5. Scope of Prefix Color Since a home can be connected to multiple ISPs, it is possible that it receives multiple prefixes with the same color from different ISPs. Since the application coloring policy is not received with the color, multiple ISPs may use different coloring policy for a single color. For example: One ISP could use color 50 for video whilst a second ISP is using color 50 for audio. Le Pape, et al. Expires January 16, 2014 [Page 8] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 This section presents some alternatives to handle this problem. 3.5.1. Local scoping A locally scoped color is a value which is selected by the network and application providers with no central registry. In a multi homed network, this may result in two providers selecting the same color for different behaviors. A color translation could be performed to ensure unique color at the device that connects to multiple providers. 3.5.2. Local scoping with fuzzy matching To avoid having to maintain multiple colors for each prefix for translating the color, a specific algorithm can be used to determine the new color from the old one on conflict. For example, when a collision is detected, the new color value may be incremented. Further, colors could be defined to be equally spaced (e.g., 10s or 100s). Many other encodings are possible as well, as long as obtaining the original color communicated by the ISP may be recovered in the event the application policy server requires this. 3.5.3. Global scoping A globally scoped color avoids the need for responding to collisions. This can be achieved by disambiguating the color by attaching the domain that provisions the color to the prefix meta-data or by assigning colors from a global registry that comes with the overhead of maintaining such a registry. 3.6. Compatibility with Existing Implementations The prefix meta-data mechanism that is described in this document provides a way of improving source address selection over the longest-prefix matching method used by [RFC6724]. However, all IPv6 capable hosts deployed at the time of writing do not have the capability of understanding and processing prefix meta- data. This means that any new mechanism must be backwards compatible with existing implementations. Also, clients which understand prefix meta-data need to support applications which do not have meta-data awareness. There are a number of possible approaches that could be taken here. The following list is included as ideas for further development: Le Pape, et al. Expires January 16, 2014 [Page 9] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 o In DHCPv6 only clients which request prefixes with meta-data (e.g. signalled through OPTION_ORO in the IA_NA or IA_PD request) will receive them. o In case of prefix delegated using IPv6 Neighbour discovery (ND) both forms of prefix i.e with and without meta-data can be offered. o If an application makes a socket API request and does not include meta-data as part of the request, follow [RFC6724] source address selection, but remove any prefixes that have meta-data from the list of candidate addresses. It follows that there should be a GU prefix advertised that does not have any meta-data associated that would act as the default choice for non prefix meta-data aware clients and applications. 4. IANA Considerations Should the global scoping for prefix color be chosen, a new registry should be created by IANA to store colors. 5. Security Considerations TBD 6. Acknowledgements The authors would like to acknowledge review and guidance received from 7. Change History (to be removed prior to publication as an RFC) 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.bhandari-dhc-class-based-prefix] Systems, C., Halwasia, G., Gundavelli, S., Deng, H., Thiebaut, L., and J. Korhonen, "DHCPv6 class based prefix", draft-bhandari-dhc-class-based-prefix-04 (work in progress), February 2013. [I-D.ietf-dhc-dhcpv4-over-ipv6] Le Pape, et al. Expires January 16, 2014 [Page 10] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 Cui, Y., Wu, P., Wu, J., and T. Lemon, "DHCPv4 over IPv6 Transport", draft-ietf-dhc-dhcpv4-over-ipv6-06 (work in progress), March 2013. [I-D.jiang-v6ops-semantic-prefix] Jiang, S., Sun, Q., Farrer, I., and Y. Bo, "A Framework for Semantic IPv6 Prefix", draft-jiang-v6ops-semantic- prefix-03 (work in progress), May 2013. [I-D.korhonen-6man-prefix-properties] Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D. Liu, "IPv6 Prefix Properties", draft-korhonen-6man-prefix- properties-02 (work in progress), July 2013. [I-D.troan-homenet-sadr] Troan, O. and L. Colitti, "IPv6 Multihoming with Source Address Dependent Routing (SADR)", draft-troan-homenet- sadr-00 (work in progress), February 2013. [RFC3549] Salim, J., Khosravi, H., Kleen, A., and A. Kuznetsov, "Linux Netlink as an IP Services Protocol", RFC 3549, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. Le Pape, et al. Expires January 16, 2014 [Page 11] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 Appendix A. Prototype notes A.1. Homenet prototype implementation notes This section provides the implementation details of a prototype video application on Android for a Galaxy Nexus device developed for the home network. A.1.1. Video provider service A possible use of this prefix coloring is a video service, which requires the network to guarantee a minimal throughput for streaming video. A prefix could be colored by the ISP to indicate that traffic sourced from that prefix will have a certain service level. Using prefix coloring avoids having to set up a separate network for this usage, or implement QoS traffic identification, classification and marking. An agreement could then be established between the video service provider and the ISP, telling the video provider to use the specific color when streaming video. In the following example, the color 50 was used. A.1.2. Prefix Color delegation The CPE routers request prefixes using prefix delegation [RFC3633] with the OPTION_PREFIX_CLASS option [I-D.bhandari-dhc-class-based-prefix]. This informs the upstream provider that the CPE supports colored prefixes. If an ISP does not support this option, it will be ignored, and the CPE will only get colorless prefixes. Otherwise, the ISP returns multiple prefixes each with their associated color. A color of '0' is identical to an uncolored prefix, for application compatibility, as explained in Appendix A.1.5. If the CPE does not support colored prefixes, the ISP could decide to delegate a normally colored prefix as an colorless one, though this means hosts will use this prefix according to the default source address selection algorithm, and will not associate any meaning to it. Le Pape, et al. Expires January 16, 2014 [Page 12] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 Once the CPE receives those prefixes, it distributes them, along with their color, using OSPF and the homenet protocols. [I-D.troan-homenet-sadr] defines "Source Address Dependent Routing" (SADR) which ensures that packets are routed based on their destination as well as source address. SADR is necessary to ensure that a multihomed network using provider aggregatable addresses will send the packet out the right path to avoid violating the provider's ingress filtering.To ensure that those prefixes keep their meaning, Source Address Dependent Routing [I-D.troan-homenet-sadr] is implemented and used. Colored addresses are advertised to hosts through DHCPv6, to associate the color to the address. Colorless addresses may be distributed through DHCPv6 or through Router Advertisements. Hosts supporting colored prefixes include the OPTION_PREFIX_CLASS, and receive colored addresses. For legacy hosts, who do not include this option, there are two possibilities : o Those hosts can receive all available prefixes, including colored ones, as uncolored. This allows a legacy host in a fully colored homenet to still have access to IPv6. However, those hosts may use prefixes for the wrong purposes. o Those hosts can receive only colorless prefixes. This ensures that a prefix will not be used for the wrong purpose. However, hosts in a fully colored environment will not get access to IPv6. This can however be what the ISP originally intended, for example if the ISP does not provide access to the IPv6 Internet, but uses IPv6 for wall gardened services, which their specific devices know how to use. A.1.3. Configuring Applications Applications supporting multiple prefixes obtain the prefixes from the host kernel, along with their color. The policy can be contained either in a local database (e.g. If the application is intended only for use within a specific network, linked to a particular ISP), or be contained on a distant server. For applications that do not contain a local database, an HTTP POST request is sent to a predefined server using a colorless prefix. This server, through means that are out of the scope of this document, selects the most appropriate color for the URIs used by the application. It then returns an XML document containing the mapping between the URIs and the colors. URIs in this document MAY use wild cards. Le Pape, et al. Expires January 16, 2014 [Page 13] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 When the application is started, it sends the available prefixes and their color to the video provider server which answers with a wild card URI videos.example.com associated to color 50. In this example application it receives: *://audio.example.com/* 40 rtsp://video.example.com/* 50 The server is expected to know the application, and thus to list all URIs that could be of use to the application. The application will not ask the server if it has to contact an address not in the list and will use the colorless prefix. This avoids an additional delay when trying to contact an unlisted URI. Example: While the application is browsing the video list, it is using www.example.com, and thus the colorless prefix. However as soon as a video is chosen, it starts streaming from videos.example.com, and asks to connect to host videos.example.com with color 50, indicating that it wishes to use the colored prefix. A.1.4. Android DHCPv6 Considering that this prototype is being implemented on Android, the first step is to get a running DHCPv6 client on Android, with support for the OPTION_PREFIX_CLASS option. The odhcp6c client, which already supports OPTION_PREFIX_CLASS, has been ported to Android, and is set to run in parallel to the dhcpcd client used for DHCP. The success of any of the two clients results in the success of the WiFi connection, so as to support IPv6 only networks. This client configures the IPv6 addresses using calls to IP address, which is modified to support the addition of a class option to set the prefix color. A.1.5. Application to network stack communication Le Pape, et al. Expires January 16, 2014 [Page 14] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 Once an application has received the appropriate color for its use, in this prototype it specifies the prefix it wishes to use by using the IPv6 address scope [RFC4007]. When resolving this address, the standard library then adds this information in the address information it returns, using the scope field, allowing the kernel to appropriately select the source IP when connecting. For this reason, a color of 0 is identical to an colorless prefix. In the example, when downloading from video.example.com, the application would request a connection to video.example.com%50. This allows the user to override the application's default simply by specifying a color in the scope of the URI it is trying to access, and requires little to no change in applications to support it. Applications that allow scope ids do not need to be modified in order to allow the user to use multiple prefixes (though it is then up to the user to select its color). A web browser that allows scope id would allow the user to add a color to the URI, without requiring any modifications. A.1.6. Android kernel To reduce the amount of modifications needed by the applications to support this prefix coloring, we need to avoid having to bind to the address in the colored prefix before initiating the connection. The kernel is expected to choose the correct source address when a colored destination is used. This implies storing the color in the kernel, along with the address, which is done using a new attribute IFA_color to the netlink message RTM_NEWADDR, used by ip address. Setting a colored prefix using ioctls is not supported. Since colors are put in the scope id part of the destination address, we continue to use the scope element of the sockaddr_in6 structure to store the color when sending connect messages to the kernel. The scope is only used when considering local addresses, so we interpret the presence of a scope on a non link-local address to be a color. Colors can not be assigned to link-local addresses, but since they are on the same link, source address shouldn't impact how the network treats packets. When selecting the source address, we then discard all addresses which do not have the correct color. Le Pape, et al. Expires January 16, 2014 [Page 15] Internet-Draft IPv6 Prefix Meta-data and Usage July 2013 A.1.7. Limitations of the current prototype It does not implement any duplicate color detection. Colors are considered to be unique within the home, and to correspond to the original color provided by the ISP. This is compatible with Global scoping. No changes would be required to the host in order to support Local scoping with fuzzy matching, but OSPF would need to detect collisions, and the server would need to recalculate the original color before making a decision. In this implementation, hosts that do not support colors do not receive colored prefixes. Authors' Addresses Maico Le Pape Cisco Systems Paris FR Email: maico@maicolepape.org Shwetha Bhandari Cisco Systems Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Email: shwethab@cisco.com Ian Farrer Deutsche Telekom AG GTN-FM4, Landgrabenweg 151 Bonn 53227 Germany Email: ian.farrer@telekom.de Le Pape, et al. Expires January 16, 2014 [Page 16]