Hi Steinar, > -----Original Message----- > From: sth...@nethelp.no [mailto:sth...@nethelp.no] > Sent: Monday, July 01, 2013 9:32 AM > To: Templin, Fred L > Cc: otr...@employees.org; ipv6@ietf.org > Subject: Re: draft-bonica-6man-frag-deprecate > > > > 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*.
Tunnels within tunnels are a fact of life in real networks today. Tunnels are used for many things other than transition, including security, mobility, routing control, etc. and deployment of IPv6 would sustain rather than reverse that trend. Plus, it is not just about tunnels within tunnels but also native links that configure a small MTU. Back to tunnels within tunnels, there are *many* examples that would prove my point but I will give just one. A mobile node configures a 1280 MTU tunnel to a "home agent" and keeps the tunnel alive as it moves around. A second mobile node comes onto the link provided by the first mobile, and also configures a 1280 MTU tunnel. The second mobile node emits a 1280 packet which (when tunneled) becomes 1320. The first mobile node drops the packet and returns "Packet Too Big". In response, the second mobile has two choices: 1) fragment, or 2) shut down the tunnel. > I run my IPv6 customer links with MTU 1500. Good, but I would like to see you push that to 8KB. > > > 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. Reassembly is also required by any node that configures an RFC2473 egress tunnel endpoint. > If I were to vote with my wallet, reassembly at 100G and similar line > rates is *way* down on my requirements list. Two things about this is that 1) the location of the tunnel egress should be carefully selected, and 2) the SEAL tunnel egress can use RFC4821-style probing to tune out fragmentation when the path supports a sufficiently large MTU. SEAL is not about steady-state, use-all-the-time fragmentation; it is about doing what needs to be done while being as efficient as possible. > Requiring L4 info in the first fragment SEAL does that. > (*and* in each subsequent fragment) SEAL doesn't do that unless some new IPv6 extension header was defined. Then, SEAL would use the extension header the same as any other IPv6 protocol. > is far more important. Good; let's make it happen. Thanks - Fred fred.l.temp...@boeing.com > Steinar Haug, AS 2116 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
