Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

From: Yannis Nikolopoulos <[email-masked]>
Date: Sun, 1 Jul 2018 20:18:06 +0300

Hello,

as with all such documents, this has a potential to help those starting 
with such a transition. So, I support the draft's intention

regards,

Yannis

On 06/27/2018 08:04 PM, Fred Baker wrote:
> Chair comment: I am interested in making this draft a working group draft. I think there is merit in it to do so. However, following our usual process, I need agreement from the working group. Consider this a solicitation for that. To do so, I'm looking for comments, supportive or otherwise, especially from operators. To respond to Barbara's question that she raised with ipv4aas, making it a working group document doesn't mean it's done, it means it's a work item as opposed to a suggestion to the working group.
>
> The rest of this is sans hats.
>
> Thanks for your new draft. Let me say that I am increasingly hearing about ISPs (cellular and broadband) that, in the words of one, "just don't want to allocate IPv4 addresses anymore", and are taking important steps toward turning IPv4 off within their networks in favor of IPv4 as a service. As you know, this falls into a couple of categories - those that are willing to offer a client-only IPv4-over-IPv6 or IPv4-cum-IPv6 service, and those that need to be able to somehow still put an IPv4 address into an A record (such as a company like Lumix that uses Dynamic DNS Update and firewall hole-punching to allow a residential user to access their surveillance system from an Android/iPhone app) and use it to send a message to the IPv4 server. So IMHO, this is an important draft, and it would be useful to get operator comment on it.
>
> I'm reviewing the draft. I'll bring up nits inline, and I may have some other thoughts as well.
>
>> Abstract
>>
>>     This document describes how NAT64 and 464XLAT can be deployed in an
>>     IPv6 operator (cellular and broadband) or enterprise network and the
> I suspect that this would read better as "IPv6 network, whether cellular ISP, broadband ISP, or enterprise".
>
>> 1.  Introduction
>>     To avoid changes in both, the IPv6-only hosts and the IPv4-only
>>     server, NAT64 requires also the use of a DNS64 ([RFC6147]), in charge
>>     for the synthesis of AAAA records from the A records.
> I would disagree that NAT64 "requires" DNS64. NAT64 requires that the destination IPv6 address contain an embedded IPv4 address. The source of that IPv4-embedded IPv6 address is up to the system that sent the packet. A CLAT (stateless translation as in RFC 7915) uses address synthesis with a PLAT translation prefix. MAP-T adds NAPT44 functionality to that with respect to the outbound IPv4 source address. A random IPv6 host accessing an IPv4-only peer might use DNS64, and the AAAA records might simply exist in DNS containing an IPv4-embedded IPv6 address. But the NAT64 function doesn't use, nor does it require, DNS64.
>
> BTW, SIIT-DC makes rather a point that RFC 6146 is a per-session (effectively NAPT) translator, and provides translation strictly at the IP layer. I suspect that is also a valid configuration, one that needs to be supported. In the 464XLAT case, I think it falls out, but I'll have to think about MAP-T.
>
>> 3.  NAT64 Deployment Scenarios
>>     Consequently, the perspective in this document is to broader those
> "broaden"
>
>> 3.1.2.  Service Provider offering 464XLAT, with DNS64
> Pictorial image of what I'm picturing:
>
>                            +----+                +----+
>                            |DNS |     +-----+    |DNS |
>                            |IPv6|     |DNS64|    |IPv4|
>                            +--+-+     +--+--+    +--+-+
>    +------+ v6 +------+       |          |          |
>    |      +----+      |    ,--+--.       |       ,--+--.
>    |Dual  |    | IPv6 |   /       \    ,-+-.    /       \
>    |Stack |  +-+Router+--(  IPv6   )--( PLAT)--(  IPv4   )
>    |Device|v4|C|      |   \Network/`.  `---'    \Network/
>    |      +--+L|      |    `--+--'   `.         /`-----'
>    +------+  |A|      |       |        `+------+
>              |T|      |    +--+---+     | Peer |
>              +-+------+    | IPv6 |     |Device|
>                            |Device|     +------+
>                            +------+
>
> The dual stack device obviously has an IPv4 and an IPv6 address, and the IPv4 side of it speaks through the CLAT. The IPv6 device has no IPv4 address. The peer device is the thing the "dual stack" device connects to, and might itself be dual stack or IPv4-only. In both cases, however, IPv4 access to the peer device will go through the PLAT.
>
> When the IPv6 device wants to talk with the peer device, it will need a AAAA record. In the dual stack case, that will contain a "usual" IPv6 address, and connectivity will be IPv6 end to end; in the IPv4-only case, it will need its IPv4 address embedded into the PLAT's translation prefix, which is or is functionally equivalent to DNS64.
>
> When the dual stack device wants to talk with the Peer Device, its IPv4 side will need an A record and the CLAT will do the address synthesis. Hence, no need for DNS64, and no requirement for it if it exists. The IPv6 side will need a AAAA record. If there is a native IPv6 address, that's fine, it will use that, and the system might be best served if the IPv6 connectivity is used. If there is a DNS64 AAAA record, the IPv4 side will use an A record and the CLAT and PLAT, and the IPv6 side will use the PLAT and the DNS64 address.
>
>> 3.1.3.  Service Provider offering 464XLAT, without DNS64
> The difference from the preceding section will be connectivity between an IPv6-only device and an IPv4-only peer. In the previous section, the IPv6 device will be unable to communicate with an IPv4-only peer, and the dual stack device will use its IPv4 side, the CLAT, and the PLAT.
>
>>     The major advantage of this scenario, using 464XLAT without DNS64, is
>>     that the service provider ensures that DNSSEC is never broken.
> Yes, but at the cost of IPv6-IPv4 connectivity.
>
>> 3.2.  Known to Work Under Special Conditions
>>
>>     The scenarios in this category are known not to work unless
> "known to not work"
>
> I'll probably have more comments later, but I'm sending this much now.
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Sun, 1 Jul 2018 17:42:07 -0700

