Internet DRAFT - draft-lepape-6man-prefix-metadata

draft-lepape-6man-prefix-metadata







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:

   <?xml version="1.0" encoding="UTF-8"?>
   <mappings>
       <mapping>
           <URI>*://audio.example.com/*</URI>
           <color>40</color>
       </mapping>
       <mapping>
           <URI>rtsp://video.example.com/*</URI>
           <color>50</color>
       </mapping>
   </mappings>


   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]