Network Working Group S. Jiang, Ed.
Internet-Draft Huawei Technologies Co., Ltd
Intended status: Informational Q. Sun
Expires: November 29, 2013 China Telecom
I. Farrer
Deutsche Telekom AG
Y. Bo
Huawei Technologies Co., Ltd
May 28, 2013
A Framework for Semantic IPv6 Prefix
draft-jiang-v6ops-semantic-prefix-03
Abstract
This document describes a framework method that network operations
may use their addresses. Network operators, who have large IPv6
address space, may choose to embedded some semantics into IPv6
addresses by assigning additional significance to specific bits
within the prefix. By embedded semantics into IPv6 prefixes, the
semantics of packets can be inspected easily. Routers and other
intermediary devices can easily apply relevant policies as required.
Packet-level differentiation can also enable flow-level and user-
level differentiation. Consequently, the network operators can
accordingly treat network packets differently and efficiently. The
management and maintenance of networks can be much simpler.
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 November 29, 2013.
Copyright Notice
Jiang, et al. Expires November 29, 2013 [Page 1]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
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
2. Existing Approaches to Traffic Differentiation . . . . . . . 3
2.1. Differentiated Services . . . . . . . . . . . . . . . . . 3
2.2. Deep Packet Inspection . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Technical Framework of Semantic IPv6 Prefix . . . . . . . . . 4
4.1. Justifcation for Semantics with the IPv6 Prefix . . . . . 5
4.2. The Semantic Prefix Domain . . . . . . . . . . . . . . . 6
4.3. The Embedded Semantics . . . . . . . . . . . . . . . . . 7
4.4. Network Operations Based on Semantic Prefix . . . . . . . 7
5. Potential Benefits . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Change Log (removed by RFC editor) . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. An ISP Semantic Prefix Example . . . . . . . . . . . 11
A.1. Function Type Semantic Bits . . . . . . . . . . . . . . . 12
A.2. Network Device Type Bits within Network Device Address
Space . . . . . . . . . . . . . . . . . . . . . . . . . . 13
A.3. Subscriber Type Bits within Subscriber Address Space . . 13
A.4. Service Platform Type Bits within Service Platform
Address Space . . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. An Enterprise Semantic Prefix example . . . . . . . 15
Appendix C. A Multi-Prefix Semantic example . . . . . . . . . . 16
Appendix D. Gaps for complex semantic scenarios . . . . . . . . 17
D.1. Semantic Notification in the Network . . . . . . . . . . 17
D.2. Semantic Relevant Interactions between Hosts and the
Network . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix E. Topics for Future Work . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Jiang, et al. Expires November 29, 2013 [Page 2]
Internet-Draft Semantic IPv6 Prefix Framework May 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.
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
Domain.
The informational document is NOT intended to suggest the
standardization of any common global semantics.
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.
Jiang, et al. Expires November 29, 2013 [Page 3]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
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
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
isolation.
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
semantics.
Semantic Prefix Domain: A portion of the Internet over which a
consistent semantic-prefix based policy is in operation.
Semantic Prefix Policy: A policy based on the embedded semantics
within IPv6 prefix.
4. Technical Framework of Semantic IPv6 Prefix
Jiang, et al. Expires November 29, 2013 [Page 4]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
The IPv6 address can explicitly express semantics due to its large
address space. This can be used by network operators 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.
This document describes a technical 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
networks.
A network operator should first carefully plan/design its IPv6
address schema, in which useful semantics (see Section 4.3) are
embedded into prefix. It then delegates prefixes with correspondent
semantics to users. The users generate their IPv6 addresses based on
assigned prefixes. Then, when the IPv6 stack on the user devices
forms packets, the source addresses comprise compliance semantics.
The filters on the edge router drop packets which does not compliant
with assigned prefixes.
Semantic prefix definitions are only meaningful within a domain which
implements a single policy (see Section 4.2). Different service
providers may make very different choices regarding the specific
semantics which are relevant to their networks. Therefore, it is not
possible or desirable to attempt to standardize a general semantic
prefix policy.
Forwarding policies, security isolation and other network operations
(see Section 4.4) can be easily applied according to semantics, which
self-expressed by the source address of every packet. Also, the
semantics of the destination address may take in account if the
destination is in the same Semantic Prefix Domain or the peer
Semantic Prefix Domain whose semantics has been notified.
4.1. Justifcation for Semantics with the IPv6 Prefix
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.
Jiang, et al. Expires November 29, 2013 [Page 5]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
Prefix is almost the only thing a network operator can trust in an IP
packet. Semantic prefix approach does require the deployment of
access control filters. The packets with the noncompliance source
addresses should be filtered. The prefix is delegated by the network
and therefore the network is able to detect any undesired
modifications and filter the packet accordingly. This 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
establish.
4.2. The Semantic Prefix Domain
A Semantic Prefix Domain is analogous 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:
a. Administrative domains
b. Autonomous systems
c. Trust regions
d. Network technologies
e. Hosts
f. Routers
g. User groups
h. Services
i. Traffic groups
j. 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
Jiang, et al. Expires November 29, 2013 [Page 6]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
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.
4.3. 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:
a. User types
b. Applications
c. Security domain
d. Traffic identity types
e. 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.
4.4. Network Operations Based on Semantic Prefix
Based on the explicit semantics from the addresses of every packet,
many network operations can be applied. Comparing with traditional
operations, these operations are easier to realize and stable.
Although the detailed operation are various depending on various
Jiang, et al. Expires November 29, 2013 [Page 7]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
embedded semantics, the network operations based on semantic prefix
can be abstracted into following categories:
a. Statistic based on certain semantic. Any embedded semantic can
be set as a statistic condition. In other word, any embedded
semantic can be measured independently.
b. Differentiate packet processing. Many packet processing
operations can be applied based on the semantic differentiation,
such as queueing, path selection, forwarding to certain process
devices, etc.
c. Security isolation. A set of packet filters that are based on
semantic can fulfil network security isolation.
d. Access control. Resource access, authentication, service access
can be based on semantic directly.
e. Resource allocation. Resources, such as bandwidth, fast queue,
cache, etc., can be allocated or reserved for certain semantic
users/packets.
f. Virtualization. Within a Semantic Prefix Domain, it would be
easy to organize a virtual network, in which all the nodes have
been assigned same semantic identifier so that the packets from
them can be distinguished from other virtual networks.
5. Potential Benefits
Depending on embedded semantics, various beneficial scenarios can be
expected.
a. 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.
b. Simplified flow control: by applying policies according to
certain bit values, packets carrying the same semantics in their
source/destination addresses can.
c. 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
Jiang, et al. Expires November 29, 2013 [Page 8]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
d. Policy aggregation: the semantic prefix allows many policies to
be aggregated according to the same semantics within the policy
based routing system [RFC1104].
e. 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.
f. Application-aware routing: embedding application information into
IP addresses is the simplest way to realize application aware
routing.
g. Easy user behavior management: based on the user type reading
from the addresses, any improper user behaviors can be easy
detected and automatically handle by network policies.
h. Easy network resources access rights management: the
authentication of access right may already be embedded into the
addresses. Simple matching policies can filter improper access
requests.
i. Easy virtualization: virtual network based on any semantics can
be easily deployed using the semantic prefix mechanism.
6. IANA Considerations
This document has no IANA considerations.
7. Change Log (removed by RFC editor)
draft-jiang-v6ops-semantic-prefix-03: reword to emphasis this
mechanism is a (not the) method that network operators use their
addresses; add text to clarify the increased trust is actually from
the deployment of source address filter, which is a compliance
requirement by semantic prefix; restructure the document, move
examples and gap analysis into appendixes, reorganize most content
into a frame section; add summarized description for framework at the
beginning of Section 4; add description for network operations based
on semantic prefix; add a new coauthor who contributes an enterprise
semantic prefix network example; combine most of draft-sun-v6ops-
semantic-usecase into the draft as ISP example in appendix;
2013-5-28.
draft-jiang-v6ops-semantic-prefix-02: add new coauthor, re-organize
the content, and refine the English, 2013-1-31.
Jiang, et al. Expires November 29, 2013 [Page 9]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
draft-jiang-v6ops-semantic-prefix-01: add the concept of hierarchical
Semantic Prefix Domain and more gap analysis, 2012-10-22.
draft-jiang-v6ops-semantic-prefix-00: 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
8. 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.
If networks announce their local prefix semantics to their peer
networks, it may also 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.
9. Acknowledgements
Useful comments were made by Erik Nygren, Nick Hilliard, Ray Hunter,
David Farmer, Fred Baker, Joel Jaeggli, John Curran and other
participants in the V6OPS working group.
10. References
10.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.L. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
Jiang, et al. Expires November 29, 2013 [Page 10]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
[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.
10.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. An ISP Semantic Prefix Example
This ISP semantic prefix example is abstracted from a real ISP
address architecture design.
Note: for now, this example only covers unicast address within IP
Version 6 Addressing Architecture [RFC4291].
For ISPs, several motivations to use semantic prefixes are as
follows:
a. Network Device management: Separated and specialized address
space for network device will help to identify the network device
among numerous addresses and apply policy accordingly.
b. Differentiated user management: In ISPs' network, different kinds
of customers may have different requirements for service
provisioning.
Jiang, et al. Expires November 29, 2013 [Page 11]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
c. High-priority service guarantee: Different priorities may be
divided into apply differentiated policy.
d. Service-based Routing: ISPs may offer different routing policy
for specific service platforms .e.g.video streaming, VOIP, etc.
e. Security Control: For security requirement, operators need to
take control and identify of certain devices/customers in a quick
manner.
f. Easy measurement and statistic: The semantic prefix provides
explicit identifiers for measurement and statistic.
These requirements are largely falling into two categories: some is
regarding to the network device features, and the others are related
to services provision and subscriber identification. The functional
usage of the semantics for the two categories are quite different.
Therefore, an ISP semantic IPv6 prefix example is designed as a two-
level hierarchical architecture, in which the first level is the
function types of prefixes, and the second level is the further usage
within an specific prefix type.
A.1. Function Type Semantic Bits
Function Type (FT): the value of this field is to indicate the
functional usage of this prefix. The typical types for operators
include network device, subscriber and service platform.
+--------+--------+------------------------------------------------+
| | FT | |
+--------+--------+------------------------------------------------+
/ \
+------------+------------+
|000: network device |
|000~010: service platform|
|011~101: subscriber |
|110: reserved |
+-------------------------+
Function Type Bits Example
Figure 1
The portion of each type should be estimated according to the actual
requirements for operators, in order to use the address space most
efficiently. Within the above FT design, the whole ISP IPv6 address
space is divided into four parts: the network device address space (1
/8 of total address space), the service platform address space (2/8
Jiang, et al. Expires November 29, 2013 [Page 12]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
of total address space), the subscriber address space (3/8 of total
address space), and a reserved address space (1/8 of total address
space) for future usage.
A.2. Network Device Type Bits within Network Device Address Space
Network Device Type (NDT) indicates different types of network
devices. Normally, one operator may have multiple networks,
e.g.backbone network, mobile network, ISP brokered service network,
etc. Using NDT field to indicate specific network within an operator
may help to apply some routing policies. Locating NDT bits 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. The Locator field is followed behind
NDT.
+--------+--------+------+-----------------------------------------+
| | FT(000)| NDT | Locator | Network Device bits |
+--------+--------+------+-----------------------------------------+
/ \
/ \
+------------+-----+
|000~001: SubNet 1|
|010~110: SubNet 2|
|111: Reserved|
+------------------+
Network Device Type Bits Example
Figure 2
The portion of each subnet type should be estimated according to the
actual requirements for operators, in order to use the address space
most efficiently. Within the above NDT design, SubNet 1 is assigned
2/8 of the network device address space, SubNet 2 is assigned 5/8,
and 1/8 is reserved.
A.3. Subscriber Type Bits within Subscriber Address Space
Subscriber Type (ST) indicates different types of subscribers, e.g.
wireline broadband subscriber, mobile subscriber, enterprise, WiFi,
etc. This type of prefix is allocated to end users. Further,
division may be taken on subscriber's priorities within a certain
subscriber type.
The Locator field within subscriber address space is put before ST
for better routing aggregation.
Jiang, et al. Expires November 29, 2013 [Page 13]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
+--------+--------+---------------+------+-------------------------+
| | FT(011)| Locator | ST | Subscriber bits |
+--------+--------+---------------+------+-------------------------+
/ \
/ \
+----------+------------+---------------+
|0000~0011: broadband access subscriber |
|0100~0111: mobile subscriber |
|1000~1001: enterprise |
|1010~1011: WiFi subscriber |
|1100~1111: Reserved |
+---------------------------------------+
Subscriber Type Bits Example
Figure 3
The portion of each subscriber type should be estimated according to
the actual requirements for operators, in order to use the address
space most efficiently. Within the above ST design, the broadband
access subscriber type is assigned 4/16 of the subscriber address
space, the mobile subscriber is assigned 4/16, enterprise type and
WiFi subscriber type are assigned 2/16 each, and 2/16 is reserved.
A.4. Service Platform Type Bits within Service Platform Address Space
Service Platform Type (SPT) indicates typical service platforms
offered by operators. This field may have scalability problem since
there are numerous types of services . It is recommended that only
aggregated service platform types should be defined in this field.
This type of prefix is usually allocated to service platforms in
operator's data center.
+--------+--------+---------------+------+-------------------------+
| | FT(001)| Locator | SPT | Service bits |
+--------+--------+---------------+------+-------------------------+
/ \
/ \
+----------+------------+---------------+
|000~001: Self-running service platform |
|001~011: Tenant service platform |
|100~101: Independent service platform |
|110~111: Reserved |
+---------------------------------------+
Service Platform Type Bits Example
Figure 4
Jiang, et al. Expires November 29, 2013 [Page 14]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
The portion of each subnet type should be estimated according to the
actual requirements for operators, in order to use the address space
most efficiently.
Appendix B. An Enterprise Semantic Prefix example
This enterprise semantic prefix example is also abstracted from an
ongoing enterprise address architecture design. This example is
designed for a realtime video monitor network across a city region.
The semantic prefix solution is planning to be deployed along with a
strict authorization system.
Note: this example only covers unicast address within IP Version 6
Addressing Architecture [RFC4291].
For this example, the below semantics are important for the network
operation and require different network behaviors.
a. Terminal type: there are two terminal types only: monitor cameras
or video receivers. They are estimated to have similar number.
Network devices use another different address space.
b. Geographic location: the city has been managed in a three-level
hierarchical regionalism: district, area and street. Each level
has less than 28 sub-regions. This can also be considered as a
replacement of topology locator within this specific network.
c. Authorization level: the network operator is planning to
administrate the authorization in three or four levels. An
receiver can access the cameras that are the same or lower
authorization level.
d. Civilian or police/government.
e. Device attribute: this indicates the attribute of a camera
device. The attribute is expressed in an abstract way, such as
road traffic, hospital, nursery, bank, airport, etc. The
abstracted attribute type is designed to be less than 64.
f. Receiver Attribute: this indicates the attribute of a video
receiver. The attribute is based on the receiver group, such as
police, firefighter, local security, etc. The attribute/receiver
group type is designed to be less than 128.
This example enterprise network has obtained a /32 address block from
ISP. There is another /48 dedicated for network devices.
The first bit is Terminal type, which indicates terminal type.
Jiang, et al. Expires November 29, 2013 [Page 15]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Geographic Locator | AL|C|Device Attr| Device Bit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A semantic prefix design example for cameras
Figure 5
3-level hierarchical geographic locator takes 15 bits (each level 5
bits, 32 sub-regions). Authorization level takes 2 bits and 1 bit
differentiates civilian or police/government. 6 bits is assigned for
device attribute.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| GeoLoc | AL|C|Receiver Attr| Topology Locator |ReceiverBit|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An semantic prefix design example for video receivers
Figure 6
The receiver is not as much as geographically distributed as cameras.
Therefore, Geographic locator is only detailed to district level.
Topology locator is needed for network forwarding and aggregation
within a district. It is assigned 10 bits. Authorization level bits
and civilian bit are the same with camera address space. Receive
attribute takes 7 bits, giving it is designed to be up to 128.
Appendix C. A Multi-Prefix Semantic example
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
Jiang, et al. Expires November 29, 2013 [Page 16]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
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. The semantic
and the Semantic Prefix Domain can traverse the intermediate ISP
networks, or even public networks.
The similar situation may happen on ISPs in the future, when an ISP
used up its assigned address space, or built up multiple networks in
different places.
Appendix D. Gaps for complex semantic scenarios
The simplest semantic prefix model is to embed only abstracted user
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.
D.1. Semantic Notification in the Network
In order to manage semantic prefixes and their relevant network
actions, the network should be able to notify semantics along with
prefix delegation.
When an prefix is delegated using a DHCPv6 IA_PD [RFC3633], the
associated semantics should also be propagated to the requesting
router. This is particularly useful for autonomic process when a new
device is connected.
D.2. Semantic Relevant Interactions between Hosts and the Network
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.
Jiang, et al. Expires November 29, 2013 [Page 17]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
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.
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.
Appendix E. Topics for Future Work
There are several areas in which the semantic prefix could be
extended in order to increase the usefulness and applicability of the
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. To achieve this automatically by
message exchanging would require new functions or protocol
extensions.
- 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).
Jiang, et al. Expires November 29, 2013 [Page 18]
Internet-Draft Semantic IPv6 Prefix Framework May 2013
Authors' Addresses
Sheng Jiang (editor)
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 BeiQing Road
Hai-Dian District, Beijing 100095
P.R. China
Email: jiangsheng@huawei.com
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
Germany
Email: ian.farrer@telekom.de
Yang Bo
Huawei Technologies Co., Ltd
Q21, Huawei Campus, No.156 BeiQing Road
Hai-Dian District, Beijing 100095
P.R. China
Email: boyang.bo@huawei.com
Jiang, et al. Expires November 29, 2013 [Page 19]