Subject: RE: The internet architecture

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Dec 2008 06:29:03 -0800

Right, the DNS is no longer providing mere hostname mapping and host discovery, it is providing service mapping and service discovery.

[email-masked] does not connect to an IP address, the outgoing email server first attempts to resolve MX records.

What we are discussing here is architecture, that is not just about solving the problems of today, it is looking forward to the problems that are emerging today and will be worse over time. Questions such as performance are really not very relevant. It is very easy to over-optimize for the current network and use and foreclose better ways of solving problems.

If resolving service endpoints is your biggest performance concern, you probably don't have a performance concern.

Is the current situation entirely ideal? Certainly not, or else there would be no work to be done. We have a lot of pieces but no integration between them. DHCP and DNS are only sometimes integrated. If we had an architectural statement we could make that a much stronger assumption.

Another, bigger problem is that the IETF/W3C split has led to a situation where we don't have so many of the application developers here. Now in Web Services land they have a model, but the original model had a box labeled UDDI which clearly is not going to happen. So now we (apps folk) have a bunch of bubbleware, an abstraction without a specified reification as protocol. And there are slight differences in each instantiation.

OK we now have two standards orgs producing platform, but we can only have one Internet architecture. And the bigger problem here is that instead of arguments being followed through to a conclusion, each camp can retreat to its own tent. And the discussion never gets finished.

Case in point here being the question of whether schema URIs should be URLs or URNs. The arguments made by both camps are true. But instead of developing an architecture that resolves both sets of requirements W3C does things one way and IETF another.

I know IETF thinks IP is the center of the universe and the one true religion. But not in process control it is not. A PIC controller comes with 384 bytes (BYTES, not kilo) of RAM. Good luck getting an IP stack in there. And even if you use a bigger processor with a built in TCP/IP stack you can only run it over Ethernet type media. You can't use RS485 which looks a much better bet for hardwired home automation systems to me, it is what process control has used for decades.

What I think we need here is for IETF to construct a service discovery architecture. By this I mean the mechanism that all future protocols MUST support and the one mechanism that all future network layer protocol changes will be required to support. Protocols can do whatever they like in addition. And then the IETF needs to convince the W3C and OASIS architecture boards to make this a requirement at their end. And this needs to be through negotiation, not a diktat. 

And the W3C needs to come up with a framework for device and service description that works in that service discovery architecture and sell it to the IETF. This will involve lots of angle bracket thingies but essentially it is a MIB for applications.

-----Original Message-----
From: [email-masked] on behalf of Dave CROCKER
Sent: Mon 12/1/2008 12:05 AM
To: John Day
Cc: Keith Moore; [email-masked]
Subject: Re: The internet architecture

John Day wrote:
>>
>>
>> Please elaborate. I agree that the current resolution protocol is not
>> perfect but what is wrong with the semantics of domain names?
> 
> As we have known since the early 80s, naming the host has nothing to do 
> with the problem at hand.  It is sloppy and gets in the way of getting 

"The problem at hand" is what, exactly?  Concretely and specifically.

> it right.  Currently, domain name is a synonym for an IP-address.  The 
> IP-address names the interface and is largely redundant since the MAC 
> address does the same thing.

Ignoring, for the moment, that a domain name does not always map to an IP 
Address, nevermind that it often maps to a set of them, the fact of mapping is 
not quite the same as being "synonymous".  It can be -- and often is -- 
equivalent to find a path to the named resource.  A path is not a synonym.

www.example.com is a common name for the an organization's online web presence.

That sort of description of the name is quite different from the mechanical and 
narrow simplicity of a host name or a synonym for a *set of* IP Addresses that 
might refer to a single machine or to multiple.

d/

-- 

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

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

---

From: <[email-masked]>
Date: Mon, 1 Dec 2008 14:43:55 -0000

> I know IETF thinks IP is the center of the universe and the 
> one true religion. But not in process control it is not. A 
> PIC controller comes with 384 bytes (BYTES, not kilo) of RAM. 

This is wildly out of date. For at least the last 10 years
cheap and common PICs have been made with more RAM than that.
The IP stack has been implemented in 1K bytes of code that
will run on the 8-bit PIC CPUs.

> Good luck getting an IP stack in there. And even if you use a 
> bigger processor with a built in TCP/IP stack you can only 
> run it over Ethernet type media. You can't use RS485 which 
> looks a much better bet for hardwired home automation systems 
> to me, it is what process control has used for decades.

Exactly. Process control doesn't need IP at all at the
edge of their network. They have other solutions that
work well for them. Whether it is I2C or one-wire or
RS-485, data can be relayed onto an IP network by devices
which speak both protocols. There is no problem here.

--Michael Dillon

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Dec 2008 07:16:08 -0800

Well technically you are right, but you are still wrong :-0

