summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7316.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7316.txt')
-rw-r--r--doc/rfc/rfc7316.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7316.txt b/doc/rfc/rfc7316.txt
new file mode 100644
index 0000000..6d2fbe9
--- /dev/null
+++ b/doc/rfc/rfc7316.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. van Elburg
+Request for Comments: 7316 Detecon International Gmbh
+Category: Informational K. Drage
+ISSN: 2070-1721 Alcatel-Lucent
+ M. Ohsugi
+ S. Schubert
+ K. Arai
+ NTT
+ July 2014
+
+
+ The Session Initiation Protocol (SIP) P-Private-Network-Indication
+ Private Header (P-Header)
+
+Abstract
+
+ This document specifies the SIP P-Private-Network-Indication P-header
+ used by the 3GPP. The P-Private-Network-Indication indicates that
+ the message is part of the message traffic of a private network and
+ identifies that private network. A private network indication allows
+ nodes to treat private network traffic according to a different set
+ of rules than the set applicable to public network traffic.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7316.
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Elburg, et al. Informational [Page 1]
+
+RFC 7316 Private Network Indication July 2014
+
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Overview ...................................................3
+ 1.2. Applicability ..............................................3
+ 1.3. Background .................................................3
+ 1.4. Business Communication .....................................3
+ 1.5. Indication Types ...........................................4
+ 2. Conventions .....................................................6
+ 3. Definitions .....................................................6
+ 3.1. Traffic ....................................................6
+ 3.2. Public Network Traffic .....................................6
+ 3.3. Private Network Traffic ....................................6
+ 3.4. Break-In ...................................................6
+ 3.5. Break-Out ..................................................6
+ 3.6. Trust Domain ...............................................6
+ 4. Application of Terminology ......................................7
+ 5. Overview of Solution ...........................................10
+ 6. Proxy Behavior .................................................11
+ 6.1. P-Private-Network-Indication Generation ...................11
+ 6.2. P-Private-Network-Indication Consumption ..................11
+ 6.3. P-Private-Network-Indication Removal ......................11
+ 6.4. P-Private-Network-Indication Verification .................11
+ 7. P-Private-Network-Indication Header Field Definition ...........12
+ 8. Security Considerations ........................................12
+ 9. IANA Considerations ............................................13
+ 10. Acknowledgments ...............................................13
+ 11. References ....................................................13
+ 11.1. Normative References .....................................13
+ 11.2. Informative References ...................................14
+
+
+
+
+
+
+van Elburg, et al. Informational [Page 2]
+
+RFC 7316 Private Network Indication July 2014
+
+
+1. Introduction
+
+1.1. Overview
+
+ ETSI TISPAN (Telecommunications and Internet converged Services and
+ Protocols for Advanced Networking) defined Next Generation Networks
+ (NGNs), which use the 3GPP IP Multimedia Subsystem (IMS), which, in
+ turn, uses SIP [RFC3261] as its main signaling protocol. For more
+ information on the IMS, a detailed description can be found in 3GPP
+ TS 23.228 [3GPP.23.228] and 3GPP TS 24.229 [3GPP.24.229]. 3GPP and
+ ETSI TISPAN have identified a set of requirements that can be met by
+ defining a new optional SIP header, according to the procedures in
+ RFC 5727 [RFC5727].
+
+1.2. Applicability
+
+ The P-Private-Network-Indication header field is intended to be used
+ in controlled closed networks like 3GPP IMS and ETSI TISPAN NGNs.
+ The P-Private-Network-Indication header is not intended for the
+ general Internet environment and is probably not suitable for such an
+ environment.
+
+ For example, there are no mechanisms defined to prevent spoofing of
+ this header. So, if a network were to accept calls carrying this
+ header from the general Internet, an attacker would be able to inject
+ information into private networks.
+
+1.3. Background
+
+ The P-Private-Network-Indication header field has been referred to in
+ 3GPP IMS specifications and has already been used in some networks as
+ an indicator for a specific capability. The header field has already
+ been implemented in some vendors' equipment in some countries. RFC
+ 5727 [RFC5727] prohibits the new proposal of P-header "unless
+ existing deployments or standards use the prefix already". The
+ P-Private-Network-Indication header field is already used by existing
+ deployments and 3GPP standards; therefore, this is exactly the case
+ where the P-header is allowed as an exception.
+
+1.4. Business Communication
+
+ ETSI TISPAN has identified a framework, which was adopted by 3GPP as
+ [3GPP.22.519], for the support of business communication capabilities
+ by the NGN. In addition to the direct attachment of Next Generation
+ Corporate Network (NGCN) equipment, this includes the capability to
+ "host" functionality relating to an enterprise within the NGN itself.
+
+
+
+
+
+van Elburg, et al. Informational [Page 3]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ These hosting arrangements are:
+
+ a) virtual leased line, where NGCN sites are interconnected through
+ the NGN;
+
+ b) business trunking application, where the NGN hosts transit
+ capabilities between NGCN's; break-in capabilities, where the NGN
+ converts public network traffic to private network traffic for
+ delivery at a served NGCN; and break-out capabilities, where the
+ NGN converts private network traffic from a served NGCN to public
+ network traffic; and
+
+ c) hosted enterprise services, where an NGN hosts originating and/or
+ terminating business communication capabilities for business
+ communication users that are directly attached to an NGN.
+
+ ETSI TISPAN has requirements that can be met by the introduction of
+ an explicit indication for private network traffic.
+
+ The traffic generated or received by a public NGN on behalf of a
+ private network can be either:
+
+ 1) public network traffic: traffic sent to or received from an NGN
+ for processing according to the rules for ordinary subscribers of
+ a public telecommunication network. This type of traffic is
+ known as public network traffic.
+
+ 2) private network traffic: traffic sent to the NGN for processing
+ according to an agreed set of rules specific to an enterprise.
+ This type of traffic is known as private network traffic.
+ Private network traffic is normally exchanged within a single
+ enterprise, but private network traffic can also be exchanged
+ between two or more different enterprises, based on some prior
+ arrangements, if not precluded for regulatory reasons.
+
+1.5. Indication Types
+
+ A private network indication as proposed by this document indicates
+ to the receiving network element (supporting this specification) that
+ this request is related to private network traffic as opposed to
+ public network traffic. This indication does not identify an end
+ user on a private network and is not for delivery to an end user on
+ the private network. It is an indication that special service
+ arrangements apply (if such service is configured based on private
+ network traffic) for an enterprise; therefore, it is an indication of
+ service on behalf of an enterprise, not an indication of service to a
+ private network's end user.
+
+
+
+
+van Elburg, et al. Informational [Page 4]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ In order to allow NGN IMS nodes to perform different processing, ETSI
+ TISPAN formulated the following requirements for NGN. The NGN shall:
+
+ a) distinguish public network traffic from private network traffic;
+ and
+
+ b) distinguish private network traffic belonging to one enterprise
+ from that belonging to another enterprise.
+
+ To summarize, a few example reasons for a public NGN to make the
+ distinction between the two types of traffic include:
+
+ 1) Different regulations apply to two types of traffic, for example,
+ emergency calls may be handled differently depending on the type
+ of traffic.
+
+ 2) Different charging regimes may apply.
+
+ 3) Call recording for business reasons (e.g., quality control,
+ training, non-repudiation) might apply only to a specific type of
+ traffic.
+
+ 4) Different levels of signaling and/or media transparency may apply
+ to the different types of traffic.
+
+ There are several reasons why there is a need for an explicit
+ indication in the signaling:
+
+ a) Caller and callee addresses cannot always be used to determine
+ whether a certain call is to be treated as private or public
+ network traffic.
+
+ b) Nodes spanning multiple networks often need to have different
+ behavior depending upon the type of traffic. When this is done
+ using implicit schemes, enterprise-specific logic must be
+ distributed across multiple nodes in multiple operators'
+ networks. That is clearly not a manageable architecture and
+ solution.
+
+ c) There may be cases where treating the call as a public network
+ call although both participants are from the same enterprise is
+ advantageous to the enterprise.
+
+ Based on the background provided, this document formulates
+ requirements for SIP to support an explicit private network
+ indication and defines a P-header, P-Private-Network-Indication, to
+ support those requirements.
+
+
+
+
+van Elburg, et al. Informational [Page 5]
+
+RFC 7316 Private Network Indication July 2014
+
+
+2. Conventions
+
+ 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 BCP 14, RFC 2119
+ [RFC2119].
+
+3. Definitions
+
+3.1. Traffic
+
+ In the context of this document, the term "traffic" is understood as
+ all communication pertaining to and/or controlled by a SIP
+ transaction or dialog.
+
+3.2. Public Network Traffic
+
+ Traffic sent to or received from a public telecommunication network
+ for processing according to the rules for ordinary subscribers of a
+ public telecommunication network.
+
+3.3. Private Network Traffic
+
+ Traffic sent to or received from a public telecommunication network
+ for processing according to an agreed set of rules specific to an
+ enterprise or a community of closely related enterprises.
+
+3.4. Break-In
+
+ Act of converting public network traffic to private network traffic.
+ The header defined in this specification will be added to indicate
+ the traffic is a private network traffic after conversion.
+
+3.5. Break-Out
+
+ Act of converting private network traffic to public network traffic.
+ The header defined in this specification will be removed to indicate
+ the traffic is a public network traffic after conversion.
+
+3.6. Trust Domain
+
+ The term "trust domain" in this document is taken from P-Asserted-
+ Identity [RFC3324]. A trust domain applies to the private network
+ indication. The rules for specifying such a trust domain are
+ specified in P-Asserted-Identity [RFC3324] and require the
+ specification of a Spec(T) as covered in Section 2.4 of [RFC3324].
+
+
+
+
+
+van Elburg, et al. Informational [Page 6]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ The same information is required to specify a Spec(T) for purposes of
+ P-Private-Network-Indication as for P-Asserted-Identity [RFC3324].
+ However, if a network is using P-Private-Network-Indication as well
+ as other header fields subject to Spec(T) (such as P-Asserted-
+ Identity), the Spec(T) for each header field will probably be
+ different from the others.
+
+4. Application of Terminology
+
+ Figure 1 shows the interconnection of sites belonging to two private
+ networks using the public network. Traffic in the public network
+ relating to the interconnection of the two sites of enterprise 1 are
+ tagged as private network traffic relating to enterprise 1. In
+ certain cases, an enterprise can also choose to send traffic from one
+ enterprise site to another enterprise site as public network traffic
+ when this is beneficial to the enterprise. Traffic in the public
+ network relating to the interconnection of the two sites of
+ enterprise 2 are tagged as private network traffic relating to
+ enterprise 2. Enterprise 1 also generates traffic to public phones,
+ and this is public network traffic (untagged in the public network).
+ There may be circumstances where traffic in the public network
+ between two different private networks is tagged as private network
+ traffic using a pre-arranged domain name agreed by the two involved
+ enterprises. This is illustrated by the interconnection of the site
+ from enterprise 3 and the site from enterprise 4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Elburg, et al. Informational [Page 7]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ +------------------------------+
+ | private network |
+ +------------+ |<===========traffic==========>| +------------+
+ | enterprise | | (enterprise 1) | | enterprise |
+ | 1 +-----+------------------------------+-----+ 1 !
+ | site 1 | | | | site 2 |
+ +------------+ | +---+-----| |
+ | public | | | |
+ /--\ |<=========network========>| | +------------+
+ o /\ o | traffic | |
+ / \----------+--------------------------+ |
+ +----+ | |
+ public | |
+ phone | |
+ | private network |
+ +------------+ |<===========traffic==========>| +------------+
+ | enterprise | | (enterprise 2) | | enterprise |
+ | 2 +-----+------------------------------+-----+ 2 !
+ | site 1 | | | | site 2 |
+ +------------+ | | +------------+
+ | |
+ | private network |
+ +------------+ |<===========traffic==========>| +------------+
+ | enterprise | | (pre-arranged domain name) | | enterprise |
+ | 3 +-----+------------------------------+-----+ 4 !
+ | site 1 | | | | site 1 |
+ +------------+ | | +------------+
+ | |
+ +------------------------------+
+
+ Figure 1: Two Private Networks
+
+ Figure 2 shows the interconnection of sites belonging to a private
+ network using the public network and supported in the public network
+ by a server providing a business trunking application. The business
+ trunking application provides routing capabilities for the enterprise
+ traffic and supports the identification of calls to and from public
+ network users and routing of break-in and break-out of that traffic.
+ (Note that the business trunking application may consist of a
+ concatenation of application logic provided to the originating
+ enterprise site and application logic that is provided to the
+ terminating enterprise site.) Traffic in the public network relating
+ to the interconnection of the two sites of enterprise 1 is tagged as
+ private network traffic relating to enterprise 1. The business
+ trunking application also routes traffic to public phones, and this
+ is public network traffic (untagged in the public network).
+
+
+
+
+
+van Elburg, et al. Informational [Page 8]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ +-------------------------------------------------+
+ | private network |
+ +------------+ |<===========traffic============>+------------+ |
+ | enterprise | | (enterprise 1) | | |
+ | 1 +-----+--------------------------------+ | |
+ | site 1 | | | business | |
+ +------------+ | +-----+ trunking | |
+ | public | | application| |
+ /--\ |<=========network========>| +--+ | |
+ o /\ o | traffic | | | | |
+ / \----------+--------------------------+ | | | |
+ +----+ | | +------------+ |
+ public | | |
+ phone | | |
+ | private network | |
+ +------------+ |<===========traffic=========>| |
+ | enterprise | | (enterprise 1) | |
+ | 1 +-----+-----------------------------+ |
+ | site 2 | | |
+ +------------+ | |
+ | |
+ +-------------------------------------------------+
+
+ Figure 2: Private Network and Business Trunking
+
+ Figure 3 shows the interconnection of sites belonging to a private
+ network on a server providing a hosted enterprise service application
+ (also known as Centrex). The hosted enterprise service application
+ supports phones belonging to the enterprise and is also able to route
+ traffic to and from public network phones using break-in or break-out
+ functionality. Traffic in the public network relating to the
+ interconnection of the site of enterprise 1 and the hosted enterprise
+ service belonging to enterprise 1 is tagged as private network
+ traffic relating to enterprise 1. The hosted enterprise service
+ application also routes traffic to public phones, and this is public
+ network traffic (untagged in the public network). Traffic from the
+ enterprise phones would not normally be tagged, but it can be tagged
+ as private network traffic. (Note that the hosted enterprise service
+ logic may precede or succeed a business trunking application that
+ offers services on behalf of an enterprise site.)
+
+
+
+
+
+
+
+
+
+
+
+van Elburg, et al. Informational [Page 9]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ +-------------------------------------------------+
+ | private network |
+ +------------+ |<===========traffic============>+------------+ |
+ | enterprise | | (enterprise 1) | | |
+ | 1 +-----+--------------------------------+ hosted | |
+ | site 1 | | | enterprise | |
+ +------------+ | +-----+ service | |
+ | public | | enterprise | |
+ /--\ |<=========network========>| +--+ 1 | |
+ o /\ o | traffic | | | | |
+ / \----------+--------------------------+ | | | |
+ +----+ | | +------------+ |
+ public | | |
+ phone | | |
+ | private network | |
+ /--\ |<===========traffic=========>| |
+ o /\ o | (enterprise 1) | |
+ / \----------+-----------------------------+ |
+ +----+ | |
+ enterprise | |
+ phone | |
+ +-------------------------------------------------+
+
+ Figure 3: Hosted Service and Private Network
+
+5. Overview of Solution
+
+ The mechanism proposed in this document relies on a new header field
+ called 'P-Private-Network-Indication' that contains a private network
+ identifier expressed as a domain name, for example:
+
+ P-Private-Network-Indication: example.com
+
+ A proxy server that handles a message MAY insert such a P-Private-
+ Network-Indication header field into the message based on
+ authentication of the source of a message, configuration, or local
+ policy. A proxy server MAY forward the message to other proxies in
+ the same administrative domain or proxies in a trusted domain to be
+ handled as private network traffic. A proxy that forwards a message
+ to a proxy server or user agent (UA) that it does not trust MUST
+ remove the P-Private-Network-Indication header field before
+ forwarding the message.
+
+ The private network identifier expressed as a domain name allows it
+ to be a globally unique identifier, associated with the originating
+ and/or terminating enterprise(s). Domain name is used, as it allows
+ reuse of a company-owned Internet domain name without requiring an
+
+
+
+
+van Elburg, et al. Informational [Page 10]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ additional private network identifier registry. When the enterprise
+ needs more than one identifier, it can freely add subdomains under
+ its own control.
+
+ The formal syntax for the P-Private-Network-Indication header is
+ presented in Section 7.
+
+6. Proxy Behavior
+
+6.1. P-Private-Network-Indication Generation
+
+ Proxies that are responsible for determining certain traffic to be
+ treated as private network traffic or contain a break-in function
+ that converts incoming public network traffic to private network
+ traffic MUST insert a P-Private-Network-Indication header field into
+ incoming or outgoing requests for a dialog or for a standalone
+ transaction. The value MUST be set to the private network identifier
+ corresponding to the enterprise(s) to which the traffic belongs.
+
+6.2. P-Private-Network-Indication Consumption
+
+ Proxies that are responsible for applying different processing
+ behaviors to specific private network traffic MUST support this
+ extension. The P-Private-Network-Indication header field MUST NOT be
+ used by a proxy in case it is received in a request from an entity
+ that it does not trust; in such a case, it MUST be removed before the
+ request is forwarded.
+
+6.3. P-Private-Network-Indication Removal
+
+ Proxies that are at the edge of the trust domain or contain a break-
+ out function that converts incoming private network traffic to public
+ network traffic MUST remove the P-Private-Network-Indication header
+ field before forwarding a request that contains such a header field.
+
+6.4. P-Private-Network-Indication Verification
+
+ When proxies supporting this specification receive a P-Private-
+ Network-Indication header field in a SIP request from a trusted node,
+ proxies MUST check whether the received domain name in the request is
+ the same as the domain name associated with the provisioned domain
+ name. If the received domain name does not match, proxies MUST
+ remove the P-Private-Network-Indication header field.
+
+
+
+
+
+
+
+
+van Elburg, et al. Informational [Page 11]
+
+RFC 7316 Private Network Indication July 2014
+
+
+7. P-Private-Network-Indication Header Field Definition
+
+ This document defines the SIP P-Private-Network-Indication header
+ field. This header field can be added by a proxy to initial requests
+ for a dialog or standalone requests. The presence of the P-Private-
+ Network-Indication header field signifies to proxies that understand
+ the header field that the request is to be treated as private network
+ traffic. The P-Private-Network-Indication header field contains a
+ domain name value that allows the private network traffic to be
+ associated with an enterprise to which it belongs and allows proxies
+ that understand this header field to process the request according to
+ the local policy configured for a specific enterprise(s).
+
+ The Augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the
+ P-Private-Network-Indication header field is described below:
+
+ P-Private-Network-Indication = "P-Private-Network-Indication" HCOLON
+ PNI-value *(SEMI PNI-param)
+ PNI-param = generic-param
+ PNI-value = hostname
+
+ EQUAL, HCOLON, SEMI, hostname, and generic-param are defined in RFC
+ 3261 [RFC3261].
+
+ The following is an example of a P-Private-Network-Indication header
+ field:
+
+ P-Private-Network-Indication: example.com
+
+8. Security Considerations
+
+ The private network indication defined in this document MUST only be
+ used in the traffic transported between network elements that are
+ mutually trusted. Traffic protection between network elements can be
+ achieved by using security protocols such as IP Encapsulating
+ Security Payload (ESP) [RFC4303] or SIP / Transport Layer Security
+ (SIP/TLS) or sometimes by physical protection of the network. In any
+ case, the environment where the private network indication will be
+ used needs to ensure the integrity and the confidentiality of the
+ contents of this header field.
+
+ A private network indication received from an untrusted node MUST NOT
+ be used, and the information MUST be removed from a request or
+ response before it is forwarded to entities in the trust domain.
+ Additionally, local policies may be in place that ensure that all
+ requests entering the trust domain for private network indication
+ from untrusted nodes with a private network indication will be
+ discarded.
+
+
+
+van Elburg, et al. Informational [Page 12]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ There is a security risk if a private network indication is allowed
+ to propagate out of the trust domain where it was generated. The
+ indication may reveal information about the identity of the caller,
+ i.e., the organization that he belongs to. That is sensitive
+ information. It also reveals to the outside world that there is a
+ set of rules that this call is subject to that is different then the
+ rules that apply to public traffic. That is sensitive information
+ too. To prevent such a breach from happening, proxies MUST NOT
+ insert the information when forwarding requests to a next hop located
+ outside the trust domain. When forwarding the request to a trusted
+ node, proxies MUST NOT insert the header field unless they have
+ sufficient knowledge that the route set includes another proxy in the
+ trust domain that understands this header field. However, how to
+ learn such knowledge is out of the scope of this document. Proxies
+ MUST remove the information when forwarding requests to untrusted
+ nodes or when the proxy does not have knowledge of any other proxy in
+ the route set that is able to understand this header field.
+
+9. IANA Considerations
+
+ This document defines a new SIP header field: P-Private-Network-
+ Indication. This header field has been registered by the IANA in the
+ "SIP Parameters" registry under the "Header Fields" subregistry.
+
+ RFC Number: [RFC7316]
+
+ Header Field Name: P-Private-Network-Indication
+
+ Compact Form: none
+
+10. Acknowledgments
+
+ The authors would like to thank Richard Barnes, Mary Barnes, Atle
+ Monrad, Bruno Chatras, John Elwell, and Salvatore Loreto for
+ providing comments on an early version of this document. Further, we
+ thank John Elwell for performing the expert review.
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+
+
+van Elburg, et al. Informational [Page 13]
+
+RFC 7316 Private Network Indication July 2014
+
+
+ [RFC3324] Watson, M., "Short Term Requirements for Network Asserted
+ Identity", RFC 3324, November 2002.
+
+ [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", STD 68, RFC 5234, January
+ 2008.
+
+11.2. Informative References
+
+ [3GPP.22.519]
+ 3GPP, "Business Communication Requirements", TS 22.519.
+
+ [3GPP.23.228]
+ 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS
+ 23.228 V8, July 2007.
+
+ [3GPP.24.229] 3GPP, "Internet Protocol (IP) multimedia call control
+ protocol based on Session Initiation Protocol (SIP) and
+ Session Description Protocol (SDP); Stage 3", 3GPP TS
+ 24.229 V8, July 2007.
+
+ [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
+ for the Session Initiation Protocol (SIP) and the Real-
+ time Applications and Infrastructure Area", BCP 67, RFC
+ 5727, March 2010.
+
+ [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+ 4303, December 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+van Elburg, et al. Informational [Page 14]
+
+RFC 7316 Private Network Indication July 2014
+
+
+Authors' Addresses
+
+ Hans Erik van Elburg
+ Detecon International Gmbh
+ Oberkasselerstrasse 2
+ Bonn 53227
+ Germany
+
+ EMail: ietf.hanserik@gmail.com
+
+
+ Keith Drage
+ Alcatel-Lucent
+ The Quadrant, Stonehill Green, Westlea
+ Swindon SN5 7DJ
+ UK
+
+ EMail: drage@alcatel-lucent.com
+
+
+ Mayumi Ohsugi
+ NTT Corporation
+
+ Phone: +81 422 36 7502
+ EMail: mayumi.ohsugi@ntt-at.co.jp
+
+
+ Shida Schubert
+ NTT Corporation
+
+ Phone: +1 415 323 9942
+ EMail: shida@ntt-at.com
+
+
+ Kenjiro Arai
+ NTT Corporation
+ 9-11, Midori-cho 3-Chome
+ Musashino-shi, Tokyo 180-8585
+ Japan
+
+ Phone: +81 422 59 3518
+ EMail: arai.kenjiro@lab.ntt.co.jp
+ URI: http://www.ntt.co.jp
+
+
+
+
+
+
+
+
+van Elburg, et al. Informational [Page 15]
+