Subject: in6_pktinfo etc still missing in POSIX specs

From: Pekka Savola <[email-masked]>
Date: Tue, 14 Oct 2008 15:47:13 +0300 (EEST)

FYI,

It's interesting to see that the IEEE Std 1003.1-2001 (+2004 changes) 
still doesn't include the definitions from the advanced sockets API 
spec (RFC2292, RFC3542).

I'm hoping that the recently finalized Open Group base spec revision 7 
/ IEEE 1003.1-2008 does include these (these don't seem to be 
available for public download), but I'm not holding my breath. Could 
someone with access to this check if netinet/in.h now defines 
in6_pktinfo?

As a result, at least some implementors are forced to put these 
definitions in different namespaces [1], which hinders 
interoperability.

I'd say there's a failure somewhere (missing liaison?) in driving IPv6 
APIs to completion.  This isn't exactly a recent issue given the 
predecessor RFC2292 was completed some 10 years ago..

[1]
http://sourceware.org/bugzilla/show_bug.cgi?id=6775

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Tue, 14 Oct 2008 12:24:08 -0400

I'm not involved in this in detail, so I may be off base, but my
understanding is that the advanced API has not been picked up by Open
Group because its members didn't support doing so -- they just didn't
see a need to.

My own take is that standardization of the advanced API just isn't
compelling. When I did a survey in the past of what various vendors
had done with the advanced API, I found that none implemented it
completely. Rather, most implemented bits and pieces of it depending
on what applications needed the funcitonality (or just implemented
private versions for the applications that needed the
functionality). And since the functionality in the adnvanced API (by
definition) isn't needed accept by fairly exotic usages, it's hard to
make the arguement that it needs to be implemented for basic
interoperability.

Thomas

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Oct 2008 08:38:28 +1100

In message <[email-masked]>, Thomas Narten
> make the arguement that it needs to be implemented for basic

	If you want to make UDP replies work without using a
	descriptor per address you listen on you need part's of the
	advanced API.

	Named uses the advanced API to get reply UDP traffic
	sourced from the correct address.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Andrews <[email-masked]>
Date: Wed, 15 Oct 2008 12:08:48 +1100

> Group because its members didn't support doing so -- they just didn't

	One shouldn't have to have OS specific knowledge to write
	IPv6 code.  Failure of POSIX to ratify the advanced API is
	causing that to happen.  This is not conjecture.  It is fact.

	We need more standisation not less.

	The following was just committed to the BIND sources.

2463.   [port]          linux: POSIX doesn't include the IPv6 Advanced Socket
                        API and glibc hides parts of the IPv6 Advanced Socket
                        API as a result.  This is stupid as it breaks how the
                        two halves (Basic and Advanced) of the IPv6 Socket API                          were designed to be used but we have to live with it.
                        Define _GNU_SOURCE to pull in the IPv6 Advanced Socket
                        API. [RT #18388]

---

From: Stig Venaas <[email-masked]>
Date: Wed, 15 Oct 2008 11:10:32 +0200

> 	sourced from the correct address.

Right, I have also used it for receiving unicast and multicast on the
same socket and checking the destination address to determine if unicast
or multicast, or to which multicast group when receiving multiple
groups.

I also have some multicast debugging/testing tools that work on a wide
range of platforms (http://www.venaas.no/ssmping/) where I need the
advanced API (not in6_pktinfo though) to get the hoplimit of received
packets,

Stig