On 5/31/2016 7:43 PM, Xuxiaohu wrote: > In the above case, there are three FEASIBLE ways: Let's take these in order then:
> 1) Configure the transit core to carry an MTU at least large enough to > accommodate the added encapsulation headers. Note that this is the dominant > and mature choice in most MPLS networks; So you are deploying IPv6 over an IPv6 tunnel. Even without UDP, you still need 40 bytes for the encapsulation header. So in order to deploy a compliant IPv6 1280-byte MTU tunnel, you need to use a core that you know can transit IPv6 packets that are 1320 bytes. Unless you examine every physical link to ensure that the technology supports a larger MTU, you're stuck assuming that your IPv6 equipment can only guarantee 1280. Which means you can't know this will work. Even if you do know this for a physical path, every path you *think* is physical will be virtualized at some point, and at some point the number of layers of tunneling will end up eating the whole of any "headroom" you engineer. > 2) Fragment the packet before encapsulation if allowed; That covers only IPv4 with DF=0. It won't cover DF=1 or IPv6. > 3) Drop it if inner fragmentation is not allowed. You've now black-holed your network, all because you didn't want to use the 1500-byte fragmentation and reassembly that every IPv6 source and sink are already required to support (per RFC2460). Note that every tunnel ingress is a IPv6 source and every IPv6 egress is an IPv6 sink, so if you claim that many vendors don't support this, you're just pointing out that they don't satisfy existing IPv6 requirements. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
