Subject: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 09 Jun 2018 13:58:17 +0200

Hi all,

As a result of this week email exchange with Barbara, she mention about the need to make sure, that any transition mechanism is enabled or not by the CE, depending on the operator wish, which I agree.

It seems to me that the best way for doing so is by ensuring that RFC8026 is used, so the S46 DHCPv6 option tells the CE what mechanisms (if any) that the operator supports, and we have already text to say that in the document. However, this option today only supports DS-Lite, lw4o6 and MAP-E/T.

So, my question to the WG (and the chairs):

It is possible (and the WG agree on that), to update RFC8026 (by means of a short "Update of RFC8026 for 464XLAT Support" section in draft-ietf-v6ops-transition-ipv4aas) and instruct IANA to add a new code for 464XLAT? 

I think this will be the cleaner and simpler way to do this.

A more complex alternative will be to "force" the CE to actually "test" for available NSP/WKP for the NAT64, using RFC7050 and RFC7225 if PCP is being used.

Regards,
Jordi

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Fred Baker <[email-masked]>
Date: Sat, 9 Jun 2018 08:24:02 -0700

You might take a look at https://github.com/LACNIC/natmeter for ideas.

> On Jun 9, 2018, at 4:58 AM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Sat, 9 Jun 2018 20:40:15 -0700

I would ask one question. When the operator is using this in a managed service, of course the operator should be in control of it. Are we precluding using the CE in other than a managed service? I should think that in cases in which it is *not* a managed service, the owner of the CE would be in control
If it.

Sent using a machine that autocorrects in interesting ways...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 10 Jun 2018 10:23:13 +0200

Yeah, I know this. Alejandro, from LACNIC is measuring NAT44 and NAT66. Probably it could be adapted to detect NAT64, but I want to make it much simpler, and there is one more detail I've not mention in my email ...

We may have an ISP having NAT64, but NOT wanting some customers to use it (at least not by default), so with a DHCP option we facilitate that, as you may have different DHCP options for different customers.

Regards,
Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 10 Jun 2018 10:26:21 +0200

You're right, and that's why we also will include a new requirement (this was also part of the email exchange with Barbara), in order to make sure that is possible to turn on/off the mechanisms with a GUI or CLI, whatever is available.

This is already today an option with most of the CEs in the market for other transition mechanisms, and this was not part of RFC7084, but here it is much better we make it explicit.

Regards,
Jordi

---

From: Richard Patterson <[email-masked]>
Date: Sun, 10 Jun 2018 09:45:27 +0100

There are regulated markets that require providers to allow for BYO
devices.  Whilst BYO CE on an IPv4aaS network is probably a grey area,
DHCP signalling would allow for a non-managed CE that supports the
transition method to work without manual user configuration.

I'm for this approach, to bring 464XLAT inline with the other methods.

-Richard

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 10 Jun 2018 11:02:52 +0200

Thanks Richard, I'm guessing nobody will be against this, but I needed to ask, as this work is a WG item.

Just to clarify my (procedural) question to the chairs or even AD. Long explanation, but the question deserves it.

RFC8026, unless I recall it incorrectly, was developed in softwires WG and of course, being DHCPv6 options, was reviewed in DHCPv6 WG. The "long" title of the document mention "softwire" because the actual options are mechanisms developed within softwires WG (while 464XLAT was not).

There are several mentions of softwires in the document, but my reading is that the "softwire" word across the document is only "descriptive" not "prescriptive".

I mean that the S46 priority option could be also used for something with is not "softwires". In fact, there is also an option (DHCPv4 over DHCPv6) which was developed within DHCPv6 WG and if you look into that document (RFC7341), it has no a single mention of "softwire" ...

In other words. We could make an RFC8026-bis to:
1) Remove the mention of softwires and make it more generic for transition DHCPv6 options
2) Add an option to support 464XLAT (and may be others)

However, that may be a much slower path, and may be conflictive, because if the work was done in Softwire WG, they may not like that now the document is not used "only" for Softwires ...

So, the alternative I'm asking is, from a procedural point of view:
Can v6ops WG, just include an update in draft-ietf-v6ops-transition-ipv4aas to add the option code for 464XLAT?

I guess also Med and Ian, the original authors, may want to say something. Clearly my intent is not to "break" in any way the actual document (on the contrary, we are extending the usage and I guess this may be done by future documents as well) and I don't think what I'm suggesting does it.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Richard Patterson <[email-masked]>
Fecha: domingo, 10 de junio de 2018, 10:46
Para: "[email-masked] list" <[email-masked]>
CC: <jordi.palet=[email-masked]>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

    
    -Richard

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 10 Jun 2018 20:16:18 +0900

On Sun, Jun 10, 2018 at 6:03 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> Can v6ops WG, just include an update in
> draft-ietf-v6ops-transition-ipv4aas to add the option code for 464XLAT?
>

ISTR that the last time this was discussed in v6ops there was substantial
opposition to a DHCPv6 option for 464xlat.

To be honest, as a wireline ISP I don't see why you'd want to do 464xlat at
all. It's pretty much the worst of all the IPv4-over-IPv6 mechanisms. Its
only advantage is that it's easy to deploy on mobile networks.

If you do want to do 464xlat, it's much better to do discovery using RFC
7050. That way, hosts behind the CPE can discover the NAT64 by themselves,
and do smart things like AAAA synthesis and DNSSEC, and also provide input
to their happy eyeballs mechanisms that IPv4 is not native and thus may be
less reliable.

---

From: Alejandro Acosta <[email-masked]>
Date: Sun, 10 Jun 2018 08:42:43 -0400

Hello,

  Thanks for bringing the Natmeter project up.

  You are right, we not measuring -yet- DNS64..., thanks for the idea,
hope we come up with a clue in how to do this :-)..., just added to our
radar. As a final comment we do have few more things about 1) CGN and 2)
detecting prefix 192.0.0.0/29 on the client. 

  Willing to share the info.

Alejandro,

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 10 Jun 2018 15:07:05 +0200

Hi Lorenzo,

There are now many ISPs that have 464XLAT in the celular, and they will like to use the same mechanism for the wireline. This is very convenient, if you are using also an LTE interface on a wireline router as a backup of the wired link.

I don’t agree is the worst IPv4-in-IPv6 mechanism, in fact it is the most successful one, thanks in part to Android and Windows having implemented it.

The point is not to discover the NAT64, this is easily done, as you indicated by using RFC7050 or even with PCP. This is already described in the document.

The point is the ISP to be able to turn on or off each mechanism (464XLAT, MAP, DS-Lite, etc.), and this is easily done if all them share the same DHCP option.

I will like to understand if we still have such opposition, why.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: domingo, 10 de junio de 2018, 13:17
Para: <jordi.palet=[email-masked]>
CC: "[email-masked] WG" <[email-masked]>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

On Sun, Jun 10, 2018 at 6:03 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

ISTR that the last time this was discussed in v6ops there was substantial opposition to a DHCPv6 option for 464xlat.

To be honest, as a wireline ISP I don't see why you'd want to do 464xlat at all. It's pretty much the worst of all the IPv4-over-IPv6 mechanisms. Its only advantage is that it's easy to deploy on mobile networks.

If you do want to do 464xlat, it's much better to do discovery using RFC 7050. That way, hosts behind the CPE can discover the NAT64 by themselves, and do smart things like AAAA synthesis and DNSSEC, and also provide input to their happy eyeballs mechanisms that IPv4 is not native and thus may be less reliable.

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 11 Jun 2018 21:37:07 +0900

On Sun, Jun 10, 2018 at 10:07 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> There are now many ISPs that have 464XLAT in the celular, and they will
> like to use the same mechanism for the wireline. This is very convenient,
> if you are using also an LTE interface on a wireline router as a backup of
> the wired link.
>

Then they can use RFC 7050, which already works today both in their
networks and in client implementations.

> I don’t agree is the worst IPv4-in-IPv6 mechanism, in fact it is the most
> successful one, thanks in part to Android and Windows having implemented it.
>

It's successful in mobile. It isn't successful in wireline, and IMO it does
not deserve to be since there are much better transition mechanisms.

> The point is the ISP to be able to turn on or off each mechanism (464XLAT,
> MAP, DS-Lite, etc.), and this is easily done if all them share the same
> DHCP option.
>

The ISP can easily turn off 464xlat via DHCPv6 today: just provide DNS
servers that don't do DNS64 translation.

> I will like to understand if we still have such opposition, why.

Because it requires additional standards work, engineering work and
implementation complexity to achieve something that is already possible
today using RFC 7050.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 11 Jun 2018 14:55:26 +0200

Then they can use RFC 7050, which already works today both in their networks and in client implementations.

It's successful in mobile. It isn't successful in wireline, and IMO it does not deserve to be since there are much better transition mechanisms.

Each network is a different case, and in many cases 464XLAT is much better than any other mechanism in wireline, WISP, etc. Every ISP has their own view/decision on this. We just need to provide the tools to make it feasible.

The ISP can easily turn off 464xlat via DHCPv6 today: just provide DNS servers that don't do DNS64 translation.

No, that is not a solution, at least not for the scope of what is needed in this document.

You can run 464XLAT without DNS64, so to avoid breaking DNSSEC, so that will not work.

Also, users tend to change their DNS servers, so once more this doesn’t work.