OK, I see enough interest in taking this to the next step. I have instructed Jordi to refile draft-palet-v6ops-nat64-deployment as draft-ietf-v6ops-nat64-deployment.

> On Jul 1, 2018, at 10:18 AM, Yannis Nikolopoulos <[email-masked]> wrote:
> 
> Hello,
> 
> as with all such documents, this has a potential to help those starting with such a transition. So, I support the draft's intention
> 
> regards,
> 
> Yannis
>

---

From: <[email-masked]>
Date: Mon, 2 Jul 2018 09:39:26 +0000

Hi Jordi, all,

V6ops has published "NAT64 Deployment Options and Experience" (RFC7269). You may want position your draft vs. that RFC. 

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Fred Baker
> Envoyé : lundi 2 juillet 2018 02:42
> À : [email-masked] list
> Objet : Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
> 
> OK, I see enough interest in taking this to the next step. I have instructed
> Jordi to refile draft-palet-v6ops-nat64-deployment as draft-ietf-v6ops-nat64-
> deployment.
> 
> >> Chair comment: I am interested in making this draft a working group draft.
> I think there is merit in it to do so. However, following our usual process,
> I need agreement from the working group. Consider this a solicitation for
> that. To do so, I'm looking for comments, supportive or otherwise, especially
> from operators. To respond to Barbara's question that she raised with
> ipv4aas, making it a working group document doesn't mean it's done, it means
> it's a work item as opposed to a suggestion to the working group.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 02 Jul 2018 13:02:15 +0200

Thanks Med,

Sure, will do. Working already in an updated version, hopefully I can include it before the cut-off.

Regards,

Jordi

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

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

Fecha: lunes, 2 de julio de 2018, 11:40

Para: Fred Baker <[email-masked]>, "[email-masked] list" <[email-masked]>

Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

    Hi Jordi, all,

    Thank you. 

    Cheers,

    Med

    v6ops mailing list

    [email-masked]

