Subject: Re: [tae] The internet architecture

From: Bryan Ford <[email-masked]>
Date: Wed, 3 Dec 2008 19:29:37 +0100

I know this follow-up is a bit late, but on the topic of transitioning  
upper-layer protocols such as transports and applications toward being  
"IP address oblivious" - either by using DNS names instead, or  
location-independent crytpographic identifiers as in HIP, or personal  
names as in UIA, or something else -  I just wanted to suggest that  
the new "Transport Architecture Evolution" ([email-masked])) mailing  
list that I set up just after the IETF meeting might be a good place  
to discuss such architectural issues, especially in terms of the way  
they affect application<->transport and transport<->network layer  
interfaces.

To throw in my quick $.02 (and perhaps invite more discussion :) ), I  
think we absolutely need to migrate both networking APIs and transport  
layer protocols themselves toward a model where an "endpoint" is an  
opaque (to the transport/application) variable-length string of some  
kind, and the transport/application shouldn't even care much if any  
what exactly the string is.  The string could potentially be a DNS  
name, a dotted IPv4 address, a colonificated IPv6 address, a hex- 
encoded HIP cryptographic host identifier, a UIA personal name, ...   
And sure, the semantics of these different kinds of "endpoint strings"  
will vary depending on what they actually are, and for network  
management purposes they won't all be equivalent or interchangeable,  
but for purposes of normal transport and application protocol  
operation - i.e., "gimme a TCP-like connection to the endpoint named  
'X'", why should transports and applications need to care?  Just think  
how much easier the IPv4 to IPv6 transition would have been if nothing  
above the IP layer cared exactly what an IP address looks like or how  
big it is.

Cheers,
Bryan

_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Dec 2008 13:23:44 -0500

Bryan Ford wrote:

> kind, and the transport/application shouldn't even care much if any what
> exactly the string is.  The string could potentially be a DNS name, a
> dotted IPv4 address, a colonificated IPv6 address, a hex-encoded HIP
> cryptographic host identifier, a UIA personal name, ...  And sure, the
> semantics of these different kinds of "endpoint strings" will vary
> depending on what they actually are, and for network management purposes
> they won't all be equivalent or interchangeable, but for purposes of
> normal transport and application protocol operation - i.e., "gimme a
> TCP-like connection to the endpoint named 'X'", why should transports
> and applications need to care?  

Sigh.  Maybe this is unfair, but it seems to me that people keep wanting
to take (relatively) straightforward, bulletproof interfaces and replace
them with fragile ones that depend on extra layers of indirection, and
additional services that (a) can fail, (b) don't share fate with the
endpoints and (c) are likely to be very sensitive to configuration
errors, all for the sake of some notion of architectural purity.

I won't claim that you can't do it, or that it's a fundamentally bad
idea on its face.  I *will* claim that it's a fundamentally bad idea if
you don't do very careful engineering on it to make sure that the
resulting system is as reliable was it would be without the extra layer
of indirection - and that includes accounting for the ability of people
to misconfigure things.

> Just think how much easier the IPv4 to IPv6 transition would have been if nothing above the IP layer cared
> exactly what an IP address looks like or how big it is.

It wouldn't have made much difference at all, partly because due to
other warts in the IPv6 architecture (like the desire to push the cost
of multihoming to all endpoints rather than the core [*]), applications
have even more need to deal directly with addresses in IPv6 than they do
in IPv4 - even in a pure IPv6 world.

The other reason it wouldn't have made much difference is because
transitioning applications to IPv6 is actually much easier than
transitioning networks.

Keith

[*] Not that I blame the routing guys for wanting to move the cost of
multihoming out of the core.  But pushing those costs onto hosts and
applications was moving those costs even further away from those who
benefit from multihoming, than was the case in IPv4.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Dec 2008 11:58:13 -0800

I am trying to parse this claim.

Are you saying that the DNS is fragile and raw IP relatively robust? 

If so I can show you mountains of evidence to show that you are completely wrong.

-----Original Message-----
From: [email-masked] on behalf of Keith Moore
Sent: Thu 12/4/2008 1:23 PM
To: Bryan Ford
Cc: [email-masked]; [email-masked]
Subject: Re: The internet architecture

Keith

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Dec 2008 16:29:51 -0500

> 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.

Keith

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Dec 2008 13:37:46 -0800

You are wrong.
 
Take SMTP email. Imagine that a company has three mail servers at geographically dispersed locations with independent network connections. With MX records a local failure of IP connectivity does not need to mean total failure of IP connectivity.
 
In fact provided that core DNS is there, and BGP is not borked it is possible to contingency plan for pretty much any outage that does not result in a virtually complete loss of connectivity at the client end.

A chain is only as strong as its weakest link. The Internet is not a chain, it is a mesh. A mesh is stronger than the weakest link.

________________________________

From: Keith Moore [mailto:[email-masked]]
Sent: Thu 12/4/2008 4:29 PM
To: Hallam-Baker, Phillip
Cc: Bryan Ford; [email-masked]; [email-masked]
Subject: Re: The internet architecture

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Dec 2008 16:51:20 -0500

> You are wrong.

I often get the impression that the laws of physics do not apply on the
planet where you live...

> Take SMTP email. Imagine that a company has three mail servers at
> geographically dispersed locations with independent network connections.
> With MX records a local failure of IP connectivity does not need to mean
> total failure of IP connectivity.

You want to extrapolate to the whole Internet and all of its
applications from a single, somewhat hypothetical, data point - one that
you haven't even completely analyzed?

> In fact provided that core DNS is there, and BGP is not borked it is
> possible to contingency plan for pretty much any outage that does not
> result in a virtually complete loss of connectivity at the client end.

There's a big difference between what is possible and what is usually
true in practice.

There's also a big difference between the perspective of someone who
operates networks (and who can presumably fix the network if it's
broken), and application writers and users (who are forced to deal with
whatever brain-damage the network - including DNS in their view -
presents to them).