We need something very simple to explicitly tell the CE “you MUST ENABLE/DISABLE the CLAT”.

Fortunately this is already there: RFC8026, we just need a new option code.

Because it requires additional standards work, engineering work and implementation complexity to achieve something that is already possible today using RFC 7050.

I believe you’re misunderstanding what is needed here. I’m not talking about a new DHCPv6 way to “find” the NAT64 prefix or server. This is already done by RFC7050 or RFC7225 (PCP). 

It is not a NEW DHCPv6 protocol. Is a new option code in an existing protocol (RFC8026). There is nothing new to develop. We just need to tell IANA “in addition to the already defined option codes for DS-LITE, MAP, etc., define one for 464XLAT”.

What we have now is:

+-------------+--------------------+-----------+

| Option Code |   S46 Mechanism    | Reference |

+-------------+--------------------+-----------+

|      64     |      DS-Lite       | [RFC6334] |

|      88     | DHCPv4 over DHCPv6 | [RFC7341] |

|      94     |       MAP-E        | [RFC7598] |

|      95     |       MAP-T        | [RFC7598] |

|      96     | Lightweight 4over6 | [RFC7598] |

+-------------+--------------------+-----------+

And what we need is to add a code for 464XLAT, so it will become:

+-------------+--------------------+-----------+

| Option Code |   S46 Mechanism    | Reference |

+-------------+--------------------+-----------+

|      64     |      DS-Lite       | [RFC6334] |

|      88     | DHCPv4 over DHCPv6 | [RFC7341] |

|      94     |       MAP-E        | [RFC7598] |

|      95     |       MAP-T        | [RFC7598] |

|      96     | Lightweight 4over6 | [RFC7598] |

|      xy     |      464XLAT       | [RFC6877] |

+-------------+--------------------+-----------+

I believe this is a very frequent usage of new option codes, for existing protocols, via the IANA section.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 11 Jun 2018 15:08:00 +0200

>    I believe you're misunderstanding what is needed here. I'm not
>    talking about a new DHCPv6 way to "find" the NAT64 prefix or
>    server. This is already done by RFC7050 or RFC7225 (PCP).

If you can detect the presence of NAT64 using either RFC7050 or RFC7225 then
why do you need a separate DHCPv6 option?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 11 Jun 2018 15:15:18 +0200

Hi Philip,

The point is not to detect the NAT64, is to tell the CE "use it or not".

You may have a network with some customers that you want to use 464XLAT, others only IPv6, others dual-stack.

If we use a detection mechanism based in RFC7050 and RFC7225, the CE must try both. Even more, if in the future there is another way defined for the NAT64, the CE also need to try that.

But the worst is that you're forcing all the customers the same way. This is what it was discussed a few days ago. The ISP want to have different customers using different transition mechanisms, because he may be in the middle of a transition, or the customers have different "properties", etc., and we need to allow it.

Again, is not a new DHCP option. Is a new "option code" for the RFC8026. Not a new "DHCP" mechanism to develop.

Regards,
Jordi

---

From: Philip Homburg <[email-masked]>
Date: Mon, 11 Jun 2018 15:47:56 +0200

> You may have a network with some customers that you want to use
> 464XLAT, others only IPv6, others dual-stack.
> 
> If we use a detection mechanism based in RFC7050 and RFC7225, the
> CE must try both. Even more, if in the future there is another way
> defined for the NAT64, the CE also need to try that.

A CPE already has to have code for both RFC7050 and RFC7225 because it still
has to find the translation prefix.

Your DHCPv6 code point doesn't tell the CPE which protocol to use. Worse, you
could send the prefix directly in DHCPv6 avoiding the need to run RFC7050 or
RFC7225 in the first place.

Note that there are multiple ways to have per customer DNS resolvers settings.
One option is to vary the addresses of the DNS resolvers assigned to a
particular link. Another is the use of ACLs in a DNS resolver to give
different views to different devices.

So the drawback of your proposal is that everybody (both CPE vendors and
operators) has to implement the DHCPv6 option, only for the benefit of those
operators that want to mix and match customers without resorting to other
mechanisms.

Personally I think that if you would make it mandatory for a CPE to issue a
DHCPv6 request to find out about NAT64, then at least return the prefix as
well.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 11 Jun 2018 16:05:33 +0200

Yes, it tells the CE which ones are available. See section 1.4/1.5 of RFC8026. The operator code what transition mechanism (even several ones if available and in order of preference), in the S46 priority option. The CE then uses the first one that match with the list of transition mechanisms available in the CE.

Right, but again, you're assuming that in addition to NAT64, DNS64 is being used, which is not necessarily the case for 464XLAT (in order to avoid breaking DNSSEC). You're also missing the point that the customer may have changed the DNS, so this doesn't work in that case.

CE vendors will implement this anyway, if they want to follow this document and support other mechanism (not just for 464XLAT, but for the others). So actually, by making a single mechanism (RFC8026) to allow to sort out what are the transition mechanism to be used, it is much simpler. Operators only will need to use that parameter (not a new development, is only a parameter in the DHCP server config if it supports already RFC8026 for the other mechanisms).

