>>>>> On Fri, 17 Nov 2000 16:28:00 -0800 (PST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
> This is what I've edited together so far.
Thanks for the quick revise. Here are some comments:
> 11.2. Sending without fragmentation
We might have to clarify what happens if the application disables
fragmentation, but sends a larger packet than the MTU of the outgoing
interface. For example, just return an EMSGSIZE error, return an
IPV6_PATHMTU ancillary data item (if the application sets
IPV6_RECVPATHMTU beforehand), or both...
> 11.3. Path MTU Discovery and UDP
> UDP and raw socket applications need to be able to determine the
> "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to
> a given destination so that those applications can participate in
> path MTU discovery. This lets those applications send smaller
> datagrams to the destination, avoiding fragmentation.
> This is accomplished using a new ancillary data item (IPV6_PATHMTU)
> which is delivered to recvmsg() without any actual data. The
> application enable the receipt of IPV6_PATHMTU ancillary data items
> by enabing IPV6_RECVPATHMTU.
> int on = 1;
> setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on));
> By default, this socket option is disabled. Setting the value to 0
> also disables the option.
> 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 4 bytes long. CMSG_DATA will point to a
Now we define and use struct ip6_mtuinfo, thus the size of cmsg_data
is not 4 bytes, but (at least) sizeof(struct ip6_mtuinfo).
> struct ip6_ carrying the path MTU to use together with the IPv6
"mtuinfo" is missed after "ip6_".
> destination address.
> struct ip6_mtuinfo {
> struct sockaddr_in6 ip6m_addr; /* dst IPv6 address including scope
> */
> unsigned int ip6m_mtu; /* path MTU in host byte order */
Is "unsigned int" appropriate here (I'm just wondering, not sure on
this)?
> };
And, as I said in a pervious message, the draft should clearly state
that this ancillary data should be passed to every socket that wants,
even if the socket is non-connected. I'd propsose the following
paragraph to be added.
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. An implementation
may skip to deliver the data to sockets that connect a different
foreign address from the destination address of the corresponding
ip6_mtuinfo strucutre.
This is based on the behavior of our implementation, but I don't stick
to minor details (e.g. the last sentence).
> XXX What about more complex paths e.g. when using a routing header?
How about the following text?
When an application sends packet with a routing header, the final
destination stored in the ip6m_addr member does not necessarily
contain complete information of the entire path. Thus, an
implementation may append an additional data structure after
ip6_mtuinfo to tell the application precise information of the
entire path. This definition of the additinaol structure is beyond
the scope of this document.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
