Subject: RE: IPV6_USEMTU socket option

From: "Dave Thaler" <[email-masked]>
Date: Fri, 17 Nov 2000 16:43:07 -0800

Erik Nordmark writes:
> > => I agree, it should be a library function (still in advanced API
> > but not as a getsockopt()).
> > 
> > [email-masked]
> > 
> > PS: on some systems getsockopt() is not supposed to have an argument
> > (ie. optval points only to a buffer for the result) then be careful.
> 
> Good point. getsockopt only does a copyout from the kernel.
> 
> Do you have a proposal for a name of a function which retrieves the
> path MTU for a destination/path?

We ran into a similar problem with the multicast source filter API
in http://www.ietf.org/internet-drafts/draft-ietf-idmr-msf-api-01.txt

We decided to use ioctl() as a result, and the above draft includes
the note:

     SIOCGIPMSFILTER could not be done with getsockopt(), since
     the group and interface must be passed down in order to
     retrieve the correct filter.  This can, however, be done with
     an ioctl(), and hence for symmetry, both gets and sets are
     done with an ioctl.

-Dave Thaler
--------------------------------------------------------------------
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: Jack McCann <[email-masked]>
Date: Tue, 21 Nov 2000 11:27:37 -0500 (EST)

>> >  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)?
>
>What would you like to see instead?
>uint32_t? uint16_t?

An observation: both icmp6_mtu and nd_opt_mtu_mtu are uint32_t.

---

From: Tim Hartrick <[email-masked]>
Date: Mon, 27 Nov 2000 10:42:46 -0800 (PST)

Erik,

> What would you like to see instead?

uint32_t is probably best.

> 
> >    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.
> 
> I'll add the above. THanks for the text.
> 
> > 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.
> 
> I can add this unless somebody has any concerns about essentially making
> this implementation specific.
> 

I do, since I am having a difficult time understanding how an application
would make use of such information.  If it can be used by an application
then it should be documented in full or not referenced at all in the
document.

Note that I am not saying that someone can't implement anything they like.
What I am saying is that the specification is intended to document specific
features that application writers can depend on being available on all
platforms.

tim