GROBJ BOF B. Carpenter, Ed.
Internet-Draft Univ. of Auckland
Intended status: Informational January 20, 2010
Expires: July 24, 2010
Problem Statement and Requirements for Generic Referrals
draft-carpenter-grobj-reqts-00
Abstract
The purpose of a referral is to enable a given entity in a multiparty
Internet application to pass information to another party. This memo
discusses the problems involved and describes requirements for a
generic referral mechanism.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 24, 2010.
Copyright Notice
Copyright (c) 2010 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
Carpenter Expires July 24, 2010 [Page 1]
Internet-Draft Referral Requirements January 2010
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 BSD License.
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2. The additional problem of scope . . . . . . . . . . . . . . . 7
3. The additional problem of path selection . . . . . . . . . . . 10
4. Summary of Requirements . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Contributing authors . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. Change log . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Carpenter Expires July 24, 2010 [Page 2]
Internet-Draft Referral Requirements January 2010
1. Introduction and Problem Statement
A frequently occurring situation is that one entity A connected to
the Internet (or to some private network using the Internet protocol
suite) needs to inform another entity B how to reach either A itself
or some third-party entity C. This is known as a referral.
In the original design of the Internet, IP addresses were global,
unique, and quasi-permanent. Also any differentiation beyond that
provided by an IP address was done by protocol and port numbers.
Referrals were therefore performed simply by passing an IP address
and possibly protocol and port numbers. In fact simple referrals
(the first case above, sometimes called first-party referrals) were
never needed since B could simply use A's address. Third-party
referrals were trivial: A would tell B about C's address. Thus, it
became common practice to pass raw addresses between entities. A
classical example is the FTP PORT command [RFC0959].
Unfortunately, this simple approach to referrals often fails in
today's Internet. As has been known for some time [RFC2101],
addresses no longer all have global scope, often have limited
reachability, and may have limited lifetime. It is no longer
reasonable to assume that a host with a fixed location has a fixed
address, or even a stable address.
We also encounter multi-interfaced hosts whose reachability is bound
to a particular (logical/physical) interface. Furthermore, in the
context of IPv4 address exhaustion, several solutions have emerged to
share a single public IPv4 address between several customers
simultaneously. Consequently, an IPv4 address often no longer
identifies a single customer/user/host. Other information (e.g.,
port range) is required to identify unambiguously a given customer/
user/host.
Both addresses and port numbers may be different on either side of a
NAT or some other middlebox [RFC3234], and firewalls may block them.
It is no longer reasonable to assume that an address for host H,
which allows a given peer to reach that host in one location, also
works from a different location - even if H is reachable from the
second location. Also, the Internet now has two co-existing address
formats for IPv4 and IPv6. Having the address of the source and
destination in the same IP version does not necessarily mean that the
path will be using that IP version. Simple approaches may cause
unnecessary double translation [I-D.boucadair-softwire-cgn-bypass].
Some addresses may even be the result of translation between IPv4 and
IPv6, with severe limitations on their scope and lifetime. Sending
an out-of-scope or expired address, or one of the wrong format, as a
referral will fail.
Carpenter Expires July 24, 2010 [Page 3]
Internet-Draft Referral Requirements January 2010
IP addresses today may have an implied "context" (VPN, VoIP VC, IP
TV, etc.): the reachability of such an address depends on that
context.
In some cases, this problem may be readily solved by passing a Fully
Qualified Domain Name (FQDN) instead of an IP address. Indeed, that
is an architecturally preferred solution [RFC1958]. However, it is
not sufficient in many cases of dynamic referrals. Experience shows
that an application cannot use a domain name in order to reliably
find useable address(es) of an arbitrary peer. Domain names work
fairly well to find the addresses of public servers, as in web
servers or SMTP servers, because operators of such servers take pains
to make sure that their domain names work. But DNS records are not
as reliably maintained for arbitrary hosts such as might need to be
contacted in peer-to-peer applications, or for servers within
corporate networks. Many small networks do not even maintain DNS
entries for their hosts, and for some networks that do list local
hosts in DNS, the listings may well be unusable from a remote
location, because of two-faced DNS, or because the A record contains
a private address. These cases may even be intentional as part of a
security ring-fence, where w3.example.com only resolves within the
corporate boundary, and/or resolves to IP addresses which are only
reachable within the corporate administrative boundaries. In such
contexts, incoming connections are usually filtered by the corporate
firewall.
An additional issue with FQDNs is the very common situation where
multiple hosts are hidden behind a NAT, but they share one FQDN which
is in fact a dummy name, created automatically by the ISP so that
reverse DNS lookup will succeed for the NAT's public IPv4 address.
Such FQDNs are useless for identifying specific hosts.
Furthermore, an FQDN may not be sufficient to establish successful
communications involving heterogeneous peers (i.e., IPv4 and IPv6)
since A and AAAA records may not be consistently provisioned. There
are known cases where a server has one name that produces an A record
(e.g., www.example.com) and another name that produces an AAAA record
(e.g., ipv6.example.com). An additional complication is that some
answers from DNS may be synthetic IP addresses, e.g., AAAA records
sent by DNS64. The host may have no means to detect that such an
address represents an IPv4 host. These addresses should not be
interpreted as native IPv6 address.
In such cases, an IP address either cannot be derived from an FQDN,
or if so derived, cannot be accessed from an arbitrary location in
the Internet.
A related problem is that an application does not have a reliable way
Carpenter Expires July 24, 2010 [Page 4]
Internet-Draft Referral Requirements January 2010
of knowing its own domain name - or to be more precise, a way of
knowing a domain name that will allow the application to be reached
from another location.
There are wider systemic problems with the DNS as a reliable way to
find a useable address, which are somewhat out of scope here, but can
be summarised:
o In large networks, it is now quite common that the DNS
administrator is out of touch with the applications user or
administrator, and as a result, that the DNS is out of sync with
reality.
o DNS was never designed to accommodate mobile or roaming hosts,
whose locator may change rapidly.
o DNS has never been satisfactorily adapted to isolated,
transiently-connected, or ad hoc networks.
o It is no longer reasonable to assume that all addresses associated
with a DNS name are bound to a single host. One result is that
the DNS name might suffice for an initial connection, but a
specific address is needed to rebind to the same peer, say, to
recover from a broken connection.
o It is no longer reasonable to assume that a DNS query will return
all usable addresses for a host.
o Hosts may be identified by a different URI per service: no unique
URI scheme, meaning no single FQDN, will apply.
For all the above reasons, the problem of address referrals cannot be
solved simply by recommending the use of FQDNs instead. The
guideline in [RFC1958] is in fact too simple for today's network.
Something more elaborate than an IP address or an FQDN appears to be
needed in the general case of application referrals.
The first problem motivating this draft is the observation that
unless the parties involved have reached an understanding about the
scope, lifetime, and format of the elements in a referral through
some other means, that information must be passed with the referral.
This is required so that the receiving entity can determine whether
or not the referral is useful. The referral therefore needs to
consist of a fully-fledged data structure, or to be made using a
mutually agreed referral protocol.
When a referral fails, good design suggests that the receiving entity
should attempt to correct the situation. For example, if
communication fails to be established using an IP address, it would
often be appropriate to attempt a DNS lookup, despite the
difficulties mentioned above. The second motivating problem is that
it may be helpful to the entity receiving a referral to also receive
information about the source of the referral, such as an FQDN, if
that is known to the sender of the referral. The receiving entity
Carpenter Expires July 24, 2010 [Page 5]
Internet-Draft Referral Requirements January 2010
can then attempt to recover a valid address (and possibly port
number) for the referred entity.
The third motivating problem is to allow a referral to contain
alternatives to an IP address or an FQDN, when any such alternatives
exist.
Additional arguments for a generic referral mechanism include:
1. Allow for general mechanisms that can be used by any application
to handle referrals and understand the meaning of referral
information, such as IP address, possibly protocol and port
numbers. However, there is an open question whether this
standard referral design should be used for new applications
only, or extended to existing applications.
2. Simplify ALG design during middlebox traversal. There are
middleboxes, like firewalls and translators, especially in the
mobile network, which require application layer gateways ALG.
The cost of ALG functions is huge for the mobile operator in
terms of implementation, performance. Standard referrals could
simplify ALG implementation during middlebox traversal in the
mobile network.
3. Simplify packet inspection. Operators sometimes need to inspect
information or details during communication for administration
reasons. If referral mechanism is standardized, it is easier for
an operator to capture and investigate the required information.
We observe that we have identified two general requirements: the need
to define address scope more precisely, and the need to communicate
referrals in a generic way.
It should be noted that partial or application-specific solutions to
these problems abound, because any multi-party distributed
application must solve them. The best documented example is ICE
[I-D.ietf-mmusic-ice], which is an active protocol specific to
applications mediated by SDP [RFC4566]. ICE "works by including a
multiplicity of IP addresses and ports in SDP offers and answers,
which are then tested for connectivity by peer-to-peer connectivity
checks." The question raised here is whether we can define
requirements for a generic solution that can be used by future
applications, and possibly be retro-fitted to existing applications.
One approach could be a "SuperICE" designed to be completely general
and not tied to the SDP model. Another approach, considered here, is
the idea of a generic referral object, defined below. Such an object
could be passed between the entities of a multi-party application,
but without defining a specific protocol for that purpose. Some
applications might choose to send it in-band as a raw binary object,
others might use a simple ASCII encoding, and still others might
Carpenter Expires July 24, 2010 [Page 6]
Internet-Draft Referral Requirements January 2010
prefer to encode it in XML, for example. Finally, it might also be
used as part of SuperICE.
1.1. Terminology
This document makes use of the following terms:
o "Entity": we use this rather than "application" to describe any
software component embedded in an Internet host, not just a
specific application, that sends, receives or makes use of
referrals. Also, in case of dynamic load sharing or failover, an
entity might even migrate between hosts.
o "Referral": the act of one entity informing another entity how to
contact a specific entity.
o "Generic Referral Object (GRO)": a data object expressed in an
application-independent format that can be passed between entities
to communicate referrals.
o "Reference": the actual data (name, address, identitifier,
locator, pointer, etc.) that is the basis of a referral. The
reference(s) contained in a GRO provide an entity with sufficient
information to utilise one or more methods to attempt to reach
another entity.
o "Qualifier": a data item that gives additional information about a
Reference, such as lifetime, port numbers, etc.
o "Referring entity": the entity that sends a referral.
o "Receiving entity": the entity that receives a referral.
o "Referenced entity": the entity described in a GRO; the target of
a reference.
o "Scope": the region or regions of the Internet within which a
given reference is applicable to reach the referenced entity. See
further discussion in the next section.
o "Scope Identifier" (ScopeID): an identifier in an unambiguous
namespace for the scope of a reference. Used as a Qualifier.
o "Limited Scope": whatever set of referring and receiving entities
have been configured (statically or dynamically) to accept a given
Scope Identifier.
2. The additional problem of scope
The principal purpose of a referral is to enable one entity in a
multi-party application to pass information to another party involved
in the same application. This document makes no assumptions about
whether the entities are acting as clients, servers, peers, super-
nodes, relays, proxies, etc., as far as the application is concerned.
Neither does it take a position as to how the various entities become
aware of the need to send a referral; this depends entirely on the
structure of the application.
Carpenter Expires July 24, 2010 [Page 7]
Internet-Draft Referral Requirements January 2010
Since the most fundamental quantity likely to be conveyed in a GRO is
an IP address, (and possibly a port number) its scope is a key
question. Address scope is not a simple concept, as shown by the
discussion in [RFC4007] and the practical difficulties caused by
[RFC3484]. Even the concept of link-local scope is complicated by
the existence of multi-link subnets [RFC4903]. For the purpose of
referrals, it seems that previous formalisations of the concept of
scope are inadequate. Assuming that a GRO is trustworthy, one
question that a receiving entity must answer is: "can the address in
this GRO be reached from here?" That question is not answered by
knowing only the scope (in the sense of [RFC4007]) as defined at the
location of the referring entity. For that reason, scope needs to be
represented in a new way in GROs. Firstly, the effective scope (to
the best of the referring entity's knowledge) could be any of the
following:
o Null. The address is known not to be applicable outside the
referring host (e.g., a loopback address). This option is
mentioned mainly for completeness; it has no value in a GRO, and
for privacy reasons it should not be communicated anyway.
o Link. Apart from the standard Ethernet-like view of link
locality, this scope would also apply to point-to-point links and
to fragments of a multi-link subnet. Although on-link referrals
should be trivial, this case is included to allow for uniform
design of applications utilising GROs, so that link-local does not
become a special case.
o Limited. The address has applicability beyond the link, but it is
known not to have global applicability. Examples include IPv4
private addresses [RFC1918] and IPv6 Unique Local Addresses
(ULAs)[RFC4193]. Other cases include addresses on subnets which
the referring entity knows to be obstructed by firewalls, network
address translators, or other barriers to transparency [RFC2775].
A typical case is the set of subnets sharing a single set of
border routers connecting them to the Internet.
o Global. The address has applicability beyond the link, and is
believed to have global applicability within its address family.
However, particularly in the case of limited scope, this is
insufficient for the receiving entity to decide whether the address
is applicable in the receiving entity's context. The scopes above
are described as if they were a set of concentric circles, but
reality is more complex, and limited scopes might overlap each other
in an arbitrary way, for example when multiple VPNs are formed. A
case in point is a VPN constructed between two independent sites,
over which only those two sites' ULAs are routed. This would allow a
complex pattern of overlapping scopes. For example, hosts in site A
might potentially have addresses in three different scopes (global,
Site_A_only, ULA_A+B). Similarly, site B might also recognize three
scopes (global, Site_B_only, ULA_A+B). Which hosts can send packets
Carpenter Expires July 24, 2010 [Page 8]
Internet-Draft Referral Requirements January 2010
to each other will depend on the combination of addresses and scopes
available. For example, a host which only has an address in scope
Site_A_only cannot send a packet to a host which only has an address
in scope ULA_A+B. Hosts in scope ULA_A+B can send packets between
sites A and B over the VPN. This can readily be encoded in routing
configurations, but application software is generally unaware of it.
Thus, a referring entity may or may not be aware that the receiving
entity and the referenced entity are within a link scope or limited
scope that does not contain the referring entity.
The delimiter of a limited scope will in many cases be the device
(firewall or NAT) that obstructs transparency. A tempting solution
would be to use some unique identifier of that device as the unique
ScopeID. Unfortunately, this cannot be an IP address of the device,
since in the case of nested NATs, all its addresses may be ambiguous.
Neither can we rely on such a device having its own FQDN, or on that
FQDN being known to all entities within the scope concerned.
Finally, some limited scopes may not be hidden behind a single such
device; for example, a limited scope might consist of a company's
network and selected VPN connections to subsets of several business
partners' networks. Alternatively, multiple limited scopes might be
hidden behind the same device. Device addresses are therefore not
suitable as ScopeIDs.
Methods for configuring, advertising and discovering ScopeIDs are not
discussed in this document. However, in their absence, it is
extremely hard for receiving entities to interpret and use
information about limited scopes. To the extent possible, all
entities involved in referrals should determine what scope is shared
between the referred entity and the receiving entity, by any means.
Those means are not covered in this document, but may include use of
external services, agreement on scope identifiers, or direct
negotiation.
In general, the referring entity cannot know the scope in which the
GRO will be interpreted. For example, the initial receiving entity
may itself be behind a NAT, unknown to the referring entity, or the
receiving entity may send the GRO onwards to another host in yet
another scope. In practice, we have to leave the receiver to decide
whether certain information is useful or not. In the case of a
ScopeID in particular, the referring entity is not able to know which
ScopeIDs apply to the receiving entity.
Discovery or negotiation of ScopeIDs between referring, referenced
and receiving entities is certainly a possibility, but may be
expensive, and is not assumed by this document.
Carpenter Expires July 24, 2010 [Page 9]
Internet-Draft Referral Requirements January 2010
A referring entity may obtain the address and port number for the
referenced entity in various ways, and knowledge about this may help
the receiving entity when combined with scope information. For
example, if the receiving entity is aware that the address has been
translated, and that it has global scope, it may choose to use it
without further checks. If it is not marked as translated, and has
limited scope, the receiving entity may then verify whether it has a
suitable ScopeID.
To enable such logic, a GRO may describe the source of an address or
port number. How knowledge of this source is obtained is outside the
scope of the present document, but ICE [I-D.ietf-mmusic-ice] is an
example method. It is also out of scope here to describe exactly how
the receiving entity uses the information; for example GRO semantics
do not include or imply preferences or priorities when multiple
addresses are provided. The receiving entity may choose to use a
predefined policy, apply general logic as sketched in the previous
paragraph, or follow application-specific logic, all based on the
data provided in a GRO.
Finally we note that theoretical scope does not guarantee actual
reachability. A receiving entity should always be prepared for
reachability failures and associated retry and failover mechanisms.
3. The additional problem of path selection
We note that theoretical scope does not guarantee actual
reachability. A receiving entity should always be prepared for
reachability failures and associated retry and failover mechanisms.
A GRO might carry multiple references for the same target. These may
lead to multiple paths from the receiving entity to the referenced
entity. The referring entity is not likely to know which path is
best. The receiving entity will need to make a choice, possibly by
policy (e.g. [RFC3484]) or possibly by trial and error (e.g.
[RFC4038], [RFC5534]). Even if a reference is in scope, and within
its defined lifetime, it may have become unreachable since it was
sent. The whole problem of path selection is quite complex in
itself, and is not discussed further in this document.
4. Summary of Requirements
R1: A GRO should contain all available information that the referring
entity can provide (subject to security policy) about the scope,
lifetime, format and source of the referral. It is the
responsibility of the referring entity to construct a GRO on the
Carpenter Expires July 24, 2010 [Page 10]
Internet-Draft Referral Requirements January 2010
basis of information in its possession.
[[ Discussion invited: Another view is that a GRO should contain the
minimum information required to establish connectivity. The problem
is that the referring entity may not know enough about the context of
the receiving entity to determine what that minimum is. ]]
R2: It is the responsibility of the receiving entity to interpret and
check this information by testing reachability. Due to the barriers
to connectivity in today's Internet, the referring entity cannot
guarantee that the referenced entity can be reached by any specific
reference. This can only be checked by the receiving entity. In the
event of a reachability problem, the alternative information in the
GRO may assist the receiving entity to find a working path.
R3: A GRO must contain at least one Reference. One option would be
to make the presence of at least one IP address mandatory. However,
there are alternatives, the most obvious one being an FQDN. Any form
of identifier-locator separation, with HIP [RFC5201] as an example,
may also offer an alternative. Therefore, we do not require a GRO to
include an IP address, even though its inclusion is a very likely
case.
R4: A GRO should be self-contained in a context-independent format.
Even if it is forwarded several times across the network, the
ultimate receiving entity should be able to extract and interpret all
the information inserted by the original referring entity.
R5: A GRO should be compact and designed for efficient processing.
R6: The GRO format must not be specific to a given IP version.
R7: The GRO format should be extensible with well-defined backwards
compatibility.
R8: A GRO must be able to contain any reasonable number of References
of mixed types.
R9: Each Reference may carry any reasonable number of Qualifiers.
R10: To maintain efficiency, intrinsic error detection or correction
for GROs should not be mandatory. Therefore, GROs should be sent
over a channel supporting error detection or correction.
R11: To maintain efficiency, intrinsic cryptographic authentication
of GROs should not be mandatory. The use of an authenticated channel
to transmit GROs is recommended.
Carpenter Expires July 24, 2010 [Page 11]
Internet-Draft Referral Requirements January 2010
R12: To maintain efficiency, intrinsic encryption of GROs should not
be mandatory. The use of an encrypted channel to transmit GROs is
recommended.
R13: A GRO must be able to include a lifetime as a Qualifier for each
Reference.
R14: A GRO must be able to include a scope identifier (ScopeID) as a
Qualifier for each Reference.
R15: There needs to be a high level of assurance that ScopeIDs are
unique, or at least that a GRO will never be forwarded outside a
region in which ScopeIDs are unique.
R16: All referring and receiving entities need to be aware of the
ScopeID(s) that apply to them. However, it is clearly undesirable to
create a new global registration scheme for ScopeIDs.
R17: If shared scope (or set of scopes) is determined between the
referring and receiving entities, a referral should ideally only
include information useful in that scope or set of scopes. If shared
scope is uncertain, a referral should include all information that
might be useful, taking privacy considerations into account.
[[ Discussion invited: Should we also require optional preference
information for each reference in a GRO, or alternatively require
that references be listed in order of preference? Here is some
tentative text. ]]
Rxx: A preference order (or reachability trust level?) may be
associated with references.
Ryy: The receiving entity will interpret the preferences in
accordance with local policies (sometimes on per interface basis).
5. Security Considerations
It should be noted that GROs cannot function as a way to nullify the
effect of a firewall or any other security mechanism. If the
receiving entity chooses a particular reference in the GRO and
attempts to send packets to the corresponding IP address, whether
they are delivered or not will depend on the existing security
mechanisms, whatever they may be.
Nevertheless, if a site security policy requires it, certain
references may be excluded from GROs sent to certain destinations.
This would require a security policy mechanism to be added to the
Carpenter Expires July 24, 2010 [Page 12]
Internet-Draft Referral Requirements January 2010
process of generating GROs.
Forged or intercepted GROs would enable a wide variety of attacks.
Although not fundamentally different from attacks based on forged or
observed IP addresses or FQDNs, no doubt GROs would allow such
attacks to be more ingenious, simply because they provide more
information than an address or FQDN alone. As noted in Section 4,
GROs should be transmitted through authenticated and encrypted
channels. Since this is a requirement of the channel and not of the
GRO, and the channel used depends on a specific use case, it is not
further elaborated here.
Conceivably, an extension to the GRO format could be defined which
would allow it to carry security information (for example, some sort
of handle or nonce to authorise firewall penetration). Any such
extension must be adequately encrypted, in such a way that only a
receiving entity in possession of a given key can decrypt it. This
is necessary even if the GRO is transmitted through a secure channel.
GROs raise potential privacy issues, which are not explored in this
document. For example, in the SIP context, mechanisms such as
[RFC3323] and [I-D.ietf-sip-ua-privacy] are available to hide
information that might identify end-points. Usage scenarios for GROs
must ensure that they do not unintentionally defeat privacy
solutions.
6. IANA Considerations
This document requests no action by IANA.
7. Contributing authors
At the moment, one editor is shown for this document. Authors of two
preceding drafts whose text has been used were: Mohamed Boucadair,
Joel Halpern, Sheng Jiang, Keith Moore and Bo Zhou.
8. Acknowledgements
This document was requested by the GROBJ BOF at IETF76. Valuable
comments and contributions were made by Scott Brim, Alan Ford, Simon
Perreault, Andrew Sullivan, Dan Wing, and others.
This document was produced using the xml2rfc tool [RFC2629].
Carpenter Expires July 24, 2010 [Page 13]
Internet-Draft Referral Requirements January 2010
9. Change log
draft-carpenter-grobj-reqts-00: original version, 2010-01-20
10. References
10.1. Normative References
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
10.2. Informative References
[I-D.boucadair-softwire-cgn-bypass]
Boucadair, M., "Procedure to bypass DS-lite AFTR",
draft-boucadair-softwire-cgn-bypass-00 (work in progress),
December 2009.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-ua-privacy]
Munakata, M., Schubert, S., and T. Ohba, "UA-Driven
Privacy Mechanism for SIP", draft-ietf-sip-ua-privacy-08
(work in progress), May 2009.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 959, October 1985.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
Address Behaviour Today", RFC 2101, February 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
Carpenter Expires July 24, 2010 [Page 14]
Internet-Draft Referral Requirements January 2010
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
Issues", RFC 3234, February 2002.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
June 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, June 2009.
Author's Address
Brian Carpenter (editor)
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Carpenter Expires July 24, 2010 [Page 15]