**********************************************
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: Mon, 2 Jul 2018 12:18:10 -0700

I think your sketch is fine. There is one issue: the DNS64 has to perform address synthesis in the sense RFC 6877 uses the term. Yes, it will connect to the IPv4 network to access DNS and retrieve A records, and the IPv6 network to respond to DNS requests. It could also access the IPv6 network to get the relevant IPv6 prefix. In a network with multiple such prefixes, that could also be "interesting". I note that NAT64 implementations frequently have associated DNS64 implementations - not required, but simplifies knowing the relevant prefix. I connected DNS64 to the PLAT on the assumption that the PLAT talks to both, but certainly the drawing could show those directly.

> On Jun 28, 2018, at 12:46 PM, Lencse Gábor <[email-masked]> wrote:
> 
> Dear Fred and Jordi,
> 
> As an academic researcher, I think this draft makes sense and I support its adoption.
> 
> I have one minor comment regarding the figure below:
> 
> Connecting the DNS64 server to the PLAT device suggests me as if DNS64 were a kind of subfunction of PLAT. Of course it is not the case. They can be implemented by two independent devices: stateful NAT64 is usually implemented by a router and DNS64 is usually implemented by a DNS server.
> 
> I have been thinking about an alternative drawing like this:
> 
>                          +----+                +----+
>                          |DNS |     +-----+    |DNS |
>                          |IPv6|     |DNS64|    |IPv4|
>                          +--+-+     +-----+    +--+-+
>  +------+ v6 +------+       |      /       \      |
>  |      +----+      |    ,--+--.  /         \  ,--+--.
>  |Dual  |    | IPv6 |   /       \/   ,---.   \/       \
> What do you think of it?
> Best regards,
> Gabor

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Jul 2018 12:55:35 -0700

No hats, and a comment to get picked up next week, not before 23:59 UTC today.

I'm thinking further about the statement that "DNS64 breaks DNSSEC". I think that is just incorrect.

Here's the scenario. I'm thinking from the perspective of the user of DNS64 in

                         +----+                +----+
                         |DNS |     +-----+    |DNS |
                         |IPv6|     |DNS64|    |IPv4|
                         +--+-+     +-----+    +--+-+

which might be the IPv6 side of the "Dual Stack Device" or might be the "IPv6 Device". There are two sets of possibilities:

From an IPv6 perspective (either device), assuming the response contains correct data, a request for a AAAA record will yield one of four things:

1) NXDOMAIN
2) a signed AAAA record
3) an unsigned but valid native AAA record
4) an unsigned DNS64-generated IPv4-embedded IPv6 Address, the synthesis of an IPv6 prefix and an IPv4 address.

Barring a few exclusions, #4 will never happen if a native AAAA record is known by the DNS64 device (https://tools.ietf.org/html/rfc6147#section-5.1.1).

From an IPv4 perspective, the "Dual Stack Device" will also request an A record, and might get:

1) NXDOMAIN
2) a signed A record
3) an unsigned but valid native A record

