[cancellato]
Grazie degli ottimi insight, sei veramente molto disponibile!
Premetto che potrei non aver ben chiaro come funziona 6rd, quindi mi studierò la documentazione di come funziona il protocollo. Nel frattempo, la mia comprensione attuale è questa.
Ipotizziamo che io abbia una videocamera e un router.
Il router non ha connettività IPV6, quindi attiva un tunnel 6rd verso un border relay. In questa maniera si crea sul router un'interfaccia che assume un prefisso IPV6, che verrà utilizzato anche per dare indirizzi alla videocamera.
Il traffico fra il router e il border relay avviene in IPV4: i pacchetti scambiati contengono pacchetti IPV6. Il border relay riceve quindi questi pacchetti incapsulati, li "decapsula" e vede i pacchetti IPV6, che routerà verso le rispettive destinazioni. Se qualcuno si vuole collegare alla mia videocamera (che, come detto prima, ha un indirizzo IP6), invierà un pacchetto avente tale indirizzo come destinazione. Dal momento che il border relay 6rd annuncia il mio prefisso IPV6, questi pacchetti arriveranno al border relay, che li incapsulerà in un pacchetto IPV4, che arriverà al mio router, che li decapsulerà in pacchetti IP6, forwardandoli alla videocamera.
A livello di filtraggio, io semplicemente bloccherei le richieste di attivazione del tunnel agli IPV4 non abilitati (come puoi fare per bloccare il protocollo ICMP), in maniera tale che questi non possano ottenere il prefisso (a meno che ottenere il prefisso non richieda di comunicare con il border relay). Quindi sì, farei conntrack, e so quanto può essere dispendioso a livello di risorse.
Nel caso opposto, invece, quando arriva nel border relay un pacchetto destinato a un host della rete interna IP6, basterebbe analizzare l'indirizzo IP6 per ricavare l'IP4 cui inoltrare il pacchetto incapsulato. Questo dovrebbe essere fatto sempre, altrimenti come potrebbe il border relay sapere su quale tunnel inviarlo?
