> Since, in this case, we instantly know that the packet is dropped, wouldn't
> it be better to specifically notify the application via a returned error
> code?
The X/Open (or whoever "owns" the socket standard now adays) socket
specifications allow for implementations where certain error
messages, such as EHOSTUNREACH etc, can not be returned as an
error to a send/sendto/sendmsg.
Implementations using asynchronous message passing between the socket layer
and the procol stack depend on this being allowable behavior.
So I don't think it would be useful to have the IPv6 socket API extensions
pretend that such implementations exist and indeed conform to the socket API
standards.
> > When the application is sending packets too big for the path MTU
> > recvmsg() will return zero (indicating no data) but there will be a
> > cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will
> > indicate that cmsg_data is sizeof(struct ip6_mtuinfo) bytes long.
>
> What happens to any buffered data? If there is buffered data that came
> before the MTU error, should recvmsg() still return 0 and no data?
The assumption is that the mtu indication is a separate "event"
("record" for those looking a *BSD socket code) thus in this case
the application would first receive the buffered data and then receive
the msg with no data and just msg_control.
> Actually, it's worse then that. For non-connected sockets (I am assuming
> non-connected
> means no destination address specified), the ancillary data will be given to
> all of them.
> This now places a burden on the application to figure out whether they are
> sending to a
> given destination or not. We ether need a warning here that the application
> may
> receive MTU ancillary data for a destination they do not care about, or we
> may want to
> restrict this to connected sockets only (i.e. the ones with destination
> address set).
The purpose of the ancillary data item is to allow applications which do
not connect() their UDP sockets to correctly participate in path MTU
discovery.
So I think it makes sense to put in some explicit text saying that the
application needs to verify that it indeed has sent a packet to the
desination.
However, in practise I don't see this being an issue. A UDP application
participating in path MTU discovery (i.e. any UDP application which wishes
to send packet larger than 1280 bytes) must maintain path mtu state for
all the peers it is sending data to. So receiving the IPV6_PATHMTU,
just means it need to find that state and update it.
> Why limit this functionality to only a connected socket? Is it because
> of the odd semantics with providing data to a getsockopt? I mean, the
> application
> could set the ip6m_addr to the destination address it wants to look up the
> MTU for,
> but it would be a little strange for an application to specify data on a
> getsockopt().
s/a little strange/completely inconsistent with getsockopt as defined/
One could envision being able to ask questions about destination addresses
where path MTU is one of the things to ask.
But this quickly evolves into being able to ask about other useful things
(cached rtt estimate, etc). I belive RTM_GET with routing sockets already
provides an API for asking all those questions.
Would it be useful to add a pointer to routing sockets in the spec?
> Section 14.2 and 14.3 [pages 51 and 52]
>
> It may be worth mentioning that AF_UNSPEC may also be used as an argument to
> rcmd_af and rexec_af for protocol independent applications. This aligns this
> API closer to the basic api.
OK
Erik
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