In either case, NXDOMAIN (option #1) kind of closes the options. I should expect the device(s) will prefer a signed record to an unsigned one, which might mean that the "Dual Stack Device" prefers a signed A record to an unsigned DNS64 AAAA record. If it gets two signed records, it's cook's choice, and the "Dual Stack Device" is likely to prefer the signed AAAA record to the signed A record "just because". If it gets no signed records, I don't know offhand how it would tell a native address from a DNS64 address without parsing the address in the AAAA record. So it might use a generated address to get to the PLAT or let the CLAT create an address to get to the PLAT. But in either case, if DNS64 is in use, it gets to the PLAT, so it probably doesn't matter.

                +--------+--------+----------+
  IPv6:    IPv4:|NXDOMAIN|Signed A|Unsigned A|
 +--------------+========+========+==========+
 |NXDOMAIN      |  fail  |use A   | use A    |
 +--------------+--------+--------+----------+
 |Signed AAAA   |use AAAA|choice  | use AAAA |
 +--------------+--------+--------+----------+
 |Unsigned AAAA |use AAAA|use A   | choice   |
 +--------------+--------+--------+----------+
 |DNS64 AAAA    |use AAAA|use A   | choice   |
 +--------------+--------+--------+----------+

But I don't see any case in which an unsigned record replaces a signed record, or a signed record cannot be verified, which is what would break DNSSEC.

Hence, I don't think DNS64 "breaks" DNSSEC. It enables connectivity in cases where NXDOMAIN would disable connectivity, and the user goes through a NAT, with all the evils that implies.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 02 Jul 2018 22:17:36 +0200

Hi Fred,

I think is much simpler than all that.

DNSSEC is *only* broken if the dual-stack host is doing DNSSEC validation over the synthetized AAAA.

That's why, according Jen work, it only happens around 1.7% of the times, because not many OSs/apps/hosts do that (today). Of course, the goal of DNSSEC deployment is that it always done, so this % may increase.

Of course, it may happen as well in the ISP DNSSEC validator (or other validators being used, etc.), if is a DNS which is now aware of DNS64. For example, default DNS64 in bind, doesn't cause that problem, unless you wrongly configure it.

The point is if I'm an ISP, even if 1.7% is very small fraction, do I want that to come back to my call-center?

Even if I'm an ISP deploying DNS64, users change DNSs ... so they may break other aspects (NAT64 prefix discovery), or they will end up using 8.8.8.8 and of course this is not a DNS64.

I think I've explained that in the document but will make sure to review any relevant text where it is not clear.

Regards,

Jordi

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

De: Fred Baker <[email-masked]>

Fecha: lunes, 2 de julio de 2018, 21:55

Para: JORDI PALET MARTINEZ <[email-masked]>

CC: "[email-masked] list" <[email-masked]>

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

                             |DNS |     +-----+    |DNS |

                             |IPv6|     |DNS64|    |IPv4|

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

               |T|      |    +--+---+     | Peer |

                             |Device|     +------+

                             +------+

    1) NXDOMAIN

    2) a signed AAAA record

    1) NXDOMAIN

    2) a signed A record

---

From: Fred Baker <[email-masked]>
Date: Mon, 2 Jul 2018 13:40:46 -0700

> On Jul 2, 2018, at 1:17 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 

So you're worried about DNSSEC validation working through NAT64 in the case that the host is using the DNS service in the IPv4 network through the NAT64 device.

That doesn't have anything to do with DNS64; an a 464XLAT network, if we believe RFC 6877, the issue you raise happens in the absence of DNS64.

---

From: Ca By <[email-masked]>
Date: Mon, 2 Jul 2018 14:55:09 -0700

On Mon, Jul 2, 2018 at 1:41 PM Fred Baker <[email-masked]> wrote:

> So you're worried about DNSSEC validation working through NAT64 in the
> case that the host is using the DNS service in the IPv4 network through the
> NAT64 device.
>
> That doesn't have anything to do with DNS64; an a 464XLAT network, if we
> believe RFC 6877, the issue you raise happens in the absence of DNS64.

A good postion for the IETF to take is that one should only produce a
signed A if they can also produce a signed AAAA, which is not a tall order
these says

https://tools.ietf.org/html/draft-byrne-v6ops-dnssecaaaa-00

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 03 Jul 2018 09:50:36 +0200

Hi Fred,

In RFC6877, there is no mention of DNSSEC, in fact, this document explicitly mentions the case when DNS64 is not used, so I'm not sure I understand you comment on this.

Regards,

Jordi

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

Fecha: lunes, 2 de julio de 2018, 22:40

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 03 Jul 2018 09:53:32 +0200

Hi Cameron,

Fully agree, the issue is always that we don’t have the power to tell operators (content and app providers mainly in this case), “if you do DNSSEC, you must do IPv6”. May be thru ICANN/IANA …

I tried that already:

https://tools.ietf.org/html/draft-palet-sunset4-ipv6-ready-dns-00

