< draft-jiang-v6ops-semantic-prefix-02.txt		draft-jiang-v6ops-semantic-prefix-03.txt >
	Network Working Group S. Jiang, Ed.		Network Working Group S. Jiang, Ed.
	Internet-Draft Huawei Technologies Co., Ltd		Internet-Draft Huawei Technologies Co., Ltd
	Intended status: Informational Q. Sun		Intended status: Informational Q. Sun
	Expires: August 3, 2013 China Telecom		Expires: November 29, 2013 China Telecom
	I. Farrer		I. Farrer
	Deutsche Telekom AG		Deutsche Telekom AG
	January 30, 2013		Y. Bo
			Huawei Technologies Co., Ltd
			May 28, 2013
	A Framework for Semantic IPv6 Prefix and Gap Analysis		A Framework for Semantic IPv6 Prefix
	draft-jiang-v6ops-semantic-prefix-02		draft-jiang-v6ops-semantic-prefix-03
	Abstract		Abstract
	Some Internet Service Providers and enterprises require detailed		This document describes a framework method that network operations
	information about the payload of traffic, so that packets can be		may use their addresses. Network operators, who have large IPv6
	treated differently and efficiently. Packet-level differentiation		address space, may choose to embedded some semantics into IPv6
	can also enable flow-level and user-level differentiation.		addresses by assigning additional significance to specific bits
			within the prefix. By embedded semantics into IPv6 prefixes, the
	With its large address space, IPv6 allows semantics to be embedded		semantics of packets can be inspected easily. Routers and other
	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.		intermediary devices can easily apply relevant policies as required.
	This document describes a framework for such an approach. It also		Packet-level differentiation can also enable flow-level and user-
	analyses the technical advantages and limitations associated with		level differentiation. Consequently, the network operators can
	such an approach.		accordingly treat network packets differently and efficiently. The
			management and maintenance of networks can be much simpler.
	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 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",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 3, 2013.		This Internet-Draft will expire on November 29, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Existing Approaches to Traffic Differentiation . . . . . . . . 4		2. Existing Approaches to Traffic Differentiation . . . . . . . 3
	2.1. Differentiated Services . . . . . . . . . . . . . . . . . 4		2.1. Differentiated Services . . . . . . . . . . . . . . . . . 3
	2.2. Deep Packet Inspection . . . . . . . . . . . . . . . . . . 5		2.2. Deep Packet Inspection . . . . . . . . . . . . . . . . . 4
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Justifcation for Semantics with the IPv6 Prefix . . . . . . . 5		4. Technical Framework of Semantic IPv6 Prefix . . . . . . . . . 4
	5. The Semantic Prefix Domain . . . . . . . . . . . . . . . . . . 6		4.1. Justifcation for Semantics with the IPv6 Prefix . . . . . 5
	6. The Embedded Semantics . . . . . . . . . . . . . . . . . . . . 7		4.2. The Semantic Prefix Domain . . . . . . . . . . . . . . . 6
	7. Applicability Examples . . . . . . . . . . . . . . . . . . . . 8		4.3. The Embedded Semantics . . . . . . . . . . . . . . . . . 7
	7.1. An ISP Semantic Prefix Example . . . . . . . . . . . . . . 8		4.4. Network Operations Based on Semantic Prefix . . . . . . . 7
	7.2. A Semantic Prefix for Security Domains . . . . . . . . . . 9		5. Potential Benefits . . . . . . . . . . . . . . . . . . . . . 8
	7.3. A Multi-Prefix Semantic . . . . . . . . . . . . . . . . . 9		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Semantic Prefix Benefits . . . . . . . . . . . . . . . . . . . 9		7. Change Log (removed by RFC editor) . . . . . . . . . . . . . 9
	9. Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9.1. Semantic Relevant Operations in Networks . . . . . . . . . 11		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9.2. Semantic Relevant Interactions with Hosts . . . . . . . . 11		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 12		Appendix A. An ISP Semantic Prefix Example . . . . . . . . . . . 11
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		A.1. Function Type Semantic Bits . . . . . . . . . . . . . . . 12
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		A.2. Network Device Type Bits within Network Device Address
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 13		Space . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	14.2. Informative References . . . . . . . . . . . . . . . . . . 13		A.3. Subscriber Type Bits within Subscriber Address Space . . 13
	Appendix A. Appendix A: Topics for Future Extention . . . . . . . 13		A.4. Service Platform Type Bits within Service Platform
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		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
	1. Introduction		1. Introduction
	As the global Internet expands, it is being used for an increasingly		As the global Internet expands, it is being used for an increasingly
	diverse range of services. These services place differentiated		diverse range of services. These services place differentiated
	requirements upon packet delivery networks meaning that Internet		requirements upon packet delivery networks meaning that Internet
	Service Providers and enterprises need to be aware of more		Service Providers and enterprises need to be aware of more
	information about each packet in order to best meet a specific		information about each packet in order to best meet a specific
	service's needs.		service's needs.
	skipping to change at page 4, line 26 ¶		skipping to change at page 3, line 26 ¶
	applications, security requirements, traffic identity types, quality		applications, security requirements, traffic identity types, quality
	requirements and other criteria may also be relevant parameters which		requirements and other criteria may also be relevant parameters which
	a network operator may wish to use to treat packets differently and		a network operator may wish to use to treat packets differently and
	efficiently. Packet-level differentiation can also be used for flow-		efficiently. Packet-level differentiation can also be used for flow-
	level and user-level differentiation.		level and user-level differentiation.
	However, almost all of the above mentioned criteria are not expressed		However, almost all of the above mentioned criteria are not expressed
	explicitly within an packet. Hence, it is difficult for network		explicitly within an packet. Hence, it is difficult for network
	operators to identify from packet level.		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		2. Existing Approaches to Traffic Differentiation
	There are several existing approaches which have been developed that		There are several existing approaches which have been developed that
	can assist operators in identifying and marking traffic. These		can assist operators in identifying and marking traffic. These
	solutions were mainly developed in the IPv4 era, where the IP address		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		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		32-bit IPv4 address provides very little room for encoding additional
	information. Correspondingly, these approaches are indirect,		information. Correspondingly, these approaches are indirect,
	inefficient and expensive for operators.		inefficient and expensive for operators.
	skipping to change at page 5, line 40 ¶		skipping to change at page 4, line 48 ¶
	3. Terminology		3. Terminology
	The following terms are used throughout this document:		The following terms are used throughout this document:
	Semantic Prefix: A flexible-length IPv6 prefix which embeds certain		Semantic Prefix: A flexible-length IPv6 prefix which embeds certain
	semantics.		semantics.
	Semantic Prefix Domain: A portion of the Internet over which a		Semantic Prefix Domain: A portion of the Internet over which a
	consistent semantic-prefix based policy is in operation.		consistent semantic-prefix based policy is in operation.
	Semantic Prefix Policy: [IF - I think that this could simplify		Semantic Prefix Policy: A policy based on the embedded semantics
	wording elsewhere in the document] Write this		within IPv6 prefix.
	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.
	Using semantic prefix information for this function also makes it		4. Technical Framework of Semantic IPv6 Prefix
	possible for the service provider to increase the level of trust in a		The IPv6 address can explicitly express semantics due to its large
	customer-generated packet. If the packet has an incorrectly set		address space. This can be used by network operators to embed
	source or destination address, then a session will simply fail to		certain pre-defined semantics into an address so that intermediate
	establish.		devices can easily apply relevant forwarding operations each packet
			based solely on network layer source and destination address
			information.
	This document describes a framework for embedding semantics into IPv6		This document describes a technical framework for embedding semantics
	prefixes so that network devices can process and forward packets		into IPv6 prefixes so that network devices can process and forward
	based on these semantics. This approach diverts much network		packets based on these semantics. This approach diverts much network
	complexity to the planning and management of IPv6 address and IP		complexity to the planning and management of IPv6 address and IP
	address based policies. It indeed simplifies the management of ISP		address based policies. It indeed simplifies the management of ISP
	networks.		networks.
	Different service providers may make very different choices regarding		A network operator should first carefully plan/design its IPv6
	the specific semantics which are relevant to their networks.		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		Semantic prefix definitions are only meaningful within a domain which
	implements a single policy. Therefore, it is not possible or		implements a single policy (see Section 4.2). Different service
	desirable to attempt to standardize a general semantic prefix policy.		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		Although the interface identifier portion of an IPv6 address has
	arbitrary bits and extension headers can carry significantly more		arbitrary bits and extension headers can carry significantly more
	information, these fields can not be trusted by network operators.		information, these fields can not be trusted by network operators.
	Users may easily change the setting of interface identifier or		Users may easily change the setting of interface identifier or
	extension header in order to obtain undeserved priorities/privileges,		extension header in order to obtain undeserved priorities/privileges,
	while servers or enterprise users may be much more self-restricted		while servers or enterprise users may be much more self-restricted
	since they are charged accordingly.		since they are charged accordingly.
	The prefix can offer a higher level of trust for the network operator		Prefix is almost the only thing a network operator can trust in an IP
	because it is delegated by the network and therefore the network is		packet. Semantic prefix approach does require the deployment of
	better able to detect any undesired modifications and filter the		access control filters. The packets with the noncompliance source
	packet accordingly. If a user manipulated the destination address,		addresses should be filtered. The prefix is delegated by the network
	the packet will never arrive at the desired service; if the source		and therefore the network is able to detect any undesired
	address is altered, then the return packet will not be received.		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.
	5. The Semantic Prefix Domain		4.2. The Semantic Prefix Domain
	A Semantic Prefix Domain is analagous to a Differentiated Services		A Semantic Prefix Domain is analogous to a Differentiated Services
	Domain [RFC2474]. It can be described as a portion of the Internet		Domain [RFC2474]. It can be described as a portion of the Internet
	over which a consistent set of semantic-prefix-based policies are		over which a consistent set of semantic-prefix-based policies are
	administered in a coordinated fashion. Some of the characteristics		administered in a coordinated fashion. Some of the characteristics
	of a single Semantic Prefix Domain could represent include:		of a single Semantic Prefix Domain could represent include:
	o Administrative domains		a. Administrative domains
	o Autonomous systems		b. Autonomous systems
	o Trust regions
	o Network technologies		c. Trust regions
	o Hosts		d. Network technologies
	o Routers		e. Hosts
	o User groups		f. Routers
	o Services		g. User groups
	o Traffic groups		h. Services
	o Applications		i. Traffic groups
			j. Applications
	An enterprise Semantic Prefix Domain may span several physical		An enterprise Semantic Prefix Domain may span several physical
	networks and traverse ISP networks. However, when an interim network		networks and traverse ISP networks. However, when an interim network
	is traversed (such as when an intermediary ISP is used for		is traversed (such as when an intermediary ISP is used for
	interconnectivity), the relevance of the semantics is limited to		interconnectivity), the relevance of the semantics is limited to
	network domains that share a common Semantic Prefix Policy.		network domains that share a common Semantic Prefix Policy.
	The selection of semantics vary between different Semantic Prefix		The selection of semantics vary between different Semantic Prefix
	Domains. Network operators should choose semantics according to		Domains. Network operators should choose semantics according to
	their network and service management needs. If an ISP has several		their network and service management needs. If an ISP has several
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 19 ¶
	definitions, which are only meaningful locally. Without an efficient		definitions, which are only meaningful locally. Without an efficient
	semantics notification, exchanging mechanism or service agreement,		semantics notification, exchanging mechanism or service agreement,
	the definitions of semantics are only meaningful within local		the definitions of semantics are only meaningful within local
	Semantic Prefix Domain. Manual interactions between network		Semantic Prefix Domain. Manual interactions between network
	operators may also work out. However, this may involve trust models		operators may also work out. However, this may involve trust models
	among network operators.		among network operators.
	Sharing semantic definition among Semantic Prefix Domains enables		Sharing semantic definition among Semantic Prefix Domains enables
	more semantic based network operations.		more semantic based network operations.
	6. The Embedded Semantics		4.3. The Embedded Semantics
	The size of the operator assigned prefix means that there is		The size of the operator assigned prefix means that there is
	potentially much more scope for embedding semantics than has		potentially much more scope for embedding semantics than has
	previously been possible. The following list describes some		previously been possible. The following list describes some
	suggested semantics which may be useful to network operators besides		suggested semantics which may be useful to network operators besides
	source/destination location:		source/destination location:
	o User types		a. User types
	o Applications		b. Applications
	o Security domain		c. Security domain
	o Traffic identity types		d. Traffic identity types
	o Quality requirements		e. Quality requirements
	Consideration must also be given to the complexity that is created		Consideration must also be given to the complexity that is created
	within the semantic prefix policy. Whilst it may be desirable to		within the semantic prefix policy. Whilst it may be desirable to
	encode as much information within the prefix so that it is possible		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		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		future addressing flexibility and could also lead to a high amount of
	address wastage. In the same time, embedding too many semantics may		address wastage. In the same time, embedding too many semantics may
	waste addressing space and induce semantic overlap. It should be		waste addressing space and induce semantic overlap. It should be
	taken into careful consideration on semantics definition.		taken into careful consideration on semantics definition.
	7. Applicability Examples		4.4. Network Operations Based on Semantic Prefix
	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
	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
	embedded.
	- 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
	can.
	- 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
	[RFC1104].
	- Easy dynamic reconfiguration of semantic oriented policy
	Network operators may want to dynamically change the policy actions		Based on the explicit semantics from the addresses of every packet,
	that are operated on certain semantic packets. The semantic prefix		many network operations can be applied. Comparing with traditional
	allows such changes be operated easily, as only a small number of		operations, these operations are easier to realize and stable.
	consistent policy rules need to be updated on all devices within the		Although the detailed operation are various depending on various
	semantic prefix domain.		embedded semantics, the network operations based on semantic prefix
			can be abstracted into following categories:
	- Application-aware routing		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.
	Embedding application information into IP addresses is the simplest		b. Differentiate packet processing. Many packet processing
	way to realize application aware routing.		operations can be applied based on the semantic differentiation,
			such as queueing, path selection, forwarding to certain process
			devices, etc.
	- Easy virtualization		c. Security isolation. A set of packet filters that are based on
			semantic can fulfil network security isolation.
	Virtual network based on any semantics can be easily deployed using		d. Access control. Resource access, authentication, service access
	the semantic prefix mechanism.		can be based on semantic directly.
	9. Gaps		e. Resource allocation. Resources, such as bandwidth, fast queue,
			cache, etc., can be allocated or reserved for certain semantic
			users/packets.
	The simplest semantic prefix model is to embed only abstracted user		f. Virtualization. Within a Semantic Prefix Domain, it would be
	type semantics into the prefix. Current network architectures can		easy to organize a virtual network, in which all the nodes have
	support this as each subscriber is still assigned a single prefix,		been assigned same semantic identifier so that the packets from
	while they are not notified the semantic within it.		them can be distinguished from other virtual networks.
	In order to maximise the benefits of the semantic prefix design,		5. Potential Benefits
	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		Depending on embedded semantics, various beneficial scenarios can be
	single interface. This creates a precondition for the approach that		expected.
	user chooses addresses differently for different purposes/usages.
	9.1. Semantic Relevant Operations in Networks		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.
	In order to manage semantic prefixes and their relevant network		b. Simplified flow control: by applying policies according to
	actions, the network should provide the following semantic relevant		certain bit values, packets carrying the same semantics in their
	functions:		source/destination addresses can.
	- Notification of semantics within the managed network		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
	When an prefix is delegated using a DHCPv6 IA_PD [RFC3633], the		d. Policy aggregation: the semantic prefix allows many policies to
	associated semantics should also be propogated to the requesting		be aggregated according to the same semantics within the policy
	router. This is particularly useful for autonomic process when a new		based routing system [RFC1104].
	device is connected.
	9.2. Semantic Relevant Interactions with Hosts		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.
	The more that semantics are embedded into a prefix, the more that		f. Application-aware routing: embedding application information into
	complicated functions are needed for semantic relevant interactions		IP addresses is the simplest way to realize application aware
	between hosts and the network, such as prefix delegation, host		routing.
	notification and address selections, etc.
	In practice, a single host may belong to multiple semantics. This		g. Easy user behavior management: based on the user type reading
	means that several IPv6 addresses are configured on a single physical		from the addresses, any improper user behaviors can be easy
	interface and should be selected for use depending on the service		detected and automatically handle by network policies.
	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		h. Easy network resources access rights management: the
	semantics in order to choose right source address when forming a		authentication of access right may already be embedded into the
	packet. If the embedded semantic is application relevant,		addresses. Simple matching policies can filter improper access
	applications on the hosts should also be involved in the address		requests.
	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		i. Easy virtualization: virtual network based on any semantics can
	selection, some semantic prefix policies may conflict with this		be easily deployed using the semantic prefix mechanism.
	algorithm. In this case, the source address selection mechanism may
	also further supporting functions to be developed.
	10. IANA Considerations		6. IANA Considerations
	This document has no IANA considerations.		This document has no IANA considerations.
	11. Change Log		7. Change Log (removed by RFC editor)
	draft-jiang-v6ops-semantic-prefix-02: new coauthor and re-organize		draft-jiang-v6ops-semantic-prefix-03: reword to emphasis this
	the content, 2013-1-31.		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.
	draft-jiang-v6ops-semantic-prefix-01: add the concept of hierarchical		draft-jiang-v6ops-semantic-prefix-01: add the concept of hierarchical
	Semantic Prefix Domain and more gap analysis, 2012-10-22.		Semantic Prefix Domain and more gap analysis, 2012-10-22.
	draft-jiang-v6ops-semantic-prefix-00: resubmitted to v6ops WG.		draft-jiang-v6ops-semantic-prefix-00: resubmitted to v6ops WG.
	Removed detailed examples and recommendations for semantics bits,		Removed detailed examples and recommendations for semantics bits,
	2012-10-15.		2012-10-15.
	draft-jiang-semantic-prefix-01: added enterprise considerations and		draft-jiang-semantic-prefix-01: added enterprise considerations and
	scenarios, emphasizing semantics only for local meaning and no intend		scenarios, emphasizing semantics only for local meaning and no intend
	to standardize any common global semantics, 2012-07-16.		to standardize any common global semantics, 2012-07-16.
	draft-jiang-semantic-prefix-00: original version, 2012-07-09		draft-jiang-semantic-prefix-00: original version, 2012-07-09
	12. Security Considerations		8. Security Considerations
	Embedding semantics in prefix is actually exposing more information		Embedding semantics in prefix is actually exposing more information
	of packets explicit. These informations may also provide convenient		of packets explicit. These informations may also provide convenient
	for malicious attackers to track or attack certain type of packets.		for malicious attackers to track or attack certain type of packets.
	When networks announce their local prefix semantics to their peer		If networks announce their local prefix semantics to their peer
	networks, it may increase the vulnerable risk.		networks, it may also increase the vulnerable risk.
	Prefix-based filters should be deployed, in order to protect against		Prefix-based filters should be deployed, in order to protect against
	address spoofing attacks or denial of service for packets with forged		address spoofing attacks or denial of service for packets with forged
	source addresses.		source addresses.
	13. Acknowledgements		9. Acknowledgements
	Useful comments were made by Erik Nygren, Nick Hilliard, Ray Hunter,		Useful comments were made by Erik Nygren, Nick Hilliard, Ray Hunter,
	David Farmer, and other participants in the V6OPS working group.		David Farmer, Fred Baker, Joel Jaeggli, John Curran and other
			participants in the V6OPS working group.
	14. References		10. References
	14.1. Normative References		10.1. Normative References
	[RFC1104] Braun, H., "Models of policy based routing", RFC 1104,		[RFC1104] Braun, H., "Models of policy based routing", RFC 1104,
	June 1989.		June 1989.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,		[RFC2474] Nichols, K., Blake, S., Baker, F., and D.L. Black,
	"Definition of the Differentiated Services Field (DS		"Definition of the Differentiated Services Field (DS
	Field) in the IPv4 and IPv6 Headers", RFC 2474,		Field) in the IPv4 and IPv6 Headers", RFC 2474, December
	December 1998.		1998.
	[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,		[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
	and M. Carney, "Dynamic Host Configuration Protocol for		and M. Carney, "Dynamic Host Configuration Protocol for
	IPv6 (DHCPv6)", RFC 3315, July 2003.		IPv6 (DHCPv6)", RFC 3315, July 2003.
	[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic		[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
	Host Configuration Protocol (DHCP) version 6", RFC 3633,		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		December 2003.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,		[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
	"Default Address Selection for Internet Protocol Version 6		"Default Address Selection for Internet Protocol Version 6
	(IPv6)", RFC 6724, September 2012.		(IPv6)", RFC 6724, September 2012.
	14.2. Informative References		10.2. Informative References
	[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6		[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
	Socket API for Source Address Selection", RFC 5014,		Socket API for Source Address Selection", RFC 5014,
	September 2007.		September 2007.
	[RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker,		[RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker,
	"Multicast Negative-Acknowledgment (NACK) Building		"Multicast Negative-Acknowledgment (NACK) Building
	Blocks", RFC 5401, November 2008.		Blocks", RFC 5401, November 2008.
	Appendix A. Appendix A: Topics for Future Extention		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.
			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
			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.
			+--------+--------+---------------+------+-------------------------+
			| | 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
			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.
			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
			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.
			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		There are several areas in which the semantic prefix could be
	extended in order to increase the usefulness and applicability of the		extended in order to increase the usefulness and applicability of the
	concept. They are complementarity besides the main framework. These		concept. They are complementarity besides the main framework. These
	are being described here as topics for possible future work. Each of		are being described here as topics for possible future work. Each of
	them may deserve a separated document for technical details.		them may deserve a separated document for technical details.
	- Dynamic Policy Configuration		- Dynamic Policy Configuration
	Dynamic policy configuration would simplify the distribution of		Dynamic policy configuration would simplify the distribution of
	policy across devices in the semantic prefix domain. New functions		policy across devices in the semantic prefix domain. New functions
	or protocol extension are needed to enable dynamic changes to the		or protocol extension are needed to enable dynamic changes to the
	policy actions in operation on certain semantic packets.		policy actions in operation on certain semantic packets.
	- Semantics Announcements to peer networks		- Semantics Announcements to peer networks
	A network may announce all, or some of its Semantic Prefix Policy to		A network may announce all, or some of its Semantic Prefix Policy to
	connected peer networks. This could be used to enable more dynamic		connected peer networks. This could be used to enable more dynamic
	configuration and enable traffic from different semantic prefix		configuration and enable traffic from different semantic prefix
	domains to traverse different networks whilst having the same		domains to traverse different networks whilst having the same
	semantic prefix policy applied. Again, this would require new		semantic prefix policy applied. To achieve this automatically by
	functions or protocol extensions to realise.		message exchanging would require new functions or protocol
			extensions.
	This also would allow enterprise semantics to be able to traverse ISP
	networks.
	- Extension of Prefix Semantics beyond the left-most 64-bits		- Extension of Prefix Semantics beyond the left-most 64-bits
	The prefix concept refers here to the left-most bits in the IP		The prefix concept refers here to the left-most bits in the IP
	addresses delegated by the network management plane. The prefix		addresses delegated by the network management plane. The prefix
	could be longer than 64-bits if the network operators strictly manage		could be longer than 64-bits if the network operators strictly manage
	the address assignment by using Dynamic Host Configuration Protocol		the address assignment by using Dynamic Host Configuration Protocol
	for IPv6 (DHCPv6) [RFC3315] (but in this case standard Stateless		for IPv6 (DHCPv6) [RFC3315] (but in this case standard StateLess
	Address Autoconfiguration - SLAAC [RFC4862] cannot be used).		Address AutoConfiguration - SLAAC [RFC4862] cannot be used).
	Authors' Addresses		Authors' Addresses
	Sheng Jiang (editor)		Sheng Jiang (editor)
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	Q14, Huawei Campus, No.156 Beijing Road		Q14, Huawei Campus, No.156 BeiQing Road
	Hai-Dian District, Beijing, 100095		Hai-Dian District, Beijing 100095
	P.R. China		P.R. China
	Email: jiangsheng@huawei.com		Email: jiangsheng@huawei.com
	Qiong Sun		Qiong Sun
	China Telecom		China Telecom
	Room 708, No.118, Xizhimennei Street		Room 708, No.118, Xizhimennei Street
	Beijing 100084		Beijing 100084
	P.R. China		P.R. China
	Email: sunqiong@ctbri.com.cn		Email: sunqiong@ctbri.com.cn
	Ian Farrer		Ian Farrer
	Deutsche Telekom AG		Deutsche Telekom AG
	Bonn 53227		Bonn 53227
	Germany		Germany
	Email: ian.farrer@telekom.de		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
End of changes. 70 change blocks.
	285 lines changed or deleted		547 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/