Subject: [RAM] Naming & APIs

From: RJ Atkinson <[email-masked]>
Date: Sun, 6 May 2007 13:34:53 -0400

From http://www.ietf.org/internet-drafts/draft-ietf-hip-native- 
api-01.txt:
>
> 2.3.  Namespace Model
>
>    The namespace model is shown in from HIP view point.  The namespace
>    identifiers are described in this section.
>
>                +-------------------+-----------------------+
>                | Layer             | Identifier            |
>                +-------------------+-----------------------+
>                | User Interface    | FQDN                  |
>                | Application Layer | ED, port and protocol |
>                | Transport Layer   | HI, port              |
>                | SHIM Layer        | HI                    |
>                | Network Layer     | IP address            |
>                +-------------------+-----------------------+
>
>                                   Table 1
>

An alternative view, increasing the abstraction but using
roughly that table format, might look rather more like this:

Layer                   Naming
=============		=================
User/Human		URL, FQDN
Application		URL, (FQDN + ServiceName)
Transport		Identifier (HI or other)
Network			Locator (Routing Prefix or other)

Java turns out to be a good example here, although many
on this list might be C/C++ programmers instead.  Java
does offer a relatively low-level Sockets-like API,
but most Java programs are written using a networking
API that works either on a full URL or on (FQDN +
ServiceName).  [See the URL Class of Java, and for example
the OpenConnection() or OpenStream() methods.]

The reason for that being common usage in the Java
application community appears to be that it is easier and
simpler for application authors to call the more abstract
API directly, rather than to make (multiple) calls to the
equivalent of getservbyname(), gethostbyname(), and then
into low-level Sockets APIs to glue everything together
and create a new session.

A feature (and property) of using a (much) more abstract API
is that the same exact API works equally well with IPv4,
IPv6, HIP, or some (tbd) Identifier/Locator schema.  I
also think it is a useful metre stick to compare any
proposed API against this test of being simple and also
being ignorant of nearly all lower-level (i.e. below the
application-layer) details.  The main thing that one might
want to expose above, and I'm not sure about this, is
whether one is using a datagram service versus a stream
service (and this detail probably should be abstracted
in the ServiceName).

So I like the idea of a new more abstracted networking
API very very much, preferably ones for C and C++ to
complement the existing abstract Java APIs, but I think
the HIP draft's API is not abstract enough at present.

Cheers,

Ran
[email-masked]

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: <[email-masked]>
Date: Mon, 7 May 2007 11:55:05 +0300

For whatever it's worth I must violently agree with Ran here. App layer
identifiers & names should be made as independent of the underlying
stack as possible, and Java APIs seem to show the way here.

This would also help with problems like linking security certificate
(which has domain names) to a communication instance within the stack
(which currently does not have unambiguous access to the domain name the
communication is related to).

Regards,

	Jarno

