The Great Naming Debate (was Re: The internet architecture)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The Great Naming Debate (was Re: The internet architecture)
So, after being distracted by OSDI last week, I'm now trying to catch
up on the raging debates on TAE that are already exceeding all the
wildest dreams I had before setting up the list... :)
On the issue of weaning applications (and potentially transports) away
from IP addresses in favor of names of some kiFrom ietf-bounces at ietf.org Mon Dec 15 10:43:54 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 0306C3A6964;
Mon, 15 Dec 2008 10:43:54 -0800 (PST)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 88E5C3A68B0
for <ietf at core3.amsl.com>; Sun, 14 Dec 2008 11:51:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.359
X-Spam-Level:
X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5
tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9v4Xv8p2T0Eq for <ietf at core3.amsl.com>;
Sun, 14 Dec 2008 11:51:14 -0800 (PST)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154])
by core3.amsl.com (Postfix) with ESMTP id 1D97B3A67D2
for <ietf at ietf.org>; Sun, 14 Dec 2008 11:51:13 -0800 (PST)
Received: by fg-out-1718.google.com with SMTP id d23so1120248fga.41
for <ietf at ietf.org>; Sun, 14 Dec 2008 11:51:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:cc:message-id:from:to
:in-reply-to:content-type:content-transfer-encoding:mime-version
:subject:date:references:x-mailer;
bh=jak8HjlJAPIeFxZxAEwZl/7cy7xuun4fKbliK++LLGk=;
b=WgA800sybjQEen/CDVuGF+QZ3m/ocqkex724rLbjRIiZdFs4XzNHD+cI8270ucgNfd
6BY2LbnY6v07RBQYsth3/MeOgNPRWLBL3ChscBlXmXiLOg2V/HErldAMXSvyjcuTO0ED
vtfdHMFqnis8sf8qgd3Kt7MYKd8qLZ2pxhV6c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=cc:message-id:from:to:in-reply-to:content-type
:content-transfer-encoding:mime-version:subject:date:references
:x-mailer;
b=S03rt/wyFT+z6XorzaFPxkPO9/Ly7Xs1CkNAROaTIeGFVm6Csv+oU9bqfivHQTqUoY
J5TBhlwvncw1pfCNTSnIakpVplDj5sSHk9csiCwUF4FCNtI9lZEDw1IgXUtPt3pqAd/r
IoqoygXnVNCK+vpG2didk9m9AstcaXrzlL6io=
Received: by 10.86.4.2 with SMTP id 2mr3342871fgd.43.1229284265465;
Sun, 14 Dec 2008 11:51:05 -0800 (PST)
Received: from ?192.168.178.36? (p54A594E9.dip0.t-ipconnect.de
[84.165.148.233])
by mx.google.com with ESMTPS id e20sm67608fga.13.2008.12.14.11.51.04
(version=TLSv1/SSLv3 cipher=RC4-MD5);
Sun, 14 Dec 2008 11:51:04 -0800 (PST)
Message-Id: <C3937105-9315-42E7-97B1-E96292AB81BD at gmail.com>
From: Bryan Ford <brynosaurus at gmail.com>
To: Keith Moore <moore at network-heretics.com>
In-Reply-To: <49384BCF.2080600 at network-heretics.com>
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: The Great Naming Debate (was Re: The internet architecture)
Date: Sun, 14 Dec 2008 20:51:03 +0100
References: <C15AE32B-E564-4C93-86FF-40EF203E673A at mpi-sws.org>
<49382030.5020704 at network-heretics.com>
<2788466ED3E31C418E9ACC5C316615572FFBEF at mou1wnexmb09.vcorp.ad.vrsn.com>
<49384BCF.2080600 at network-heretics.com>
X-Mailer: Apple Mail (2.929.2)
X-Mailman-Approved-At: Mon, 15 Dec 2008 10:43:52 -0800
Cc: tae at ietf.org, ietf at ietf.org
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org
So, after being distracted by OSDI last week, I'm now trying to catch
up on the raging debates on TAE that are already exceeding all the
wildest dreams I had before setting up the list... :)
On the issue of weaning applications (and potentially transports) away
from IP addresses in favor of names of some kind, I fend, I feel that a lot of
the disagreement results from a misunderstanding of exactly what I
(and perhaps others who have made similar proposals) was proposing...
On Dec 4, 2008, at 10:29 PM, Keith Moore wrote:
Hallam-Baker, Phillip wrote:
I am trying to parse this claim.
Are you saying that the DNS is fragile and raw IP relatively robust?
DNS is layered on top of IP. So for a large class of IP failures, DNS
won't work either. And if IP routing fails, DNS is likely to be
irrelevant because the application using DNS won't work anyway.
And in practice, DNS is quite likely to fail due to configuration
errors, inadequate provisioning, outdated cache entries due to
unanticipated changes, brain-damaged DNS caches built into NATs,
failure
of registries to transfer a DNS name in a timely fashion, etc.
So it's not a question of whether DNS is less reliable than IP (it
is),
or even whether the reliability of DNS + IP is less than that of IP
alone (it is). It's a question of whether increasing reliance on
DNS by
trying to get apps and other things to use DNS names exclusively,
makes
those apps and other things less reliable. And I'd argue that it
does,
except perhaps in a world where renumbering happened frequently, at
irregular intervals, and without notice. And I don't think that's a
realistic scenario.
I entirely agree in principle with your concerns about reliability: if
everything has to work correctly in two layers (DNS and IP), then
that's strictly less likely to happen than hoping everything will work
correctly in only one layer (just IP) - unless DNS can somehow make up
for unreliability in the IP layer, which it occasionally might be able
to do with some effort (e.g., via DNS-based load balancers that take
end-to-end IP reachability information as input), but it usually
doesn't because that's not the purpose of DNS. And I agree that some
applications (and some users) sometimes need to deal with IP addresses
directly, and probably still will need to for a long time, maybe
forever. You seem to be assuming that my proposal was to disallow
such "visibility into the network" entirely, but that wasn't my intent
at all. I just would like it to become no longer _mandatory_ for
every application to know about the structure IP addresses in order to
accomplish anything.
To be specific, there are (at least) three positions we might be in:
1. ALL applications MUST know about IP addresses, in each IP address
format that exists, in order to operate at all. This is the current
state of the world for applications that use the sockets API, because
apps have to call gethostbyname etc. and copy the resulting IP
address(es) into sockaddr_in or sockaddr_in6 structs to pass to
connect() et al. Even though the sockets API is "generic" in that it
supports multiple address families, its design forces the application
to have code specific to each family in order to support that family
at all, which is the key problem.
2. ALL applications MUST use only DNS names for all operations, and
never provide or see IP addresses for any reason. This seems to be
what you're assuming I'm suggesting (i.e., where you say "...by trying
to get apps and other things to use DNS names >>exclusively<<").
That's a world we might hold up as an ideal to strive for eventually,
but it's indeed not realistic in the short term, and it's not what I'm
pushing for. Besides, there may be many different naming or host
identity schemes we might eventually want to support besides DNS names
- e.g., UIA personal names, HIP cryptographic host identities, ...
3. Applications MAY be aware of IP addresses if they need to be for
whatever reason, but aren't ALWAYS forced to have hard-coded
dependencies on the existence and structure of IP addresses by the
API's design. Applications see IP addresses as variable-length string
blobs of some kind - e.g., along the lines Florian Weimer suggested in
another message. Applications can parseel that a lot of
the disagreement results from a misunderstanding of exactly what I
(and perhaps others who have made similar proposals) was proposing...
On Dec 4, 2008, at 10:29 PM, Keith Moore wrote:
Hallam-Baker, Phillip wrote:
I am trying to parse this claim.
Are you saying that the DNS is fragile and raw IP relatively robust?
DNS is layered on top of IP. So for a large class of IP failures, DNS
won't work either. And if IP routing fails, DNS is likely to be
irrelevant because the application using DNS won't work anyway.
And in practice, DNS is quite likely to fail due to configuration
errors, inadequate provisioning, outdated cache entries due to
unanticipated changes, brain-damaged DNS caches built into NATs,
failure
of registries to transfer a DNS name in a timely fashion, etc.
So it's not a question of whether DNS is less reliable than IP (it
is),
or even whether the reliability of DNS + IP is less than that of IP
alone (it is). It's a question of whether increasing reliance on
DNS by
trying to get apps and other things to use DNS names exclusively,
makes
those apps and other things less reliable. And I'd argue that it
does,
except perhaps in a world where renumbering happened frequently, at
irregular intervals, and without notice. And I don't think that's a
realistic scenario.
I entirely agree in principle with your concerns about reliability: if
everything has to work correctly in two layers (DNS and IP), then
that's strictly less likely to happen than hoping everything will work
correctly in only one layer (just IP) - unless DNS can somehow make up
for unreliability in the IP layer, which it occasionally might be able
to do with some effort (e.g., via DNS-based load balancers that take
end-to-end IP reachability information as input), but it usually
doesn't because that's not the purpose of DNS. And I agree that some
applications (and some users) sometimes need to deal with IP addresses
directly, and probably still will need to for a long time, maybe
forever. You seem to be assuming that my proposal was to disallow
such "visibility into the network" entirely, but that wasn't my intent
at all. I just would like it to become no longer _mandatory_ for
every application to know about the structure IP addresses in order to
accomplish anything.
To be specific, there are (at least) three positions we might be in:
1. ALL applications MUST know about IP addresses, in each IP address
format that exists, in order to operate at all. This is the current
state of the world for applications that use the sockets API, because
apps have to call gethostbyname etc. and copy the resulting IP
address(es) into sockaddr_in or sockaddr_in6 structs to pass to
connect() et al. Even though the sockets API is "generic" in that it
supports multiple address families, its design forces the application
to have code specific to each family in order to support that family
at all, which is the key problem.
2. ALL applications MUST use only DNS names for all operations, and
never provide or see IP addresses for any reason. This seems to be
what you're assuming I'm suggesting (i.e., where you say "...by trying
to get apps and other things to use DNS names >>exclusively<<").
That's a world we might hold up as an ideal to strive for eventually,
but it's indeed not realistic in the short term, and it's not what I'm
pushing for. Besides, there may be many different naming or host
identity schemes we might eventually want to support besides DNS names
- e.g., UIA personal names, HIP cryptographic host identities, ...
3. Applications MAY be aware of IP addresses if they need to be for
whatever reason, but aren't ALWAYS forced to have hard-coded
dependencies on the existence and structure of IP addresses by the
API's design. Applications see IP addresses as variable-length string
blobs of some kind - e.g., along the lines Florian Weimer suggested in
another message. Applications can parse/interpr/interpret or create these
blobs if they want/need to, but don't necessarily have to if they're
just passing the blob through from the GUI or URL parser to the OS's
protocol stack. This is the position I think we need to be pushing for.
In short, I don't think either the current fascist extreme of an "IP-
address-only API" or the opposite fascist extreme of a "DNS-name-only
protocol stack" is very appealing; we need an environment in which
different kinds of names/addresses/identities can coexist. You'll
still be able to enter an IPv4 or IPv6 address instead of a host name
when you need to, and applications will be able to tell when you do
when they want to, but hopefully not all applications will always need
to care what the difference is.
Cheers,
Bryan
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
et or create these
blobs if they want/need to, but don't necessarily have to if they're
just passing the blob through from the GUI or URL parser to the OS's
protocol stack. This is the position I think we need to be pushing for.
In short, I don't think either the current fascist extreme of an "IP-
address-only API" or the opposite fascist extreme of a "DNS-name-only
protocol stack" is very appealing; we need an environment in which
different kinds of names/addresses/identities can coexist. You'll
still be able to enter an IPv4 or IPv6 address instead of a host name
when you need to, and applications will be able to tell when you do
when they want to, but hopefully not all applications will always need
to care what the difference is.
Cheers,
Bryan
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