Not a week goes by when I'm not asked to figure out "why people can't
get to a web server" or "why email isn't working".  In about 70% of the
web server cases and 30% of the email cases, the answer turns out to be
DNS related.  IP failures, by contrast, are quite rare.  And the ones
that I see mostly consist of failures of the user's local wireless
access point.

Keith

---

From: John Leslie <[email-masked]>
Date: Thu, 4 Dec 2008 18:03:25 -0500

Keith Moore <[email-masked]> wrote:
> Bryan Ford wrote:
> 
>> I think we absolutely need to migrate both networking APIs and
>> transport layer protocols themselves toward a model where an
>> "endpoint" is an opaque (to the transport/application) variable-
>> length string of some kind, and the transport/application
>> shouldn't even care much if any what exactly the string is.

   Pure layering would call for that...

>> ... for purposes of normal transport and application protocol
>> operation - i.e., "gimme a TCP-like connection to the endpoint
>> named 'X'", why should transports and applications need to care?  

   Let us not forget the other side of that: the application which
you connect to needs to identify your end somehow...

> Sigh.  Maybe this is unfair, but it seems to me that people keep
> wanting to take (relatively) straightforward, bulletproof
> interfaces and replace them with fragile ones that depend on
> extra layers of indirection,

   I don't think Bryan said that...

> and additional services that (a) can fail,

   Everything "can fail". That doesn't mean we can't engineer a
layering which makes failure _less_ likely.

> (b) don't share fate with the endpoints

   It's not clear that application layer _should_ always share fate
with lower layers. In particular, the application-layer connection
of a server invoked by a mobile user _shouldn't_ fail when the user
wanders out of range of a particular cell tower.

> and (c) are likely to be very sensitive to configuration errors,
> all for the sake of some notion of architectural purity.

   Architectural "purity" is often helpful to analyze a situation
to decide which wish-list items are "easy".

> I won't claim that you can't do it, or that it's a fundamentally
> bad idea on its face. I *will* claim that it's a fundamentally
> bad idea if you don't do very careful engineering on it to make
> sure that the resulting system is as reliable as it would be
> without the extra layer of indirection

   It may be premature to ask for any particular way of increasing
application-layer reliability. (Several come to mind, though.)

> - and that includes accounting for the ability of people to
> misconfigure things.

   We all know it's a waste of time to aim for 100% foolproof --
the fools are too ingenious. ;^)

>> Just think how much easier the IPv4 to IPv6 transition would
>> have been if nothing above the IP layer cared exactly what an
>> IP address looks like or how big it is.
> 
> It wouldn't have made much difference at all, partly because due
> to other warts in the IPv6 architecture (like the desire to push
> the cost of multihoming to all endpoints...

   I will agree with you that it would have been better to avoid
loading IPv6 with such criteria, but complaining doesn't help.
With a transport structure as Bryan envisions it, folks needing
multihoming could continue operating in IPv6 while seamlessly
connecting to IPv6 servers.

--
John Leslie <[email-masked]>
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Dec 2008 15:49:55 -0800

> wanders out of range of a particular cell tower.

Sharing fate with lower layers isn't the issue, since the contrary has
been an assumption for many years (dynamic routing, robust
retransmission, E2E security all compensate for lower layer issues).

Sharing fate with the *endpoints* is the issue; designing around that
means you haven't selected your endpoint properly. I.e., if you want
robust file xfer that survives the failure of an individual server, you
want to describe a service to a *system*, not to the individual server.

Multihoming is a mechanism that can help support this, but the point is
to define the service system endpoint properly (i.e., as a service tag,
not a host address). Done correctly, that doesn't necessarily imply
upending what's already been done at the packet endpoint layer.

Joe

---

From: Keith Moore <[email-masked]>
Date: Thu, 04 Dec 2008 20:50:34 -0500

> layering which makes failure _less_ likely.

No, it doesn't.  But that kind of engineering goes beyond mere protocol
design, and into things like configuration management where we have less
expertise, and less ability to specify what happens.

> wanders out of range of a particular cell tower.

The point about fate sharing is relative to the potential for these
mapping layers to fail.  If a mapping layer used by two endpoints can
fail independently of either of those endpoints, the overall reliability
is less than if the mapping layer shares fate with one of its
endpoints... assuming that the reliability of the individual components
is the same for both cases.

> to decide which wish-list items are "easy".

Really?  I more often find it being used to pretend that things are easy
when they are not.

I do think that notions of "purity" or "simplicity" or "elegance" can be
valuable.  If a design choice doesn't seem "pure" according to the
architectural model, it warrants further examination to see if it really
is a good idea.  But notions like "purity" are best regarded as
rules-of-thumb, which can be trumped by actual analysis or experience.

> application-layer reliability. (Several come to mind, though.)

I was just talking about the mapping layer here.

> the fools are too ingenious. ;^)

Of course.  But if we design a system to replace the current one that
requires a higher level of clue to configure than the current one, we
should look around and see if the clue level is sufficient.

Or to put it more concrete terms: if DNS is the state-of-the-art for
mapping layers that are deployed on a large scale, and ordinary network
operators can't provision it and configure it so that it's reliable -
maybe we shouldn't be trying to put more trust into mapping layers just
yet.

--

Before we go too far down this path, I should say that at some level I
do sympathize with Bryan Ford's desire to "migrate both networking APIs
and transport layer protocols themselves toward a model where an
'endpoint' is [...] opaque (to the transport/application) [...] and the
transport/application shouldn't even care much if any what exactly the
string is."

The big caveat is that if you really want to make endpoint IDs opaque to
applications, and hide all of the details about locations and network
topology and so forth from applications, you have to do several things:

1. As already mentioned, you have to make whatever service maps between
endpoint IDs and addresses extremely reliable so that you don't degrade
overall system reliability.

2. The lower layers have to "do the right thing" independent of
those endpoint IDs and where they're actually located.  If the details
of locations etc. are hidden from applications, then applications can't
ever be expected to make up for the things like the network's inability
to do things like handle site multihoming.