I know you can get IPv4 on a controller. But I think you will need more than 1kB for IPv6 since IPSEC is required... And IPSEC requires public key on the controller.

Yes there are bigger processors, but what I am interested in doing is putting the processor into a light socket base. And to get the larger RAM you need to get more pins (!). I was reading spec sheets over the weekend.

And the other issue is power. The larger, ethernet capable chips require a lot more power. The tiny 384 byte RAM chips draw 11 micro-Watt. Which comes out at half kilowatt hour in a millennia.

And yes, you can do IP in 1Kb ROM. But I need that for my cryptography. So far I have found Skipjack in PIC logic but no code for AES yet. I am trying to decide if Skipjack is enough for my application (controlling the garage door from the Internet) or whether to code up the AES. Looks to me as if AES-128 should be practical.

The point I was making is that we are not going to have IP all the way out to the edge of the network. However fast logic controllers get, the earlier generation gets cheaper and is pushed out to another level. 

And even if they can run IP they are not going to run the firewalls and such that you would want to put the device out naked on the network?

But even without IP out to the edge, I can use the DNS to name them. And that is all that matters to count them as part of the Internet. I can even assign them a globally routable IPv6 address. But the device itself will never see it.

-----Original Message-----
From: [email-masked] on behalf of [email-masked]
Sent: Mon 12/1/2008 9:43 AM
To: [email-masked]
Subject: RE: The internet architecture

--Michael Dillon

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Dec 2008 16:41:56 +0100

On Dec 1, 2008, at 15:43 , <[email-masked]> <[email-masked] 
 > wrote:

> Process control doesn't need IP at all at the
> edge of their network.

This is a side-track, but:
Some people in the IETF, as well as in the industry, might disagree...
Watch out for the next billion nodes on the Internet.

Gruesse, Carsten (not speaking as 6lowpan co-chair today)

---

From: Fred Baker <[email-masked]>
Date: Sat, 29 Nov 2008 16:35:19 -0800

Did you review the slides I discussed during the behave working group  
meeting as to what I view as the principal value of the technology? If  
not, may I suggest that you obtain them from
     ftp://ftpeng.cisco.com/fred/gse/behave-nat66-gse.pdf

At this point, given the amount of discussion that has happened that  
presumes that "we", for some definition of that term, are wise, smart,  
and good, and everyone else (in your email, those thieving greedy  
vendors), without taking into account the written statements or the  
discussion that happened in the working group meeting (which is the  
email address you conveniently dropped from the thread), I am at a  
loss for words.

Take time to find out what I took time to tell people about my  
motivations. Then, and only then, sit in judgement.

As a matter of fact, the IETF is looking very hard at solutions to the  
problem I raise and has for the past several years been very  
explicitly reaching out to operators and others. A GSE/8+8 approach,  
which is the root of several proposed solutions in that area, can't  
work without the components fundamental to it, one of which is a NAT.

On Nov 26, 2008, at 1:27 AM, <[email-masked]> <[email-masked] 

>> Yeah, but we're trying to get rid of that stuff, or at least
>> considerably reduce the cost and complexity, because (among other
>> things) it presents a huge barrier to adoption of new multiparty  
>> apps.
>
> Promoters of NAT, particularly vendors, seem to have a two-valued
> view of the network in which inside is good and outside is evil.
> But network operators, who sit on the outside of the NAT,
> do not share that view. In fact, we see a future in which
> cloud computing centers within the network infrastructure
> will lead to a wide variety of new multiparty applications.
> In many cases the network operator also takes management
> responsibility for gateway devices, so the idea of evil on
> the outside is even further fetched.
>
> That said, if there is to be some form of NAT66 because there
> are real requirements elsewhere, it would be preferable if
> the defined default state of this NAT66 was to *NOT* translate
> addresses. This is not crazy if you see it in the context
> of a NAT device which includes stateful firewalling.
>
> I suggest that if part of the problem is an excess of
> pressure from vendors, then the IETF could resolve this
> by actively seeking greater input from other stakeholders
> such as network operators.
>
> --Michael Dillon

---

From: Christian Vogt <[email-masked]>
Date: Thu, 4 Dec 2008 11:26:52 +0200

John,

yep, I understand, and do fully agree to, your point that applications
are primarily interested in connecting to a particular service, which
makes it in general irrelevant which physical host is running the
service.  Hence it is in general unnecessary to name a specific physical
machine.  In fact, this reasoning is in line with the new network
protocol stack architecture proposed in [1]:

As I explained to Keith in my previous email, in the proposed stack
architecture, connections are initiated by specifying a remote service
instead of a remote host.  They are initiated using the combination of a
service name and a DNS hostname, where the hostname is, despite its
intuitive meaning of being specific to a physical machine, just a set of
IP addresses through which the service of interest can be reached.

