In your previous mail you wrote: I don't know if the following question has already been discussed, but I haven't found information on the net. => there is a least one generic RFC about tunneling with a lot of good things for error handling.
Consider the following topology: Server ---- AFTR ---- Router ---- B4 ---- host The host communicate with the server and the server reply to the host. There is a DS-Lite tunnel between the "B4" element and the "AFTR" element. Consider a link failure between the "Router" and the "B4". When a packet comes from the server in direction of the host, the "router" generates an ICMPv6 destination unreachable message in direction of the "AFTR" element. => ICMPv6 destination unreachable is only an example. The packet too big is very interesting (and likely) too. My question is: What is required from the AFTR element in this situation ? - Does the "AFTR" needs to drop the packet ? => obviously not the best solution (:-) even you can argue ICMPv4 errors are so heavily filtered out than it is just not 'friendly'. - Does the "AFTR" needs to convert the ICMPv6 in an ICMPv4 ? => this can be done for a class of errors. Note you need an IPv4 address for the source of the ICMPv4 and some linux kernels have a hidden anti-spoofing device which limits what can be use. - something else ? => you can manage soft state for the tunnel and generate directly ICMPv4 errors for next packets which should trigger ICMPv6 errors if they were sent through the tunnel. The great advantage of DS-Lite is that it doesn't have to convert packet from one protocol to another. Converting an ICMPv6 in an ICMPv4 considerably complicate the "AFTR" element. => it is not true: the complicate thing is to translate the packet which is included in ICMP errors and this is true for ICMPv6 and tunneled ICMPv4, so in fact converting some 'interesting' ICMPv6 is not so difficult. Regards [email protected] PS: in ISC AFTR implementation 'packet too big' is handled by soft state (there is a per tunnel MTU) and some unreachables are converted. But there is no proof it is 'friendly', in fact we got many proofs the ICMP based path MTU discovery doesn't work in the real world (so the (in)famous TCP MSS hacking is implemented too :-). _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