3. If you are really serious about hiding all of these details from
applications, you need to explain how you're going to build network
management and diagnostic tools.  You also need a lot better system for
detecting and reporting errors caused by network failures so that both
the users and whoever can fix the problem can know what is going on.

But as an application writer, what Bryan is suggesting is pretty much
what I want.  I want to be able to open up a connection to an endpoint
ID and have it stay up even if links go up or down, networks have to
renumber, hosts move, and so on.  Once I have an endpoint ID that binds
to a specific instance of a service, I want to be able to hand that
endpoint ID off to peers on other hosts and have it be usable by those
peers without having to worry about those hosts' locations on the
network or what kinds of addressing they use.  As an application writer,
I don't want to have to know about network topology or addressing realms
or NATs or ULAs or v4/v6 issues.  I don't want to be expected to recover
from failures that result from the network's inability to do
multihoming.  etc.  I want to be able to ask the network to do something
and have the network make its best effort to do that - and by "best
effort" I mean that it shouldn't be possible for the application to do
better even if it does know about the network addressing and topology etc.

But the things that arose in my mind when reading Bryan's statement were
pretty much these:

1. Granted it would be nice for an application to be able to work that
way, but would that much enforced opacity really be a good thing?
Especially in light of the current network architecture's apparent
inability to provide anything close to that kind of programming model?
Again as an applications programmer, I like being able to use a simple
model, but I also find it useful to be able to get under the hood if I
need to do that.

2. It seems to me that the real problems with doing this are not with
defining the API or even the transport layers - and the most significant
benefits are not resulting from the API either.   The hard parts are
building the mapping layer so that it's fast and reliable and secure,
and designing secure signaling between the network, hosts, and mapping
layer, so that the binding IDs continue to work in all cases (and there
are lots of cases to analyze).  The benefits don't seem so much in ease
of programming (though that would be nice) but in having _everything_ be
able to be truly mobile and still be reliable.

When there's so much emphasis on the easy part of the problem, it makes
me wonder whether the true nature of the problem is understood.   It
strikes me as a bit like someone in 1960 saying "if only we could mine
moon rocks, we'd have all of the iron we could possibly need" and then
proceeding to design mechanisms for mining moon rocks without first
figuring out how to get there and back.

Keith

---

From: Thomas Narten <[email-masked]>
Date: Fri, 05 Dec 2008 09:25:20 -0500

Keith Moore <[email-masked]> writes:

> > Just think how much easier the IPv4 to IPv6 transition would have
> > been if nothing above the IP layer cared exactly what an IP
> > address looks like or how big it is.

> It wouldn't have made much difference at all,

Wow. I find this statement simply astonishing.

IMO, one of the biggest challenges surrounding IPv6
adoption/deployment is that all applications are potentially impacted,
and each and everyone one of them needs to be explicitely enabled to
work with IPv6. That is a huge challenge, starting with the
observation that there are a bazillion deployed applications that will
NEVER be upgraded.

Boy, wouldn't it be nice of all we had to do was IPv6-enable the
underlying network and stack (along with key OS support routines and
middleware) and have existing apps work over IPv6, oblivious to IPv4
vs. IPv6 underneath.

And, if one wants to look back and see "could we have done it
differently", go back to the BSD folk that came up with the socket
API. It was designed to support multiple network stacks precisely
because at that point in time, there were many, and TCP/IP was
certainly not pre-ordained. But that API makes addresses visible to
APIs. And it is widely used today.

Wouldn't it have been nice if the de facto APIs in use today were more
along the lines of ConnectTo(DNS name, service/port).

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 05 Dec 2008 09:35:15 -0500

Keith Moore <[email-masked]> writes:

> those apps and other things less reliable.

No. Your argument seems to be "because relying even more on DNS than
we do today makes things more brittle, BAD, BAD BAD, we cannot go
there."