Regards,

Jordi

De: Ca By <[email-masked]>
Fecha: lunes, 2 de julio de 2018, 23:55
Para: Fred Baker <[email-masked]>
CC: JORDI PALET MARTINEZ <[email-masked]>, "[email-masked] list" <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

A good postion for the IETF to take is that one should only produce a signed A if they can also produce a signed AAAA, which is not a tall order these says

---

From: Fred Baker <[email-masked]>
Date: Tue, 3 Jul 2018 10:10:56 -0700

A general note. I have wondered aloud about interest in several new drafts, and managed to miss Cameron's:

https://datatracker.ietf.org/doc/draft-byrne-v6ops-dnssecaaaa
https://tools.ietf.org/html/draft-byrne-v6ops-dnssecaaaa
  "DNSSEC Resource Record Should Include AAAA", Cameron Byrne, 2018-07-01,

If you want it on the agenda in two weeks, now would be the time to say so.

> Begin forwarded message:
> 
> From: Ca By <[email-masked]>
> Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
> Date: July 2, 2018 at 2:55:09 PM PDT
> To: Fred Baker <[email-masked]>
> Cc: JORDI PALET MARTINEZ <[email-masked]>, "[email-masked] list" <[email-masked]>
> 
> 
>

---

From: Ca By <[email-masked]>
Date: Tue, 3 Jul 2018 12:37:13 -0700

> If you want it on the agenda in two weeks, now would be the time to say so.

No, i will not be present.

But  i am interested in folks sending feedback on if this is useful.  The
goal of this I-D is to harmonize dns64 and dnssec deployment with an ideal
solution, as opposed to falling into a worst case where folks pick one or
the other.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 4 Jul 2018 12:45:53 +1000

While it will mitigate things it is a case of the tail wagging the dog and
really the correct solution is to make DNS64 historic.  DNS64 has always
been a case of tail-wagging-dog.

Accounting could have been fixed by “if next hop is IPv4 do accounting on
the that layer”.  That should have been a quick fix for the telcos.

It was claimed "This will be a short term hack”.  Yeh, really?

It was claimed “Hosts won’t need to be upgraded” yet all those hosts (cell
phones) supported personal hotspots with IPv4 clients.  Almost all cell phones
have some mechanism to support IPv4 clients today.

It was claimed “Than DNS64 was the only way that would let one know when it
was safe to turn off IPv4 as a service as nothing else would move the traffic
to IPv6”.  Yet we see traffic prefering IPv6 instead of IPv4 when DNS64 is not
in use.

It was claimed that DNS64/NAT64 was better than tunnels yet it has basically
all the same problems.  You have a smaller PMTU for translated packets.  Bring
with it PMTUD problems, mss re-writing in the NAT64 mitigates some of the for
TCP but the problem still exists.

It was argued at the time DNSSEC problems were not properly addressed and that
has been demonstrated to be true.

The IETF process itself doesn’t lead to got solutions because if you have argued
in the working group against something you get ignored at IETF last call with
“you argued that in the W-G and lost”.

There is NO REASON to keep DNS64.  The current crop of phones will work without
it.  464XLAT doesn’t need DNS64, it just need ipv4only.arpa configured on the
recursive servers.  For wireline / fixed wireless / personal hotspot there are
IPv4 only clients that have to be handled so DNS64/NAT64 was never enough.

Put DNS64 out of its misery.

> On 4 Jul 2018, at 5:37 am, Ca By <[email-masked]> wrote:
> 
> 
> 
> But  i am interested in folks sending feedback on if this is useful.  The goal of this I-D is to harmonize dns64 and dnssec deployment with an ideal solution, as opposed to falling into a worst case where folks pick one or the other.
> 
> 
> 
> > Begin forwarded message:
> > 
> > > On Jul 2, 2018, at 1:17 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel..es> wrote:
> > >

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

---

From: <[email-masked]>
Date: Wed, 4 Jul 2018 08:03:35 +0000

