> none of the above document specify what IPv6 MTU to use for these > interfaces. (RFC3056 has a pointer to RFC2893, but RFC2893 has nothing > about IPv6 MTU)
I see these words in RFC 2893 which seem to be relevant to this issue: The IPv6 layer in the encapsulating node can then view a tunnel as a link layer with an MTU equal to the IPv4 path MTU, minus the size of the encapsulating IPv4 header. This is suggesting that the interface MTU for such a tunnel is dynamic by being a function of the IPv4 path MTU across the tunnel. A result of such behavior is that the initial MTU for such a tunnel interface would be the interface MTUs for the underlying physical interface for the tunnel, minus 20 bytes for the IPv4 header. But I take it from your question that you'd like to see a fixed number for the MTU. Is this really necessary? > now, if B transmits packets larger than X, A may drop it as it is > larger than MTU (assuming MRU == MTU), causing blackhole. Such an assumption and the resulting dropping behavior seems like a very bad idea. (Are there such implementations?) If folks make such assumptions I guess we need to make it more clear what "be liberal in what you accept" in the case of tunnels and explain what the "T" stands for in "MTU". But it doesn't follow that we need to pick a fixed MTU number. > also, MTU mismatch could have some impact to PMTUD if A and B are > routers. I don't understand the issue. Care to explain? > we actually have experienced interoperability problem between KAME and > JunOS for configured tunnels, as KAME is using 1280 as MTU and JunOS > is using infinity (so PMTUD does not occur). Do either of then drop received packets that exceed the configured MTU? The way you dscribe it it seems like JunOS doesn't follow the text in section 3.2 in RFC 2893, but that by itself will merely cause inefficient behavior (IPv4 reassembly at the router = tunnel endpoint instead of e2e IPv6 path mtu discovery and IPv6 reassembly at the IPv6 endpoint) and not interoperability problems. > therefore, I propose: > - to specify default IPv6 MTU of RFC2893 tunnel interface be 1280, > in RFC2893bis (so, 6to4 MTU will become 1280). of course operators > can override if they wish to, specifically for configured tunnel case. Seems like overkill. But perhaps I don't understand the details of the problems yet. BTW: Shouldn't we discuss RFC 2893 on the ngtrans list? 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] --------------------------------------------------------------------
