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

Versions: 00 01 02 03 04 05 06

DHC Working Group                                          Sheng Jiang
Internet Draft                            Huawei Technologies Co., Ltd
Intended status: Informational                        October 22, 2012
Expires: April 23, 2013

          A Framework for Semantic IPv6 Prefix and Gap Analysis
                   draft-jiang-semantic-prefix-02.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html

   This Internet-Draft will expire on April 23, 2013.



Copyright Notice

   Copyright (c) 2012 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.






Sheng Jiang            Expires April 23, 2013                 [Page 1]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012



Abstract

   Some Internet Service Providers and enterprises desire to be aware of
   more information about each packet, so that packets can be treated
   differently and efficiently. Packet-level differentiating can also
   enable flow-level and user-level differentiating.

   IPv6, with a large address space, allows semantics to be embedded
   into addresses. Routers can easily apply relevant operations
   accordingly.

   This document describes a framework that embeds semantics into IPv6
   prefixes, so that network devices can treat packets based on these
   explicit semantics. This document also analyzes on the technical gaps
   for embedding complex semantics.

   This informational document only discusses usage of semantics in a
   Semantic Prefix Domain. It does NOT intent or suggest to standardize
   any common global semantics.

Table of Contents

   1. Introduction ................................................ 3
   2. Terminology ................................................. 4
   3. Why Prefix .................................................. 4
   4. The Semantic Prefix Domain .................................. 5
   5. The Embedded Semantics ...................................... 5
   6. Applicability ............................................... 6
      6.1. An ISP semantic prefix example ......................... 6
      6.2. An enterprise semantic prefix example .................. 7
   7. Benefits .................................................... 7
   8. Gaps ........................................................ 8
   9. Security Considerations ..................................... 9
   10. IANA Considerations......................................... 9
   11. Change log ................................................. 9
   12. References ................................................. 9
      12.1. Normative References .................................. 9
      12.2. Informative References ............................... 10











Sheng Jiang            Expires April 23, 2013                 [Page 2]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012

1. Introduction

   While the global Internet increases explosively, more and more
   differentiated requirements are raised for the packet delivery of
   networks. Internet Service Providers and enterprises desire to be
   aware of more information about each packet, such as
   destination/source location, user types, service types, applications,
   security requirements, traffic identity types, quality requirements,
   etc. Based on these informations, network operators could treat
   packets differently and efficiently. Packet-level differentiating can
   also enable flow-level and user-level differentiating.

   However, except for destination/source location, almost of
   abovementioned information is not expressed explicitly. Hence, it is
   difficult for network operators to identify.

   Two passive and indirect technologies are already developed to
   distinguish the packets. Deep Packet Inspection (DPI) has been used
   by ISPs to learn the characters of packets. But DPI is expensive for
   both operational costs and process latency. Its time delay is too
   much to be able to be used for real time traffic control. Overlay
   networks are constructed in order to permit routing of packets to
   destinations not specified by IP addresses. But still, the overlay
   has no control over how packets are routed in the underlying network
   between two overlay nodes. Although tunnel or label forwarding may
   operate the traffic path, they introduce extra overhead while they
   depend on indirect information sources.

   An initiative solution, Quality of Service (QoS) and DiffServ
   [RFC2474] was also developed. It specifies a simple, scalable and
   coarse-grained mechanism for classifying and managing network
   traffic. However, the DiffServ fields set by the packet senders are
   not trustable by the network operators. In the real user case, ISPs
   deploy "remarking" points at the edge network, which classify each
   received packet and rewrite its DiffServ field according to user
   information learned from AAA or VLAN.

   The abovementioned solutions are mainly developed in IPv4 era, in
   which IP address is only locator, nothing else, giving the limited
   space. Although DiffServ was developed identically for IPv4 and IPv6,
   it inherits the same limitation.

   IPv6 has broken such limitation with its very large address space. It
   allows certain semantics to be embedded into addresses. ISPs or
   Enterprises can proactively embed pre-defined information into
   addresses so that intermediate devices can easily apply relevant
   operations on packet since addresses are the most explicit element in
   a packet. It provides an easy access and trustable fundamental for
   packet differentiated treatment. The technical fact that IPv6 allow
   multiple addresses on a single interface also provides precondition