I find this a useful draft, this problematic outcome that the draft seeks to avoid will exist.
The draft is worthy of consideration.

From: v6ops [mailto:[email-masked]] On Behalf Of Ca By
Sent: 03 July 2018 20:37
To: Fred Baker <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [v6ops] Fwd: draft-palet-v6ops-nat64-deployment-02 comments

On Tue, Jul 3, 2018 at 10:11 AM Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
A general note. I have wondered aloud about interest in several new drafts, and managed to miss Cameron's:

> Begin forwarded message:
>
> From: Ca By <[email-masked]<mailto:[email-masked]>>
> To: Fred Baker <[email-masked]<mailto:[email-masked]>>
> Cc: JORDI PALET MARTINEZ <[email-masked]<mailto:jordi.palet@consulintel..es>>, "[email-masked]<mailto:[email-masked]> list" <[email-masked]<mailto:[email-masked]>>
>
>
>
> On Mon, Jul 2, 2018 at 1:41 PM Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:
>
>
> > On Jul 2, 2018, at 1:17 PM, JORDI PALET MARTINEZ <jordi.palet@consulintel..es<mailto:[email-masked]>> wrote:
> >
> [email-masked]<mailto:[email-masked]>

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

---

From: <[email-masked]>
Date: Wed, 4 Jul 2018 08:13:43 +0000

You are arguing to make DNS64 historic. I think that case is mutually exclusive.
What I mean is, I don't see that v6ops/IETF should stop trying to make DNS64 workable/compatible until the point it is retired. So it is not an argument against draft-byrne-v6ops-dnssecaaaa.

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Mark Andrews
Sent: 04 July 2018 03:46
To: Ca By <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

While it will mitigate things it is a case of the tail wagging the dog and really the correct solution is to make DNS64 historic.  DNS64 has always been a case of tail-wagging-dog.

Accounting could have been fixed by “if next hop is IPv4 do accounting on the that layer”.  That should have been a quick fix for the telcos.

It was claimed “Hosts won’t need to be upgraded” yet all those hosts (cell
phones) supported personal hotspots with IPv4 clients.  Almost all cell phones have some mechanism to support IPv4 clients today.

It was claimed “Than DNS64 was the only way that would let one know when it was safe to turn off IPv4 as a service as nothing else would move the traffic to IPv6”.  Yet we see traffic prefering IPv6 instead of IPv4 when DNS64 is not in use.

It was claimed that DNS64/NAT64 was better than tunnels yet it has basically all the same problems.  You have a smaller PMTU for translated packets.  Bring with it PMTUD problems, mss re-writing in the NAT64 mitigates some of the for TCP but the problem still exists.

It was argued at the time DNSSEC problems were not properly addressed and that has been demonstrated to be true.

The IETF process itself doesn’t lead to got solutions because if you have argued in the working group against something you get ignored at IETF last call with “you argued that in the W-G and lost”.

There is NO REASON to keep DNS64.  The current crop of phones will work without it.  464XLAT doesn’t need DNS64, it just need ipv4only.arpa configured on the recursive servers.  For wireline / fixed wireless / personal hotspot there are
IPv4 only clients that have to be handled so DNS64/NAT64 was never enough.

> > A good postion for the IETF to take is that one should only produce 
> > a signed A if they can also produce a signed AAAA, which is not a 
> > tall order these says
> >

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Jul 2018 10:17:41 +0200

Hi,

> https://tools.ietf.org/html/draft-byrne-v6ops-dnssecaaaa-00

Can we adopt this as a WG document?  Support!

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Kossut Tomasz - Hurt <[email-masked]>
Date: Tue, 10 Jul 2018 13:29:41 +0000

So far DNS64 is mandatory for iOS.

Orange Poland is running IPv6-only mobile network without DNS64 since 2012.

Cheers,
tk

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Jul 2018 15:01:03 +0200

Hi,

> Orange Poland is running IPv6-only mobile network without DNS64 since 2012.

So how do their customers reach all those ipv4-only websites out there, 
like github.com?