Of course, it would alternatively be possible to directly embed service
semantics into DNS hostnames, similar to what we do today with SRV
records.  The result would then be a name, retrievable via the DNS, that
specifies a service in globally unique manner.  I am open to such
embedding, but the embedding would conceptual make no difference. There
are two reasons why I chose to separate service names from hostnames in
the initial design of the proposed stack architecture: First, due to the
different constraints for service names versus hostnames:  Only
hostnames can be selected freely; service names need to be well known.
Secondly, because service names and hostnames don't always go together:
To accept incoming connections, only a local service must be named, but
a local hostname is unnecessary.  And to filter incoming connections,
only a remote hostname is needed, but not a remote service name.

In any case, your comment is useful input, as it shows that calling the
proposed stack architecture in [1] "hostname-oriented" may be wrong.
Calling it "service-name-oriented" -- or simply "name-oriented" -- may
be more appropriate.  Thanks for the input.

- Christian

[1] Christian Vogt:  Towards A Hostname-Oriented Network Protocol
     Stack for Flexible Addressing in a Dynamic Internet,
     http://users.piuha.net/chvogt/pub/2008/vogt-2008-hostname-oriented-stack.pdf

On Dec 1, 2008, John Day wrote:

> Naming the host is sometimes useful for network management purposes,  
> but
> really has nothing to do with the problem of forwarding or delivering
> packets.  I realize there is a lot of sentimental attachment to the  
> idea
> of naming a host, but as I said that was a sloppy habit we got in very
> early and for some reason sloppiness has prevailed.
>
> The "entity" to be named is whatever the packets are delivered to.  
> That
> may reside on a host, but that fact is purely coincidental.  As long  
> as
> sentimentality trumps logic, it will be difficult to get it right, but
> in the current climate it will be possible to publish a lot of papers.

---

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

Rémi Després wrote:

> IMO, service names and SRV records  SHOULD be supported asap in all
> resolvers (in addition to host names and A/AAAA records that they
> support today).
> Any view on this?

a) SRV records only apply to applications that use them.  to use them
otherwise would break compatibility.

b) SRV records also increase reliance on DNS which (among other things)
is a barrier to deployment of new applications.  use of SRV would
therefore encourage overloading of existing protocols and service names
to run new applications (another version of the everything-over-http
syndrome).

c) use of SRV would encourage even more meddling with protocols by NATs

d) it's not immediately clear to me that it would be feasible for SRV to
be used by applications that need to do referrals.  they'd need some way
to generate new, unique "service names" and there would need to be a way
to generate and distribute new DNS dynamic update credentials to those
applications or even application instances.

and that's just the problems I can think of off the top of my head.

Keith

---

From: Rémi Després <[email-masked]>
Date: Fri, 05 Dec 2008 11:25:41 +0100

> be more appropriate.  Thanks for the input.
Full support for the idea of a *name-oriented architecture*.

In it, the locator-identifier separation principle applies naturally: 
names are the identifiers; addresses, or addresses plus ports,  are the 
locators.

Address plus port locators are tneeded to reach applications in hosts 
that have to share their IPv4 address with other hosts ( e.g. behind a 
NAT with configured port-forwarding.)

*Service-names* are the existing tool to advertise address plus port 
locators, and and to permit efficient multihoming because, in *SRV 
records* which are returned by the DNS to service-name queries:
- several  locators  can be received for one name, possibly with a mix 
of IPv4 and IPv6
- locators can include port numbers
- priority and weight parameters of locators provide for backup and load 
sharing control.

Regards,
RD

---

From: Marc Manthey <[email-masked]>
Date: Sat, 6 Dec 2008 08:03:45 +0100

Am 05.12.2008 um 11:25 schrieb Rémi Després:

> In it, the locator-identifier separation principle applies  
> naturally: names are the identifiers; addresses, or addresses plus  
> ports,  are the locators.
>
> Address plus port locators are tneeded to reach applications in  
> hosts that have to share their IPv4 address with other hosts ( e.g.  
> behind a NAT with configured port-forwarding.)
>
> - several  locators  can be received for one name, possibly with a  
> mix of IPv4 and IPv6
> - priority and weight parameters of locators provide for backup and  
> load sharing control.
>

hello Rémi,

i totally agree with you in all points, from my perspective , there is  
no sufficent support
for identifying  and signing tools, like DNS TSIG whitch will be from  
by apples wide area bonjour

http://www.dns-sd.org/ServerSetup.html

I was following a interesting software project , BUT

quote :
----
On Linux (at least on Debian), you need the mDNSResponder package  
provided by
Apple on the Bonjour downloads page.  Unfortunately, Avahi doesn't yet
implement all of the API functions UIA needs.
---

