One document matched: draft-wu-pce-dns-pce-discovery-02.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-02"
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>
<date year="2013" />
<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, in some deployment scenarios PCEs may not wish, or be able, to
participate within the IGP process, therefore it would be beneficial for
the Path Computation Client (PCC) (or other PCEs) 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 discovery via DNS for PCE.</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 PCEs) 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="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:">TBD.</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., intra-layer, 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>that allows PCCs to select appropriate PCEs:</t>
<t>This document specifies an extension to DNS for the above PCE
information discovery, which is complements the existing 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 Interior Gateway
Protocol (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>But the existing mechanism does not work in following
situations:</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:">[I.D.draft-ietf-idr-ls-distribution] 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 server 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="Query-Response v/s Advertisement">
<t>Advertisement based IGP PCE discovery [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 (say PCC) can use
DNS to discover a PCE only when it needs it and does not require any
other node in the network to be involved.</t>
<t>Incase 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 utilize DNS based
load-balancing and recovery functions.</t>
</section>
<section title="Network Address Translation Gateway">
<t>PCEP uses TCP as the transport [RFC5440]. To secure TCP connection
that underlay PCEP sessions, 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="Other Considerations">
<section title="Load Sharing of Path Computation Requests">
<t>Multiple PCE servers 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="Discovering a Path Computation Element">
<t>The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to
implement lazy binding of strings to data, in order to support
dynamically configured delegation systems. The DDDS functions by mapping
some unique string to data stored within a DDDS database by iteratively
applying string transformation rules until a terminal condition is
reached. When DDDS uses DNS as a distributed database of rules, these
rules are encoded using the Naming Authority Pointer (NAPTR) Resource
Record (RR). One of these rules is the First Well Known Rule, which says
where the process starts.</t>
<t>In current specifications, the First Well Known Rule in a DDDS
application [RFC3403] is assumed to be fixed, i.e., the domain in the
tree where the lookups are to be routed to, is known. This document
proposes the input to the First Well Known Rule to be dynamic, based on
the search path the resolver discovers or is configured to use.</t>
<t>The search path of the resolver can either be pre-configured, or
discovered using DHCP.</t>
<t>When the PCC or other PCEs needs to discover PCEs in the domain into
which the PCEP speaker has visibility (e.g.,local domain), the input to
the First Well Known Rule MUST be the domain the PCC knows, which is
assumed to be pre-configured in the PCC or discovered using DHCP.</t>
<t>When the PCC needs to discover PCE in the other domain (e.g., AS,
Parent PCE in the parent domain)into which the PCC has no visibility, it
SHOULD know the domain name of that domain and use DHCP to discover IP
address of the PCE in that domain that provides path computation service
along with some PCE location information useful to a PCC for 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 NAPTR lookups. If neither the
IP address nor other PCE location information can be discovered with the
above procedure, the PCC 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 does not find valid domain names using the procedures
above, it MUST stop the attempt to discover any PCE.</t>
<t>The dynamic rule described above SHOULD NOT be used for discovering
services other than Path computation services described in this
document, unless stated otherwise by a future specification.</t>
<t>The procedures defined here result in an IP address, PCE domain,
neighboring PCE domain and PCE Computation Scope where the PCC can
contact the PCE that hosts the service the PCC is looking for.</t>
<section title="Determining the PCE Service and transport protocol">
<t>The PCC should know the service identifier for the Path Computation
Discovery service. The service identifier for the Path Computation
Discovery service is defined as "PCED", The PCE supporting "PCED"
service MUST support only TCP as transport, as described in
[RFC5440].</t>
<t>The services relevant for the task of transport protocol selection
are those with NAPTR service fields with values "ID+M2X", where ID is
the service identifier defined in the previous section, and X is a
letter that corresponds to a transport protocol supported by the
domain. This specification only defines M2T for TCP. This document
also establishes an IANA registry for mappings of NAPTR service name
to transport protocol.</t>
<t>These NAPTR [RFC3403] records provide a mapping from a domain to
the SRV [RFC2782] record for contacting a PCE with the specific
transport protocol in the 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 MUST discard any service fields that identify a resolution
service whose value is not "M2T", for values of T that indicate TCP
transport protocols supported by the client. The NAPTR processing as
described in RFC 3403 will result in the discovery of the most
preferred transport protocol of the 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>As an example, consider a client that wishes to find PCED service
in the example.com domain. 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 50 50 "s" "PCED" ""
_PCED._tcp.example.com
IN NAPTR 90 50 "s" "PCED+M2T" ""
_PCED._tcp.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. Since the
client only supports TCP, TCP will be used, targeted to a host
determined by an SRV lookup of _PCED._tcp.example.com. That lookup
would return: <figure>
<artwork>
;; Priority Weight Port Target
IN SRV 0 1 XXXX server1.example.com
IN SRV 0 2 XXXX server2.example.com
</artwork>
</figure></t>
<t>where XXXX represents the port number at which the service is
reachable.</t>
<t>Note that the regexp field in the NAPTR example above is empty. The
regexp field MUST NOT be used when discovering path computation
services, as its usage can be complex and error prone. Also, the
discovery of the path computation service does not require the
flexibility provided by this field over a static target present in the
TARGET field.</t>
<t>If the client is already configured with the information about
which transport protocol is used for a path computation service in a
particular domain, it 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_PCED._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>
<section title="Determining path computation scope,capability,the PCE domains and Neighbor PCE domains">
<t>DNS servers MAY use DNS TXT record to give additional information
about PCE service and add TXT record to the additional information
section 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 includes path
computation scope, capability, the PCE domains and Neighbor PCE
domains associated with the PCE. the PCC MAY inspect those Additional
Information section and be capable of handling responses from
nameservers that never fill in the Additional Information part of a
response.</t>
</section>
<section title="Relationship between PCE-Domain and DNS Domain-Name">
<t>As per [RFC4655], PCE-Domain is a collection of network elements
within a common sphere of address management or path computational
responsibility. Examples of PCE-domains include Interior Gateway
Protocol (IGP) areas and Autonomous Systems (ASs). The DNS domain-name
should have a mechanism to link the IGP area or AS to the DNS
namespace.</t>
<t>Editors Note - To be discussed further</t>
</section>
</section>
<section title="IANA Considerations">
<t>The usage of NAPTR records described here requires well-known values
for the service fields for the transport supported by Path Computation
Services. The table of mappings from service field values to transport
protocols is to be maintained by IANA.</t>
<t>The registration in the RFC MUST include the following
information:<figure>
<artwork>
Service Field: The service field being registered.
Protocol: The specific transport protocol associated with that
service field. This MUST include the name and acronym for the
protocol, along with reference to a document that describes the
transport protocol.
Name and Contact Information: The name, address, email address,
and telephone number for the person performing the registration.
</artwork>
</figure></t>
<t>The following values have been placed into the registry:<figure>
<artwork>
Service Fields Protocol
PCED+M2T TCP
</artwork>
</figure></t>
<t>New Service Fields are to be added via Standards Action as defined in
[RFC5226].</t>
<t>IANA is also requested to register PCED as service name in the
Protocol and Service Names registry.</t>
</section>
<section title="Security Considerations">
<t>It is believed that this proposed DNS extension introduces no new
security considerations (i.e., A list of known threats to services using
DNS) beyond those described in [RFC3833]. 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>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="Acknowledges">
<t>The author would like to thank Claire Bi,Ning Kong, Liang Xia,
Stephane Bortzmeyer,Yi Yang, Ted Lemon and Adrian Farrel 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="RFC5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in
RFCs</title>
<author fullname="T.Narten" initials="T." surname="Narten">
<organization></organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5226" />
<format target="http://www.rfc-editor.org/rfc/rfc5226.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="RFC4848">
<front>
<title>Domain-Based Application Service Location Using URIs and the
Dynamic Delegation Discovery Service (DDDS)</title>
<author fullname="L. Daigle" initials="D." surname="Daigle">
<organization></organization>
</author>
<date month="April" year="2007" />
</front>
<seriesInfo name="RFC" value="4848" />
<format target="http://www.rfc-editor.org/rfc/rfc4848.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>
</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="RFC3401">
<front>
<title>Dynamic Delegation Discovery System (DDDS) Part One: The
Comprehensive DDDS</title>
<author fullname="M.Mealling" initials="M." surname="Mealling">
<organization></organization>
</author>
<date month="October" year="2002" />
</front>
<seriesInfo name="RFC" value="3401" />
<format target="http://www.rfc-editor.org/rfc/rfc3401.txt" type="TXT" />
</reference>
<reference anchor="RFC3833">
<front>
<title>Threat Analysis of the Domain Name System (DNS)</title>
<author fullname="D.Atkins" initials="D." surname="Atkins">
<organization></organization>
</author>
<date month="August" year="2004" />
</front>
<seriesInfo name="RFC" value="3833" />
<format target="http://www.rfc-editor.org/rfc/rfc3833.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="March" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-alto-server-discovery-08" />
</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="May" year="2013" />
</front>
<seriesInfo name="ID" value="draft-ietf-idr-ls-distribution-03" />
</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>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:46:58 |