Subject: draft-ietf-ipngwg-rfc2292bis-02.txt

From: "Markku Savela" <[email-masked]>
Date: Thu, 9 Nov 2000 12:25:56 +0200

I'm currently looking how the ideas presented in
draft-ietf-ipngwg-rfc2292bis-02.txt would map into our IPv6 implementation
for EPOC, and I have some questions (suggestions?).

Concerning packet specific data and "4.2. UDP and Raw Socket Implications"

I may have missed it, but the text appears to leave it somewhat unclear as
to which packet the data actually belong, say we have a sequence

  recv() UDP packet #1,
  Queued UDP packet #2 is waiting
  recvmsg()

Which UDP packet the recvmsg data applies? I would lean to saying #2,
because then the kernel doesn't need to keep extra buffers around, and it
can just build the data as required directly from the packet.

How are current implementations actually doing it? My interpretation would
mean that to reliably get the correct data about the packet, application
must always first do recvmsg() and then recv() when a socket signals that
data can be read.

Secondly, I don't like the options:

setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR,    &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS,  &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS,  &on, sizeof(on));
setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, &on, sizeof(on));

I would prefer a more generic solution, for example, following the idea of
the ICMP6_FILTER

struct ipv6_filter extfilter;
setsockopt(fd, IPPROTO_IPV6, IPV6_FILTER, &extfilter);

I would leave it up to application to recognize between destination options
before routing header and after. It only would need to ask both routing
headers and destination options in the filter, and it can see from the
recvmsg data, whether options were before or after routing header, or both.

This does not mean that the specification could not have the nice access and
building methods for the headers, as described in later sections for options
and routing headers.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Markku Savela" <[email-masked]>
Date: Thu, 9 Nov 2000 13:20:37 +0200

> From: EXT Markku Savela
> which packet the data actually belong, say we have a sequence
>
>   recv() UDP packet #1,

Oops, I guess you can ignore this part. I didn't realize that recvmsg also
returns the packet... (shows how little I have done advanced programming
with unixes :-).

However, EPOC Socket API does not have recvmsg equivalent, and I still have
the problem I presented with whatever solution I invent (ioctl?) for
retrieving the packet data. But, that will be local issue of no generic
insterest.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Nov 2000 09:40:05 -0800 (PST)

> retrieving the packet data. But, that will be local issue of no generic

I think inventing a mechanism which delivers ancillary data (or the equivalent
thereof) together with the data is the best way to go.
A getsockopt() would need to somehow indicate which packet you want
the ancillary data for.

Otherwise, things would be confusing e.g. in this case
t=0	packet 1 from A with routing header X arrives. Queued in the socket 
	queue.
t=1	packet 2 from B with routing header Y arrives. Queued in the socket 
	queue.
t=10	application calls recv() to get data
t=11	application calls getsockopt to get ancillary data (routing header)
	Does this retrive X or Y?
t=100	application calls recv() to get data
t=101	packet 3 from C with routing header Z arrives. Queued in the socket 
	queue.
t=101	application calls getsockopt to get ancillary data (routing header)
	Does this retrive Z?

Does the getsockopt retrieve from the most recently received packet?

Note that the socket API had the above problem for IPv4 using
getsockopt(IP_OPTIONS) to retrieve information from UDP/IP.
This was fixed by assing IP_RECVOPTS which is delivered using
ancillary data.

  Erik