Sheng Jiang            Expires April 23, 2013                 [Page 3]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012

   for the approach that user chooses addresses differently for
   different purposes/usages.

   This document describes a framework that embeds semantics into IPv6
   prefixes, so that network devices can treat packets based on these
   explicit 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 networks.

   Different networks may have very different choose for the most
   important semantics. Pre-defined semantic definitions are only
   meaningful locally. Therefore, standardizing a general semantic is
   almost an impossible job. This informational document only discusses
   usage of semantics in a Semantic Prefix Domain. It does NOT intent or
   suggest to standardize any common global semantics.

   This document also analyzes the technical gaps to maximum the
   benefits of semantics prefix approach, for which complex semantics
   may need to be embedded. For now, this document only discusses
   unicast address within IPv6 Addressing Architecture [RFC4291].

2. Terminology

   Semantic Prefix: a flexible-length IPv6 prefix that was embedded
   certain semantics.

   Semantic Prefix Domain: a portion of the Internet over which a
   consistent set of semantic prefix policies are administered in a
   coordinated fashion.

3. Why Prefix

   Although interface identifier of IPv6 address has arbitrary bits and
   extension header can carry much more information, they are not
   trustable by network operators. Selfish 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.

   Prefix is almost the only thing a network operator can trust in an IP
   packet because it is delegated by the network and the network can
   detect any undesired modifications, then, filter the packet. If one
   gets the destination address wrong, the packet would not reach; if it
   gets the source address wrong, the return packet would not arrive.
   This also would allow enterprise semantics to be able to traverse ISP
   networks.

   The prefix concept here refers the most left bits in IP addresses,
   that are delegated by the network management plane. It could be


Sheng Jiang            Expires April 23, 2013                 [Page 4]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012

   longer than 64, 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 - SLACC [RFC4862] cannot be used).

   Although IPv6 address space is plentiful, it should not be wasted.
   This argument can be dealt with by ensuring that only a small number
   of traffic classes are identified within a given user's traffic, so
   only a few bits in the prefix are needed.

4. The Semantic Prefix Domain

   A Semantic Prefix Domain, analagous to a Differentiated Services
   Domain [RFC2474], is a portion of the Internet over which a
   consistent set of semantic prefix policies are administered in a
   coordinated fashion. A Semantic Prefix Domain can represent different
   administrative domains or autonomous systems, different trust
   regions, different network technologies, hosts and routers, different
   user groups, different services, different traffic groups, different
   applications, etc. An enterprise Semantic Prefix Domain may span
   several physical networks, traversing ISP networks.

   The selections of semantics are various among different Semantic
   Prefix Domains. Network operators should choose semantics according
   to their needs for network management and services management. If an
   ISP has several discontinuous address blocks, it may be organized as
   a single Semantic Prefix Domain if the same semantic definition
   shared among these discontinuous address blocks. If these address
   blocks have different prefix lengths, their Semantic Prefix Domains
   may be distinguished each other by minimum differences of semantic
   definition.

   A Semantic Prefix Domain has a set of pre-defined semantic
   definitions, which are only meaningful locally. Without an efficient
   semantics notification or exchanging mechanism or service agreement,
   the definitions of semantics are only meaningful within local
   Semantic Prefix Domain. The semantics notification or exchanging does
   not have to through protocols. 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.

5. The Embedded Semantics

   As mentioned in Section 1, much information regarding to packets is
   useful for network operators. But, the prefix bits that can be used
   for embedded semantics are very limited. Therefore, only the
   selected, most useful semantics can be embedded in the prefix. Note,


Sheng Jiang            Expires April 23, 2013                 [Page 5]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012

   however, that DiffServ provides a very rich QoS semantic with only 6
   bits. The available bits increase largely in the strictly managed
   network by DHCPv6.

   The following are some semantics may be useful by network operators
   beside source/destination location: user types, service types,
   applications, security requirements, traffic identity types, quality
   requirements, etc. When used, all of them should be restricted in a
   highly abstracted way. Larger granularity of semantics may provide
   better aggregation and extensibility. This document does not intend
   to define or give recommendations on choose of semantics for
   embedding in prefix.

   In a given Semantic Prefix Domain, multiple semantics can be used
   combinatorially. To use the limited bits efficiently, bits semantics
   should be pre-defined very carefully. The network operators should be
   very careful to plan and manage the semantic field. The network
   operators should self-restrict NOT to put too many semantic into
   prefixes, in order to avoid to be trapped into very complicated
   management issues. Too many semantics make management for prefix
   delegation become very complicated and hosts would not be able to
   handle.

   An important principle is to avoid semantic overlap for packet though
   semantic overlap for devices/hosts is fine. Any potential scenarios
   that a given packet may be mapped two or more semantic prefixes are
   considered harmful.

6. Applicability