The more relevant engineering question is whether the benefits of such
an approach outweigh the downsides. Sure there are downsides. But
there are also real potential benefits. Some of them potentially game
changers in terms of addressing real deficiencies in what we have
today. It may well be that having applications be more brittle would
be an acceptable cost for getting a viable multihoming approach that
address the route scalability problem. (All depends on what "more
brittle" really means.) But the only way to answer such questions in a
productive manner is to look pretty closely at a complete
architecture/solution together with experience from real
implementation/usage.

Thomas

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 5 Dec 2008 09:40:09 -0500

> along the lines of ConnectTo(DNS name, service/port).

This certainly seems to be the way that "modern" APIs are heading. If  
I'm not mistaken, Java, PHP, Perl, Tcl, Python and most other  
scripting languages have a socket-like API that does not expose IP  
addresses, but rather connects directly to DNS names. (In many cases,  
they unify file and socket opening and specify the application  
protocol, to, so that one can do fopen("http://www.ietf.org"), for  
example.) Thus, we're well on our way towards the goal of making  
(some) application oblivious to addresses. I suspect that one reason  
for the popularity of these languages is exactly that programmers  
don't want to bother remembering when to use ntohs().

Henning

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Dec 2008 06:59:23 -0800

> APIs. And it is widely used today.

Thomas,

If you are citing BSD merely as an example of a component that imposes knowledge 
of addresses on upper layers, then yes, it does make a good, concrete example.

If you are citing BSD because you think that they made a bad design decision, 
then you are faulting them for something that was common in the networking 
culture at the time.

People  -- as in end users, as in when they were typing into an application -- 
commonly used addresses in those days, and hostnames were merely a preferred 
convenience.  (Just to remind us all, this was before the DNS and the hostname 
table was often out of date.)

Worse, we shouldn't even forgive them/us by saying something like "we didn't 
understand the need for name/address split, back then" because it's pretty clear 
from the last 15 years of discussion and work that, as a community, we *still* 
don't.  (The Irvine ring was name-based -- 1/4 of the real estate on its network 
card was devoted to the name table -- but was a small LAN, so scaling issues 
didn't apply.)

d/

ps. As to your major point, that having apps de-coupled from addresses would 
make a huge difference, boy oh boy, we are certainly in agreement there...
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: Melinda Shore <[email-masked]>
Date: Fri, 05 Dec 2008 10:05:45 -0500

> then you are faulting them for something that was common in the networking

Not to go too far afield, but I think there's consensus
among us old Unix folk that the mistake that CSRG made
wasn't in the use of addresses but in having "sockets"
instead of using file descriptors.  This was actually
fixed in SysVRSomethingOrOther with the introduction of
a network pseudo-filesystem (open("/net/192.168.1.1", ... )
with ioctls but never got traction.

Melinda

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Dec 2008 07:18:03 -0800

> with ioctls but never got traction.

It's possible that this represents insight worth sharing broadly, so I'm copying 
the list.

It isn't immediately obvious to me why file descriptors would have had a major 
impact, so can you elaborate?

Thanks.

d/
-- 

   Dave Crocker

---

From: John Day <[email-masked]>
Date: Fri, 5 Dec 2008 10:23:00 -0500

>along the lines of ConnectTo(DNS name, service/port).

That had been the original plan and there were APIs that did that. 
But for some reason, the lunacy of the protocol specific sockets 
interface was preferred.  I know people who have been complaining 
about it for 25 years or thereabouts.

Some knew even then that the purpose of an API was to hide those 
sorts of dependencies.  There seems to be a history here of always 
picking the bad design.
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: Melinda Shore <[email-masked]>
Date: Fri, 05 Dec 2008 10:26:35 -0500

On 12/5/08 10:18 AM, "Dave Crocker" <[email-masked]> wrote:
> It's possible that this represents insight worth sharing broadly,

I doubt that very much, since it's really about API
design and ideological purity and I think has had only
a negligible impact on deployability, but
 
> impact, so can you elaborate?

I don't think they have.  "Unix" (whatever that means
for the purpose of discussion) was designed around a few
abstractions, like pipes, filedescriptors, and processes,
and by the time IP was implemented we'd pretty much settled
on filedescriptors as endpoints for communications.  We
could do things with them like i/o redirection, etc., and
sockets are something else entirely.  That is to say,
in Unix we shouldn't care whether an input or output
stream is a terminal, a file, or a network data stream,
but because of sockets we do have to care.

Melinda

---

From: John Day <[email-masked]>
Date: Fri, 5 Dec 2008 10:25:34 -0500

It is so reassuring when "modern" is a third of a  century old.

Sorry, but I am finding this new found wisdom just a little frustrating.

At 9:40 -0500 2008/12/05, Henning Schulzrinne wrote:
>This certainly seems to be the way that "modern" APIs are heading. 
>If I'm not mistaken, Java, PHP, Perl, Tcl, Python and most other 
>addresses, but rather connects directly to DNS names. (In many 
>cases, they unify file and socket opening and specify the 
>application protocol, to, so that one can do 
>fopen("http://www.ietf.org"), for example.) Thus, we're well on our 
>way towards the goal of making (some) application oblivious to 
>addresses. I suspect that one reason for the popularity of these 
>languages is exactly that programmers don't want to bother 
>remembering when to use ntohs().
>
>Henning

---

From: John Day <[email-masked]>
Date: Fri, 5 Dec 2008 10:29:49 -0500

Speak for yourself David.  These problems have been well understood 
and discussed since 1972.  But you are correct, that there were still 
a large unwashed that didn't and I am still not sure why that was. 
This seems to be elementary system architecture.

At 6:59 -0800 2008/12/05, Dave CROCKER wrote:
>If you are citing BSD merely as an example of a component that 
>imposes knowledge of addresses on upper layers, then yes, it does 
>make a good, concrete example.
>
>If you are citing BSD because you think that they made a bad design 
>decision, then you are faulting them for something that was common 
>in the networking culture at the time.
>
>People  -- as in end users, as in when they were typing into an 
>application -- commonly used addresses in those days, and hostnames 
>were merely a preferred convenience.  (Just to remind us all, this 
>was before the DNS and the hostname table was often out of date.)
>
>Worse, we shouldn't even forgive them/us by saying something like 
>"we didn't understand the need for name/address split, back then" 
>because it's pretty clear from the last 15 years of discussion and 
>work that, as a community, we *still* don't.  (The Irvine ring was 
>name-based -- 1/4 of the real estate on its network card was devoted 
>to the name table -- but was a small LAN, so scaling issues didn't 
>apply.)
>
>d/
>
>ps. As to your major point, that having apps de-coupled from 
>addresses would make a huge difference, boy oh boy, we are certainly 
>in agreement there...
>--
>
>   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 11:03:26 -0500

> observation that there are a bazillion deployed applications that will

There were also a bazillion deployed applications that would never be
upgraded to deal with Y2K.  Somehow people managed.  But part of how
they managed was by replacing some applications rather than upgrading them.

I certainly won't argue that it's not a significant challenge to edit
each application, recompile it, retest it, update its documentation,
educate tech support, and release a new version.   But you'd have all of
those issues with moving to IPv6 even if we had already had a socket API
in place where the address was a variable-length, mostly opaque, object.

Consider also that the real barrier to adapting many applications to
IPv6 (and having them work well) isn't the size of the IPv6 address, or
adapting the program to use sockaddr_in6 and getaddrinfo() rather than
sockaddr_in and gethostbyname().  It's figuring out what it takes to get
the application to work sanely in a world consisting of a mixture of
IPv4 and IPv6, IPv4 private addresses and global addresses and maybe
linklocal addresses (useful on ad hoc networks), IPv6 ULAs and global
addresses and maybe linklocal addresses, the fact that 6to4 traffic is
sometimes blocked (so v6 connections time out), and that 6to4 relay
routers often cause IPv6 connections to work more poorly than native
IPv4 connections, NATs, and so forth.