This was proposed, a few times in int-area, but people don't like "new" DHCP protocols, because they said that it can be done with RFC7050 or RFC7225. I don't agree with that (so I will agree with you and that was my contribution to https://datatracker.ietf.org/meeting/98/materials/slides-98-intarea-dhcpv6-options-for-discovery-nat64-prefixes-00), but anyway going back to that way and discussing for years, means meanwhile, we will need a more complex mechanism instead of defining a new option code for an existing protocol (RFC8026). This is something that is being done, I believe, from time to time in IETF documents.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 11 Jun 2018 18:36:56 +0200

>Right, but again, you're assuming that in addition to NAT64, DNS64 is being us
>ed, which is not necessarily the case for 464XLAT (in order to avoid breaking 
>DNSSEC). You're also missing the point that the customer may have changed the 
>DNS, so this doesn't work in that case.

Thinking about this a bit more, not so much DNSSEC, but how DNS64 can break
things.

It is safe to assume that DNS64 will be used only in combination with NAT64.
I.e., if an operator wants to provide a CPE with dual stack or any other
transition mechanism, there won't be DNS64.

This means that if a CPE finds DNS64, then it can safely assume that there is
NAT64. No need for a DHCP option.

I guess that if a CPE requests a PCP Server Option using DHCPv6, then it
would also make sense to request the S46 Priority Option as well. But only
in that case.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 11 Jun 2018 19:15:21 +0200

I see your point, but what an operator need is a "100% sure" way to make sure that they can tell the CPE to not use a specific transition mechanism (which for the other mechanisms we have with RFC8026).

So, assuming that DNS64 is only there if combined with NAT64 is not "safe 100%" because if using CLAT, you can avoid having a DNS64 (this is the one that breaks DNSSEC, in case I wrote it incorrectly before).

But if the user changed the DNS in the CPE (which is quite common), there will not be DNS64 and still may be the ISP want to have the CLAT running, because is using that for the IPv4 service for that particular customer.

If you agree that the CPE may request a PCP option, etc., then request the S46, I think you are in agreement that we need the S46 priority option codes for all the mechanism that we are asking to be supported by the CPE, right?

Regards,
Jordi

---

From: Philip Homburg <[email-masked]>
Date: Tue, 12 Jun 2018 11:53:13 +0200

> I see your point, but
> what an operator need is a "100% sure" way to make sure that they
> can tell the CPE to not use a specific transition mechanism (which
> for the other mechanisms we have with RFC8026).
> 
> So, assuming that DNS64 is only there if combined with NAT64 is
> not "safe 100%" because if using CLAT, you can avoid having a DNS64
> (this is the one that breaks DNSSEC, in case I wrote it incorrectly
> before).

I'm saying that if an operator uses DNS64 to signal the presence of NAT64,
then that is a reliable signal that doesn't need an additional DHCP option.

So if is safe for a CPE to just do RFC7050, because if DNS64 is detected,
you can be sure that the operator wants the CPE to use NAT64.

> But if the user changed the DNS in the CPE (which is quite common),
> there will not be DNS64 and still may be the ISP want to have the
> CLAT running, because is using that for the IPv4 service for that
> particular customer.

Yeah, what if the user changes settings? Maybe the CPE has a way to force 
NAT64 on. What do you do then? All bets are off when users start changing
settings.

In the context of RFC7050, the CPE can opt to use the original resolvers
provided by upstream to figure out the translation prefix.

Note that if the CPE uses resolvers configured by the user for RFC7050, then
is it quite possible that the translation prefix is not discovered (for example
if the user configures a well known public resolver). Or worse, 
the user may configure a DNS64 resolver that uses a different prefix.

> If you agree that the CPE may request a PCP option, etc., then
> request the S46, I think you are in agreement that we need the S46
> priority option codes for all the mechanism that we are asking to
> be supported by the CPE, right?

To the extent that RFC8026 is incomplete, that should be fixed. However as
Section 2.2 describes, what S46 offers can be done already be done by the
DHCPv6 server. So S46 just provides a relative priority of different
mechanisms, not an on/off switch for NAT64.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 12 Jun 2018 19:12:44 +0900

> You can run 464XLAT without DNS64, so to avoid breaking DNSSEC, so that

If you don't use DNS64 you can't use 464xlat at all, because you can't
communicate the plat prefix to the clat.

Also, users tend to change their DNS servers, so once more this doesn’t
> work.

Per the above: if the users change the DNS servers, 464xlat will stop
working regardless of what the ISP says.

> I believe you’re misunderstanding what is needed here. I’m not talking
> about a new DHCPv6 way to “find” the NAT64 prefix or server. This is
> already done by RFC7050 or RFC7225 (PCP).
>
> It is not a NEW DHCPv6 protocol. Is a new option code in an existing
> protocol (RFC8026). There is nothing new to develop. We just need to tell
> IANA “in addition to the already defined option codes for DS-LITE, MAP,
> etc., define one for 464XLAT”.
>

I still don't see a use case for this. If an operator uses 464xlat, they
must use RFC 7050 to provision it because there is no other mechanism.
Additionally, if the user changes the DNS server to a non-DNS64 server,
464xlat stops working, and if the user changes the DNS server to a DNS64
server that doesn't hand out the operator's NAT64 prefix, 464xlat stops
working or only works suboptimally. There is nothing the operator can do
about this except accept the breakage or prevent the user from changing the
DNS server.

Therefore, I think the following covers all cases:

   1. If the operator wants to enable 464xlat: they should hand out a DNS64
   to the CPE.
   2. If the operator wants to disable 464xlat: they should NOT hand out a
   DNS64 to the CPE.
   3. If the operator uses 464xlat, they should not allow the user to
   change the DNS server.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 12 Jun 2018 19:13:53 +0900

On Tue, Jun 12, 2018 at 2:15 AM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> But if the user changed the DNS in the CPE (which is quite common), there
> will not be DNS64 and still may be the ISP want to have the CLAT running,
> because is using that for the IPv4 service for that particular customer.
>

You can't use 464xlat without DNS64 as there is no way to configure the
plat prefix.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 12 Jun 2018 12:40:22 +0200

Hi Lorenzo,

You don’t need RFC7050 neither DNS64, you can use PCP (RFC7225) to tell the CLAT the NAT64 prefix. It also provides additional advantages to the operator to control many related aspects (see section 3 of RFC7225).

1.       If the operator wants to enable 464xlat: they should hand out a DNS64 to the CPE.

2.       If the operator wants to disable 464xlat: they should NOT hand out a DNS64 to the CPE.

This doesn’t work, because the operator may be using RFC7225 instead of RFC7050. You need to try both in that case, and you aren’t providing a “priority” to a possible list of mechanisms, which is what RFC8026 does.

3.       If the operator uses 464xlat, they should not allow the user to change the DNS server.

Let’s be realistic. You can’t “force” the customer to avoid changing the DNS … So that means that if instead of enforcing DNS64 mechanism (RFC7050) to communicate the NAT64 prefix, you use an alternative way such at RFC7225, it becomes safer to unwanted user changes.

Regards,

Jordi

De: Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: martes, 12 de junio de 2018, 12:13
Para: <[email-masked]>
CC: "[email-masked] WG" <[email-masked]>
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

On Mon, Jun 11, 2018 at 9:55 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

If you don't use DNS64 you can't use 464xlat at all, because you can't communicate the plat prefix to the clat.

Per the above: if the users change the DNS servers, 464xlat will stop working regardless of what the ISP says.

I still don't see a use case for this. If an operator uses 464xlat, they must use RFC 7050 to provision it because there is no other mechanism. Additionally, if the user changes the DNS server to a non-DNS64 server, 464xlat stops working, and if the user changes the DNS server to a DNS64 server that doesn't hand out the operator's NAT64 prefix, 464xlat stops working or only works suboptimally. There is nothing the operator can do about this except accept the breakage or prevent the user from changing the DNS server.

If the operator wants to enable 464xlat: they should hand out a DNS64 to the CPE.
2.       If the operator wants to disable 464xlat: they should NOT hand out a DNS64 to the CPE.

3.       If the operator uses 464xlat, they should not allow the user to change the DNS server.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 12 Jun 2018 12:48:07 +0200

I think my earlier email to Lorenzo provides answers to most of this ... but

    

As said, you can use the CLAT w/o DNS64, so it is not a safe way to detect the CPE should use or not the NAT64.

An operator wants to make it as proof as possible to user changes. A user has no interest in changing the status of NAT64 (probably they don't know what it means), but they have interested in changing the DNS, because many apps or web sites tell them to change it.

Right, that's one case, using an alternative DNS64, which will bring alternative NAT64, unless/or the operator is using PCP for the NAT64 provisioning.

    
What it makes this work is the combination of RFC8026 and the CPE behavior. The idea is to have a S46 option to provide a priority in a list of "possible" transition mechanism to a given CPE. If the operator doesn't want that a specific CPE uses NAT64, then the S46 will not contain that option, so the CE will not use it, because will not have a match (even if the CPE is able to use 464XLAT). Not sure if this explanation clarify it ? I'm working on the precise text for that in the ID ...

---

From: Alejandro D'Egidio <[email-masked]>
Date: Tue, 12 Jun 2018 17:54:18 -0300 (ART)

Hello,
First at all, I've read all the thread and I think this is a very useful discussion.
I work in a cable operator and I think 464XLAT is a great idea to be included in CPEs. So, everything related to that is interesting for me.
I have some questions:
1- Why the RFC8026 can include Option Codes for many transition methods and not for 464XLAT?
2- Why we can't have an alternative to RFC7050 and RFC7225?
3- What if some CPEs works fine with some RFCs and not with other? Shouldn't be better to have alternatives? It's really common to have many Bugs in CPEs specially with new protocols. They can say they support some RFC but it doesn't work and you will need to wait some months (if you're lucky) to get the solution.
4- In our cablemodems we doesn't allow to customer to modify DNS configuration but, what about if customer change cablemodem to Bridge Mode and connects it's own CPE? This is a usual case where you can't control DNS configuration but you still want to use 464XLAT.

Thanks and Regards,

ALEJANDRO D'EGIDIO 
Jefe de Ingeniería de Backbone 
F: +54 11 3977 1025  | M: +54 911 5794 1589 
Lavardén 157. Piso 3. CABA (C1437FBC)

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Jun 2018 11:44:51 +0900

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> You don’t need RFC7050 neither DNS64, you can use PCP (RFC7225) to tell
> the CLAT the NAT64 prefix. It also provides additional advantages to the
> operator to control many related aspects (see section 3 of RFC7225).
>
>
>
> This doesn’t work, because the operator may be using RFC7225 instead of
> RFC7050. You need to try both in that case, and you aren’t providing a
> “priority” to a possible list of mechanisms, which is what RFC8026 does.
>

But it's the same problem again: what's the use case for this DHCPv6
option? An operator that's using RFC7225 has an easy way to tell the CPE
not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is
already possible today.

> Let’s be realistic. You can’t “force” the customer to avoid changing the
> DNS …
>

On an operator-managed CPE, you can. On a user-managed CPE, you can't. But
on such a CPE you probably shouldn't be disabling 464xlat. If the user
wants to use it, it's their CPE, right?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 08:50:21 +0200

Lorenzo, you’re missing the key aspect: Being able to prioritize, when an ISP supports several transition mechanisms.

RFC8026 key aspect is priority. If we don’t add an option code for 464XLAT, then it can’t be managed the same way.

Regards,

Jordi

Fecha: miércoles, 13 de junio de 2018, 4:45

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

But it's the same problem again: what's the use case for this DHCPv6 option? An operator that's using RFC7225 has an easy way to tell the CPE not to do 464xlat: don't hand out the prefix64 to those CPEs. So this is already possible today.

 

Let’s be realistic. You can’t “force” the customer to avoid changing the DNS …

On an operator-managed CPE, you can. On a user-managed CPE, you can't. But on such a CPE you probably shouldn't be disabling 464xlat. If the user wants to use it, it's their CPE, right?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Jun 2018 16:38:25 +0900

That goes back to my earlier point of that from a technical perspective
464xlat is pretty much the worst of the transition mechanisms. I don't
think we should be recommending running it on wireline at all, let alone
prioritizing it over something else .:-)

On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> Lorenzo, you’re missing the key aspect: Being able to prioritize, when an
> ISP supports several transition mechanisms.
>
>
>
> RFC8026 key aspect is priority. If we don’t add an option code for
> 464XLAT, then it can’t be managed the same way.
>
>
> Regards,
>
> Jordi
>
>
>
>
>
>
>
> *De: *v6ops <[email-masked]> en nombre de Lorenzo Colitti
> <lorenzo=[email-masked]>
> *Fecha: *miércoles, 13 de junio de 2018, 4:45
> *Para: *<jordi.palet=[email-masked]>
> *CC: *"[email-masked] WG" <[email-masked]>
> *Asunto: *Re: [v6ops] updating RFC8026 to support 464XLAT in
> draft-ietf-v6ops-transition-ipv4aas
>
>
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 09:52:48 +0200

I don’t think is fair to judge if 464XLAT is better or worse than other transition mechanism because it was not included in RFC8026 …

By the way, I realized also that some CLAT implementations are taking by default the NAT64 WKP (64:ff9b::/96, and other prefixes can be manually configured by GUI or CLI), so in fact, one more example that DNS64 is not needed and you may not need to implement at all RFC7050 neither RFC7225, so one more reason for requiring this change.