6.1. An ISP semantic prefix example

   The current ISP network is mainly aggregated according to locator.
   The below ISP semantic prefix example uses the most left bits of
   prefix for locator function and lower bits for semantics. In other
   scenarios, if the network operator would like to organize network
   aggregation by semantic prior, using higher bits for semantics is
   also possible. Mixed aggregation model can be reached by put
   semantics or part of semantics bits in the middle of locator bits.

    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|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: An ISP semantic prefix example



Sheng Jiang            Expires April 23, 2013                 [Page 6]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012

   In this example, the Semantic Prefix Domain has a /20 IPv6 address
   space. The 28 most-left (roughly 26 million of /64 prefixes) bits are
   allocated as locator. It serves network aggregation of topology
   based. The 8 most-right bits are subscriber bits. It means /56 prefix
   is assigned to subscribers. 8 bits (from bit 44 to 51) are assigned
   as semantic field.

6.2. An enterprise semantic prefix example

   The below enterprise semantic prefix example also uses the most left
   bits of prefix for locator function and lower bits for semantics.
   However, the locator function of IP address in enterprise networks
   may not be as important as in ISP networks. The enterprise network
   operator may prefer to organize network by semantic prior.

   A multiple-site enterprise may receive several prefixes that have
   different lengths. The semantic bits should be based on the longest
   prefix. The shorter prefix can use extra available bits for locators.
   It is compatible that shorter prefixes serve bigger networks with
   more users.

    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   |       Locator         | Semantic Field|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: An enterprise semantic prefix example

   In this example, an enterprise have received a 38/ address block for
   one site A and a /44 for another site B (semantic prefix shown in
   Figure 2). They can be organized in a same Semantic Prefix Domain.
   The most-left 18 (site A) / 12 (site B, as shown in Figure 2) bits
   are allocated as locator. It serves network aggregation of topology
   based. The most-right 8 bits (from bit 56 to 63) are assigned as
   semantic field.

7. Benefits

   This section presents some, definitely not all, benefits. Depending
   on embedded semantics, various beneficial scenarios can be expected.

   - Easy measurement and statistic

   The semantic prefix provides explicit identifiers for measurement and
   statistic. They are as simple as checking certain bits of address in
   each packets.



Sheng Jiang            Expires April 23, 2013                 [Page 7]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012

   - Easy flow control

   By applying policies according to certain bit value, it is easy to
   control packets that have the same semantics.

   - Policy aggregation

   Semantic prefix allows many policies to be aggregated according to
   the same semantics in the policy based routing system [RFC1104].

   - Application-aware routing

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

8. Gaps

   The simplest model of semantic prefix is only embedded abstracted
   user type semantic into the prefix. It can be supported with the
   current network architecture because each subscriber is still
   assigned one prefix, while they are not notified the semantic within
   it.

   The more semantics embedded into prefix, the more complicated
   functions are needed for prefix delegation, host notification and
   address selections.

   - Associate semantics with prefix delegation

   When DHCPv6-PD [RFC3633] delegates a prefix, the associated semantics
   should be bounded.

   - Notify prefix semantics to hosts

   When a host connects to network, it should be assign a short prefix
   locator with some enabled semantics rules.

   - Address selection according to semantics on hosts

   In practice, a host may belong to several semantics. It means several
   IPv6 addresses are available on a single physical interface. A
   certain packet would only serve a certain semantic. The IPv6 stack on
   that host must know and understand these semantics and its
   correspondent bits 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]). Then the
   application responses the one it attached.


Sheng Jiang            Expires April 23, 2013                 [Page 8]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012

   In this architecture, hosts have to be intelligent enough to choose
   its source address according to its given information. In some
   complicated scenarios, choosing destination address may also need
   further supporting functions.

   The current address selection algorithms and address selection API
   [RFC5014] are too simple to support this architecture. More
   complicated functions and intelligence are needed.

9. 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.

10. IANA Considerations

   This document has no IANA considerations.

11. Change log

      draft-jiang- semantic-prefix-02: Removed detailed examples and
   recommendations for semantics bits, 2012-10-22.

      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. References

12.1. Normative References

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

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

   [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
             IPv6", RFC 3315, July 2003.

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

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


Sheng Jiang            Expires April 23, 2013                 [Page 9]


Internet-Draft     draft-jiang-semantic-prefix-02         October 2012

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

12.2. Informative References

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



   Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Q14, Huawei Campus
   No.156 Beiqing Road
   Hai-Dian District, Beijing  100095
   P.R. China
   EMail: jiangsheng@huawei.com
































Sheng Jiang            Expires April 23, 2013                [Page 10]

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