Re: [v6ops] discussion of transition technologies

[Ole Troan <[e-mail]>]

>> Restated. Close?
>> 
>>> On Jan 19, 2018, at 4:22 PM, Fred Baker <[e-mail]>
>>> wrote:
>>> 
>>> At least part of this commentary wound up in
>>> https://tools.ietf.org/html/rfc6180
>>>    Guidelines for Using IPv6 Transition Mechanisms during IPv6
>>>    Deployment. J. Arkko, F. Baker. May 2011. (Format: TXT=49679 bytes)
>>>    (Status: INFORMATIONAL) (DOI: 10.17487/RFC6180)
>>> 
>>> I think Jari's view in that was that we needed to rein in the plethora
>>> of transition technologies, and "if one has to translate, can we please
>>> do so above the IP layer?" I added SIIT/NAT64, because I think there is
>>> market relevance including several deployments of various kinds; any
>>> mention of MAP-T or 464XLAT is SIIT/NAT64. But the basic recommendation
>>> of RFC 6180 was:
>>> - first choice, deploy native IPv6 - for scenarios in which IPv6
>>> islands are connected across IPv4 space, use dslite (a tunneling design).
>>> - for scenarios in which IPv4 islands are connected across IPv6 space,
>>> use dslite (a tunneling design).
> 
> You would argue that 464xlat, MAP-E, and MAP-T are simply implementations
> of SIIT/NAT64 (which you do, below), but it seems to me that they are also
> used in these scenarios. In some cases the “island” is but a single
> application on a mobile phone.
> 

MAP-E is not an implementation of SIIT/NAT64.

> For large networks, like access ISPs, mobile networks, and maybe campus
> networks, the advice might be finer-grained:
> - for scenarios in which IPv4 islands (e.g., households, a mobile phone,
> or other stub network), consider:
> — If you need home gateway support right now, use DS-Lite
> — If you are using CGN anyway (such as mobile networks), consider
> 464xlat, which allows native IPv6 end to end when possible, native IPv6
> end-to-translation-edge when IPv4 is needed to reach the other end, and
> CLAT on the device or IPv4 edge when the local application or device
> requires it.
> — If you can pressure or wait for home gateway vendors for MAP support
> and would prefer stateless BRs (probably more scalable/cheaper than
> stateful DS-Lite AFTR), use MAP. (One more decision branch between MAP-T
> and MAP-E, but they’re pretty close).
> 
> 
>> - for scenarios in which IPv6 islands are connected across IPv4 space,
>> use 6rd (a tunneling design).
>>> - for scenarios in which IPv6 systems have to talk with IPv4 systems,
>>> translate. Please consider doing so above the IP layer.
>>> 
>>> I would argue that 464XLAT, MAP-E, and MAP-T are "services in which an
>>> ISP might use SIIT/NAT64 in its network", and are therefore not
>>> fundamental transition technologies as much as ISP services built using
>>> them.
>>> 
>>> I think I might also argue that the market has more or less followed
>>> that advice. Your spreadsheet seems to suggest that.
>> 
>> The interesting thing is that 6rd, which is a way of appearing to have an
>> IPv6 network without actually having one, is not what one might call
>> "prevalent". It has in fact been used for *transition*, in places like
>> Free - which used to connect IPv6 customers using 6rd and (I understand)
>> has recently announced native IPv6 deployment. The places I know that
>> have used it used it for a while and then have gone native.
>> 
>> Would you agree with that?
> 
> I would; that is my perception. MHO is that 6rd has had its day, and while
> I don’t think it needs to be deprecated, I haven’t heard any scenarios in
> the past several years where it solves an actual problem.

Apart from giving millions of users IPv6 access?

Ole