> > as far as I can see the setting IPv6 minimum MTU to 1280, which gives > > ample room for > > nested tunnels works as designed. > > But, what would that look like in real life? The first tunnel > (T1) would have to set a 1280 MTU so that its tunneled packets > would emerge as 1320 bytes. Then, the next tunnel (T2) would > have to set a 1320 MTU so its tunneled packets would emerge as > 1360. Then the next tunnel (T3) would have to set a 1360 MTU > so that its tunneled packets would emerge as 1400, etc. until > we run out of available MTU. The question is, how can those > tunnels be so carefully coordinated so that the nesting is > nailed down enough so that we will never have an MTU infraction?
I strongly disagree that we should make provisions for umpteen levels of tunneling. In my network, native IPv6 with no tunnels is clearly the goal. Anything more than one level of tunneling is a *failure*. I run my IPv6 customer links with MTU 1500. > > the vendor I'm most familiar with does not do this in hardware. sure, > > you can get reassembly, but at an order of one or two magnitudes less. > > if anyone know of platforms doing IPv6 fragment reassembly at line rate > > for 10G or 100G interfaces I'll stand corrected. ;-) > > for now reassembly in the network is not realistic. > > Reassembly is required by RFC2460, RFC2473 and I think others > have also been mentioned. To support tunnels, and especially > tunnels within tunnels, it needs to be there. Reassembly is required by end systems, which typically don't run at 100G. If I were to vote with my wallet, reassembly at 100G and similar line rates is *way* down on my requirements list. Requiring L4 info in the first fragment (*and* in each subsequent fragment) is far more important. Steinar Haug, AS 2116 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
