At Sat, 11 May 2013 22:09:49 -0700, Kevin Oberman <rkober...@gmail.com> wrote:
> > > However I'm only able to send IPv6 packets from my host that fit an MTU > > > of 1280 even though I've set the tunnel interface and per-route MTU to > > > 1480, based on the "outer" ethernet connection having an MTU of 1500. > > > Hurricane Electric supports this and I've set the MTU to 1480 on their > > > side as well. [...] > I complained about this at least a couple of years ago and was told by the > developer (I don't recall exactly who any more) that it was right and would > not be changed. I really would love to see this reconsidered before IPv6 > becomes much more popular as it will simply cause confusion, but I, too, > fear that it is a lost cause. What's "this" (to reconsider)? That ping6 fragments outgoing packets at 1280 octets (by default)? Or, more in general whether any outgoing IPv6 packet can initially honor the interface MTU? If it's the former, I personally believe the default behavior makes more sense because IPv6 doesn't have the concept of "don't fragment bit", so any packet/fragment larger than 1280 octets could be dropped at an intermediate router. In theory, we could recover from that situation if that router sent an ICMPv6 packet too big message and the kernel performed path MTU discovery (which in my understanding is not the case for non connected sockets like the one ping6 uses), but even if PTMU discovery worked, some initial echo requests would still be lost. As a user, I wouldn't like to bother to wonder the reason for the packet loss if my main concern is reachability check (that would be my primary purpose for using ping6). The same argument applies to non connected UDP sockets, and, in fact, DNS server implementations behave exactly like ping6 in that sense (fragmenting large DNS responses at 1280 octets), and exactly for that reason. If it's the latter, I thought at least TCP (if not also for other connected sockets) honors the best possible MTU, starting from the MTU of the outgoing interface. If it doesn't, I agree with you; it should be fixed, and I don't think it's a lost cause. --- JINMEI, Tatuya Internet Systems Consortium, Inc. _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
