[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Network Working Group                                      S. Jiang, Ed.
Internet-Draft                              Huawei Technologies Co., Ltd
Intended status: Informational                                    Q. Sun
Expires: August 3, 2013                                    China Telecom
                                                               I. Farrer
                                                     Deutsche Telekom AG
                                                        January 30, 2013

         A Framework for Semantic IPv6 Prefix and Gap Analysis


   Some Internet Service Providers and enterprises require detailed
   information about the payload of traffic, so that packets can be
   treated differently and efficiently.  Packet-level differentiation
   can also enable flow-level and user-level differentiation.

   With its large address space, IPv6 allows semantics to be embedded
   into addresses by assigning additional significance to specific bits
   within the prefix.  Using these semantics, routers and other
   intermediary devices can easily apply relevant policies as required.
   This document describes a framework for such an approach.  It also
   analyses the technical advantages and limitations associated with
   such an approach.

   This informational document only discusses the usage of semantics
   within a single network, or group of interconnected networks which
   share a common addressing policy, referred to as a Semantic Prefix

   The document is NOT intended to suggest the standardization of any
   common global semantics.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [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

Jiang, et al.            Expires August 3, 2013                 [Page 1]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   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 August 3, 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.

Jiang, et al.            Expires August 3, 2013                 [Page 2]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Existing Approaches to Traffic Differentiation . . . . . . . .  4
     2.1.  Differentiated Services  . . . . . . . . . . . . . . . . .  4
     2.2.  Deep Packet Inspection . . . . . . . . . . . . . . . . . .  5
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Justifcation for Semantics with the IPv6 Prefix  . . . . . . .  5
   5.  The Semantic Prefix Domain . . . . . . . . . . . . . . . . . .  6
   6.  The Embedded Semantics . . . . . . . . . . . . . . . . . . . .  7
   7.  Applicability Examples . . . . . . . . . . . . . . . . . . . .  8
     7.1.  An ISP Semantic Prefix Example . . . . . . . . . . . . . .  8
     7.2.  A Semantic Prefix for Security Domains . . . . . . . . . .  9
     7.3.  A Multi-Prefix Semantic  . . . . . . . . . . . . . . . . .  9
   8.  Semantic Prefix Benefits . . . . . . . . . . . . . . . . . . .  9
   9.  Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Semantic Relevant Operations in Networks . . . . . . . . . 11
     9.2.  Semantic Relevant Interactions with Hosts  . . . . . . . . 11
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     14.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Appendix A: Topics for Future Extention . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Jiang, et al.            Expires August 3, 2013                 [Page 3]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

1.  Introduction

   As the global Internet expands, it is being used for an increasingly
   diverse range of services.  These services place differentiated
   requirements upon packet delivery networks meaning that Internet
   Service Providers and enterprises need to be aware of more
   information about each packet in order to best meet a specific
   service's needs.

   Within a specific prefix, source/destination location information is
   used for routing decisions.  However, user types, service types,
   applications, security requirements, traffic identity types, quality
   requirements and other criteria may also be relevant parameters which
   a network operator may wish to use to treat packets differently and
   efficiently.  Packet-level differentiation can also be used for flow-
   level and user-level differentiation.

   However, almost all of the above mentioned criteria are not expressed
   explicitly within an packet.  Hence, it is difficult for network
   operators to identify from packet level.

2.  Existing Approaches to Traffic Differentiation

   There are several existing approaches which have been developed that
   can assist operators in identifying and marking traffic.  These
   solutions were mainly developed in the IPv4 era, where the IP address
   is used as a host locator and little else.  The limited capacity of a
   32-bit IPv4 address provides very little room for encoding additional
   information.  Correspondingly, these approaches are indirect,
   inefficient and expensive for operators.

2.1.  Differentiated Services

   Quality of Service (QoS) based on and Differentiated Services
   [RFC2474] is a widely deployed framework specifying a simple,
   scalable and coarse-grained mechanism for classifying and managing
   network traffic.  But in a service provider's network, DiffServ
   codepoint (DSCP) values cannot be trusted when they are set by the
   customer as these are arbitrary values.

   In real-world scenarios, ISPs deploy "remarking" points at the
   customer edge of their network, re-classifying received packets by
   rewriting the DSCP field according to local policy using information
   such as the source/destination address, IP protocol number and
   transport layer source/destination ports.

   The traffic classification process leads to increased packet

Jiang, et al.            Expires August 3, 2013                 [Page 4]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   processing overhead and complexity at the edge of the service
   provider's network.

   The DSCP in the IPv6 header traffic class field allows 6-bits for
   encoding service provider specific information related to the
   contents of the packet.  Whilst this is a useful part of an overall
   packet differentiation architecture, the relative small number of
   available bits (when compared to the available number of bits within
   the service providers prefix) means that it cannot be used in

2.2.  Deep Packet Inspection

   Deep Packet Inspection (DPI) may also be used by ISPs to learn the
   characteristics of users packets.  This involves looking into the
   packet well beyond the network-layer header to identify the specific
   application traffic type.  Once identified, the traffic type can be
   used as an input for setting the packet's DSCP or other actions.

   But DPI is expensive both in processing costs and latency.  The
   processing costs means that dedicated infrastructure is necessary to
   carry out the function.  The incurred latency may be too much for use
   with any delay/jitter sensitive applications.  As a result, DPI is
   difficult for large-scale deployment and it's usage is usually
   limited to small and specific functions in the network.

3.  Terminology

   The following terms are used throughout this document:

   Semantic Prefix:  A flexible-length IPv6 prefix which embeds certain

   Semantic Prefix Domain:  A portion of the Internet over which a
      consistent semantic-prefix based policy is in operation.

   Semantic Prefix Policy:  [IF - I think that this could simplify
      wording elsewhere in the document] Write this

4.  Justifcation for Semantics with the IPv6 Prefix

   The IPv6 address can remove such limitations due to its large address
   space.  This can be used by service provides to embed certain pre-
   defined semantics into an address so that intermediate devices can
   easily apply relevant forwarding operations each packet based solely
   on network layer source and destination address information.

Jiang, et al.            Expires August 3, 2013                 [Page 5]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   Using semantic prefix information for this function also makes it
   possible for the service provider to increase the level of trust in a
   customer-generated packet.  If the packet has an incorrectly set
   source or destination address, then a session will simply fail to

   This document describes a framework for embedding semantics into IPv6
   prefixes so that network devices can process and forward packets
   based on these semantics.  This approach diverts much network
   complexity to the planning and management of IPv6 address and IP
   address based policies.  It indeed simplifies the management of ISP

   Different service providers may make very different choices regarding
   the specific semantics which are relevant to their networks.
   Semantic prefix definitions are only meaningful within a domain which
   implements a single policy.  Therefore, it is not possible or
   desirable to attempt to standardize a general semantic prefix policy.

   Although the interface identifier portion of an IPv6 address has
   arbitrary bits and extension headers can carry significantly more
   information, these fields can not be trusted by network operators.
   Users may easily change the setting of interface identifier or
   extension header in order to obtain undeserved priorities/privileges,
   while servers or enterprise users may be much more self-restricted
   since they are charged accordingly.

   The prefix can offer a higher level of trust for the network operator
   because it is delegated by the network and therefore the network is
   better able to detect any undesired modifications and filter the
   packet accordingly.  If a user manipulated the destination address,
   the packet will never arrive at the desired service; if the source
   address is altered, then the return packet will not be received.

5.  The Semantic Prefix Domain

   A Semantic Prefix Domain is analagous to a Differentiated Services
   Domain [RFC2474].  It can be described as a portion of the Internet
   over which a consistent set of semantic-prefix-based policies are
   administered in a coordinated fashion.  Some of the characteristics
   of a single Semantic Prefix Domain could represent include:

   o  Administrative domains

   o  Autonomous systems

Jiang, et al.            Expires August 3, 2013                 [Page 6]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   o  Trust regions

   o  Network technologies

   o  Hosts

   o  Routers

   o  User groups

   o  Services

   o  Traffic groups

   o  Applications

   An enterprise Semantic Prefix Domain may span several physical
   networks and traverse ISP networks.  However, when an interim network
   is traversed (such as when an intermediary ISP is used for
   interconnectivity), the relevance of the semantics is limited to
   network domains that share a common Semantic Prefix Policy.

   The selection of semantics vary between different Semantic Prefix
   Domains.  Network operators should choose semantics according to
   their network and service management needs.  If an ISP has several
   non-contiguous address blocks, they may be organized as a single
   Semantic Prefix Domain if the same Semantic Prefix Policy is shared
   across these non-contiguous address blocks.

   A Semantic Prefix Domain has a set of pre-defined semantic
   definitions, which are only meaningful locally.  Without an efficient
   semantics notification, exchanging mechanism or service agreement,
   the definitions of semantics are only meaningful within local
   Semantic Prefix Domain.  Manual interactions between network
   operators may also work out.  However, this may involve trust models
   among network operators.

   Sharing semantic definition among Semantic Prefix Domains enables
   more semantic based network operations.

6.  The Embedded Semantics

   The size of the operator assigned prefix means that there is
   potentially much more scope for embedding semantics than has
   previously been possible.  The following list describes some
   suggested semantics which may be useful to network operators besides
   source/destination location:

Jiang, et al.            Expires August 3, 2013                 [Page 7]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   o  User types

   o  Applications

   o  Security domain

   o  Traffic identity types

   o  Quality requirements

   Consideration must also be given to the complexity that is created
   within the semantic prefix policy.  Whilst it may be desirable to
   encode as much information within the prefix so that it is possible
   to have a high level of granularity, this can come at the expense of
   future addressing flexibility and could also lead to a high amount of
   address wastage.  In the same time, embedding too many semantics may
   waste addressing space and induce semantic overlap.  It should be
   taken into careful consideration on semantics definition.

7.  Applicability Examples

   The following sections provide some examples of how semantics
   prefixes could be applied in different use cases.  The network
   operators could also choose to combine ideas from the following
   examples, or create their own as best suits their requirements.

7.1.  An ISP Semantic Prefix Example

   Current ISP networks are mainly aggregated by using the IP prefix as
   a geographical locator.  The ISP semantic prefix example below uses
   the left most bits of the prefix for the locator function and lower
   bits for semantics.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |           IANA assigned block         |      locator          |
   |        locator (Cont.)        | Semantic Field|Subscriber bits|
   An ISP semantic prefix example

   In this example, the service provider has been allocated a /20
   prefix.  This means that the Semantic Prefix Domain is potentially up
   to 44-bits long.  The 28 left-most bits (starting at bit-20) are
   allocated for use as geographical locators.  These provide the
   facility for topolgy based network aggregation.  The semantic prefix

Jiang, et al.            Expires August 3, 2013                 [Page 8]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   is assigned to bits 48 to 55.  The remaining /56 is delegated as
   prefixes for subscribers.

7.2.  A Semantic Prefix for Security Domains

   In some networks, the locator function of the IP address may be
   considered to be secondary to the geographical locator function.  An
   example application could be where an operator wishes to use the
   semantic field to separate services across their entire network to
   create security domains.

   Implementing the semantic field in the left-most bits means that a
   single, simple access-control list implemented across all networking
   devices would be enough to enforce effective traffic segregation.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |                       ISP assigned block                      |
   | ISP assigned block    |  Security Domain Bits |    Locator    |
   An Semantic Prefix example for Security Domains

7.3.  A Multi-Prefix Semantic

   A multiple-site enterprise may have been assigned several prefixes of
   different lengths by its upstream ISPs.  In this situation, in order
   to create a single, contiguous Semantic Prefix Domain, it is
   necessary to base the semantic prefix policy on the longest assigned
   prefix to ensure that there in enough addressing space to encode a
   consistent set of semantics across all of the assigned prefixes.

   In this example, an enterprise has received a /38 address block for
   one site (A) and a /44 for a second site (B) .  They can be organized
   in the same Semantic Prefix Domain.  The most-left 18 (site A) and 12
   (site B) bits are allocated as locator.  It provides topology based
   network aggregation.  The 8 right-most bits (from bits 56 to 63) are
   assigned as the semantic field.  In this design, the multiple-site
   enterprise that has been assigned two prefixes of different lengths
   can be organized as the same Semantic Prefix Domain.

8.  Semantic Prefix Benefits

   This section describes some of the benefits associated with the
   semantic prefix approach, depending on the semantics which are

Jiang, et al.            Expires August 3, 2013                 [Page 9]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   - Simplified measurement and statistics gathering

   The semantic prefix provides explicit identifiers which can be used
   for measurement and statistical information collection.  This can be
   achieved by checking certain bits of the source and/or destination
   address in each packet.

   - Simplified flow control

   By applying policies according to certain bit values, packets
   carrying the same semantics in their source/destination addresses

   - Service Segregation

   When service related information is encoded within the semantic
   prefix, this can be used to create simple access-control lists which
   can be applied uniformly across all network devices.  This means that
   it is easy to

   - Policy aggregation

   The semantic prefix allows many policies to be aggregated according
   to the same semantics within the policy based routing system

   - Easy dynamic reconfiguration of semantic oriented policy

   Network operators may want to dynamically change the policy actions
   that are operated on certain semantic packets.  The semantic prefix
   allows such changes be operated easily, as only a small number of
   consistent policy rules need to be updated on all devices within the
   semantic prefix domain.

   - Application-aware routing

   Embedding application information into IP addresses is the simplest
   way to realize application aware routing.

   - Easy virtualization

   Virtual network based on any semantics can be easily deployed using
   the semantic prefix mechanism.

9.  Gaps

   The simplest semantic prefix model is to embed only abstracted user

Jiang, et al.            Expires August 3, 2013                [Page 10]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   type semantics into the prefix.  Current network architectures can
   support this as each subscriber is still assigned a single prefix,
   while they are not notified the semantic within it.

   In order to maximise the benefits of the semantic prefix design,
   additional functions are needed to allow semantic relevant operations
   in networks and semantic relevant interactions with hosts.

   IPv6 provides a facility for multiple addresses to be configured on a
   single interface.  This creates a precondition for the approach that
   user chooses addresses differently for different purposes/usages.

9.1.  Semantic Relevant Operations in Networks

   In order to manage semantic prefixes and their relevant network
   actions, the network should provide the following semantic relevant

   - Notification of semantics within the managed network

   When an prefix is delegated using a DHCPv6 IA_PD [RFC3633], the
   associated semantics should also be propogated to the requesting
   router.  This is particularly useful for autonomic process when a new
   device is connected.

9.2.  Semantic Relevant Interactions with Hosts

   The more that semantics are embedded into a prefix, the more that
   complicated functions are needed for semantic relevant interactions
   between hosts and the network, such as prefix delegation, host
   notification and address selections, etc.

   In practice, a single host may belong to multiple semantics.  This
   means that several IPv6 addresses are configured on a single physical
   interface and should be selected for use depending on the service
   that a host wishes to access.  A certain packet would only serve a
   certain semantic.

   The host's IPv6 stack must have a mechanism for understanding these
   semantics in order to choose right source address when forming a
   packet.  If the embedded semantic is application relevant,
   applications on the hosts should also be involved in the address
   choosing process: the host IPv6 stack reports multiple available
   addresses to the application through socket API (one example is "IPv6
   Socket API for Source Address Selection" [RFC5014]).  The application
   then needs to apply the semantic logic so that it can correctly
   select from the offered candidate addresses.

Jiang, et al.            Expires August 3, 2013                [Page 11]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   Although [RFC6724] provides an algorithm for source address
   selection, some semantic prefix policies may conflict with this
   algorithm.  In this case, the source address selection mechanism may
   also further supporting functions to be developed.

10.  IANA Considerations

   This document has no IANA considerations.

11.  Change Log

   draft-jiang-semantic-prefix-04: new coauthor and re-organize the
   content, 2013-1-31.

   draft-jiang-semantic-prefix-03: add the concept of hierarchical
   Semantic Prefix Domain and more gap analysis, 2012-10-22.

   draft-jiang-semantic-prefix-02: resubmitted to v6ops WG.  Removed
   detailed examples and recommendations for semantics bits, 2012-10-15.

   draft-jiang-semantic-prefix-01: added enterprise considerations and
   scenarios, emphasizing semantics only for local meaning and no intend
   to standardize any common global semantics, 2012-07-16.

   draft-jiang-semantic-prefix-00: original version, 2012-07-09

12.  Security Considerations

   Embedding semantics in prefix is actually exposing more information
   of packets explicit.  These informations may also provide convenient
   for malicious attackers to track or attack certain type of packets.
   When networks announce their local prefix semantics to their peer
   networks, it may increase the vulnerable risk.

   Prefix-based filters should be deployed, in order to protect against
   address spoofing attacks or denial of service for packets with forged
   source addresses.

13.  Acknowledgements

   Useful comments were made by Erik Nygren, Nick Hilliard, Ray Hunter,
   David Farmer, and other participants in the V6OPS working group.

Jiang, et al.            Expires August 3, 2013                [Page 12]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

14.  References

14.1.  Normative References

   [RFC1104]  Braun, H., "Models of policy based routing", RFC 1104,
              June 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
              Host Configuration Protocol (DHCP) version 6", RFC 3633,
              December 2003.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

14.2.  Informative References

   [RFC5014]  Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
              Socket API for Source Address Selection", RFC 5014,
              September 2007.

   [RFC5401]  Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "Multicast Negative-Acknowledgment (NACK) Building
              Blocks", RFC 5401, November 2008.

Appendix A.  Appendix A: Topics for Future Extention

   There are several areas in which the semantic prefix could be
   extended in order to increase the usefulness and applicability of the

Jiang, et al.            Expires August 3, 2013                [Page 13]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   concept.  They are complementarity besides the main framework.  These
   are being described here as topics for possible future work.  Each of
   them may deserve a separated document for technical details.

   - Dynamic Policy Configuration

   Dynamic policy configuration would simplify the distribution of
   policy across devices in the semantic prefix domain.  New functions
   or protocol extension are needed to enable dynamic changes to the
   policy actions in operation on certain semantic packets.

   - Semantics Announcements to peer networks

   A network may announce all, or some of its Semantic Prefix Policy to
   connected peer networks.  This could be used to enable more dynamic
   configuration and enable traffic from different semantic prefix
   domains to traverse different networks whilst having the same
   semantic prefix policy applied.  Again, this would require new
   functions or protocol extensions to realise.

   This also would allow enterprise semantics to be able to traverse ISP

   - Extension of Prefix Semantics beyond the left-most 64-bits

   The prefix concept refers here to the left-most bits in the IP
   addresses delegated by the network management plane.  The prefix
   could be longer than 64-bits if the network operators strictly manage
   the address assignment by using Dynamic Host Configuration Protocol
   for IPv6 (DHCPv6) [RFC3315] (but in this case standard Stateless
   Address Autoconfiguration - SLAAC [RFC4862] cannot be used).

Authors' Addresses

   Sheng Jiang (editor)
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus, No.156 Beijing Road
   Hai-Dian District, Beijing,   100095
   P.R. China

   Email: jiangsheng@huawei.com

Jiang, et al.            Expires August 3, 2013                [Page 14]

Internet-Draft       Semantic IPv6 Prefix Framework         January 2013

   Qiong Sun
   China Telecom
   Room 708, No.118, Xizhimennei Street
   Beijing 100084
   P.R. China

   Email: sunqiong@ctbri.com.cn

   Ian Farrer
   Deutsche Telekom AG
   Bonn 53227

   Email: ian.farrer@telekom.de

Jiang, et al.            Expires August 3, 2013                [Page 15]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/