> 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...

I'll add this.


> >        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?


>    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.

  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]
--------------------------------------------------------------------

Reply via email to