Hello
I apologize for the very late mail as I finally found the time to go through this spec, but I have a few comments about Draft 4. Section 11.2 [page 46] > ... > When the data size is larger than the MTU of the outgoing interface, > the packet will be discarded. Applications can know the result by > enabling the IPV6_RECVPATHMTU option described below and receiving > the corresponding ancillary data items. 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? Particularly, in the case of traceroute that you mention in this section, adding error code would be a good indication because traceroute does not try to receive on it's sending socket. This also applies to any other application that has a sending and a receiving socket. An error code would tell the application that it should perform a receive operation to learn the mtu. Section 11.3 [page 46] > ... > 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? > This cmsghdr will be passed to every socket that sets the > IPV6_RECVPATHMTU socket option, even if the socket is non-connected. > Note that this also means an application that sets the option may get > the ancillary data upon a too big message sent from other > applications to the same destination. 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). Section 11.4 [page 47] > This specification defines a get-only socket option to retrieve the > current path MTU value for the destination of a given connected > socket. > ... > This option can only be used for a connected socket, because a non- > connected socket does not have the information of the destination and > there is no way to pass the destination via getsockopt(). When > getsockopt() for this option is issued on a non-connected socket, the > call will fail. 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(). 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. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
