>>>>> On Sat, 18 Nov 2000 17:58:05 +0100,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
> In your previous mail you wrote:
>> 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...
> => I don't understand: you can't get ancillary data from a sending
> system call then the only possibility is to return an EMSGSIZE error.
> Of course the kernel can/should keep the value of the MTU to use...
I meant that the output routine put the ancillary data into the
receive queue of the sending packet.
> 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 don't understand what is non-connected with ancillary data.
> If you have ancillary data then addresses are available, non-connected
> is for get/setsockopt()...
Sorry, I don't understand what you meant here. BTW: my proposal is
just from Erik's intention:
>>>>> On Mon, 6 Nov 2000 13:11:07 -0800 (PST),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> 1. this option has its meaning for a connected socket only. The
>> destination is the foreign address of the socket.
(snip)
> The spec is clearly incomplete in this area.
> I do think we want this to work for unconnected datagram sockets i.e. 1 is
> not an option.
>> 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.
> => finally I believe the option #3 is too complex for its little utility...
Okay, then how do we pass the destination address to non-noconnected socket?
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]
--------------------------------------------------------------------
