>>>>> On Thu, 09 Nov 2000 01:32:54 +0900,
>>>>> JINMEI Tatuya <[EMAIL PROTECTED]> said:
>> Does the implementors have any preferences between #2 and #3?
>> Doing #3 would require defining a data structure containing an MTU field
>> plus a socketaddr_in6.
>> => by problem with #3 is the path MTU is a property of the path, not
>> of an address, ie. with a routing header the path MTU can be different.
>> I know this is not implemented like that (ie. pMTU are cached by destination
>> address and if someone plays with a routing header one can spuriously
>> change the pMTU :-) but it should then we have to keep the distinction...
> I personally like #3, because it seems the most flexible one (e.g. to
> contain the real "path" including all intermediate nodes - although
> I'm not sure if this kind of stuff is worth implementing despite of
> its complexity). But this will affect existing implementations, so I
> won't insist on this idea. I vote for #3 if pre-implementors of this
> option do not object. (We've not implemented this option yet.)
I've implemented the IPV6_RECVPATHMTU option adopting #3 approach. I
defined a new structure "ip6_mtuinfo" as ancillary data item for
IPV6_PATHMTU as follows:
struct ip6_mtuinfo {
u_int32_t ip6mtu_mtu;
struct sockaddr_in6 ip6mtu_dst;
};
I used the sockaddr_in6 structure for the ip6mtu_dst (not just
in6_addr) in order to support scoped addresses. As Francis pointed
out, the finally destination does not necessarily give complete
information of a "path", but I think it is usually enough in a
practical point of view. We could also add some additional data after
the ip6mtu_dst if we wanted.
By the way, the rfc2292bis draft seems a bit ambiguous on the byte
order of the 32-bit MTU value. Like other fields used in the spec, I
treated the value in the network byte order, but the spec should
clearly specify the byte order.
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]
--------------------------------------------------------------------
