>>>>> On Wed, 13 Feb 2002 14:56:52 +0100 (CET),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
>> > - 11.4: there is a discussion about MTUs and extra headers added by
(snip)
>> So, I'd propose to clarify that the MTU is an "IP MTU" (in your
>> definition above) and can be larger than the actual current path MTU
>> when the kernel inserts additional headers. Is it okay with you?
> I think the philosophical question is deeper.
> Knowing the size of IP packets that can be sent without IP fragmentation
> (the path mtu) isn't that useful to an application when IP might add a
> variable amount of headers to the packet and the transport might in
> theory do the same.
> What would be useful to the application is something
> like "MAX_UNFRAGMENTED_SEND_SIZE"
> i.e. the largest amount of data that can be passed to send/sendto
> without causing IP fragmentation.
> Today with UDP over IPv6 the difference between this and path MTU is
> just a constant.
> But with mobile IP the sending IP stack some times inserts home address options
> and/or routing headers in which case the difference isn't constant.
> Of course, applications using sendmsg with ancillary data have more problems
> in this area since they need to know what size headers result from
> the ancillary data items they pass down e.g. that IPV6_HOPLIMIT
> doesn't add headers but IPV6_DSTOPTS does add.
(As a "philosophical" argument) I agree with all the points. But as
for the API document, we should (or can) just keep the current text,
as Francis agreed in his message.
>> > - 11.5: is IPV6_REACHCONF really useful (example)?
>>
>> Honestly, I personally do not see a practical usage of this option.
>> At least I've never seen an application that uses it. I don't mind to
>> remove this, but if any other person wants to keep it, I'll just leave
>> the current text as is. The definition has been there since a quite
>> old revision of the draft, and it can at least be implemented.
> An application like a DNS resolver library might pass this down
> on a sendmsg when it has recently gotten a reply from the same server.
> But the saving of the NUD probe in this case isn't yet a strong enough
> motivation to pass down IPV6_REACHCONF. It's hard to tell whether this
> motivation will be stronger in the future.
Agreed, so, are you okay with removing this section?
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]
--------------------------------------------------------------------