Note that I’m not saying is good a CLAT with by default the WKP NAT64, because it means the operator is forced to use the WKP, however, I ‘ve the feeling that in 99% of the NAT64 deployments is done that way ...

Regards,

Jordi

Fecha: miércoles, 13 de junio de 2018, 9:39

That goes back to my earlier point of that from a technical perspective 464xlat is pretty much the worst of the transition mechanisms.. I don't think we should be recommending running it on wireline at all, let alone prioritizing it over something else .:-)

On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Regards,

Jordi

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Jun 2018 17:58:44 +1000

> On 13 Jun 2018, at 5:52 pm, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 

Even if they are currently, in the later stages of the transition ISP’s may want to outsource ipv4aas.  When that is done the WKP won’t work.  You need a specific prefix to direct the traffic to the outsource operator.

Outsourcing is possible for all the ipv4aas mechanisms AFAIK.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 10:04:38 +0200

Hi Mark,

Totally agree, in fact I've introduced several "outsourcing" scenarios for NAT64 in draft-palet-v6ops-nat64-deployment.

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de Mark Andrews <[email-masked]>

Fecha: miércoles, 13 de junio de 2018, 10:00

CC: "[email-masked] WG" <[email-masked]>, Lorenzo Colitti <lorenzo=[email-masked]>

    

    -- 

    Mark Andrews, ISC

    v6ops mailing list

    [email-masked]

---

From: Lencse Gábor <[email-masked]>
Date: Wed, 13 Jun 2018 11:11:40 +0200

Dear Lorenzo,

I think it is a rather strong statement that "464XLAT is pretty much the 
worse of the transition mechanisms from a technical perspective."

We have listed 26+ IPv6 transition technologies in our workshop paper 
[1], but there are even more solutions exist.

Which of them do you mean to be better than 464XLAT?

What technical points do you consider when stating that 464XLAT is worse 
than the others? (E.g. resource consumption, scalability, security, ease 
of implementation, etc.)

I think it is important for network operators to have a balanced view of 
the advantages and disadvantages of the different IPv6 transition 
mechanisms, this is why I am asking these questions.

Best regards,

Gábor Lencse

