[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Does every host need a FQDN name in the future?//re:[RRG] draft-rja-ilnp-intro-01.txt
Hi Brian -
You can always fabricate a synthetic FQDN-like name for such an
address, if a new FQDN-based API requires it. Mine right now could
be
200282d8267c00000000000082d8267c.map6.arpa for example.
This idea is workable as ENUM. However, I wonder who will manage
those
mapping entries?
They don't need managing; they aren't really in the DNS, but are
purely synthetic. (Which means they can't be validated with DNSSEC and
there will be no reverse DNS.) But a resolver could be faked to
"resolve" them into a AAAA reply.
It's a horrible idea ;-)
Why is it a horrible idea? I would say it is a straightforward and
practical method to support hosts without a real hostname when
hostnames are used as identifiers.
As I mentioned during the RRG session in Dublin as well as in an
earlier post [1] to this mailing list, we should re-consider whether
there really is a need for another ID/locator split in addition to the
existing hostname/address split. I do not believe there is. We would
get all the benefits we are after if we re-used the existing
hostname/address split, and moved the splitting point from between the
application layer and the transport layer down to between the
transport layer and the IP layer.
When we get to the engineering stage, we would need to work out three
auxiliary methods:
(1) to generate synthetic hostnames for hosts without a real hostname
(2) to support legacy transport protocols
(3) to communicate hostnames to correspondent hosts
Synthesizing a hostname based on an address, as you are suggesting, is
IMHO a very reasonable solution for (1).
A simple and secure solution for (2) would be to hash an arbitrary-
length hostname into 128 bits and use this in legacy transport
protocols -- just like HIP is generating 128-bit HITs from
arbitrary-length keys.
A cool solution for (3) could be the combination of (i) an initial
explicit exchange of hostnames between peers, and (ii) Noel's proposal
to compute checksums based on identifiers (hostnames, in this case)
for subsequent packets.
- Christian
[1] http://www.ops.ietf.org/lists/rrg/2008/msg01912.html
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg