Subject: [Softwires] DS-Lite AFTR ICMPv6 handling

From: Arnaud Ongenae <[email-masked]>
Date: Mon, 25 Oct 2010 10:16:52 +0200

Hi all,

I don't know if the following question has already been discussed, but I 
haven't found information on the net.

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.

My question is: What is required from the AFTR element in this situation ?
- Does the "AFTR" needs to drop the packet ?
- Does the "AFTR" needs to convert the ICMPv6 in an ICMPv4 ?
- something else ?

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.

Thank you

-- 
Arnaud Ongenae
Alcatel-Lucent
QA Engineer

ps: do not hesitate to point me to existing discussion,
ps: if I'm in the wrong list please redirect me.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 25 Oct 2010 11:06:39 +0200

In your previous mail you wrote:

=> there is a least one generic RFC about tunneling with a lot of
good things for error handling.

   
   
=> ICMPv6 destination unreachable is only an example. The packet too
big is very interesting (and likely) too.

=> obviously not the best solution (:-) even you can argue ICMPv4
errors are so heavily filtered out than it is just not 'friendly'.

=> 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.

=> 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-masked]

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 :-).