(size *is* an issue for applications that do referrals, and those are
important cases, but the vast majority of apps don't do that.)

And at least from where I sit, almost all of the applications I use
already support IPv6.  (I realize that's not true for everybody, but it
also tells me that it's feasible.)   From where I sit, the support
that's missing is in the ISPs, and the SOHO routers, and in various
things that block 6to4.  I understand from talking to others that
support is also lagging in firewalls and traffic monitors needed by
enterprise networks.

> middleware) and have existing apps work over IPv6, oblivious to IPv4

Sure it would have been nice.  But for that to have happened would have
required a lot more than having the API treat addresses as opaque
objects of arbitrary size.  It would have required that IPv4 support
variable length addresses in all hosts and routers so that there would
have been no need for applications to try to deal with a mixture of IPv4
and IPv6 hosts that can't talk directly to one another.   It would have
required an absence of NATs so that apps wouldn't need to know how to
route around them.  It would have required that apps be able to be
unaware of the IPv6 address architecture, and for them to not need to do
intelligent address selection, which basically would have required
solving the routing scalability problem.

Basically if we had had all of that stuff in place in the early 1990s,
we would never have needed to do a forklift upgrade of IPv4 - the net
would have evolved approximately as gracefully as it did with CIDR.

> along the lines of ConnectTo(DNS name, service/port).

No, because one of two things would have happened:

1. the defacto APIs would have long since been abandoned in favor of
sockets APIs that were more flexible at letting apps deal with various
kinds of network brain damage, or

2. if the defacto APIs were the only ones available on most platforms,
then we wouldn't have any of the applications that we have today, that
manage to get around NAT.  we'd be stuck with email and
everything-else-over-HTTP, with all servers constrained to be in the
core, and prime IP real estate being even more expensive than it is now.

--

Having said that, I'll grant that every barrier to IPv6 adoption is
significant.  The reason is that moving to IPv6 isn't just a matter of
flipping switches at any level.  It's one thing for an app to be able to
deal with IPv6 on a small scale when talking to a single peer from a
controlled environment, quite another for the app to be able to deal
with IPv6 on a large scale when running in a customer's environment and
talking with many peers that are in a variety of network environments.
So it's not just a matter of editing and recompiling the app, or
enabling IPv6 in a few routers, or arranging for your ISP to assign you
an IPv6 prefix and start routing it to you.   It's a matter of having
several iterations of each of those where you (whatever your role is)
discover significant bugs on each of the first several iterations.

Keith

p.s. If we're going to engage in "what if" discussions (e.g. "what if we
had had a better defacto API in IPv4") we could of course ask "what if"
IPng had been designed as an extension to IPv4 (e.g. IPAE) and we had
worked harder to make that approach work well.  And I suspect that with
enough cleverness we could have done so, and in the process eliminated a
few barriers to adoption - or at least, decoupled a few more things from
one another so that upgrades would not have to be in sync to be of
benefit.  But we had good reasons for (most of) the decisions that were
made in IPv6, just as there were good reasons for the BSD sockets API.
I'm not sure what purpose there is in second-guessing them now.

Nor do I really see the purpose in trying to clean up the API now, at a
time when applications often do need to be aware of address formats and
such.  Maybe once everything uses IPv6 and all of the problems are
solved and we figure out how to make DNS robust it will be possible for
most apps to use a simpler API.  But by then, we won't have any need to
change the apps that are using the old one.

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 11:16:20 -0500

> we do today makes things more brittle, BAD, BAD BAD, we cannot go

My argument is that if you really want that sort of approach to work you
need to concentrate on making DNS more reliable and better suited to
this kind of approach, and on getting people to think of DNS differently
than they do now - rather than just talking in terms of changing the
API, which is the easy part.

> there are also real potential benefits. 

Mumble.  Years ago, I worked out details of how to build a very scalable
distributed system (called SNIPE) using a DNS-like service (but a lot
more flexible in several ways) to name endpoints and associate the names
with metadata about those endpoints, including their locations.  So I
don't need to be convinced that there are potential benefits.  But that
exercise also gave me an appreciation for the difficulties involved.
And for that exercise I allowed myself the luxury of defining my own
naming service rather than constraining myself to use DNS.  It would
have been much more difficult, though perhaps not impossible, to make
that kind of system work with DNS.

> But the only way to answer such questions in a

You certainly need a more complete architecture before you can evaluate
it at all.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 11:29:23 -0500

John Day wrote:
> That had been the original plan and there were APIs that did that. But
> for some reason, the lunacy of the protocol specific sockets interface
> was preferred.  

About the time I wrote my second network app (circa 1986) I abstracted
all of the connection establishment stuff (socket, gethostbyname, bind,
connect) into a callable function so that I wouldn't have to muck with
sockaddrs any more.  And I started trying to use that function in
subsequent apps.  What I generally found was that I had to change that
function for every new app, because there were so many cases for which
merely connecting to port XX at the first IP address corresponding to
hostname YY that accepted a connection, was not sufficient for the
applications I was writing.  Now it's possible that I was writing
somewhat unusual applications  (e.g. things that constrained the source
port to be < 1024 and which therefore required the app to run as root
initially and then give up its privileges, or SMTP clients for which MX
processing was necessary) but that's nevertheless what I experienced.

These days the situation is similar but I'm having to deal with a
mixture of v4 and v6 peers, or NAT traversal, or brain-damage in
getaddrinfo() implementations, or bugs in the default address selection
algorithm.

With so much lunacy in the how the net works these days, I regard a
flexible API as absolutely necessary for the survival of applications.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 11:38:27 -0500

Henning Schulzrinne wrote:
> I'm not mistaken, Java, PHP, Perl, Tcl, Python and most other scripting
> languages have a socket-like API that does not expose IP addresses, but
> rather connects directly to DNS names. 

and yet, people wonder why so many network applications are still
written in C, despite all of the security issues associated with weak
typing, explicit memory management, and lack of bounds checking on array
references.

(people also need to realize that using a "modern" API makes it _harder_
to get an application to work well in a mixed IPv4/IPv6 environment.)

> Thus, we're well on
> our way towards the goal of making (some) application oblivious to
> addresses. 

and we're also well on our way towards the goal of having everything run
over HTTP.

> I suspect that one reason for the popularity of these languages is
> exactly that programmers don't want to bother remembering when to
> use ntohs().

probably so.  I can't exactly blame them for that.

Keith

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 05 Dec 2008 08:46:48 -0800

John Day wrote:
> Speak for yourself David.  These problems have been well understood and 
> discussed since 1972.  But you are correct, that there were still a 
> large unwashed that didn't and I am still not sure why that was. This 
> seems to be elementary system architecture.

John,

After your or I or whoever indulges in our flash of brilliant insight, it is the 
unwashed who do all the work.

So I was careful to refer to "the community" rather than claim that no one at 
all understand the issue.

I measure the community in terms of that pesky "rough consensus" construct and 
particularly in terms of running code.  Even in terms of the much more relaxed 
measure, namely mindshare, the community reflects no clear consensus on the 
matter of name-vs-address split, beyond now believing that we should do more of 
it.

We are only beginning to see broader use of the distinction between transient, 
within-session naming, for merging data coming in from alternate paths, versus 
global, persistent naming, for initial rendez vous.

d/

-- 

   Dave Crocker

---

From: John Day <[email-masked]>
Date: Fri, 5 Dec 2008 11:57:58 -0500

In other words the failure of a university education.

At 8:46 -0800 2008/12/05, Dave CROCKER wrote:
>>and discussed since 1972.  But you are correct, that there were 
>>still a large unwashed that didn't and I am still not sure why that 
>>was. This seems to be elementary system architecture.
>
>
>John,
>
>After your or I or whoever indulges in our flash of brilliant 
>insight, it is the unwashed who do all the work.
>
>So I was careful to refer to "the community" rather than claim that 
>no one at all understand the issue.
>
>I measure the community in terms of that pesky "rough consensus" 
>construct and particularly in terms of running code.  Even in terms 
>of the much more relaxed measure, namely mindshare, the community 
>reflects no clear consensus on the matter of name-vs-address split, 
>beyond now believing that we should do more of it.
>
>We are only beginning to see broader use of the distinction between 
>transient, within-session naming, for merging data coming in from 
>alternate paths, versus global, persistent naming, for initial 
>rendez vous.
>
>d/
>
>--
>
>   Dave Crocker

---

From: John Day <[email-masked]>
Date: Fri, 5 Dec 2008 12:01:21 -0500

As we all know, all attempts to turn a sow's ear into a silk purse, 
generally meet with failure.

You can only cover up so much.  I have written (or tried to write) 
too many device emulators and every time it is the same lesson.  ;-)

