Re: [Softwires] Internal routing based on the V octet can be easy

[Ole Troan <[e-mail]>]

Remi,

>>>> The 4rd function examines ALL packets that reach the CE.
>>>> It processes all those that have V in their destination addresses, and only those.
>>>> 
>>> This is a big change to the current forwarding behavior of CPE devices, doable, but quite different from, for example, some encapsulation/decapsulation implementations.
>> 
>> +1.
>> doable in theory, but I share your concerns.
> 
> Well, it wasn't quite right to say, as I did, "the 4rd function examines ALL packets that reach the CE".
> More exactly, with existing kernel architectures, the 4rd function should only see packets that have the V octet in their IPv6 destinations.
> 
> With Linux, it is feasible AFAIK as follows:
> - Before submitting a received packet to the routing function, it is submitted to the Netfilter pre-routing function. 
> - Netfilter adds to the packet a mark, specific of 4rd, if it has the V  octet (mask + value).
> - The routing function, duly configured, then sends packets that have this mark to the 4rd-function interface. 
> With BSD, the PF packet filter has a role similar to that of Netfilter.
> (Thanks to Francis Dupont for providing this information, hopefully not damaged by my transcription.)  
> 
> Useful capabilities of 4rd solutions SHOUDN'T therefore be abandoned for the unjustified fear that internal routing based on the V octet might be difficult.

regardless of implementation, your proposal does add extra processing cycles for _all_ IPv6 packets to the site.

cheers,
Ole