On 27-nov-03, at 23:20, jfcm wrote:
Some others have technical implications. I would like to quote some
suggestions listed in the preparatory document, to get advices I
could quote at the meeting or in its report. Also to list the
alternative and additional suggestions some might do.
Ok, I'm not going to quote all the details...
This looks like a big old bag of DNS tricks. Obviously the virtue of
each can be discussed individually, but wouldn't it make more sense to
start thinking about a more structured approach to arrive at the
intended benefits?
For instance, one issue seems to be the ability to continue to reach
systems using domain names when there is a problem with the DNS
infrastructure. This could be addressed by modifying the caching
mechanisms in DNS resolvers. The way things are done now is throw away
the old shoes (cached information) and then see if new ones can be
found. Rather bizarre if you think about it.
2. a menu server system permitting to access sites though their IP
address only. This would be a good promotion for IPv6 due to the
easiness to support IP virtual hosts addresses. As a security oriented
alternative to the NSI network unstabilization.
This could lead to pressure to make IP addresses more portable, which
isn't a good thing.
6. an evolution towards an international root matrix supporting
proximity root servers and proximity TLDs for abbreviated addressing
through local TLDs. The organization and the procedure of the common
authoritative root matrix should be internationally approved and
subject to the ICP-3 proposed testing rules. A quoted example
documents the target as "hart.sos" of pacemakers always resolving to
the nearest hospital (as decided by local authorities).
This isn't something you can do with simple (or even not so simple)
n-faced DNS. For instance, here in the Netherlands many service
providers backhaul all their traffic to Amsterdam over the phone
infrastructure (dial-up) or ATM (DSL). Those customers then share IP
address space and DNS resolvers. Getting the location info back in
there would be almost impossible.
However, it could be useful to create mechanisms that make it easier
for hosts to discover location information. For instance, through a
DHCP option. This information can then be used when searching
directories or search engines. (This would have interesting commercial
possibilities as well.)
- a national host numbering scheme. With an immediate identification
of any host on any network whatever the location change or connection
organized.
This second would also protect IPv6 technology and equipment from a K2
like syndrome when a new plan could be discussed, as it would have
permitted to validate the multiple plan possibility.
In the multi6 (multihoming in IPv6) working group, as one of many
proposals, we've been looking at putting a 64 bit host identifier in
the bottom 64 bits of an IPv6 address. If such a host identifier is
crypto-based (ie, a hash of a public key) then it is possible to
authenticate a host at any time regardless of where the host connects
to the network at that particular time and without the need for a PKI
or prior communication.
(I have no idea what "K2 syndrome" means by the way, and it looks like
Google doesn't either.)