One document matched: draft-wu-pce-dns-pce-discovery-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-wu-pce-dns-pce-discovery-05"
ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title abbrev="DNS based PCED">Path Computation Element (PCE) Discovery
using Domain Name System(DNS)</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization>Huawei</organization>
<address>
<postal>
<street>Leela Palace</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560008</code>
<country>INDIA</country>
</postal>
<email>dhruv.dhody@huawei.com</email>
</address>
</author>
<author fullname="Daniel King" initials="D" surname="King">
<organization>Old Dog Consulting</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<email>daniel@olddog.co.uk</email>
</address>
</author>
<author fullname="Diego R. Lopez " initials="D" surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>diego@tid.es</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>Jeff.Tantsura@ericsson.com</email>
</address>
</author>
<date year="2014" />
<area>Routing Area</area>
<workgroup>PCE Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>Path Computation Element</keyword>
<abstract>
<t>Discovery of the Path Computation Element (PCE) within an IGP area or
routing domain is possible using OSPF [RFC5088] and IS-IS [RFC5089].
However, it has been established that in certain deployment scenarios
PCEs may not wish, or be able to participate within the IGP process. In
those scenarios, it is beneficial for the Path Computation Client (PCC)
(or other PCE) to discover PCEs via an alternative mechanism to those
proposed in [RFC5088] and [RFC5089].</t>
<t>This document specifies the requirements, use cases, procedures and
extensions to support PCE type and capability discovery via DNS.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Path Computation Element Communication Protocol (PCEP) is a
transaction-based protocol carried over TCP [RFC4655]. In order to be
able to direct path computation requests to the Path Computation Element
(PCE), a Path Computation Client (PCC) (or other PCE) needs to know the
location and capability of a PCE.</t>
<t>In a network where an IGP is used and where the PCE participates in
the IGP, discovery mechanisms exist for PCC (or PCE) to learn the
identity and capability of each PCE. [RFC5088] defines a PCE Discovery
(PCED) TLV carried in an OSPF Router LSA. Similarly, [RFC5089] defines
the PCED sub-TLV for use in PCE Discovery using IS-IS. Scope of the
advertisement is limited to IGP area/level or Autonomous System
(AS).</t>
<t>However in certain scenarios not all PCEs will participate in the IGP
instance, section 3 (Motivation) outlines a number of use cases. In
these cases, current PCE Discovery mechanisms are therefore not
appropriate and another PCE discovery function would be required.</t>
<t>This document describes PCE discovery via DNS. The mechanism with
which DNS comes to know about the PCE and its capability is out of scope
of this document.</t>
<section title="Terminology" toc="default">
<t>The following terminology is used in this document.</t>
<t><list style="hanging">
<t hangText="PCE-Domain:">As per <xref target="RFC4655"></xref>,
any collection of network elements within a common sphere of
address management or path computational responsibility. Examples
of domains include Interior Gateway Protocol (IGP) areas and
Autonomous Systems (ASs).</t>
<t hangText="Domain-Name:">An identification string that defines a
realm of administrative autonomy, authority, or control on the
Internet. Any name registered in the DNS is a domain name. DNS
Domain names are used in various networking contexts and
application-specific naming and addressing purposes. In general, a
domain name represents an Internet Protocol (IP) resource.
Examples of DNS domain name is “www.example.com” or
“example.com”[RFC1035].</t>
</list></t>
</section>
<section title="Requirements">
<t>As described in [RFC4674], the PCE Discovery information should at
least be composed of: <list style="symbols">
<t>The PCE location: an IPv4 and/or IPv6 address that is used to
reach the PCE. It is RECOMMENDED to use an address that is always
reachable if there is any connectivity to the PCE;</t>
<t>The PCE path computation scope (i.e., inter-area, inter-AS, or
inter-layer);</t>
<t>The set of one or more PCE-Domain(s) into which the PCE has
visibility and for which the PCE can compute paths;</t>
<t>The set of zero, one, or more neighbor PCE-Domain(s) toward
which the PCE can compute paths;</t>
</list></t>
<t>These PCE discovery information allows PCCs to select appropriate
PCEs:</t>
<t>This document specifies the procedures and extension to facilitate
DNS-based PCE information discovery for specific use cases, and to
complement existing IGP discovery mechanism.</t>
</section>
</section>
<section title="Conventions used in this document">
<t>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 <xref
target="RFC2119">RFC2119</xref>.</t>
</section>
<section title="Motivation">
<t>This section discusses in more detail the motivation and use cases
for an alternative DNS-based PCE discovery mechanism.</t>
<section title="Outside the Routing Domain">
<t>When the PCE is a router participating in the IGP, or even a server
participating passively in the IGP, with all PCEP speakers in the same
routing domain, a simple and efficient way to announce PCEs consists
of using IGP flooding.</t>
<t>It has been identified that the existing PCE discovery mechanisms
do not work in following scenarios:</t>
<t><list style="hanging">
<t hangText="Inter-AS:">Per domain path computation mechanism
[RFC5152] or Backward recursive path computation (BRPC) [RFC5441]
MAY be used by cooperating PCEs to compute inter-domain path. In
which case these cooperating PCEs should be known to other PCEs.
In case of inter-AS where the PCEs do not participate in a common
IGP, the existing IGP discovery mechanism cannot be used to
discover inter-AS PCE.</t>
<t hangText="Hierarchy of PCE:">The H-PCE [RFC6805] architecture
does not require disclosure of internals of a child domain to the
parent PCE. It may be necessary for a third party to manage the
parent PCEs according to commercial and policy agreements from
each of the participating service providers [PCE-QUESTION]. <xref
target="RFC6805"></xref> specifies that a child PCE must be
configured with the address of its parent PCE in order for it to
interact with its parent PCE. However handling changes in parent
PCE identities and coping with failure events would be an issue
for a configured system. There is no scope for parent PCEs to
advertise their presence to child PCEs when they are not a part of
the same routing domain.</t>
<t hangText="BGP:">[BGP-LS] describes a mechanism by which links
state and traffic engineering information can be collected from
networks and shared with external components using the BGP routing
protocol. An external PCE MAY use this mechanism to populate its
TED and not take part in the same IGP routing domain.</t>
<t hangText="NMS/OSS:">PCE MAY gain the knowledge of Topology
information from some management system (e.g.,NMS/OSS) and not
take part in the same routing domain. Also note that in some case
PCC may not be a router and instead be a management system like
NMS and may not be able to discover PCE via IGP discovery.</t>
</list></t>
</section>
<section title="Discovery Mechanisms">
<section title="Query-Response versus Advertisement">
<t>Advertisement based PCE discovery using IGP methods [RFC5088] and
[RFC5089] floods the PCE information to an area, a subset of areas
or to a full routing domain. By the very nature of flooding and
advertisements it generates unwanted traffic and may lead to
unnecessary advertisement, especially when PCE information needs
frequent changes.</t>
<t>DNS is a query-response based mechanism, a client (a PCC) can use
DNS to discover a PCE only when it needs to compute a path and does
not require any other node in the network to be involved.</t>
<t>In case of Intermittent PCEP session, where PCEP sessions are
systematically open and closed for each PCEP request, a DNS-based
query-response mechanism is more suitable. One may also utilize
DNS-based load-balancing and recovery functions.</t>
</section>
</section>
<section title="Network Address Translation Gateway">
<t>PCEP uses TCP as the transport mechanism between PCC and PCE, and
PCE to PCE, communications [RFC5440]. To secure TCP connection that
underlay PCEP sessions, Transport Layer Security (TLS) can be used
besides using TCP-MD5 [RFC2385] and TCP-AUTH [RFC5295]. When PCC and
PCE support TCP-MD5 or TCP-AUTH while NAT does not, TCP connection
establishment fails. When NAT gateway is in presence, a TCP or TCP/TLS
connection can be opened by Interactive Connectivity Establishment
(ICE) [RFC5245] for the purpose of connectivity checks. However the
TCP connection cannot be established in cases where one of the peers
is behind a NAT with connection-dependent filtering properties
[RFC5382]. Therefore IGP discovery is limited within an IGP domain and
cannot be used in this case.</t>
</section>
</section>
<section title="Additional Capabilities">
<section title="Load Sharing of Path Computation Requests">
<t>Multiple PCEs can be present in a single network domain for
redundancy. DNS supports inherent load balancing where multiple PCEs
(with different IP addresses) are known in DNS for a single PCE server
name and are hidden from the PCC.</t>
<t>In an IGP advertisement based PCE discovery, one learns of all the
PCEs and it is the job of the PCC to do load-balancing.</t>
<t>A DNS-based load-balancing mechanism works well in case of
Intermittent PCEP sessions and request are load-balanced among PCEs
similar to HTTP request without any complexity at the client.</t>
</section>
</section>
<section title="Extended Naming Authority Pointer ( NAPTR )Service Field Format">
<t>The NAPTR service field format defined by the S-NAPTR DDDS
application in [RFC3958] follows this Augmented Backus-Naur Form (ABNF)
[RFC5234]: <figure>
<artwork>
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
</artwork>
</figure></t>
<t>This specification refines the "iana-registered-service" tag
definition for the discovery of PCE supporting a specific PCE
application or multiple PCE applications as defined below. <figure>
<artwork>
iana-registered-service =/ pce-service
pce-service = "pce" *("+" appln-name)
appln-name = non-ws-string
non-ws-string = 1*(%x21-FF)
</artwork>
</figure></t>
<t>The appln-name element is the Application Identifier used to identify
a specific PCE application. The PCE Application Name are allocated by
IANA as defined in section 8.1.</t>
<t>This specification also refines the "iana-registered-protocol" tag
definition for the discovery of PCE supporting a specific transport
protocol as defined below. <figure>
<artwork>
iana-registered-protocol =/ pce-protocol
pce-protocol = "pce." pce-transport
pce-transport = "tcp" / "tls.tcp"
</artwork>
</figure></t>
<t>Similar to application protocol tags defined in the [RFC6408],the
S-NAPTR application protocol tags defined by this specification MUST NOT
be parsed in any way by the querying application or Resolver. The
delimiter (".") is present in the tag to improve readability and does
not imply a structure or namespace of any kind. The choice of delimiter
(".") for the application protocol tag follows the format of existing
S-NAPTR application protocol tag registry entries, but this does not
imply that it shares semantics with any other specifications that create
registry entries with the same format.</t>
<t>The S-NAPTR application service and application protocol tags defined
by this specification are unrelated to the IANA "Service Name and
Transport Protocol Port Number Registry" (see [RFC6335]).</t>
<t>The maximum length of the NAPTR service field is 256 octets,
including a one-octet length field (see Section 4.1 of [RFC3403] and
Section 3.3 of [RFC1035]).</t>
<section title="IETF Standards Track PCE Applications">
<t>A PCE Client MUST be capable of using the extended S-NAPTR
application service tag for dynamic discovery of a PCE supporting
Standards Track applications. Therefore, every IETF Standards Track
PCE application MUST be associated with a "PCE-service" tag formatted
as defined in this specification and allocated in accordance with IANA
policy (see Section 8).</t>
<t>For example, a NAPTR service field value of:<figure>
<artwork>
'PCE+gco:pce.tcp'
</artwork>
</figure></t>
<t>means that the PCE in the SRV or A/AAAA record supports the Global
Concurrent Optimization Application (See section 8.1)and the Transport
Control Protocol (TCP) as the transport protocol (See section
8.2).</t>
</section>
</section>
<section title="Backwards Compatibility">
<t>Domain Name System (DNS) administrators SHOULD also provision legacy
NAPTR records [RFC3403] in order to guarantee backwards compatibility
with legacy PCE that only support S-NAPTR DDDS application in [RFC3958].
If the DNS administrator provisions both extended S-NAPTR records as
defined in this specification and legacy NAPTR records defined in
[RFC3403], then the extended S-NAPTR records MUST have higher
priority(e.g., lower order and/or preference values) than legacy NAPTR
records.</t>
</section>
<section title="Discovering a Path Computation Element">
<t>The extended-format NAPTR records provide a mapping from a domain to
the SRV record or A/AAAA record for contacting a server supporting a
specific transport protocol and PCE application. The resource record
will contain an empty regular expression and a replacement value, which
is the SRV record or the A/AAAA record for that particular transport
protocol.</t>
<t>The assumption for this mechanism to work is that the DNS
administrator of the queried domain has first provisioned the DNS with
extended-format NAPTR entries.</t>
<t>When the PCC or other PCEs performs a NAPTR query for a server in a
particular realm, the PCC or other PCEs has to know in advance the
search path of the resolver, i.e.,in which realm to look for a PCE, and
in which Application Identifier it is interested.</t>
<t>The search path of the resolver can either be pre-configured, or
discovered using Diameter, DHCP or other means. For example, the realm
could be deduced from the Network Access Identifier (NAI) in the
User-Name attribute-value pair (AVP) or extracted from the
Destination-Realm AVP in Diameter [RFC6733].</t>
<t>When pre-configuration is used, PCE domain(e.g.,AS200)can be added as
"subdomains" of the first-level domain of the underlying service (e.g.,
AS200.example.com), which allows a NAPTR query for a server in a PCE
domain associated with DNS domain-name.</t>
<t>When DHCP is used, it SHOULD know the domain-name of that realm and
use DHCP to discover IP address of the PCE in that realm that provides
path computation service along with some PCE location information useful
to a PCC (or other PCE) for a PCE selection, and contact it directly. In
some instances, the discovery may result in a per protocol/application
list of domain-names that are then used as starting points for the
subsequent S-NAPTR lookups [RFC3958]. If neither the IP address nor
other PCE location information can be discovered with the above
procedure, the PCC (or other PCE) MAY request a domain search list, as
described in [RFC3397] and[RFC3646], and use it as input to the DDDS
application.</t>
<t>When the PCC (or other PCE) does not find valid domain-names using
the mechanisms above, it MUST stop the attempt to discover any PCE.</t>
<t>The following procedures result in an IP address, PCE domain,
neighboring PCE domain and PCE Computation Scope where the PCC (or other
PCE) can contact the PCE that hosts the service it is looking for.</t>
<section title="Determining the PCE Service and transport protocol">
<t>The PCC (or other PCE) should know the service identifier for the
Path Computation service and associated transport protocol. The
service identifier for the Path Computation service is defined as
“PCE+apX” as specified in section 5, The PCE supporting "PCE" service
MUST support TCP as transport, as described in [RFC5440].</t>
<t>The services relevant for the task of transport protocol selection
are those with S-NAPTR service fields with values "PCE+apX:Y", where
'PCE+apX' is the service identifier defined in the previous paragraph,
and ' Y' is the letter that corresponds to a transport protocol
supported by the PCE. This document also establishes an IANA registry
for mappings of S-NAPTR service name to transport protocol.</t>
<t>These NAPTR [RFC3958] records provide a mapping from a domain to
the SRV [RFC2782] record for contacting a PCE with the specific
transport protocol in the S-NAPTR services field. The resource record
MUST contain an empty regular expression and a replacement value,
which indicates the domain name where the SRV record for that
particular transport protocol can be found. As per [RFC3403], the
client discards any records whose services fields are not
applicable.</t>
<t>The PCC (or other PCE) MUST discard any service fields that
identify a resolution service whose value is not valid. The S-NAPTR
processing as described in [RFC3403] will result in the discovery of
the most preferred PCE that is supported by the client, as well as an
SRV record for the PCE.</t>
</section>
<section title="Determining the IP Address of the PCE">
<t>If the returned NAPTR service fields contain entries formatted as
"pce+apX:Y" where "X" indicates the Application Identifier and "Y"
indicates the supported transport protocol(s), the target realm
supports the extended format for NAPTR-based PCE discovery defined in
this document. <list style="symbols">
<t>If "X" contains the required Application Identifier and "Y"
matches a supported transport protocol, the PCEP implementation
resolves the "replacement" field entry to a target host using the
lookup method appropriate for the "flags" field.</t>
<t>If "X" does not contain the required Application Identifier or
"Y" does not match a supported transport protocol, the PCEP
implementation abandons the peer discovery.</t>
</list></t>
<t>If the returned NAPTR service fields contain entries formatted as
"pce+apX" where "X" indicates the Application Identifier, the target
realm supports the extended format for NAPTR-based PCE discovery
defined in this document. <list style="symbols">
<t>If "X" contains the required Application Identifier, the PCEP
implementation resolves the "replacement" field entry to a target
host using the lookup method appropriate for the "flags" field and
attempts to connect using all supported transport protocols.</t>
<t>If "X" does not contain the required Application Identifier,
the PCEP implementation abandons the PCE discovery.</t>
</list></t>
<t>If the returned NAPTR service fields contain entries formatted as
"pce:X" where "X" indicates the supported transport protocol(s), the
target realm supports PCEP but does not support the extended format
for NAPTR-based PCE discovery defined in this document. <list
style="symbols">
<t>If "X" matches a supported transport protocol, the PCEP
implementation resolves the "replacement" field entry to a target
host using the lookup method appropriate for the "flags"
field.</t>
</list></t>
<t>If the returned NAPTR service fields contain entries formatted as
"pce", the target realm supports PCEP but does not support the
extended format for NAPTR-based PCE discovery defined in this
document. The PCEP implementation resolves the "replacement" field
entry to a target host using the lookup method appropriate for the
"flags" field and attempts to connect using TCP (in future it SHOULD
attempt all supported transport Protocols) .</t>
<t>Note that the regexp field in the S-NAPTR example above is empty.
The regexp field MUST NOT be used when discovering PCE, as its usage
can be complex and error prone. Also, the discovery of the PCE does
not require the flexibility provided by this field over a static
target present in the TARGET field.</t>
<t>As the default behavior, the client is configured with the
information about which transport protocol is used for a path
computation service in a particular domain. The client can directly
perform an SRV query for that specific transport using the service
identifier of the path computation Service. For example, if the client
knows that it should be using TCP for path computation service, it can
perform a SRV query directly for_PCE._tcp.example.com.</t>
<t>Once the server providing the desired service and the transport
protocol has been determined, the next step is to determine the IP
address.</t>
<t>According to the specification of SRV RRs in [RFC2782], the TARGET
field is a fully qualified domain-name (FQDN) that MUST have one or
more address records; the FQDN must not be an alias, i.e., there MUST
NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query
already has reported a sufficient number of these address records in
the Additional Data section of the DNS response (as recommended by
[RFC2782]), the PCC needs to perform A and/or AAAA record lookup(s) of
the domain-name, as appropriate. The result will be a list of IP
addresses, each of which can be contacted using the transport protocol
determined previously.</t>
<section title="Examples">
<t>As an example, consider a client that wishes to find PCED service
in the as100.example.com domain. The client performs a S-NAPTR query
for that domain, and the following NAPTR records are returned:
<figure>
<artwork>
Order Pref Flags Service Regexp Replacement
IN NAPTR 50 50 "s" "pce:pce.tls.tcp" ""
_PCE._tcp.as100.example.com
IN NAPTR 90 50 "s" "pce:pce.tcp" ""
_PCE._tcp.as100.example.com
</artwork>
</figure></t>
<t>This indicates that the domain does have a PCE providing Path
Computation services over TCP, in that order of preference. If the
client only supports TCP, TCP will be used, targeted to a host
determined by an SRV lookup of _PCE._tcp.example.com. That lookup
would return: <figure>
<artwork>
;; Priority Weight Port Target
IN SRV 0 1 XXXX server1.as100.example.com
IN SRV 0 2 XXXX server2.as100.example.com
</artwork>
</figure>where XXXX represents the port number at which the
service is reachable.</t>
<t>As an alternative example, a client wishes to discover a PCE in
the ex2.example.com realm that supports the GCO application over
TCP. The client performs a NAPTR query for that domain, and the
following NAPTR records are returned: <figure>
<artwork>
;; order pref flags service regexp replacement
IN NAPTR 150 50 "a" "pce:pce.tcp" ""
server1.ex2.example.com
IN NAPTR 150 50 "a" "pce:pce.tls.tcp" ""
server2.ex2.example.com
IN NAPTR 150 50 "a" "pce+gco:pce.tcp" ""
server1.ex2.example.com
IN NAPTR 150 50 "a" "pce+gco:pce.tls.tcp" ""
server2.ex2.example.com
</artwork>
</figure></t>
<t>This indicates that the server supports GCO(ID=1) over TCP and
TLS/TCP via hosts server1.ex2.example.com and
server2.ex2.example.com, respectively.</t>
</section>
</section>
<section title="Determining the PCE domains and Neighbor PCE domains">
<t>DNS servers MAY use DNS TXT record to give additional information
about PCE service and add such TXT record to the additional
information section (See section 4.1 of [RFC1035]) that are relevant
to the answer and have the same authenticity as the data (Generally
this will be made up of A and SRV records)in the answer section. The
additional information may include path computation capability, the
PCE domains and Neighbor PCE domains associated with the PCE. If
discovery of PCE supporting a specific PCE capability described in
section 7.2 has already been performed, capability associated with the
PCE does not need to be included in the additional information.</t>
<t>To store new types of information, the TXT record uses a structured
format in its TXT-DATA field [RFC1035]. The format consists of the
attribute name followed by the value of the attribute. The name and
value are separated by an equals sign (=). The general syntax may
follow one defined in section 2 of [RFC1464] as follows: <figure>
<artwork>
<owner> <class> <ttl> TXT "<attribute name>=<attribute value>"
</artwork>
</figure></t>
<t>For example, the following TXT records contain attributes specified
in this fashion: <figure>
<artwork>
ex2.example.com IN TXT "pce domain = as10"
ex2.example.com IN TXT "neigh domain= as5"
ex2.example.com IN TXT "cap=link constraint"
</artwork>
</figure></t>
<t>The client MAY inspect those Additional Information section in the
DNS message and be capable of handling responses from nameservers that
never fill in the Additional Information part of a response.</t>
</section>
</section>
<section title="IANA Considerations">
<section title="IETF PCE Application Service Tags">
<t>IANA specifies to create a new registry ‘ S-NAPTR application
service tags’ for existing IETF PCE applications.<figure>
<artwork>
+------------------+----------------------------+
| Tag | PCE Application |
+------------------+----------------------------+
| pce+gco | GCO [RFC5557] |
| pce+p2mp | P2MP [RFC5671] |
| pce+stateful | Stateful [STATEFUL-PCE] |
| pce+gmpls | GMPLS [RFC7025] |
| pce+interas | Inter-AS[RFC5376] |
| pce+interarea | Inter-Area [RFC4927] |
| pce+interlayer | Inter-layer [RFC6457] |
+------------------+----------------------------+
</artwork>
</figure></t>
<t>Future IETF PCE applications MUST reserve the S-NAPTR application
service tag corresponding to the allocated PCE Application ID as
defined in Section 3.</t>
</section>
<section title="PCE Application Protocol Tags">
<t>IANA has reserved the following S-NAPTR Application Protocol Tags
for the PCE transport protocols in the "S-NAPTR Application Protocol
Tag" registry created by [RFC3958]. <figure>
<artwork> +------------------+----------+
| Tag | Protocol |
+------------------+----------+
| pce.tcp | TCP |
+------------------+----------+
</artwork>
</figure></t>
<t>Future PCE versions that introduce new transport protocols MUST
reserve an appropriate S-NAPTR Application Protocol Tag in the
"S-NAPTR Application Protocol Tag" registry created by [RFC3958].</t>
</section>
</section>
<section title="Security Considerations">
<t>This document specifies an enhancement to the NAPTR service field
format. The enhancement and modifications are based on the S-NAPTR,
which is actually a simplification of the NAPTR, and therefore the same
security considerations described in [RFC3958] are applicable to this
document.</t>
<t>For most of those identified threats, the DNS Security Extensions
[RFC4033] does provide protection. It is therefore recommended to
consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC
Operational Practices [RFC6781] when deploying Path Computation
Services.</t>
<t>In deployments where DNSSEC usage is not feasible, measures should be
taken to protect against forged DNS responses and cache poisoning as
much as possible. Efforts in this direction are documented in
[RFC5452].</t>
<t>However a malicious host doing S-NAPTR queries learns applications
supported by PCEs in a certain realm faster, which might help the
malicious host to scan potential targets for an attack more efficiently
when some applications have known vulnerabilities.</t>
<t>Where inputs to the procedure described in this document are fed via
DHCP, DHCP vulnerabilities can also cause issues. For instance, the
inability to authenticate DHCP discovery results may lead to the Path
Computation service results also being incorrect, even if the DNS
process was secured.</t>
</section>
<section title="Acknowledgements">
<t>The author would like to thank Claire Bi,Ning Kong, Liang Xia,
Stephane Bortzmeyer,Yi Yang, Ted Lemon, Adrian Farrel and Stuart
Cheshire for their review and comments that help improvement to this
document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997" />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<t>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.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2782">
<front>
<title>A DNS RR for specifying the location of services (DNS
SRV)</title>
<author fullname="A.Gulbrandsen" initials="A." surname="Gulbrandsen">
<organization></organization>
</author>
<date month="February" year="2000" />
</front>
<seriesInfo name="RFC" value="2782" />
<format target="http://www.rfc-editor.org/rfc/rfc2782.txt" type="TXT" />
</reference>
<reference anchor="RFC3397">
<front>
<title>Dynamic Host Configuration Protocol (DHCP) Domain Search
Option</title>
<author fullname="B.Aboba" initials="B." surname="Aboba">
<organization></organization>
</author>
<date month="November" year="2002" />
</front>
<seriesInfo name="RFC" value="3397" />
<format target="http://www.rfc-editor.org/rfc/rfc3397.txt" type="TXT" />
</reference>
<reference anchor="RFC3403">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part Three: The
Domain Name System (DNS) Database</title>
<author fullname="M.Mealling" initials="M." surname="Mealling">
<organization></organization>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3403" />
<format target="http://www.rfc-editor.org/rfc/rfc3403.txt" type="TXT" />
</reference>
<reference anchor="RFC3646">
<front>
<title>DNS Configuration options for Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)</title>
<author fullname="R.Droms" initials="R." surname="Droms">
<organization></organization>
</author>
<date month="December" year="2003" />
</front>
<seriesInfo name="RFC" value="3646" />
<format target="http://www.rfc-editor.org/rfc/rfc3646.txt" type="TXT" />
</reference>
<reference anchor="RFC6733">
<front>
<title>Diameter Base Protocol</title>
<author fullname="V. Fajardo" initials="V." surname="Fajardo">
<organization></organization>
</author>
<date month="October" year="2012" />
</front>
<seriesInfo name="RFC" value="6733" />
<format target="http://www.rfc-editor.org/rfc/rfc6733.txt" type="TXT" />
</reference>
<reference anchor="RFC4655">
<front>
<title>A Path Computation Element (PCE)-Based Architecture</title>
<author fullname="A.Farrel" initials="A." surname="Farrel">
<organization></organization>
</author>
<author fullname="J.P.Vasseur" initials="J.P." surname="Vasseur">
<organization></organization>
</author>
<author fullname="J.Ash" initials="J." surname="Ash">
<organization></organization>
</author>
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC" value="4655" />
<format target="http://www.rfc-editor.org/rfc/rfc4655.txt" type="TXT" />
</reference>
<reference anchor="RFC4674">
<front>
<title>Requirements for Path Computation Element (PCE)
Discovery</title>
<author fullname="R.Droms" initials="R." surname="Droms">
<organization></organization>
</author>
<date month="December" year="2003" />
</front>
<seriesInfo name="RFC" value="4674" />
<format target="http://www.rfc-editor.org/rfc/rfc4674.txt" type="TXT" />
</reference>
<reference anchor="RFC6805">
<front>
<title>The Application of the Path Computation Element Architecture
to the Determination of a Sequence of Domains in MPLS and
GMPLS</title>
<author fullname="D.King" initials="D." surname="King">
<organization></organization>
</author>
<author fullname="A.Farrel " initials="A." surname="Farrel">
<organization></organization>
</author>
<date month="November" year="2012" />
</front>
<seriesInfo name="RFC" value="6805" />
<format target="http://www.rfc-editor.org/rfc/rfc6805.txt" type="TXT" />
</reference>
<reference anchor="RFC3958">
<front>
<title>Domain-Based Application Service Location Using SRV RRs and
the Dynamic Delegation Discovery Service (DDDS)</title>
<author fullname="L. Daigle" initials="D." surname="Daigle">
<organization></organization>
</author>
<author fullname="A. Newton" initials="A." surname="Newton">
<organization></organization>
</author>
<date month="January" year="2005" />
</front>
<seriesInfo name="RFC" value="3958" />
<format target="http://www.rfc-editor.org/rfc/rfc3958.txt" type="TXT" />
</reference>
<reference anchor="RFC5440">
<front>
<title>Path Computation Element (PCE) Communication Protocol
(PCEP)</title>
<author fullname="JL. Le Roux" initials="JL." surname="Le Roux">
<organization></organization>
</author>
<date month="April" year="2007" />
</front>
<seriesInfo name="RFC" value="5440" />
<format target="http://www.rfc-editor.org/rfc/rfc5440.txt" type="TXT" />
</reference>
<reference anchor="RFC6781">
<front>
<title>DNSSEC Operational Practices, Version 2</title>
<author fullname="O. Kolkman" initials="O." surname="Kolkman">
<organization></organization>
</author>
<author fullname="W. Mekking" initials="W." surname="Mekking">
<organization></organization>
</author>
<author fullname="R.Gieben" initials="R." surname="Gieben">
<organization></organization>
</author>
<date month="December" year="2012" />
</front>
<seriesInfo name="RFC" value="6781" />
<format target="http://www.rfc-editor.org/rfc/rfc6781.txt" type="TXT" />
</reference>
<reference anchor="RFC4033">
<front>
<title>DNS Security Introduction and Requirements</title>
<author fullname="R. Arends" initials="R." surname="Arends">
<organization></organization>
</author>
<date month="March" year="2005" />
</front>
<seriesInfo name="RFC" value="4033" />
<format target="http://www.rfc-editor.org/rfc/rfc4033.txt" type="TXT" />
</reference>
<reference anchor="RFC1035">
<front>
<title>DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION</title>
<author fullname="P. Mockapetris" initials="P."
surname="Mockapetris">
<organization></organization>
</author>
<date month="November" year="1987" />
</front>
<seriesInfo name="RFC" value="1035" />
<format target="http://www.rfc-editor.org/rfc/rfc1035.txt" type="TXT" />
</reference>
<reference anchor="RFC1464">
<front>
<title>Using the Domain Name System To Store Arbitrary String
Attributes</title>
<author fullname="R. Rosenbaum" initials="R." surname="Rosenbaum">
<organization></organization>
</author>
<date month="May" year="1993" />
</front>
<seriesInfo name="RFC" value="1464" />
<format target="http://www.rfc-editor.org/rfc/rfc1464.txt" type="TXT" />
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC5088">
<front>
<title>OSPF Protocol Extensions for Path Computation Element (PCE)
Discovery</title>
<author fullname="JL. Le Roux" initials="JL." surname="Le Roux">
<organization></organization>
</author>
<date month="January" year="2008" />
</front>
<seriesInfo name="RFC" value="5088" />
<format target="http://www.rfc-editor.org/rfc/rfc5088.txt" type="TXT" />
</reference>
<reference anchor="RFC5089">
<front>
<title>IS-IS Protocol Extensions for Path Computation Element (PCE)
Discovery</title>
<author fullname="JL. Le Roux" initials="JL." surname="Le Roux">
<organization></organization>
</author>
<date month="January" year="2008" />
</front>
<seriesInfo name="RFC" value="5089" />
<format target="http://www.rfc-editor.org/rfc/rfc5089.txt" type="TXT" />
</reference>
<reference anchor="RFC5452">
<front>
<title>Measures for Making DNS More Resilient against Forged
Answers</title>
<author fullname="A.Hubert" initials="A." surname="Hubert">
<organization></organization>
</author>
<date month="January" year="2009" />
</front>
<seriesInfo name="RFC" value="5452" />
<format target="http://www.rfc-editor.org/rfc/rfc5452.txt" type="TXT" />
</reference>
<reference anchor="RFC5382">
<front>
<title>NAT Behavioral Requirements for TCP</title>
<author fullname="S.Guha" initials="S." surname="Guha">
<organization></organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="RFC" value="5382" />
<format target="http://www.rfc-editor.org/rfc/rfc5382.txt" type="TXT" />
</reference>
<reference anchor="RFC5295">
<front>
<title>The TCP Authentication Option</title>
<author fullname="J. Touch" initials="J." surname="Touch">
<organization></organization>
</author>
<date month="June" year="2010" />
</front>
<seriesInfo name="RFC" value="5295" />
<format target="http://www.rfc-editor.org/rfc/rfc5295.txt" type="TXT" />
</reference>
<reference anchor="RFC2385">
<front>
<title>Protection of BGP Sessions via the TCP MD5 Signature
Option</title>
<author fullname="A. Heffernan" initials="A." surname="Heffernan">
<organization></organization>
</author>
<date month="August" year="1998" />
</front>
<seriesInfo name="RFC" value="2385" />
<format target="http://www.rfc-editor.org/rfc/rfc2385.txt" type="TXT" />
</reference>
<reference anchor="ALTO">
<front>
<title>ALTO Server Discovery</title>
<author fullname="S. Kiesel" initials="S." surname="Kiesel">
<organization></organization>
</author>
<date month="December" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-alto-server-discovery-22" />
</reference>
<reference anchor="BGP-LS">
<front>
<title>North-Bound Distribution of Link-State and TE Information
using BGP</title>
<author fullname="H. Gredler" initials="H." surname="Gredler">
<organization></organization>
</author>
<date month="November" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-idr-ls-distribution-04" />
</reference>
<reference anchor="PCE-QUESTION">
<front>
<title>Unanswered Questions in the Path Computation Element
Architecture</title>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization></organization>
</author>
<date month="July" year="2013" />
</front>
<seriesInfo name="ID"
value="http://tools.ietf.org/html/draft-ietf-pce-questions-00" />
</reference>
<reference anchor="RFC5245">
<front>
<title>Interactive Connectivity Establishment (ICE): A Protocol for
Network Address Translator (NAT) Traversal for Offer/Answer
Protocols</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization></organization>
</author>
<date month="April" year="2010" />
</front>
<seriesInfo name="RFC" value="5245" />
<format target="http://www.rfc-editor.org/rfc/rfc5245.txt" type="TXT" />
</reference>
<reference anchor="RFC7025">
<front>
<title>Requirements for GMPLS Applications of PCE</title>
<author fullname="T. Otani" initials="T." surname="Otani">
<organization></organization>
</author>
<date month="September" year="2013" />
</front>
<seriesInfo name="RFC" value="7025" />
<format target="http://www.rfc-editor.org/rfc/rfc7025.txt" type="TXT" />
</reference>
<reference anchor="RFC4927">
<front>
<title>Path Computation Element Communication Protocol (PCECP)
Specific Requirements for Inter-Area MPLS and GMPLS Traffic
Engineering</title>
<author fullname="JL. Le Roux" initials="JL." surname="Le Roux">
<organization></organization>
</author>
<date month="June" year="2007" />
</front>
<seriesInfo name="RFC" value="4927" />
<format target="http://www.rfc-editor.org/rfc/rfc4927.txt" type="TXT" />
</reference>
<reference anchor="RFC5376">
<front>
<title>Inter-AS Requirements for the Path Computation Element
Communication Protocol (PCECP)</title>
<author fullname="N. Bitar" initials="N." surname="Bitar">
<organization></organization>
</author>
<date month="November" year="2008" />
</front>
<seriesInfo name="RFC" value="5376" />
<format target="http://www.rfc-editor.org/rfc/rfc5376.txt" type="TXT" />
</reference>
<reference anchor="RFC6457">
<front>
<title>PCC-PCE Communication and PCE Discovery Requirements for
Inter-Layer Traffic Engineering</title>
<author fullname="T. Takeda" initials="T." surname="Takeda">
<organization></organization>
</author>
<date month="June" year="2007" />
</front>
<seriesInfo name="RFC" value="6457" />
<format target="http://www.rfc-editor.org/rfc/rfc6457.txt" type="TXT" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:56:43 |