>-----Original Message-----
>From: ext RJ Atkinson [mailto:[email-masked]] 
>Sent: 06 May, 2007 20:35
>To: [email-masked]
>Subject: [RAM] Naming & APIs
>
>
>Java turns out to be a good example here, although many on 
>this list might be C/C++ programmers instead.  Java does offer 
>a relatively low-level Sockets-like API, but most Java 
>programs are written using a networking API that works either 
>on a full URL or on (FQDN + ServiceName).  [See the URL Class 
>of Java, and for example the OpenConnection() or OpenStream() methods.]
>
>The reason for that being common usage in the Java application 
>community appears to be that it is easier and simpler for 
>application authors to call the more abstract API directly, 
>rather than to make (multiple) calls to the equivalent of 
>getservbyname(), gethostbyname(), and then into low-level 
>Sockets APIs to glue everything together and create a new session.
>
>is that the same exact API works equally well with IPv4, IPv6, 
>HIP, or some (tbd) Identifier/Locator schema.  I also think it 
>is a useful metre stick to compare any proposed API against 
>this test of being simple and also being ignorant of nearly 
>all lower-level (i.e. below the
>want to expose above, and I'm not sure about this, is whether 
>one is using a datagram service versus a stream service (and 
>this detail probably should be abstracted in the ServiceName).
>
>So I like the idea of a new more abstracted networking API 
>very very much, preferably ones for C and C++ to complement 
>the existing abstract Java APIs, but I think the HIP draft's 
>API is not abstract enough at present.
>
>Cheers,
>
>Ran
>[email-masked]
>
>
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 May 2007 11:12:57 +0200

On Mon, May 07, 2007 at 11:55:05AM +0300,
 [email-masked] <[email-masked]> wrote 
 a message of 101 lines which said:

> App layer identifiers & names should be made as independent of the
> underlying stack as possible, and Java APIs seem to show the way
> here.

Nothing specific to Java. Every language but C does it (Python, Ruby,
Haskell, Lua).

---

From: <[email-masked]>
Date: Mon, 7 May 2007 13:11:18 +0300

Stephane Bortzmeyer [mailto:[email-masked]] 
>[email-masked] <[email-masked]> wrote  a 
>message of 101 lines which said:
>
>> underlying stack as possible, and Java APIs seem to show the 
>way here.
>
>Nothing specific to Java. Every language but C does it 
>(Python, Ruby, Haskell, Lua).
>

Yes, but my point was that it would be advantageous for the domain name
etc. be available at the kernel interface, not just in a library or a
language runtime environment.

Regards,

	Jarno

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 May 2007 12:29:43 +0200

On Mon, May 07, 2007 at 01:11:18PM +0300,
 [email-masked] <[email-masked]> wrote 
 a message of 19 lines which said:

> my point was that it would be advantageous for the domain name
> etc. be available at the kernel interface, not just in a library or
> a language runtime environment.

Very slippery slope. 

First, we are quite outside IETF domain (pun intended) here. (Unless
you want the domain name to be the endpoint identifier, available in
every packet.)

Second, most of the time, it does not matter in the source code (is
foobar(42) a call to the kernel or to the libc or to another library?
You cannot tell from the source code and it is on purpose).

Third, in some OS, the difference between "the kernel" and "the
library" may be blurrier than in Unix. The fact they are separated is
not a general law of computer science. The difference between "a
library" and "a language runtime environnement" is even blurrier.

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 7 May 2007 08:05:06 -0400

> (Python, Ruby, Haskell, Lua).

All of which seems to be consistent with my suggestion that we
ought to have such an abstracted API for C (and C++).

Given that the IETF has actually done significant API work
at this point (several C APIs for IPv6, GSS-API in the security
area), it might be quite reasonable work for a more
abstracted API for C (and C++) to be published as an RFC
by the IETF (following usual processes).

Ran

---

From: Ed Jankiewicz <[email-masked]>
Date: Mon, 07 May 2007 10:03:57 -0400

Agree wholeheartedly with the abstraction idea.  Also agree with the 
objection about overstepping IETF "domain".  As suggested both points 
would be satisfied by a draft that defines an "abstract API" extension, 
similar to that existing in Java and other languages, and leave it to 
the compiler and language folks to implement as they see fit.  Then 
programmers in C can do what they always could, and abstract their 
application code through a function that mimics the API anyway 
regardless of it lacking in the compiler.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 7 May 2007 12:04:44 -0700

IPv6-in-(foo)-in-IPv4 tunneling mechanisms (e.g., LISP,
IPvLX, ISATAP, Teredo, 6to4, etc.) are currently limited
to sending packets only slightly larger than the IPv6
minMTU of 1280 bytes due to operational aspects of the
IPv4 Internet. A solution to this limitation is given in
'draft-templin-linkadapt', which specifies a Sub-IP layer
mechanism that supports larger MTUs (up to 9KB or larger)
through link adaptation at a layer below IPv6 fragmentation
but above IPv4 fragmentation.

A key requirement of the spec is that both the ITR and ETR
be made aware that the link adaptation scheme is being used,
and previous versions of the spec did this by requiring the
ITR to set the "Reserved Fragmentation (RF)" bit in the IPv4
headers of tunneled packets. The current document version
(-05) has gone away from this approach and now requires a
prior negotiation between the ITR and ETR.

This decision has some important ramifications; first, it
sets the use or non-use of the link adaptation on a per-
tunnel basis rather than on a per-flow or per-packet basis.
This means that all flows and all packets that traverse the
tunnel would either use the scheme or not. Secondly, it
requires that there be an explicit prior negotiation between
the ITR and ETR as to whether the scheme is enabled. Finally,
it does not allow for an adpative "revert to classical IPv4
fragmentation" option after the tunnel is established.

Use of the RF bit has some associated uncertainties, however.
For example, it is not clear as to whether the state of the
RF bit would be preserved across all paths since RFC791 says
that it is "reserved, must be zero" but does not say what
network middleboxes should do with a packet that has RF=1.
The other consideration is that there are other proposals
that would like to make use of this bit.

So, can we have some discussion on the use or non-use of
the RF bit for link adaptation over IPv6-in-(foo)-in-IPv4
tunnels?

Fred
[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Tue, 08 May 2007 14:39:29 +0200

>library" and "a language runtime environnement" is even blurrier.

Correct.
Example: QNX.
However, there is a real need in the back. IMHO there are several 
areas to investigate:

- DDDS and their relations with the information, in particular today 
in multilingualism. For example we considered how to multilingualise 
the DNS at application level and not how to multilingualise the IP 
addresses at network level (even though ICANN asked for it [ICP-3] 
and John Klensin introduced a possible approach [classes], I tested 
and documented (dot-root) and Chinese implemented through 
pseudo-classes or "URL" [user level domain, a move very comparable to 
the use of the "-" in the hosts.txt flat space to create a hierachy] 
in using SLDs as virtual TLDs.]

- the OPES which can massage a lot of information on the network side 
and offer netlocalised containers (depending on local technology)

- the de facto embryonic network interoperation system which has not 
been identified as such, hence no model, no description, no 
interface, no application, etc. as yet.

Most probably these three areas and others (like registries, 
semantics, anachronism, inferences) should be seriously investigated. 
But the first issue is the address in order to identify the topology 
of the considered systems. IMHO to continue to define addresses by 
examples rather than by characteristics, or even by conceptual 
characteristics rather than by emergence (common metaconcept), will 
only complexify the issue.

Let assume that an address is a numeric set of fixed, mobile, virtual 
adherences (emergence) common to a group of specific concepts, 
defined by a unique set of characteristics and openly documented by a 
complementary set of attributes, that an origin can identify as an 
absolute or relative destination.

jfc

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 8 May 2007 16:22:57 +0200

> the HIP draft's API is not abstract enough at present.

This seems as good a point as any to jump back into the discussion.

I fully agree. With IPv4, the problem is that the socket API predates  
the DNS. But the people who worked on the IPv6 API made a colossal  
mistake in keeping this layer violation. Without that, our work in  
shim6 would have been a lot simpler. I hope the HIP people see the  
error of their ways and remove the lower-layer stuff from what the  
application can see. This includes the port number.

---

From: <[email-masked]>
Date: Wed, 9 May 2007 11:37:20 +0300

Iljitsch van Beijnum [mailto:[email-masked]] wrote:
>I fully agree. With IPv4, the problem is that the socket API 
>predates the DNS. But the people who worked on the IPv6 API 
>made a colossal mistake in keeping this layer violation. 
>Without that, our work in
>shim6 would have been a lot simpler. I hope the HIP people see 
>the error of their ways and remove the lower-layer stuff from 
>what the application can see. This includes the port number.
>

Also the fact that HIP implementations more or less rely on hacks with
the resolver code should ring a bell. Current HIP implementations would
be simpler if the socket API would operate on names instead of
addresses.

	Jarno

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 9 May 2007 07:40:28 -0700

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, May 09, 2007 1:37 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [RAM] Naming & APIs
> 

I am not sure it is that simple.  There are some networks that do not
have DNS.  There are some applications that do not want to rely on DNS,
or even use DNS.  The resolver, including getaddrinfo, has been around
longer than many apps, so I don't think it is fair to suggest that the
IPv6 API designers did not try to solve this problem.

With regard to HIP, there may be an explicit security benefit for
allowing an application to connect directly to a HIT, because connecting
to a FQDN leaves the application vulnerable to attacks on the domain
name to HIT binding.  So I think it would be a mistake to not offer
applications the possibility to connect to HITs directly.  Diagnostic
applications (ping) need also to connect to IP addresses explicitly.

I think that applications should be able to use domain names, HITs, and
locators (and combinations thereof) at the APIs, but that systems should
try to provide APIs that remove the incentives to resort to lower-level
API usage, unless the programmer really wants the fine-grained control.
Maybe the problem is that the high-level APIs have not been responsive
enough to the needs of the applications, or maybe it has been an
educational problem of best-practices API usage.

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 9 May 2007 11:54:34 -0700

> From: Henderson, Thomas R 
> Sent: Wednesday, May 09, 2007 7:40 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]

Lest my previous post be misconstrued, let me clarify:
- I realize that people are not arguing against the low-level APIs, but
I was responding that the high-level API is not necessarily simple to
solve the myriad of issues that application developers have faced.
There was an attempt to do it previously (getaddrinfo), which apparently
was not enough.  
- we are, in the HIP WG, considering these higher level APIs and I think
that they would be beneficial, but I have been suggesting that we
consider the issue more broadly than just trying to facilitate HIP.  I
agree with Ran's previous comment that it may be worthwhile for the IETF
to work on a more abstracted C-based API.  That is why we've solicited
some feedback on the apps-discuss list about whether this would be
acceptable work.

Tom

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 9 May 2007 15:11:02 -0400

> There was an attempt to do it previously (getaddrinfo), which  

(I guess I haven't managed to be clear; my apologies for that.)

IMHO, getaddrinfo() is a useful library call, but is not really
an example of a high-level API.  Even with getaddrinfo(), the
application still must be aware of and directly make
BSD Sockets API calls in addition.

If one looks over the Java APIs that I mentioned in my original
note, I think one can get a much clearer grasp of what "high-level"
or "more abstract" means to me.

This next will not be a great example due to haste, the Java ones
are MUCH better, but consider a new API fragment vaguely like this:

	...
	FILE *open_URL(char *URL);
	FILE *open_session(char *ServiceName, char *Dest_FQDN);
	int   close_session(FILE *stream);
	...

where:
	"open" returns -1 for error, else a file descriptor pointer
	URL is a string like "http://www.foo.com/bar/baz.html".
	ServiceName is "http" or any string known to getservbyname()
	Dest_FQDN is "www.foo.com" or any other fully-qualified
		domain name.

	One might want to have a *simple* set of set/get options with
	these APIs (e.g. IPsec requested/provided), but those would
	need to be purely optional (varargs is one's friend) and
	would need to be VERY carefully thought out.

I think it is great that the HIP folks are thinking about
undertaking the more abstracted API work.  It would be great
if we had such an openly specified abstracted API, either as
library or as system call.

Cheers,

Ran

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 9 May 2007 21:55:11 +0200

On Wed, May 09, 2007 at 11:54:34AM -0700,
 Henderson, Thomas R <[email-masked]> wrote 
 a message of 45 lines which said:

> - we are, in the HIP WG, considering these higher level APIs and I
> think that they would be beneficial,

Yes.

> but I have been suggesting that we consider the issue more broadly
> than just trying to facilitate HIP.

Yes.

> I agree with Ran's previous comment that it may be worthwhile for
> the IETF to work on a more abstracted C-based API.  That is why
> we've solicited some feedback on the apps-discuss list about whether
> this would be acceptable work.

IMHO, yes, a big yes (but I do not volunteer for the work so take my
advice with care).

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 21 May 2007 13:57:42 +0200

> or "more abstract" means to me.

When I last looked at this, Java programmers needed to know *nothing*
about IP versions, unless they needed to invoke two special constructs
that are self-explanatory:
java.net.preferIPv4Stack, java.net.preferIPv6Addresses

     Brian

-- 
NEW: Preferred email for non-IBM matters: [email-masked]