We use to have this tag line, when you found that pesky bug and of 
course it was staring you right in the face all the time, someone 
would say, "Well, you know . . . if you don't do it right, it won't 
work."  ;-)

We seem to have that problem in spades.  ;-)

---

From: Thomas Narten <[email-masked]>
Date: Fri, 05 Dec 2008 13:34:00 -0500

> they managed was by replacing some applications rather than

There were clear business motivations for ensuring that apps survived
Y2K appropriately. There is no similar brick wall with IPv4 address
exhaustion.

> in place where the address was a variable-length, mostly opaque,

I didn't say a better API would have "variable-length, mostly opaque
objects". I think others have already chimed in that hiding the
details from the applications is the key to a better API. 

And I understand that Apple has a "more modern" API, and it made
upgrading their applications to support IPv6 that much easier.

> sockaddr_in and gethostbyname().

Actually, the real barrier to upgrading applications is lack of
incentive. No ROI.  It's not about technology at all. It's about
business cases.

Wouldn't it be nice if existing apps could run over IPv6 (perhaps in a
degraded form) with no changes? That would change the challenges of
IPv6 deployment rather significantly.

> also tells me that it's feasible.)

Huge numbers of important applications in use today do not support
IPv6. Think beyond email, ssh and a browser. Think business
applications. Talk to someone who works for a software company about
the challenges they have upgrading their software to support IPv6 (or
fixing bugs, or doing any work to "old" software). It's less about
technology than business cases.

Case in point. There is apparently still significant amounts of
deployed software that cannot handle TLDs of more than 3 characters in
length. That means DNS names with a TLD of .info or .name don't work
in all places and can't be used reliably. I heard just this week that
yahoo can't handle email with .info names. .info has existed as a TLD
for 7 years. Fixing this is not a "technical" problem, it's a business
problem (i.e., incenting the parties that need to upgrade their
software).

Thomas

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 15:38:49 -0500

> Y2K appropriately. There is no similar brick wall with IPv4 address

more like a padded wall with embedded spikes?

> incentive. No ROI.  It's not about technology at all. It's about

I suppose it follows that people don't actually need those applications
to work in order to continue doing business... in which case, of course
they shouldn't upgrade them.

Either that, or the people who are making these decisions don't really
understand what's important to keeping their businesses running... and
those businesses will fail.

(not that this helps IPv6 any, of course)

Keith

---

From: Thomas Narten <[email-masked]>
Date: Fri, 05 Dec 2008 16:03:12 -0500

> more like a padded wall with embedded spikes?

More like a swamp, with steam rising from dark looking places. But
still a fair amount of firm ground if you can stay on a narrow and
careful path, though it's hard to tell because one can't see very far
and the swamp looks very big...

But looking back, we are already pretty far in the swamp, so it's not
clear exactly what is changing or how much worse things can or will
get continuing the current trajectory, so why not continue on the
current course just a little bit longer...

> they shouldn't upgrade them.

