Re: [v6ops] BIH vs 464XLAT

On 3/27/12 12:59 , Cameron Byrne wrote:
> On Tue, Mar 27, 2012 at 3:32 AM, Simon Perreault
> <simon.perreault@viagenie.ca> wrote:
>> I was thinking that bump-in-the-host (BIH) could be used for something like
>> 464XLAT, and after some questioning I was pointed to the following extract from
>> RFC6535:
>>
>>   The IETF recommends using solutions based on dual stack or tunneling
>>   for IPv6 transition and specifically recommends against deployments
>>   utilizing double protocol translation.  Use of BIH together with a
>>   NAT64 is NOT RECOMMENDED [RFC6180].
>>
> 
> FYI -- i fought this restriction in BEHAVE.  Lost.

For whatever it's worth undesirable things are still sometime necessary.

>> Wouldn't this anti-recommendation also apply to 464XLAT?
>>
>> Did the consensus on double translation change? 
>>
>  
> I have to assume so since Softwires has mountain of work that is
> double translation, and in fact MAP-T is triple translation, NAT4464

Without it you're kind stuck beyond a certain point. in the 464xlat
case, it's seems like that point is where you've been handed a v4
literal and you have to do something with it other than fail.

> It is perhaps the situation that BIH came a few months too soon for
> the IESG to be responsive to the realistic need of double translation.
> 
> That said, 464XLAT seldom uses double translation in practice when
> used together with DNS64
> 
> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.3
> 
> Double translation is only invoked in the case when NAT64/DNS64 alone
> would result in failure of communication due to IPv4-only sockets or
> IPv4 literals.
> 
> So, the tradeoff is double translation or communication failure.
> Subscribers who don't know what IP is like the double translation
> solution that loads Skype.
> 
> There is also the fact the IESG passed this
> http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15
> ... which is clearly a tip of the hat to NAT444.  It would be
> unconscionable for the IESG to support NAT444 and not support
> something that required IPv6 and enabled IPv6 like 464XLAT
> 
> CB
> 
>> Simon
>> --
>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>> STUN/TURN server               --> http://numb.viagenie.ca
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 