(I'm all for having IPv6-only things, but as long as the rest of the world
is dragging their feet, between a rock and a hard place...)

Gert Doering
        -- NetMaster

---

From: <[email-masked]>
Date: Thu, 12 Jul 2018 13:44:55 +0000

Hi Gert, 

No surprise out there: Address synthesis on the handset (CLAT) + NAT64 at the network side.

Cheers,
Med

> De : v6ops [mailto:[email-masked]] De la part de Gert Doering
> Envoyé : jeudi 12 juillet 2018 15:01
> À : KOSSUT Tomasz O-PL
> Cc : [email-masked]; [email-masked]

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 12 Jul 2018 15:50:11 +0000

Med,

A-AAAA address synthesis without DNS64 usage??

--
Cheers,
Rajiv

From: v6ops <[email-masked]> on behalf of "[email-masked]" <[email-masked]>
Date: Thursday, July 12, 2018 at 9:45 AM
To: Gert Doering <[email-masked]>, KOSSUT Tomasz O-PL <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

Hi Gert,

Cheers,
Med

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de Gert Doering
Envoyé : jeudi 12 juillet 2018 15:01
À : KOSSUT Tomasz O-PL
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
Hi,
SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael
Emmer

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 12 Jul 2018 17:56:29 +0200

If there is a CLAT, you don’t need synthesis. The impact is that the CLAT will do always NAT46, for any IPv4 destination, so in cellular devices, there may be some extra battery impact.

If you want to have synthesis, the safer approach is doing it in the “end-device”, this way even if this device is a DNSSEC validator, will not create a trouble. This is the way RFC8305 (HEv2) is using for literals.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de "Rajiv Asati (rajiva)" <rajiva=[email-masked]>
Fecha: jueves, 12 de julio de 2018, 17:50
Para: "[email-masked]" <[email-masked]>, Gert Doering <[email-masked]>, KOSSUT Tomasz O-PL <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

Med, 

-- 

Cheers,

Rajiv 

Hi Gert, 

Cheers,

Med

-----Message d'origine-----

À : KOSSUT Tomasz O-PL

Hi,

like github.com?

Gert Doering

         -- NetMaster

--

Emmer

v6ops mailing list

[email-masked]

v6ops mailing list

[email-masked]

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 12 Jul 2018 11:24:14 -0700

> On Jul 12, 2018, at 8:50 AM, Rajiv Asati (rajiva) <rajiva=[email-masked]> wrote:
> 

As described in RFC 7050/7051? Why not?

---

From: <[email-masked]>
Date: Fri, 13 Jul 2018 06:18:18 +0000

Hi Rajiv,

There are various ways to synthesize an IPv6 address based on an IPv4 address. DNS64 is a good candidate for applications making use of DNS. But even for those applications, address synthesis can also be done locally at the host (if the host knows the prefix). There are trade-offs.

Local address synthesis is required anyway for applications which do not make use of DNS (referrals, for example). See the work we have documented for SIP/SDP at: https://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-4.2.

Cheers,

Med

De : Rajiv Asati (rajiva) [mailto:[email-masked]]
Envoyé : jeudi 12 juillet 2018 17:50
À : BOUCADAIR Mohamed IMT/OLN; Gert Doering; KOSSUT Tomasz O-PL
Cc : [email-masked]; [email-masked]
Objet : Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

Med,

--
Cheers,
Rajiv

Hi Gert,

Cheers,
Med

-----Message d'origine-----
De : v6ops [mailto:[email-masked]] De la part de Gert Doering
Envoyé : jeudi 12 juillet 2018 15:01
À : KOSSUT Tomasz O-PL
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments
Hi,

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 16 Jul 2018 09:52:51 +0800

One of the debate about NAT64 is that it will slow down the transition process of IPv6, for it allow the existance of IPv4, especially in the content side, the OTT, especially smaller ones,  will have less incentive to move to IPv6. I do not mean that this point is right,  but this draft should give some explanation or clarification to this issue.

