> > - 11.4: there is a discussion about MTUs and extra headers added by > > the kernel (Mobile IPv6 options). IMHO the MTU is an IP MTU so should > > not take into account the headers. But this makes it less useful > > for the programmer... (note: this is just a philosophical question > > for the 2292ter) > > I understand your concern, but, anyway, the value returned by > IPV6_PATHMTU is just a hint of the initial MTU. Even if it is too > big, the application can then adjust the packet size with succeeding > MTU notification (assuming that it also specifies IPV6_RECVPATHMTU). > > 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. > > - 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. 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] --------------------------------------------------------------------