So "sahred secret"  http://www.ietf.org/rfc/rfc2845.txt   are not  
implemented into "avahi"
  for wide area distribiution since 2 years. And Novell / SUSE seems  
to have no interest aswell.

just my 50 cents

regards

Marc

--
Marc Manthey 50672 Köln - Germany
Hildeboldplatz 1a
Tel.:0049-221-3558032
Mobil:0049-1577-3329231
mail: [email-masked]
PGP/GnuPG: 0x1ac02f3296b12b4d
jabber :[email-masked]
IRC: #opencu  freenode.net
twitter: http://twitter.com/macbroadcast
web: http://www.let.de

Opinions expressed may not even be mine by the time you read them, and  
certainly don't reflect those of any other entity (legal or otherwise).

Please note that according to the German law on data retention,  
information on every electronic information exchange with me is  
retained for a period of six months.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Dec 2008 10:11:40 +0100

On Sat, Dec 06, 2008 at 08:03:45AM +0100,
 Marc Manthey <[email-masked]> wrote 
 a message of 87 lines which said:

> provided by Apple on the Bonjour downloads page.  Unfortunately,
> Avahi doesn't yet implement all of the API functions UIA needs.

And it is a proprietary protocol, anyway. The IETF protocol on that
field is LLMNR (RFC 4795).

---

From: Marc Manthey <[email-masked]>
Date: Mon, 8 Dec 2008 11:25:02 +0100

Am 08.12.2008 um 10:11 schrieb Stephane Bortzmeyer:

> And it is a proprietary protocol, anyway.

who told you that  ?

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00087.html

some references

http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt

http://files.dns-sd.org/draft-sekar-dns-llq.txt

http://files.dns-sd.org/draft-sekar-dns-ul.txt

http://files.dns-sd.org/draft-cheshire-nat-pmp.txt

Marc
--
Les Enfants Terribles - WWW.LET.DE

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 8 Dec 2008 11:45:22 +0100

On Mon, Dec 08, 2008 at 11:25:02AM +0100,
 Marc Manthey <[email-masked]> wrote 

>> And it is a proprietary protocol, anyway.

Please tell me what open standard (IETF, ITU, what you want) defines
it.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stig Venaas <[email-masked]>
Date: Wed, 17 Dec 2008 16:43:29 +0100

> resolvers (in addition to host names and A/AAAA records that they

I would have liked some standard API for looking up SRV records. It's
hard to use SRV in portable applications. I've been wondering if that is
something we could do in the IETF, but would probably have to involve or
be discussed with the POSIX/Austin Group guys.

One could possibly extend getaddrinfo() or make something a bit similar.
getaddrinfo() is perhaps already becoming too complex though. A neat
thing with extending getaddrinfo() could be to make existing code use
SRV without changes. Not exactly sure if that is good or not...

Stig

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Dec 2008 11:01:09 -0500

Stig Venaas wrote:
> hard to use SRV in portable applications. 

In general there is a need for a standard, general purpose API for DNS
queries - one that lets you query for arbitrary record types.  It also
needs to be thread safe and to work in an

> SRV without changes. Not exactly sure if that is good or not...

It's not.  And I've heard rumors that some implementations of
getaddrinfo() already do this - which is a good reason to not use it at all.

Keith

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 17 Dec 2008 11:47:29 -0500

> getaddrinfo() already do this - which is a good reason to not use it  

Well, if you want portable code with consistent behavior, you can't  
use getaddrinfo with both host and service names specified, and you  
still have to do the SRV queries some other way.  But it may still be  
the most portable way to do thread-safe IPv4+IPv6 address resolution.

I originally thought I wouldn't mind seeing a flag for getaddrinfo in  
some future spec that means "do (not) look up SRV records for host 
+service", but I don't think you'd get consistent defaults implemented  
across all the existing implementations, some of which already do SRV  
records and some of which don't; maybe we'd need both "do" and "do  
not" flags.  And it still wouldn't help you with looking up  
"_sip._tls.example.com", so you still wind up wanting the additional  
API.  Still, a shortcut in getaddrinfo for the simple and most common  
cases might be handy if it could be controlled.

So far as I can tell, getaddrinfo with only host *or* service name  
specified is still portable and consistent... if you keep in mind the  
differences between the different versions of the specs that have been  
implemented.

Ken

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Dec 2008 11:58:17 -0500

Ken Raeburn wrote:
> Well, if you want portable code with consistent behavior, you can't use
> getaddrinfo with both host and service names specified, and you still
> have to do the SRV queries some other way.  But it may still be the most
> portable way to do thread-safe IPv4+IPv6 address resolution.

Mumble. I have also seen a getaddrinfo() implementation that would fail
if you passed it a literal port number, if that port wasn't listed in
/etc/services.  I kept wondering if they were trying to look up the
service name so they could do an SRV query on that.

Keith