Thank you!
Chongfeng

[email-masked]
 
From: Fred Baker
Date: 2018-07-13 02:24
To: Rajiv Asati (rajiva)
CC: [email-masked]; [email-masked]; KOSSUT Tomasz O-PL
Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

---

From: Fred Baker <[email-masked]>
Date: Mon, 16 Jul 2018 07:47:48 -0400

> On Jul 15, 2018, at 9:52 PM, [email-masked] wrote:
> 

To my way of thinking, which may or may not be correct, that can be argued either way. The existence of stateless and stateful translation has enabled 464XLAT to be used to make some networks IPv6-only (the CLAT being stateless and the PLAT being stateful) although the entire world has not switched. I would expect that few would even consider turning IPv4 off without some means of accessing IPv4-hosted content. So the existence of translation hasn't slowed that rush; it has enabled it. On the other hand, if IPv4-hosted content is still accessible, there is also no pressure to make it IPv6-accessible.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jul 2018 00:02:59 +1200

Fred,

> To my way of thinking, which may or may not be correct, that can be argued either way. The existence of stateless and stateful translation has enabled 464XLAT to be used to make some networks IPv6-…

That's true, but it applies regardless of whether the client accesses the
IPv4 content via a dual stack ISP or a NAT64 solution. The only way to
force a content provider to use IPv6 is by removing its IPv4 clients.
I don't think many consumer ISPs are going to do that.

So what we need is for IPv4 to be slower and less functional than IPv6,
which we can only reasonably arrange by making IPv6 better...

    Brian

---

From: Ca By <[email-masked]>
Date: Mon, 16 Jul 2018 05:47:15 -0700

On Mon, Jul 16, 2018 at 5:03 AM Brian E Carpenter <
[email-masked]> wrote:

> >> One of the debate about NAT64 is that it will slow down the transition
> process of IPv6, for it allow the existance of IPv4, especially in the
> content side, the OTT, especially smaller ones,  will have less incentive
> to move to IPv6. I do not mean that this point is right,  but this draft
> should give some explanation or clarification to this issue.
> >
> > To my way of thinking, which may or may not be correct, that can be
> argued either way. The existence of stateless and stateful translation has
> enabled 464XLAT to be used to make some networks IPv6-only (the CLAT being
> stateless and the PLAT being stateful) although the entire world has not
> switched. I would expect that few would even consider turning IPv4 off
> without some means of accessing IPv4-hosted content. So the existence of
> translation hasn't slowed that rush; it has enabled it. On the other hand,
> if IPv4-hosted content is still accessible, there is also no pressure to
> make it IPv6-accessible.
>

While setting out with the objective of making a customer facing service
less good is impractical in a real business, the situation is that
nat64/dns64 engenders indirection and session creation latency , while
native ipv6 goes directly.

To that end, nat64 deployment encourages end to end ipv6

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 16 Jul 2018 09:15:41 -0400

I’m not sure this is a topic for this draft.

It can be argued that any transition mechanism is against “promoting” the IPv6 deployment. It is a balance between deploying IPv6 and making sure that the way we do it is not disruptive to create “too many” problems for customers.

Any transition mechanisms is imperfect, and this means that if that means that the same service being IPv6 native works better, sooner or later, it will be preferred.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de "[email-masked]" <[email-masked]>
Fecha: domingo, 15 de julio de 2018, 21:54
Para: "fredbaker.ietf" <[email-masked]>, "Rajiv Asati (rajiva)" <rajiva=[email-masked]>
CC: "[email-masked]" <[email-masked]>, v6ops <[email-masked]>, KOSSUT Tomasz O-PL <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

Thank you!

Chongfeng

From: Fred Baker

Date: 2018-07-13 02:24

To: Rajiv Asati (rajiva)

 

 

v6ops mailing list

[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Mon, 16 Jul 2018 14:04:44 -0400

> which we can only reasonably arrange by making IPv6 better...

You mean, by stopping adding features to it? :-)