[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition 
Technologies for Security Analysis", IEICE Communications Society 
Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, /IEICE 
Tech. Rep./, vol. 117, no. 187, pp. 19-24. Available online: 
http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf

6/13/2018 9:38 AM keltezéssel, Lorenzo Colitti írta:
> That goes back to my earlier point of that from a technical 
> perspective 464xlat is pretty much the worst of the transition 
> mechanisms.. I don't think we should be recommending running it on 
> wireline at all, let alone prioritizing it over something else .:-)
>
> On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ 
> <jordi.palet=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Lorenzo, you’re missing the key aspect: Being able to prioritize,
>     when an ISP supports several transition mechanisms.
>
>     *De: *v6ops <[email-masked]
>     <mailto:[email-masked]>> en nombre de Lorenzo Colitti
>     <lorenzo=[email-masked]
>     <mailto:[email-masked]>>
>     *Para: *<jordi.palet=[email-masked]
>     <mailto:[email-masked]>>
>     *CC: *"[email-masked] <mailto:[email-masked]> WG" <[email-masked]
>     <mailto:[email-masked]>>
>     On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ
>     <jordi.palet=[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         You don’t need RFC7050 neither DNS64, you can use PCP
>         (RFC7225) to tell the CLAT the NAT64 prefix. It also provides
>         additional advantages to the operator to control many related
>         aspects (see section 3 of RFC7225).
>
>         1.If the operator wants to enable 464xlat: they should hand
>         out a DNS64 to the CPE.
>
>         2.If the operator wants to disable 464xlat: they should NOT
>         hand out a DNS64 to the CPE.
>
>         This doesn’t work, because the operator may be using RFC7225
>         instead of RFC7050. You need to try both in that case, and you
>         aren’t providing a “priority” to a possible list of
>         mechanisms, which is what RFC8026 does.
>
>     But it's the same problem again: what's the use case for this
>     DHCPv6 option? An operator that's using RFC7225 has an easy way to
>     tell the CPE not to do 464xlat: don't hand out the prefix64 to
>     those CPEs. So this is already possible today.
>
>         3.If the operator uses 464xlat, they should not allow the user
>         to change the DNS server.
>
>     On an operator-managed CPE, you can. On a user-managed CPE, you
>     can't. But on such a CPE you probably shouldn't be disabling
>     464xlat. If the user wants to use it, it's their CPE, right?
>
>     [email-masked] <mailto:[email-masked]>
>     This electronic message contains information which may be
>     privileged or confidential. The information is intended to be for
>     the exclusive use of the individual(s) named above and further
>     non-explicilty authorized disclosure, copying, distribution or use
>     of the contents of this information, even if partially, including
>     attached files, is strictly prohibited and will be considered a
>     criminal offense. If you are not the intended recipient be aware
>     that any disclosure, copying, distribution or use of the contents
>     of this information, even if partially, including attached files,
>     is strictly prohibited, will be considered a criminal offense, so
>     you must reply to the original sender to inform about this

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Jun 2018 19:55:25 +0900

Here are a few disadvantages of 464xlat:

   - It consumes lots of state on the NAT64 (one state table entry for
   every connection). MAP is much better since it uses port ranges.
   - It doesn't allow any inbound connections unless the NAT cooperates.
   MAP is better in the sense that you can at least receive connections within
   your port range.
   - The transformation is lossy because there are IPv4 header fields that
   cannot be translated. MAP-E is better because the encapsulation preserves
   the original packet header.

On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor <[email-masked]> wrote:

> We have listed 26+ IPv6 transition technologies in our workshop paper [1],
> but there are even more solutions exist.
>
> than the others? (E.g. resource consumption, scalability, security, ease of
> implementation, etc.)
>
> [1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies
> for Security Analysis", IEICE Communications Society Internet Architecture
> Workshop, Tokyo, Japan, Aug. 28, 2017, *IEICE Tech. Rep.*, vol. 117, no.
> 187, pp. 19-24. Available online:
> 464xlat is pretty much the worst of the transition mechanisms.. I don't
>> [email-masked] <[email-masked]>>
>> wrote:
>>
>> On an operator-managed CPE, you can. On a user-managed CPE, you can't.
>> But on such a CPE you probably shouldn't be disabling 464xlat. If the user
> v6ops mailing [email-masked]://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Lee Howard <[email-masked]>
Date: Wed, 13 Jun 2018 07:12:36 -0400

So you mean "stateful < stateless"?

I haven't looked recently at which packet headers get munged in what 
ways. Care to save us all half an hour of examining RFCs and tell us 
which ones?

Lee

On 06/13/2018 06:55 AM, Lorenzo Colitti wrote:
>   * It consumes lots of state on the NAT64 (one state table entry for
>   * It doesn't allow any inbound connections unless the NAT
>     cooperates. MAP is better in the sense that you can at least
>     receive connections within your port range.
>   * The transformation is lossy because there are IPv4 header fields
>     that cannot be translated. MAP-E is better because the
>     encapsulation preserves the original packet header.
>
>
> On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear Lorenzo,
>
>     I think it is a rather strong statement that "464XLAT is pretty
>     much the worse of the transition mechanisms from a technical
>     perspective."
>
>     We have listed 26+ IPv6 transition technologies in our workshop
>     paper [1], but there are even more solutions exist.
>
>     What technical points do you consider when stating that 464XLAT is
>     worse than the others? (E.g. resource consumption, scalability,
>     security, ease of implementation, etc.)
>
>     I think it is important for network operators to have a balanced
>     view of the advantages and disadvantages of the different IPv6
>     transition mechanisms, this is why I am asking these questions.
>
>     Best regards,
>
>     Gábor Lencse
>
>
>     Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017,
>     /IEICE Tech. Rep./, vol. 117, no. 187, pp. 19-24. Available
>     online:
>     <http://www.hit.bme.hu/%7Elencse/publications/IEICE-IA-2017-survey.pdf>
>
>
>>     mechanisms.. I don't think we should be recommending running it
>>     on wireline at all, let alone prioritizing it over something else
>>     .:-)
>>
>>         Lorenzo, you’re missing the key aspect: Being able to
>>         prioritize, when an ISP supports several transition mechanisms.
>>
>>         RFC8026 key aspect is priority. If we don’t add an option
>>         code for 464XLAT, then it can’t be managed the same way.
>>
>>
>>         Regards,
>>
>>         Jordi
>>
>>         *CC: *"[email-masked] <mailto:[email-masked]> WG"
>>         <[email-masked] <mailto:[email-masked]>>
>>             (RFC7225) to tell the CLAT the NAT64 prefix. It also
>>             provides additional advantages to the operator to control
>>             many related aspects (see section 3 of RFC7225).
>>
>>             1.If the operator wants to enable 464xlat: they should
>>             2.If the operator wants to disable 464xlat: they should
>>             NOT hand out a DNS64 to the CPE.
>>
>>             This doesn’t work, because the operator may be using
>>             RFC7225 instead of RFC7050. You need to try both in that
>>             case, and you aren’t providing a “priority” to a possible
>>             list of mechanisms, which is what RFC8026 does.
>>
>>         DHCPv6 option? An operator that's using RFC7225 has an easy
>>         way to tell the CPE not to do 464xlat: don't hand out the
>>         prefix64 to those CPEs. So this is already possible today.
>>
>>             3.If the operator uses 464xlat, they should not allow the
>>             user to change the DNS server.
>>
>>         On an operator-managed CPE, you can. On a user-managed CPE,
>>         you can't. But on such a CPE you probably shouldn't be
>>         disabling 464xlat. If the user wants to use it, it's their
>>         CPE, right?
>>
>>         _______________________________________________ v6ops mailing
>>         list [email-masked] <mailto:[email-masked]>
>>         privileged or confidential. The information is intended to be
>>         for the exclusive use of the individual(s) named above and
>>         further non-explicilty authorized disclosure, copying,
>>         distribution or use of the contents of this information, even
>>         if partially, including attached files, is strictly
>>         prohibited and will be considered a criminal offense. If you
>>         are not the intended recipient be aware that any disclosure,
>>         copying, distribution or use of the contents of this
>>         information, even if partially, including attached files, is
>>         strictly prohibited, will be considered a criminal offense,
>>         so you must reply to the original sender to inform about this

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 14:09:50 +0200

This always depends on your perspective, network, user requirements, etc. Different operators have different requirements.

·         It consumes lots of state on the NAT64 (one state table entry for every connection). MAP is much better since it uses port ranges.

Some ISPs care less about state and care more about having a better usage of each IPv4 address and providing as many ports as the users need automatically.

With NAT64, you have for each user as many ports as they need, nothing “extra” to configure for each user. With MAP you pre-define a number of ports per user.

·         It doesn't allow any inbound connections unless the NAT cooperates. MAP is better in the sense that you can at least receive connections within your port range.

Some ISPs don’t want inbound connections to be statically managed by users, they offer different services with different prices, etc. I’m not saying I agree with that. Even do, you have ways to cooperate with the NAT64, PCP, etc., to do that. Even for corporate users you can mix that with SIIT-DC or alike functions.

Inbound connections in your port range is useless for most of the users, or apps or devices, because they don’t allow other ports, and yes, you can sometimes play tricks with the CPE port forwarding, etc., etc.

·         The transformation is lossy because there are IPv4 header fields that cannot be translated. MAP-E is better because the encapsulation preserves the original packet header.

None of the transition mechanisms can be perfect, except probably dual-stack, but we know we can’t do dual-stack for every possible network, because we don’t have sufficient addresses, right?

Now, this has been said many times, and I don’t necessarily agree initially, but I’ve started to change my mind in the last few years. ***We DON’T WANT a perfect transition mechanism.***

We want some apps to fail, so indirectly it forces to developers and content providers to move them to IPv6.

So, all them are imperfect in one way or another, but having a single one, is much better, from all the perspectives that having many. Developers will fix easier anything for a single mechanism than for many, everything will happen faster, and of course, since 464XLAT is the one with has more users worldwide, it makes sense to push for that one everywhere, because the problems that the app developers find in the cellular world, will be sorted out, so those apps will be fixed for both, cellular and non-cellular.

Also, an operator with both, cellular and non-cellular networks, is very interested to support a single mechanism instead of two or more. Even an operator without a cellular network, many times need to provide backup by means of LTE and that means hybrid routers with both wired and LTE interfaces. It is much simpler to have a single mechanism for both, because even the cellular network is not its own network, it can use the same NAT64 (or the same outsourced one for both kind of connections).

I was not a fan of 464XLAT initially when it was developed, but market make me change my mind.

In summary, it all depends on your perspective, but if our goal is to push as much as possible for a higher % of IPv6-only traffic, I’m convinced cellular networks, which are the ones with higher % of penetration and growth, clearly defined the path that we must follow. 

Dear Lorenzo,

I think it is a rather strong statement that "464XLAT is pretty much the worse of the transition mechanisms from a technical perspective."

We have listed 26+ IPv6 transition technologies in our workshop paper [1], but there are even more solutions exist. 

What technical points do you consider when stating that 464XLAT is worse than the others? (E.g. resource consumption, scalability, security, ease of implementation, etc.)

I think it is important for network operators to have a balanced view of the advantages and disadvantages of the different IPv6 transition mechanisms, this is why I am asking these questions.

Best regards,

Gábor Lencse

[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug. 28, 2017, IEICE Tech. Rep., vol. 117, no. 187, pp. 19-24. Available online: http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf

Regards,

Jordi

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 14:21:17 +0200

Resending as my email client formatted it weirdly … and adding one more comment.

Consequently, with NAT64 you make a much better usage of every single IPv4 address, because they become shared based dynamically on “real-flow-per-port” needs at each given time.

So, all them are imperfect in one way or another, but having a single one, is much better, cheaper and easier, from all the perspectives that having many. Developers will fix easier anything for a single mechanism than for many, everything will happen faster, and of course, since 464XLAT is the one with has more users worldwide, it makes sense to push for that one everywhere, because the problems that the app developers find in the cellular world, will be sorted out, so those apps will be fixed for both, cellular and non-cellular.

 

Dear Lorenzo,

Best regards,

Gábor Lencse

Regards,

Jordi

---

From: Philip Homburg <[email-masked]>
Date: Wed, 13 Jun 2018 14:30:46 +0200

>    Now, this has been said many times, and I don't necessarily
>    agree initially, but I've started to change my mind in the last
>    few years.  ***We DON'T WANT a perfect transition mechanism.***
> 
> 
>    We want some apps to fail, so indirectly it forces to developers
>    and content providers to move them to IPv6.

If you want people to dislike IPv6, then this is the way to do it.

There are plenty of ISPs that used to provide customers with a native IPv4
address and then migrade to IPv6 with some form of NAT.

The way this registers with users is that you don't want IPv6 because that
breaks your internet connection.

There is already a sentiment that IPv6 doesn't do anything useful. That is
now becoming that IPv6 will harm your internet connection. Hang on to your
IPv4 address as long as you can.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 14:44:19 +0200

Don't read it literally, and also understand that I've said " and I don't necessarily agree initially". What I'm trying to say is that is that if 464XLAT is working in cellular, problems will appear there, users there can't switch off IPv6, so problems get sorted out by the app developer, and that means also sorted out in the wireline. I'm not trying to say "make it imperfect on purpose!"

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 13 Jun 2018 14:50:48 +0200

In fact ... I started to believe a few years ago, that the worst mistake the IETF did with IPv6, was to define more than just one transition mechanism.

Maybe we needed one for 6in4 and one for 4in6, that's it.

If we had focused in only one (even if not perfect), since the beginning, all routers will support it, will be the same for wired and not wired networks, we could have saved tons of hours of work to many IETF WGs, many OS and app developers, many operators, many enterprises, many students, etc.

Of course, we didn't knew (no crystal ball) how this will evolve.

Maybe is time to start deprecating 6in4 ones and may be some of the 4in6 ones as well?

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de JORDI PALET MARTINEZ <jordi.palet=[email-masked]>

Fecha: miércoles, 13 de junio de 2018, 14:45

Para: Philip Homburg <[email-masked]>, <[email-masked]>

Asunto: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

        

    

    

        

        

        

    

    IPv4 is over

    The IPv6 Company

    

    v6ops mailing list

    [email-masked]

---

From: Alejandro D'Egidio <[email-masked]>
Date: Wed, 13 Jun 2018 09:55:32 -0300 (ART)

Hello Lorenzo, 
I really appreciate your comments but if you don't like 464XLAT it doesn't mean that I can have the choice to use it. I like the idea to have CLAT functionality in CPE. 
I think ISPs should have the chance to decide which transition method works better on its network and infrastructure. 

Regards, 

ALEJANDRO D'EGIDIO 

De: "JORDI PALET MARTINEZ" <jordi.palet=[email-masked]> 
Para: "Lorenzo Colitti" <lorenzo=[email-masked]>, [email-masked] 
CC: "[email-masked] WG" <[email-masked]> 
Enviados: Miércoles, 13 de Junio 2018 9:21:17 
Asunto: Re: [v6ops] Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas 

On Wed, Jun 13, 2018 at 6:12 PM Lencse Gábor < [ mailto:[email-masked] | [email-masked] ] > wrote: 

Dear Lorenzo, 

Best regards, 

Gábor Lencse 

[1] G. Lencse and Y. Kadobayashi, "Survey of IPv6 Transition Technologies for Security Analysis", IEICE Communications Society Internet Architecture Workshop, Tokyo, Japan, Aug.. 28, 2017, IEICE Tech. Rep. , vol. 117, no. 187, pp. 19-24. Available online: [ http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf | http://www.hit.bme.hu/~lencse/publications/IEICE-IA-2017-survey.pdf ] 

BQ_BEGIN

On Wed, Jun 13, 2018 at 3:50 PM JORDI PALET MARTINEZ <jordi.palet= [ mailto:[email-masked] | [email-masked] ] > wrote: 

BQ_BEGIN

Regards, 

Jordi 

De: v6ops < [ mailto:[email-masked] | [email-masked] ] > en nombre de Lorenzo Colitti <lorenzo= [ mailto:[email-masked] | [email-masked] ] > 
Fecha: miércoles, 13 de junio de 2018, 4:45 
Para: <jordi.palet= [ mailto:[email-masked] | [email-masked] ] > 
CC: " [ mailto:[email-masked] | [email-masked] ] WG" < [ mailto:[email-masked] | [email-masked] ] > 
Asunto: Re: [v6ops] updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas 

On Tue, Jun 12, 2018 at 7:40 PM JORDI PALET MARTINEZ <jordi.palet= [ mailto:[email-masked] | [email-masked] ] > wrote: 

BQ_BEGIN

BQ_BEGIN

BQ_END

_______________________________________________ v6ops mailing list [ mailto:[email-masked] | v6ops@ietf..org ] [ https://www.ietf.org/mailman/listinfo/v6ops | https://www.ietf.org/mailman/listinfo/v6ops ] 

********************************************** 
IPv4 is over 
Are you ready for the new Internet ? 
[ http://www.consulintel.es/ | http://www.consulintel.es ] 
The IPv6 Company 

BQ_END

_______________________________________________ 
v6ops mailing list 
[ mailto:[email-masked] | [email-masked] ] 
[ https://www.ietf.org/mailman/listinfo/v6ops | https://www.ietf.org/mailman/listinfo/v6ops ] 

BQ_END

_______________________________________________ 
v6ops mailing list 
[ mailto:[email-masked] | [email-masked] ] 
[ https://www.ietf.org/mailman/listinfo/v6ops | https://www.ietf.org/mailman/listinfo/v6ops ] 
BQ_END

---

From: Lencse Gábor <[email-masked]>
Date: Wed, 13 Jun 2018 19:00:43 +0200

Dear Lorenzo,

Thank you very much for your answer.

For a balanced view, I think it is useful to point out that the MAP 
protocols have their disadvantages, too.

_1. Port numbers_

As Jordi has already pointed it out, one needs to dedicate a fix number 
of ports per CPE. Some advice that a few hundred will do for this value, 
but I think that it is not so simple:
- The lack of port situation may cause serious problems in the operation 
of certain programs, for more information see [1].
- The port number consumption of different applications is highly 
varying and e.g. in the case of web browsing it depends on several 
factors [2].
- There may be several users behind a CPE, especially in the wired case 
(e.g. Internet is used by different members of a family simultaneously), 
thus sometimes even a few thousands may not be enough.

Stateful NAT64 (used by 464XLAT) can use port numbers (and thus public 
IP addresses) much more economically.

_2. Complexity and security_

The operation of the MAP solution is rather complex, now I give only 
some highlights. Let us consider MAP-T. (MAP-E works similarly, but it 
uses encapsulation.) "First, the MAP-T CE (Customer Edge) device 
performs a NAT44 operation to restrict the available TCP/UDP port 
numbers for the user.  Then the CE device performs a special stateless 
translation from IPv4 to IPv6, where the source IPv4 address and the 
selected port bits are encoded into the source IPv6 address according to 
the MAP-T rules. The IPv6 packets can be destined to other users, where 
similar CEs perform the necessary transformations, or to the outside 
IPv4 Internet, in which case the MAP-T Border Relay performs the 
necessary transformations." [3]

This complexity has performance and security implications:
- Whereas the IPv6 backbone traffic of 464XLAT is normal IPv6 traffic, 
which can be inspected e.g. by firewalls, the IPv6 backbone traffic of 
MAP-T (as well as that of MAP-E) needs to be first "decoded", which 
causes further costs (both CAPEX and OPEX).
-  Complex code may contain more bugs and thus also security holes. (In 
the simplest model, the number of bugs is proportional to the number of 
code lines.)

_3. MAP-T and MAP-E are different_

On the one hand, if double translation may cause the loss of some IPv4 
fields (BTW: What exactly did you mean?), then it is also applies for MAP-T.
On the other hand, MAP-E uses encapsulation, which results in an 
overhead. An IPv6 header is at least 40 bytes, which may be a 
significant overhead in the case of small packets, e.g. TCP acknowledgments.

_4. What other IPv6 transition solutions did you also consider?_

As you have now mentioned only MAP,  I wonder what other solutions you 
could consider better than 464XLAT?

Best regards,

Gábor Lencse

References:
[1] S. Miyakawa, "IPv4 to IPv6 transformation schemes", IEICE Trans. 
Commun., vol.E93-B, no.5, pp.1078-1084, May 2010. 
DOI:10.1587/transcom.E93.B.1078
[2] S. Répás, T. Hajas, and G. Lencse, "Port number consumption of the 
NAT64 IPv6 transition technology", Proc. 37th Internat. Conf. on 
Telecommunications and Signal Processing (TSP 2014), Berlin, Germany, 
pp.66-72, Jul. 1-3, 2014. DOI: 10.1109/TSP.2015.7296411
[3] G. Lencse, Y. Kadobayashi, "Comprehensive survey of IPv6 transition 
technologies for security analysis", unpublished

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Jun 2018 21:37:23 +0200

> For a balanced view, I think it is useful to point out that the MAP protocols have their disadvantages, too.
> 
> 1. Port numbers
> 
> As Jordi has already pointed it out, one needs to dedicate a fix number of ports per CPE. Some advice that a few hundred will do for this value, but I think that it is not so simple:
> - The lack of port situation may cause serious problems in the operation of certain programs, for more information see [1].
> - The port number consumption of different applications is highly varying and e.g. in the case of web browsing it depends on several factors [2].
> - There may be several users behind a CPE, especially in the wired case (e.g. Internet is used by different members of a family simultaneously), thus sometimes even a few thousands may not be enough.
> 
> Stateful NAT64 (used by 464XLAT) can use port numbers (and thus public IP addresses) much more economically.

While that is correct, you can build endpoint dependent NATs that are extremely efficient when it comes to port utilisation.
(Reusing the same port for communication to different end systems).

> 2. Complexity and security
> 
> The operation of the MAP solution is rather complex, now I give only some highlights. Let us consider MAP-T. (MAP-E works similarly, but it uses encapsulation.) "First, the MAP-T CE (Customer Edge) device performs a NAT44 operation to restrict the available TCP/UDP port numbers for the user.  Then the CE device performs a special stateless translation from IPv4 to IPv6, where the source IPv4 address and the selected port bits are encoded into the source IPv6 address according to the MAP-T rules. The IPv6 packets can be destined to other users, where similar CEs perform the necessary transformations, or to the outside IPv4 Internet, in which case the MAP-T Border Relay performs the necessary transformations." [3]
> 
> - Whereas the IPv6 backbone traffic of 464XLAT is normal IPv6 traffic, which can be inspected e.g. by firewalls, the IPv6 backbone traffic of MAP-T (as well as that of MAP-E) needs to be first "decoded", which causes further costs (both CAPEX and OPEX).

This is incorrect. MAP-T IPv6 traffic is just as 'normal' as 464XLAT IPv6 packets.

> -  Complex code may contain more bugs and thus also security holes. (In the simplest model, the number of bugs is proportional to the number of code lines.)

On the PE side, stateful NAT64 is a lot more complex than any of the MAPs. While MAP-T is somewhat more complex (in number of lines of code) than MAP-E.
You have logging considerations as well as much more complex scaling. Scaling a MAP system is trivial. Scaling a stateful NAT system quickly requires state synchronisation between systems.

On the CPE side complexity is similar. NAT44 -> NAT46 or NAT44 -> tunnel. (Actually the 464XLAT case where even the second NAT is stateful is worse.

> 3. MAP-T and MAP-E are different
> 
> On the one hand, if double translation may cause the loss of some IPv4 fields (BTW: What exactly did you mean?), then it is also applies for MAP-T.
> On the other hand, MAP-E uses encapsulation, which results in an overhead. An IPv6 header is at least 40 bytes, which may be a significant overhead in the case of small packets, e.g. TCP acknowledgments.

Yes. At the benefit of transparency and simplicity. 464XLAT/MAP-T adds 20 bytes, encap another 20.
> 
> 4. What other IPv6 transition solutions did you also consider?
> 
> As you have now mentioned only MAP,  I wonder what other solutions you could consider better than 464XLAT?

Please don't call these IPv6 transition solutions.
These solutions are about keeping IPv4 alive a little longer.

The main "benefit" of 464XLAT is two-fold. It was lighter on provisioning than e.g. MAP-E or MAP-T and it could reuse a stateful NAT64, which could serve IPv6 only hosts reaching the IPv4 Internet.
How easy it is to provision 464XLAT or NAT64 to a CE device has in hindsight been shown to be arguable.

Cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jun 2018 18:32:20 +0900

On Thu, Jun 14, 2018 at 4:37 AM Ole Troan <[email-masked]> wrote:

> The main "benefit" of 464XLAT is two-fold. It was lighter on provisioning
> than e.g. MAP-E or MAP-T and it could reuse a stateful NAT64, which could
> serve IPv6 only hosts reaching the IPv4 Internet.
>

Almost. The "benefits" that led to 464xlat being widely deployed were:

   - It didn't use encapsulation, so it didn't break the DPI / header
   enrichment / billing / QoS ... systems used by mobile networks.
   - It didn't use DHCPv6 so it was possible to provision it on networks
   that don't support DHCPv6, like mobile networks. The first implementation
   used ipv4.google.com.
   - There were already NAT64s in the field because people had tried to
   deploy IPv6-only with NAT64 and failed due to app breakage.

---

From: <[email-masked]>
Date: Thu, 14 Jun 2018 10:28:05 +0000

Expanding on your last point:
> There were already NAT64s in the field because people had tried to deploy IPv6-only with NAT64 and failed due to app breakage.
There were no NAT64s in production for paying customers, only NAT44, as you say, apps were breaking.
Mobile Operators were already using NAT44, to defend against IPv4 public exhaustion.
Some Mobile Operators were concerned with private address exhaustion (20M private IPs is not enough).

With NAT44 all traffic passes via CGN.
With NAT64 and 464xlat then IPv6 is not translated and only the v4-only destinations go via NAT64.
Less CGN burden, and IPv6 enabled.
Private IP exhaustion is mitigated. Private IP exhaustion tends to get forgotten but this is critically why NAT44 may have limited life (for ISPs with larger bases).

If the requirement is do something better than NAT44 CGN then you can see why 464xlat has its place.
MAP-T could in theory do this job. it seems more complex to deploy and the case to go from 464xlat to MAP-T seems weak, but if it really existed in mobile devices it may be something to consider.

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 14 June 2018 10:32
To: Ole Troan <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

On Thu, Jun 14, 2018 at 4:37 AM Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:
The main "benefit" of 464XLAT is two-fold. It was lighter on provisioning than e.g. MAP-E or MAP-T and it could reuse a stateful NAT64, which could serve IPv6 only hosts reaching the IPv4 Internet.

  *   It didn't use encapsulation, so it didn't break the DPI / header enrichment / billing / QoS ... systems used by mobile networks.
  *   It didn't use DHCPv6 so it was possible to provision it on networks that don't support DHCPv6, like mobile networks. The first implementation used ipv4.google.com<http://ipv4.google.com>.
  *   There were already NAT64s in the field because people had tried to deploy IPv6-only with NAT64 and failed due to app breakage.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jun 2018 19:30:46 +0900

On Thu, Jun 14, 2018 at 7:28 PM <[email-masked]> wrote:

> MAP-T could in theory do this job. it seems more complex to deploy and the
> case to go from 464xlat to MAP-T seems weak, but if it really existed in
> mobile devices it may be something to consider.
>

Oh, I definitely agree that 464xlat has it's place. I maintain a popular
implementation of it :-)

I'm just saying it's not the best solution for a wireline network.

---

From: Ca By <[email-masked]>
Date: Thu, 14 Jun 2018 05:12:37 -0700

On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti <lorenzo=
[email-masked]> wrote:

>> MAP-T could in theory do this job. it seems more complex to deploy and
>> the case to go from 464xlat to MAP-T seems weak, but if it really existed
>> in mobile devices it may be something to consider.
>>
>

Perhaps.

The market for ipv6-only transition, afaik, is won by ds-lite and 464xlat.

Afaik, there is not a large production stateless MAP implementation, and
this market is fairly mature. That said, at this point, the theoretical
advantage of stateless has failed to materialize in real world deployment
... while the stateful solutions keep gaining share.

---

From: Lee Howard <[email-masked]>
Date: Thu, 14 Jun 2018 09:15:56 -0400

On 06/14/2018 08:12 AM, Ca By wrote:
>
>
> On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti 
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Jun 14, 2018 at 7:28 PM <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>     Oh, I definitely agree that 464xlat has it's place. I maintain a
>     popular implementation of it :-)
>
> Afaik, there is not a large production stateless MAP implementation, 
> and this market is fairly mature. That said, at this point, the 
> theoretical advantage of stateless has failed to materialize in real 
> world deployment ... while the stateful solutions keep gaining share.
>

Crowd-sourced list of transition technologies various carriers have 
deployed: 
https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

I see several that have deployed MAP.

I speculate that DS-Lite and NAT64 had early mover advantage (i.e., 
early development), and were the only game in town. 464xlat only has 
that advantage in mobile, since handsets are the only major CLAT 
implementation.

I think it's too soon to declare winners.

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2018 15:32:15 +0200

I recall Windows Update 10 also has included CLAT support. I’m sure this will happen more and more in different OSs, as it makes a lot of sense in networks that may already have NAT64.

I don’t think that will happen with MAP or DS-Lite (I mean having those in the OSs).

If we are pushing for IPv6-only enterprise networks, the CLAT will be also the way to ensure that old apps work, if the enterprise router don’t have the CLAT already enabled.

Another important aspect, in my opinion, is that the implementation of CLAT, even for a CPE, it is the much simpler one compared with any other one.

Regarsd,

Jordi

De: v6ops <[email-masked]> en nombre de Lee Howard <[email-masked]>
Fecha: jueves, 14 de junio de 2018, 15:16
Para: <[email-masked]>
Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

 

On Thu, Jun 14, 2018 at 3:31 AM Lorenzo Colitti <lorenzo=[email-masked]> wrote:

 

Oh, I definitely agree that 464xlat has it's place. I maintain a popular implementation of it :-)

Perhaps. 

Afaik, there is not a large production stateless MAP implementation, and this market is fairly mature. That said, at this point, the theoretical advantage of stateless has failed to materialize in real world deployment ... while the stateful solutions keep gaining share. 

Crowd-sourced list of transition technologies various carriers have deployed: https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early development), and were the only game in town. 464xlat only has that advantage in mobile, since handsets are the only major CLAT implementation. 

Lee

---

From: Lee Howard <[email-masked]>
Date: Thu, 14 Jun 2018 09:43:37 -0400

On 06/14/2018 09:32 AM, JORDI PALET MARTINEZ wrote:
>
> I recall Windows Update 10 also has included CLAT support. I’m sure 
> this will happen more and more in different OSs, as it makes a lot of 
> sense in networks that may already have NAT64.
>

You think? Like game console OSs and thermostat OSs and stereo OSs and 
TV OSs?

> I don’t think that will happen with MAP or DS-Lite (I mean having 

Ew, I hope not, that's the wrong place to implement those. I suppose I 
could imagine using a softwire as a VPN assuming IPv6--no, no I can't 
imagine it.

> If we are pushing for IPv6-only enterprise networks, the CLAT will be 
> also the way to ensure that old apps work, if the enterprise router 
> don’t have the CLAT already enabled.
>
> Another important aspect, in my opinion, is that the implementation of 
> CLAT, even for a CPE, it is the much simpler one compared with any 
> other one.
>

That only matters if it actually gets implemented. "Easy" and "done" are 
different.

You've said that home gateway vendors by and large have code for all of 
the mechanisms already written, so I'm not sure ease is essential.

There are other drivers here, and while I have no concerns about 
464xlat, I also am not ready to crown it the winner.

Lee

>
> Regarsd,
>
> Jordi
>
> *De: *v6ops <[email-masked]> en nombre de Lee Howard 
> <[email-masked]>
> *Fecha: *jueves, 14 de junio de 2018, 15:16
> *Para: *<[email-masked]>
> *Asunto: *Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT 
> really inferior to all other IPv6 transition technologies? -- Re: 
> updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas
>
>     Afaik, there is not a large production stateless MAP
>     implementation, and this market is fairly mature. That said, at
>     this point, the theoretical advantage of stateless has failed to
>     materialize in real world deployment ... while the stateful
>     solutions keep gaining share.
>
>
>
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents of 
> this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you 
> are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited, will be 
> considered a criminal offense, so you must reply to the original 
> sender to inform about this communication and delete it.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2018 16:20:42 +0200

You think? Like game console OSs and thermostat OSs and stereo OSs and TV OSs? 

No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, Android). It makes a lot of sense specially for devices that are “portable” and in fact that’s the idea behind Windows 10 Update. If you can use that device in a cellular IPv6-only network, should be expected that in a WiFi or wired IPv6-only network is behaving the same way when no native IPv4 is available. The other kind of OSs that you mention should either have already IPv6-only or rely in the CPE to provide IPv4 if they really need that.

Ew, I hope not, that's the wrong place to implement those. I suppose I could imagine using a softwire as a VPN assuming IPv6--no, no I can't imagine it.

Yes, as a VPN client, it may be, but hopefully not as something by default in the OS.

That only matters if it actually gets implemented. "Easy" and "done" are different.

You've said that home gateway vendors by and large have code for all of the mechanisms already written, so I'm not sure ease is essential.

Yeah, talked to many, they often provide whatever you need if the order is big, our problem is still the retail market or orders to vendors that don’t have sufficient amount to demand a specific firmware feature set.

Code required for each transition in OpenWRT (it may be quite similar in other implementations):

DS-Lite   15 Kbytes

464XLAT 17 Kbytes

MAP-E    35 Kbytes

LW4o6   35 Kbytes

MAP-T   48 Kbytes

If *all* them are implemented: 53 Kbytes (there are many “shared” modules among them, same data plane, etc.).

There are other drivers here, and while I have no concerns about 464xlat, I also am not ready to crown it the winner. 

I bet a dinner … Cellular is too powerful and they made the decision long time ago.

Lee

Regarsd,

Jordi

 

 

 

Perhaps. 

Lee

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 15 Jun 2018 00:39:09 +0900

On Thu, Jun 14, 2018 at 11:21 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> There are other drivers here, and while I have no concerns about 464xlat,
> I also am not ready to crown it the winner.
>
>
>

Actually, the real solution for mobile is true IPv6-only with NAT64. Mobile
is going to get there much faster than wireline, There's not that far much
left to do (Apple has already done it), and handsets are much more under
the control of carriers and churn so much more quickly.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2018 17:43:40 +0200

But, and is a big but, for tethering the CLAT is needed, otherwise the operator need to provide also an IPv4v6 PDP context just for the tethering.

This is the actual complain from many operators with iOS, which is sorted out in Android and Windows with the CLAT.

At least while some devices are IPv4-only and people need to use them with tethering.

Regards,

Jordi

De: Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: jueves, 14 de junio de 2018, 17:39
Para: <[email-masked]>
CC: Lee Howard <[email-masked]>, "[email-masked] WG" <[email-masked]>
Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

On Thu, Jun 14, 2018 at 11:21 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Actually, the real solution for mobile is true IPv6-only with NAT64. Mobile is going to get there much faster than wireline, There's not that far much left to do (Apple has already done it), and handsets are much more under the control of carriers and churn so much more quickly.

---

From: <[email-masked]>
Date: Thu, 14 Jun 2018 15:47:19 +0000

I disagree.
The gap: tethering an unknown device (i.e. OS may depend on v4) to a IPv6-only cellular device.
464xlat nails that use case on a single APN.

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: 14 June 2018 16:39
To: jordi.palet=[email-masked]
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

On Thu, Jun 14, 2018 at 11:21 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]<mailto:[email-masked]>> wrote:
There are other drivers here, and while I have no concerns about 464xlat, I also am not ready to crown it the winner.

---

From: Lee Howard <[email-masked]>
Date: Thu, 14 Jun 2018 13:33:54 -0400

On 06/14/2018 10:20 AM, JORDI PALET MARTINEZ wrote:
>
>     I recall Windows Update 10 also has included CLAT support. I’m
>     sure this will happen more and more in different OSs, as it makes
>     a lot of sense in networks that may already have NAT64.
>
>
> No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, 
> Android). It makes a lot of sense specially for devices that are 
> “portable” and in fact that’s the idea behind Windows 10 Update. If 
> you can use that device in a cellular IPv6-only network, should be 
> expected that in a WiFi or wired IPv6-only network is behaving the 
> same way when no native IPv4 is available. The other kind of OSs that 
> you mention should either have already IPv6-only or rely in the CPE to 
> provide IPv4 if they really need that.
>

"Or rely on the CPE" is my point. They don't have IPv6 in the OS now, so 
they need whatever the home gateway provides. No transition mechanisms 
are widespread in retail gateways; DS-Lite more than others. So we're 
waiting to see what goes into retail gateways.
Meanwhile, manufacturers are asking ISP customers what they want. You 
keep hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP.

BUT it would be cool if game consoles did deploy CLAT, and provide a 
translation layer for games that only know IPv4. I don't know the 
architecture well enough to know whether that would work,

Also, tethering behind an IPv6-only phone is still no problem if you 
have Windows 10 and a NAT64 server, apparently: just fire up the CLAT.

> You've said that home gateway vendors by and large have code for all 
> of the mechanisms already written, so I'm not sure ease is essential.
>
> Yeah, talked to many, they often provide whatever you need if the 
> order is big, our problem is still the retail market or orders to 
> vendors that don’t have sufficient amount to demand a specific 
> firmware feature set.
>
> If *all* them are implemented: 53 Kbytes (there are many “shared” 
> modules among them, same data plane, etc.).
>
>

What's the decision criterion? :)
Mobile is huge, but has little influence on wireline. And most of them 
(globally) are still on dual stack.

Lee
>
>
>
> Lee
>
>
>
>     Regarsd,
>
>     Jordi
>
>     *De: *v6ops <[email-masked]>
>     <mailto:[email-masked]> en nombre de Lee Howard
>     <[email-masked]> <mailto:[email-masked]>
>     *Para: *<[email-masked]> <mailto:[email-masked]>
>     *Asunto: *Re: [v6ops] Disadvantages of MAP protocols -- Re: Is
>     464XLAT really inferior to all other IPv6 transition technologies?
>     -- Re: updating RFC8026 to support 464XLAT in
>             Oh, I definitely agree that 464xlat has it's place. I
>             maintain a popular implementation of it :-)
>
>         implementation, and this market is fairly mature. That said,
>         at this point, the theoretical advantage of stateless has
>         failed to materialize in real world deployment ... while the
>         stateful solutions keep gaining share.
>
>
>
>     Crowd-sourced list of transition technologies various carriers
>     have deployed:
>     I speculate that DS-Lite and NAT64 had early mover advantage
>     (i.e., early development), and were the only game in town. 464xlat
>     only has that advantage in mobile, since handsets are the only
>     major CLAT implementation.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 15 Jun 2018 16:10:27 +0200

In short … mobile is so huge that impacts in everything, especially in app developers. So, if they are forced by mobile to solve any problems, it means they typically will be sorted out as well for wireline (if using the same mechanisms). Is not that influence?

I think they opted for 464XLAT because it is a very simple approach half way to the end of the path: IPv6-only. Cameron can confirm, but clearly, NAT64 alone was not sufficient as it was breaking many things.

And that responds also your point about tethering, just agree on that, but iOS not including it. I think there were other related inputs on this yesterday in the list.

Regards,

Jordi

De: Lee Howard <[email-masked]>
Fecha: jueves, 14 de junio de 2018, 19:34
Para: JORDI PALET MARTINEZ <[email-masked]>, <[email-masked]>
Asunto: Re: [v6ops] Disadvantages of MAP protocols -- Re: Is 464XLAT really inferior to all other IPv6 transition technologies? -- Re: updating RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas

"Or rely on the CPE" is my point. They don't have IPv6 in the OS now, so they need whatever the home gateway provides. No transition mechanisms are widespread in retail gateways; DS-Lite more than others. So we're waiting to see what goes into retail gateways.
Meanwhile, manufacturers are asking ISP customers what they want. You keep hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP.

BUT it would be cool if game consoles did deploy CLAT, and provide a translation layer for games that only know IPv4. I don't know the architecture well enough to know whether that would work,

Also, tethering behind an IPv6-only phone is still no problem if you have Windows 10 and a NAT64 server, apparently: just fire up the CLAT.

DS-Lite   15 Kbytes

464XLAT 17 Kbytes

MAP-E    35 Kbytes

LW4o6   35 Kbytes

MAP-T   48 Kbytes

What's the decision criterion? :)
Mobile is huge, but has little influence on wireline. And most of them (globally) are still on dual stack.

Lee

Lee

Regarsd,

Jordi

 

 

 

Perhaps. 

Lee

---

From: Hans Liu <[email-masked]>
Date: Thu, 21 Jun 2018 21:55:27 +0800

> they need whatever the home gateway provides. No transition mechanisms are
> widespread in retail gateways; DS-Lite more than others. So we're waiting
> to see what goes into retail gateways.
>
I know! I know!  Working on it!!  Wish I could drive internally as I used
to.

Meanwhile, manufacturers are asking ISP customers what they want. You keep
> hearing that ISPs want 464xlat or lw4over6, and I keep hearing MAP.
>
I heard both, but not recently.   Either ISPs gave up or they gave up on
me.  :-)

Best regards,
Hans

---

From: Ca By <[email-masked]>
Date: Thu, 21 Jun 2018 07:53:19 -0700

On Thu, Jun 14, 2018 at 10:34 AM Lee Howard <[email-masked]> wrote:

> I recall Windows Update 10 also has included CLAT support. I’m sure this
> will happen more and more in different OSs, as it makes a lot of sense in
> networks that may already have NAT64.
>
>
> No, I mean desktop/tablet OSs (Windows, Linux, Chrome OS, iOS, Android).
> It makes a lot of sense specially for devices that are “portable” and in
> fact that’s the idea behind Windows 10 Update. If you can use that device
> in a cellular IPv6-only network, should be expected that in a WiFi or wired
> IPv6-only network is behaving the same way when no native IPv4 is
> available. The other kind of OSs that you mention should either have
> already IPv6-only or rely in the CPE to provide IPv4 if they really need
> that.
>
>
> Also, tethering behind an IPv6-only phone is still no problem if you have
> Windows 10 and a NAT64 server, apparently: just fire up the CLAT.
>
>
>
> Yeah, talked to many, they often provide whatever you need if the order is
> big, our problem is still the retail market or orders to vendors that don’t
> have sufficient amount to demand a specific firmware feature set.
>
>
>

Yes, mobile is huge.

Also, i have seen 5G scenarios where pure play mobile and mobile / wireline
providers are choosing to deploy home broadband with wireless 5G.

If that mobile team had smashing success with 464xlat, i imagine they would
keep that model for 5G home broadband products.  After all, entering the
home broadband market as geenfield would be silly not to be a ipv6 first
service.

>
> Lee
>
>
>
> Lee
>
>
>
> Regarsd,
>
> Jordi
>
>
>
>
>
>
>
> *De: *v6ops <[email-masked]> <[email-masked]> en nombre
> de Lee Howard <[email-masked]> <[email-masked]>
> *Para: *<[email-masked]> <[email-masked]>
> really inferior to all other IPv6 transition technologies? -- Re: updating
> RFC8026 to support 464XLAT in draft-ietf-v6ops-transition-ipv4aas
>
>
>
>
>
>
>
> I speculate that DS-Lite and NAT64 had early mover advantage (i.e., early
> development), and were the only game in town. 464xlat only has that
> advantage in mobile, since handsets are the only major CLAT implementation.
>