Short version: A passage from draft-carpenter-referral-ps-00
indicates that ILNP's reliance on FQDNs and
DNS is more problematic than anticipated in
the ILNP I-Ds.
From that passage:
"Experience shows that an application
cannot use a domain name in order to
reliably find usable address(es) of an
arbitrary peer."
While writing up an extension to (msg07017) of my critique of
CEE architectures, in particular ILNP, involving extra delays,
packets etc. compared to today's IP protocols, I encountered a
passage in an I-D which mentions the many difficulties inherent
in relying on FQDNs to identify hosts in general. These apply
for session establishment and for attempting to restore a
session which is broken due to an IP address (or for ILNP,
Locator) change.
ILNP's session establishment is most easily understood if the
initiating application starts with a FQDN and does a DNS lookup
on it, via the stack - which will gain from the reply some
information which will directly (or indirectly, with an LP
record and a second DNS lookup) provide it with the Identifier
and Locator(s) it needs to create ILNP communications with the
desired host.
Ran's I-D draft-rja-ilnp-intro-05 asserts (9.1) that in most
cases, IP address based referrals will work - but I am trying
to figure out how, and am not yet convinced.
In section 9.3, Ran suggests the use, in the future, of a
special "referral object" being devised in the I-D I will quote
from below. But that would require applications be rewritten.
He also states:
A more sensible approach to referrals would be to use
Fully-Qualified Domain Names (FQDNs), as is commonly done
today with web URLs. This is approach is highly portable
across different network protocols, even with both the IPv4
Internet or the IPv6 Internet.
However, this too would require application changes - since I
think most applications now do referrals with IP addresses. The
above paragraph seems to me to be optimistic to the point of
unrealism considering the passage I quote below.
The quote is from:
Problem Statement for Referral
http://tools.ietf.org/html/draft-carpenter-referral-ps-00
B. Carpenter, Univ. of Auckland
S. Jiang, Huawei Technologies
B. Zhou ChinaMobile
2010-06-21
The quotation below is based on a similar passage in a now
expired I-D which is cited in draft-rja-ilnp-intro-05:
A Generic Referral Object for Internet Entities
http://tools.ietf.org/html/draft-carpenter-behave-referral-object-01
Ran suggests that in the future, such an object would be good
for referrals. However, the use of such objects would require
application changes - and one of the major attractions of ILNP
is its claimed ability to support unaltered applications.
The quote below concerns "addresses". ILNP works with Locators
and an Identifier, but I think the problems remain much the same.
It is also true that ILNP requires functional DNS arrangements
for every host - so this is a known part of the cost of adopting
the architecture. Some of the problems mentioned below concern
IPv4 NAT - and hopefully IPv6 generally won't involve NAT.
The requirement that every host in the future (assuming
ubiquitous ILNP adoption) have its own securely and reliably
updated DNS entry is non-trivial. In a recent message msg07102,
Tony Li cast aspersions on reliance on bureaucracies (for
instance for hierarchically assigning Identifier space, which he
opposes) - yet DNS involves bureaucracy, dependence on
centralized and decentralized servers etc.
ILNP's dependence on short or zero caching time DNS replies
means that each host is highly dependent on DNS in real-time.
ILNP would cause the number of queries to rise compared to the
pattern now, with most or all of those queries going to an
authoritative server rather than being answered by caching
resolvers.
The CES architectures - LISP, Ivip and IRON - do not alter host
behavior and introduce no new problems with referrals, or new
requirements for hosts relying on DNS.
ILNP involves starting with an FQDN and by looking up this,
gaining an Identifier (perhaps chosen from multiple Identifiers)
and one or more Locators. (However, as far as I can tell, if
there are more than one Identifiers, all of them must have the
same Locators - so ILNP does not appear to allow the equivalent
of round-robin DNS with hosts which have different Locators.)
Many hosts would use an LP record in their DNS entry, rather
than one or more L64 Locator records. The LP record is another
FQDN which the initiating host must look up to find the current
Locator(s) of the subnet which the desired host is connected to.
So this involves a second non-cachable DNS query before the
first packet can be sent.
Thereafter, the session is bound to the Identifier alone. (This
description is only for globally unique Identifiers - Identifiers
which are only locally unique, within a /64, are much messier
things I prefer not to think about.)
As I currently understand ILNP, the stack somehow presents a
single IP address to the application - and the application's
session is bound to that IP address. As the Locators may change,
and the stack is notified of these changes, the session can
continue by whichever Locators are active - while the stack
maintains the original IP address in its dealings with the
application.
- Robin
4.2. FQDNs are not sufficient
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 usable 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
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 usable 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.
[I think this refers to round-robin DNS, which I think ILNP
will only do if all hosts have the same Locator(s). RW.]
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.
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
