On 5/24/16 6:48 AM, Joe Touch wrote: > While this is a nice goal, it's not viable. In order to provide a viable > IPv6 tunnel, the payload MUST transit IPv6 payloads of at least 1280 > bytes.However, there's no reason to assume that the UDP/IPv6 tunnel can > support 1280 + UDP + IPv6. So you have only one choice - you can deploy > these tunnels only where you can guarantee paths that support 1280+8+40 > byte payloads over the tunnel path. However, there's no way to ensure > that solely by assuming IPv6 along that path. > > I.e., you MUST support source fragmentation at the ingress at the outer > IPv6 layer (because UDP doesn't have support for fragmentation and > reassembly). If you make this requirement, you can handle IPv6 over the > tunnel.
Yeah I don't support it for this reason. getting IP fragments back together in the same place a reassembled is hard is in some cases especially when you hash. (see frag drop) given alternatives that better address such situations it seems hard to justify. > IPv4 will work over a UDP/IPv6 tunnel fairly easily, even assuming the > common typical IPv4 MTU (576, even though that's really the reassembled > MTU, not the path MTU). > > IPv4 over IPv4 is much more difficult, and not only requires > fragmentation at the outer packet but also additional reassembly > requirements at the egress above and beyond the IPv4 minimums. > >> >> >> - signalling support (e.g., to test whether a tunnel is up or >> >> to measure MTUs) >> >> >> >> [Xiaohu] It said in the draft that >> >> “it is strongly RECOMMENDED that Path MTU Discovery [RFC1191 >> <https://tools.ietf.org/html/rfc1191>] [RFC1981 >> <https://tools.ietf.org/html/rfc1981>] >> >> is used to prevent or minimize fragmentation.” >> >> >> >> >> >> - support for robust ID fields (related to fragmentation, >> >> e.g., to overcome the limits of IPv4 ID as per RFC 6864) >> >> in other words, the PMTUD signaling is recommended to be supported. >> > > PMTUD is a recipe for black-holing. PLPMTUD is preferred for many reasons. > > However, PLPMTUD only ensures proper discovery of the tunnel MTU. It > does not describe how the ICMPs inside the tunnel relate to those that > are generated by the ingress. > > Again, for all of these, see draft-ietf-intarea-tunnels > > Joe > >> >> >> [Xiaohu] Is it enough to add a sentence like “to overcome the >> limits of IPv4 ID as per RFC 6864 when performing fragmentation on >> E-IP IPv4 packets, the specifications as described in RFC6864 MUST >> be followed.”? >> >> >> >> Best regards, >> >> Xiaohu >> >> >> >> >> >> I’m wondering whether those issues are specific to IP-in-UDP or >> not. In other words, are those issue also applicable to other >> X-in-UDP approaches (where X could be LISP, TRILL, VXLAN, >> VXLAN-GPE, GENEVE, GUE, NSH or MPLS)? >> >> >> That set of issues applies to all IP-in-(xlist), where xlist includes >> IP again. The issue is what IP expects and what the tunnel exports. >> >> The other items I pointed out are specific to transport-in-UDP or this >> specific approach. >> >> Joe >> > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
