Re: [Softwires] 4rd Address Mapping - version-01

[Wojciech Dec <[e-mail]>]

On 02/10/2011 02:58, "Qiong" <[e-mail]> wrote:

> Hi Ole and Remi,
> 
>>> > This is my answer to your first (double) question.
>>> > If it is not enough, as suggested below, please explain what you don't
>>> understand.
>> 
>> I specifically do not want a solution that changes forwarding behaviour for
>> _all_ IPv6 packets.
>> e.g. looking at 24 bits in the middle of an IPv6 address is such a change.
>> 
>> Woj> What are you referring to? Routing ³just works² as normal and is non
>> disaggregated because of the CE-index in the prefix. Classification can/is
>> done on a subset of the v6 address, and that is perfectly legit.
>> 
>> I don't understand what requirements you are basing this 'solution' on.
>> if the 4rd / dIVI CE takes (a well known or provisioned) /64 prefix out of
>> the delegated prefix. then why do you need any of that?
>  
> Qiong : I agree that routing lookup for a provisioned /64 prefix would be
> better that extracting certain bits for each IPv6 address in CE. This would
> bring less change to existing routing model.
> 
> Woj> There is no change to the existing destination based routing model. Each
> CE is uniquely addressed by the CE bits in the top /64 ­ ie the CE index is as
> proposed by all the 4rd and divi-pd drafts. The full v4 source address of each
> CE is however also embedded in the interface-id, as per RFC6052. There appears
> to be no cost for this operation, and has the upside of the full v4 info
> visible in the header and allowing source based classification (should one
> want to do that).
> 
> Regards,
> Woj.
> 
> Best wishes
> 
> Qiong 
> 
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
> 
>