Keith, this is umbelievably simplisitic logic. Try the following
reality check. The applications run today. Important things would
break if they were turned off. But there is no money to pay for an
upgrade (by the customer) because the budget is only so big, and the
current budget was more focussed on beefing up security and trying to
get VoIP running. Or, the vendor doesn't have an upgrade because the
product is EOL, and the customer can't afford to buy a replacement for
it (again for a number of different reasons). Or, the vendor does have
an upgraded product, but it requires running the latest version of the
product, which doesn't run on the OS release you happen to be running
(and can't change for various reasons), and would require new hardware
on top of things because the new product/OS is a memory pig, or was
rewritten in Java, etc., etc.

> those businesses will fail.

They may understand very well. But a simple cost/benefit analysis (in
terms of $$ and/or available technical resources) says they can't
afford to upgrade.

Happens all the time. Why do you think people run old software for
years and years and years?

Thomas

---

From: Keith Moore <[email-masked]>
Date: Fri, 05 Dec 2008 16:29:33 -0500

Thomas Narten wrote:

> Keith, this is umbelievably simplisitic logic. 

This whole discussion is unbelievably simplistic logic.  Insults don't
make the logic any better.

> The applications run today. Important things would

Yep.  I've seen it happen many times in various guises.  By now it is
widely understood that many things need maintenance budgets - e.g.
buildings, vehicles, computer and networking hardware.  And we actually
have a decent sense of how much to budget for those things.  But we
don't have a widely-understood idea of what it costs to maintain
software, particularly networking software.  There's both a strong
tendency to believe that software is fixed-cost and an increasing
tendency to fire in-house programmers and push things like software
maintenance to third parties - which is to say, they don't get paid for.
 But when the Internet keeps changing (for many more reasons than IPv4
address space exhaustion) you can't expect the software to stay static
and keep working well.

> years and years and years?

Most likely, because they aren't properly estimating cost and/or
benefit, or because they are too focused on short-term costs and
ignoring medium- and long-term costs.

Keith

---

From: Tony Finch <[email-masked]>
Date: Fri, 5 Dec 2008 17:25:17 +0000

On Fri, 5 Dec 2008, Dave CROCKER wrote:
> Melinda Shore wrote:
> >
> > Not to go too far afield, but I think there's consensus among us old
> > Unix folk that the mistake that CSRG made wasn't in the use of
> > addresses but in having "sockets" instead of using file descriptors.
> > This was actually fixed in SysVRSomethingOrOther with the introduction
> > of a network pseudo-filesystem (open("/net/192.168.1.1", ... ) with
> > ioctls but never got traction.
>
> It isn't immediately obvious to me why file descriptors would have had a
> major impact, so can you elaborate?

This isn't a question of sockets versus file descriptors, since sockets
*are* file descriptors. It is actually a question of how to specify
network addresses in the API, i.e. the BSD sockaddr structure versus the
Plan 9 extended pathname semantics. Using pathnames for everything would
eliminate warts like embedding pathnames in sockaddrs in order to address
a local IPC endpoint. On the other hand, filesystem pathnames are a
uniform hierarchial namespace, which isn't true for the combination of
network protocol, address, and port - what happens if you opendir("/net/")?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FITZROY: WESTERLY 6 TO GALE 8 DECREASING 4 OR 5 FOR A TIME THEN BECOMING
CYCLONIC LATER. VERY ROUGH OR HIGH. SQUALLY SHOWERS. MODERATE OR GOOD.
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 5 Dec 2008 10:05:56 -0800

On Fri, Dec 05, 2008 at 08:46:48AM -0800, Dave CROCKER wrote:
> John Day wrote:
>> discussed since 1972.  But you are correct, that there were still a large 
>> unwashed that didn't and I am still not sure why that was. This seems to 
>
> After your or I or whoever indulges in our flash of brilliant insight, it 
> is the unwashed who do all the work.

I'm assuming you are using the term 'unwashed' to refer to the simple
act of bathing, rather than as in my background I understand it as a
metaphor for Christian baptism.

Surely neither Mr. Crocker nor Mr. Day are referring to IETF baptismal
practices?

Could either of you two elaborate on why you think that bathing (or
the evident lack thereof) is at all relevant to Internet standards?

I'm aware that in the ~400AD's there was actually quite a lot of
(religio) philosophical debate over the practice of bathing (which I
rather would think we'd put behind us after 1600 years), but I've
never heard it said that good engineers do (or don't) bathe.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 5 Dec 2008 13:44:27 -0800

Yes, that is indeed where the world is going.
 
My point is that it would be nice if the IETF had a means of guiding the outcome here through an appropriate statement from the IAB.
 
Legacy applications are legacy. But we can and should push new applications to use SRV based connections or some elaboration on the same principle. Even with legacy applications, MX was a retrofit to SMTP.

From: [email-masked] on behalf of Henning Schulzrinne
Sent: Fri 12/5/2008 9:40 AM
To: Thomas Narten; IETF discussion list; [email-masked]
Subject: Re: The internet architecture

protocol, to, so that one can do fopen("http://www.ietf.org <http://www.ietf.org/> "), for 

Henning

---

From: Florian Weimer <[email-masked]>
Date: Sat, 06 Dec 2008 12:37:46 +0100

* Tony Finch:

> This isn't a question of sockets versus file descriptors, since
> sockets *are* file descriptors.

In any case, now that more and more protocols use TLS, if you encode
the a-socket-is-a-file-descriptor assumption too heavily (for example,
by using descriptor passing and expecting that it preserves all
connection state) in your application, you might run into significant
problems very soon.

> It is actually a question of how to specify network addresses in the
> API, i.e. the BSD sockaddr structure versus the Plan 9 extended
> pathname semantics. Using pathnames for everything would eliminate
> warts like embedding pathnames in sockaddrs in order to address a
> local IPC endpoint. On the other hand, filesystem pathnames are a
> uniform hierarchial namespace, which isn't true for the combination
> of network protocol, address, and port - what happens if you
> opendir("/net/")?

Some people have already mounted more classic file systems with
practically unenumerable directories. 8-/

I really wish there were a standard textual representation of socket
addresses.  A couple of years ago, when I was younger and had high
hopes, I designed something for Ada which used

  INET/127.0.0.1/80
  INET6/::1/80
  LOCAL/var/run/server.socket

and so on, and thought it was pretty neat.  But I haven't seen few
efforts in this area, maybe it's not that useful after all.
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: Bryan Ford <[email-masked]>
Date: Sun, 14 Dec 2008 20:51:03 +0100

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 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...

> irregular intervals, and without notice.  And I don't think that's a

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/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

---

From: Keith Moore <[email-masked]>
Date: Mon, 15 Dec 2008 00:24:11 -0500

Bryan Ford wrote:
> 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.

> 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.  

Ah, it seems I read far too much into what you wrote earlier.  I
certainly don't think it should be mandatory for all applications that
use the network to know about the structure of IP addresses. The beef I
had was with the various forms of "all apps should always use DNS names"
arguments.

Note that with getaddrinfo(), arguably they _don't_ need to know about
the structure of IP addresses.  The getaddrinfo() routine allocates a
sockaddr_xx structure of appropriate type for each address found, but
the pointers returned are (as far as the caller knows) to generic
sockaddr structures.  The caller can simply pass a pointer to this
structure to connect().  And the idea was clearly to insulate apps from
having to know about the structure or size of addresses, without
compromising their flexibility.   For several reasons, I don't happen to
think that the result works very well, but the intent was there.  If it
turns out to not work well enough to prevent apps from needing to peek
into addresses, maybe the problem isn't the API, but rather that there
are subtle differences between v4 and v6 that nevertheless matter to
applications.

Keith

---

From: "Joe Baptista" <[email-masked]>
Date: Mon, 15 Dec 2008 13:53:33 -0500

This is a very anal retentive discussion your all having here.  I support
Ford here.  Applications should be able to use names and IP addresses.   We
don't need the IP or DNS gestapo taking over application programs.

regards
joe baptista

On Sun, Dec 14, 2008 at 2:51 PM, Bryan Ford <[email-masked]> wrote:

> 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 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...
>
> 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
> 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, ...
>
> 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/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.
>
> "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
>

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084
_______________________________________________
tae mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tae

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 16 Dec 2008 08:51:44 -0800

Two points
 
1) Let us bury the idea that more parts reduces reliability. If anyone thinks that they do not understand the function of TCP and should go and read some basic networking architecture texts. TCP + IP is more reliable than IP. Ergo it is entirely possible to onfigure a service such that DNS + TCP + IP is more reliable than TCP + IP.
 
It is also possible to design systems such that more layers create less reliability.

2) From an application point of view example.com and 10.1.2.3 may both be regarded as names. They are both rendered as an ascii/unicode string. They both require translation into IP format.
 
10.1.2.3 is simply a string litteral that may be used in place of a DNS name. In neither case should the application require knowledge of the IP address itself. In fact you don't want that as at some point in the distant future, 10.1.2.3 is actually going to map to an IPv6 address, not an IPv4 address.

From: [email-masked] on behalf of Bryan Ford
Sent: Sun 12/14/2008 2:51 PM
To: Keith Moore
Cc: [email-masked]; [email-masked]
Subject: The Great Naming Debate (was Re: The internet architecture)

Cheers,
Bryan

---

From: Melinda Shore <[email-masked]>
Date: Tue, 16 Dec 2008 11:59:19 -0500

Hallam-Baker, Phillip wrote:
> 10.1.2.3 is simply a string litteral that may be used in place of a 
> DNS name. In neither case should the application require knowledge of 
> the IP address itself. In fact you don't want that as at some point in 
> the distant future, 10.1.2.3 is actually going to map to an IPv6 
> address, not an IPv4 address.

While I take your point in general, I do think it should
be pointed out that DNS names are resolved prior to
connection establishment through a directory lookup,
while addresses are routed.

Melinda

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 16 Dec 2008 11:44:25 -0800

So to be strictly accurate here, applications deal in names, some of which are DNS names and some of which are IP address litterals. But an 'end user' application only deals in names.

Now an administration tool or a security tool might well deal in 'addresses' directly, just as such tools might deal in raw message identifiers, cert paths and other arcanae that the user should never need to interpret. 
 
Actually from an API point of view I would like to see those properly rendered safe as well. 
 
The practical upshot of this is that if you have an XML protocol you should have an element of the form 
 
ServiceName: String
 
And NOT
 
ServiceName: 
   Choice 
       DNSName: String
       IPv4Address: Array of Octet [4]
       IPv6Address: Array of Octet [16]

Another area where there is likely to be a concrete output here is in determining what the difference is between a URL and a URN and between a service name and a URL. 
 
I would like to get that pinned down because we currently have a big confusion errupting in Web Services land as a result of people being confused on these points. A Web Service Endpoint may not be the most appropriate form to use as a Web Service descriptor.

From: Melinda Shore [mailto:[email-masked]]
Sent: Tue 12/16/2008 11:59 AM
To: Hallam-Baker, Phillip
Cc: Bryan Ford; Keith Moore; [email-masked]; [email-masked]
Subject: Re: [tae] The Great Naming Debate (was Re: The internet architecture)

Melinda

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Dec 2008 15:24:01 -0500

Hallam-Baker, Phillip wrote:
> So to be strictly accurate here, applications deal in names, some of
> which are DNS names and some of which are IP address litterals. But an
> 'end user' application only deals in names.

how many people are pure "end users" who never need their tools to be
able to deal with IP address literals?  nobody that I know of.  even
naive users who don't understand what IP addresses do, need for their
apps to be able to deal with them for the cases where things break.  for
instance, when the external network connection goes down and they still
want to be able to talk to their printers. [*]

actually the vast majority of users that I know of do occasionally deal
with IP addresses directly.  and many of these guys aren't computer
scientists or techies of any sort.

again, this is not only hopelessly naive, it's harmful.  you're trying
to build a system that's even more broken than what we have now.

we're a very long way from knowing how to build a naming system that
works so reliably and transparently that we can completely hide IP
addresses from users.

Keith

[*] and yeah, I know about LLMNR and even use it occasionally, but it
also breaks when you take your laptop on the road and still want to be
able to print to the printer at home.