Subject: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Oct 2017 15:36:43 +0200

Hi all,

I just submitted a document with guidelines for 464XLAT deployment.

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment/

This document was inspired in a recent discussion in the IETF general area exploder, when Christian Huitema suggested that it will be better to do it without DNS64 (https://www.ietf.org/mail-archive/web/ietf/current/msg104008.html). Mainly I worked in this document during August, but I was not able to finish it at that time (daily workload).

Note, that the main goal of the document was not related to my recent request to update 464XLAT status. However, I think it may be at least a starting point for that.

Happy to heard inputs!

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 9 de octubre de 2017, 15:30
Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
Asunto: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    A new version of I-D, draft-palet-v6ops-464xlat-deployment-00.txt
    has been successfully submitted by Jordi Palet Martinez and posted to the
    IETF repository.
    
    Name:		draft-palet-v6ops-464xlat-deployment
    Revision:	00
    Title:		464XLAT Deployment Guidelines in Operator Networks
    Document date:	2017-10-08
    Group:		Individual Submission
    Pages:		9
    URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-464xlat-deployment-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-deployment/
    Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat-deployment-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6ops-464xlat-deployment-00

    Abstract:
       This document describes how 464XLAT ([RFC6877]) can be deployed in an
       IPv6 operator network and the issues to be considered.

    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org.
    
    The IETF Secretariat

**********************************************
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: Ca By <[email-masked]>
Date: Mon, 9 Oct 2017 07:45:06 -0700

Hi,

I do not believe DNSSEC is worth supporting, it adds very little value, is
seldom deployed, and the security community in industry does not believe it
is worthy of deployment AFAIK (1).  The space you provide in the I-D
dedicated to DNSSEC is disproportionate given the title of the document.
One unfamiliar with the topics might things there is a material operational
issues with running 464XLAT in a world of DNSSEC.

I would suggest changing the title to "Experimental deployment
considerations for operators considering DNSSEC on IPv4-only servers"...
and since it is IPv4-only, it should move over to the v4ops.

The only people pushing DNSSEC or raising a fuss about DNSSEC with regards
to 464XLAT are DNSSEC vendors who may also have a competing DS-Lite product
that they think superior.  Which is fine, but i am bored of having one
voice shout out the same old yarn.

For a BCP, it may be best reflected that the *common* practice of operators
is to pay no mind to DNSSEC.

In summary, i don't care to have this group thumb wrestle over the merits
of 464XLAT or DNSSEC.  For anyone who actually cares, they can deploy end
to end ipv6 and they will not have to deal with  anything involving 464XLAT
, and their DNSSEC will work great regardless of the presence of 464xlat.

Regards,
CB

1) A) https://bugs.chromium.org/p/chromium/issues/detail?id=50874
1) B) https://sockpuppet.org/blog/2015/01/15/against-dnssec/

On Mon, Oct 9, 2017 at 6:36 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> This document was inspired in a recent discussion in the IETF general area
> exploder, when Christian Huitema suggested that it will be better to do it
> without DNS64 (https://www.ietf.org/mail-archive/web/ietf/current/
> msg104008.html). Mainly I worked in this document during August, but I
> was not able to finish it at that time (daily workload).
>
> Note, that the main goal of the document was not related to my recent
> request to update 464XLAT status. However, I think it may be at least a
> starting point for that.
>
> Happy to heard inputs!
>
> Regards,
> Jordi
>
>
>     URL:            https://www.ietf.org/internet-
> drafts/draft-palet-v6ops-464xlat-deployment-00.txt
>     Status:         https://datatracker.ietf.org/
> doc/draft-palet-v6ops-464xlat-deployment/
>     Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-palet-v6ops-464xlat-deployment-00
>
>
>     Abstract:
> 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.
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Ca By <[email-masked]>
Date: Mon, 9 Oct 2017 07:48:31 -0700

> and since it is IPv4-only, it should move over to the v4ops.

Sorry, this should read  "Experimental deployment considerations for
deploying DNSSEC records for IPv4-only names" Or  "IPv4-only DNSSEC names
considered harmful", in which case you may have an audience for this topic
in Sunset4

> For a BCP, it may be best reflected that the *common* practice of
> operators is to pay no mind to DNSSEC.
>
>> This document was inspired in a recent discussion in the IETF general
>> area exploder, when Christian Huitema suggested that it will be better to
>> do it without DNS64 (https://www.ietf.org/mail-arc
>> hive/web/ietf/current/msg104008.html). Mainly I worked in this document
>> during August, but I was not able to finish it at that time (daily
>> workload).
>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Oct 2017 17:04:32 +0200

Hi Cameron,

I heard your points … however my feeling is that doing it right (DNS validators aware of DNS64) is easy and feasible. Of course, it will be interesting to know if others agree on that.

I will be also interesting, if you want to comment, if in your network (and also for other operators that deployed 464XLAT in their mobile networks), you’re taking that in consideration (and consequently what approach you follow), or you don't care and for example, that means that users with devices doing tethering with a CLAT UE (Android, Windows), that try to validate DNSSEC (and break I guess) are calling your customer support desk or whatever …

Regards,
Jordi

-----Mensaje original-----
De: Ca By <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 9 de octubre de 2017, 16:48
Para: Jordi Palet Martinez <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    
    Hi,
    I do not believe DNSSEC is worth supporting, it adds very little value, is seldom deployed, and the security community in industry does not believe it is worthy of deployment AFAIK (1).  The space you provide in the I-D dedicated to DNSSEC is disproportionate given the title of the document.  One unfamiliar with the topics might things there is a material operational issues with running 464XLAT in a world of DNSSEC.
    
    I would suggest changing the title to "Experimental deployment considerations for operators considering DNSSEC on IPv4-only servers"... and since it is IPv4-only, it should move over to the v4ops.

    
    Sorry, this should read  "Experimental deployment considerations for deploying DNSSEC records for IPv4-only names" Or  "IPv4-only DNSSEC names considered harmful", in which case you may have an audience for this topic in Sunset4

    The only people pushing DNSSEC or raising a fuss about DNSSEC with regards to 464XLAT are DNSSEC vendors who may also have a competing DS-Lite product that they think superior.  Which is fine, but i am bored of having one voice shout out the same old yarn. 
    
    For a BCP, it may be best reflected that the *common* practice of operators is to pay no mind to DNSSEC.
    
    In summary, i don't care to have this group thumb wrestle over the merits of 464XLAT or DNSSEC.  For anyone who actually cares, they can deploy end to end ipv6 and they will not have to deal with  anything involving 464XLAT , and their DNSSEC will work great regardless of the presence of 464xlat.
    
    Regards,
    CB

    
    On Mon, Oct 9, 2017 at 6:36 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
    
    Hi all,

    

    Happy to heard inputs!
    
    Regards,
    Jordi

    -----Mensaje original-----
    De: <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 9 de octubre de 2017, 15:30
    Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
    Asunto: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

        Abstract:

    
        Please note that it may take a couple of minutes from the time of submission
        until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
    
        The IETF Secretariat

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 9 Oct 2017 17:16:53 +0200 (CEST)

> operators is to pay no mind to DNSSEC.

Comcast does DNSSEC validation from what I have understood. Google DNS 
(8.8.8.8) does the same.

80% of Internet users in Sweden sit behind a DNSSEC validating resolver.

Unfortunately at this point in time https://stats.labs.apnic.net/dnssec/US 
is not working so I can't give you numbers. DNSSEC has a non-trivial 
deployment base and needs to be taken into account. I wouldn't use that 
argument to stop DNS64 though.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ca By <[email-masked]>
Date: Mon, 9 Oct 2017 08:46:33 -0700

On Mon, Oct 9, 2017 at 8:04 AM, JORDI PALET MARTINEZ <
[email-masked]> wrote:

> Hi Cameron,
>
> I heard your points … however my feeling is that doing it right (DNS
> validators aware of DNS64) is easy and feasible. Of course, it will be
> interesting to know if others agree on that.
>

You are presupposing DNSSEC is a good idea.  The security community in
industry has not come to that conclusion.  On the other hand, security
practitioners do have to deal with DNSSEC amplification attack issues....

>
> I will be also interesting, if you want to comment, if in your network
> (and also for other operators that deployed 464XLAT in their mobile
> networks), you’re taking that in consideration (and consequently what
> approach you follow), or you don't care and for example, that means that
> users with devices doing tethering with a CLAT UE (Android, Windows), that
> try to validate DNSSEC (and break I guess) are calling your customer
> support desk or whatever …
>
>
In large 464xlat implementations i am aware of , there is  nothing done
with DNSSEC.  Never heard of a customer complaining about DNSSEC (wanting
it, having it fail, nothing ...).

The important point from a BCP perspective:  If customers dont care, and
operators dont care, and  if Android and iOS do not support DNSSEC, then it
does not exist in mobile and the whole point is moot.

We went down a similar path with DHCP on LTE interfaces... it does not
exist, not due to lack of IETF action, but due to lack of support and
desire to support.

> Asunto: Re: [v6ops] FW: New Version Notification for
> draft-palet-v6ops-464xlat-deployment-00.txt
>
>
>
>     I do not believe DNSSEC is worth supporting, it adds very little
> value, is seldom deployed, and the security community in industry does not
> believe it is worthy of deployment AFAIK (1).  The space you provide in the
> I-D dedicated to DNSSEC is disproportionate given the title of the
> document.  One unfamiliar with the topics might things there is a material
> operational issues with running 464XLAT in a world of DNSSEC.
>
>     The only people pushing DNSSEC or raising a fuss about DNSSEC with
> regards to 464XLAT are DNSSEC vendors who may also have a competing DS-Lite
> product that they think superior.  Which is fine, but i am bored of having
> one voice shout out the same old yarn.
>
>     In summary, i don't care to have this group thumb wrestle over the
> merits of 464XLAT or DNSSEC.  For anyone who actually cares, they can
> deploy end to end ipv6 and they will not have to deal with  anything
> involving 464XLAT , and their DNSSEC will work great regardless of the
> presence of 464xlat.
>
>     Regards,
>     CB
>
> do it without DNS64 (https://www.ietf.org/mail-archive/web/ietf/current/
>     This electronic message contains information which may be privileged
> or confidential. The information is intended to be for the exclusive use of

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Oct 2017 10:42:06 +0200

I’m sure we can have several different models to implement 464XLAT. Maybe I can rewrite the last section to show that more clearly, something like “if you don’t care about DNSSEC …, if you care …”. It happens with many protocols and I’m sure this ID can be improved, will love to have some other people to help on that!

Responses below, in-line.

-----Mensaje original-----
De: Ca By <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 9 de octubre de 2017, 17:46
Para: Jordi Palet Martinez <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    On Mon, Oct 9, 2017 at 8:04 AM, JORDI PALET MARTINEZ <[email-masked]> wrote:
    
    Hi Cameron,

    
    You are presupposing DNSSEC is a good idea.  The security community in industry has not come to that conclusion.  On the other hand, security practitioners do have to deal with DNSSEC amplification attack issues....

[Jordi] No, I’m not. I’m not taking any position regarding DNSSEC, just making sure that, while it is a standard, we like it or not, we don’t break it.

    
    
    In large 464xlat implementations i am aware of , there is  nothing done with DNSSEC.  Never heard of a customer complaining about DNSSEC (wanting it, having it fail, nothing ...). 
    
    The important point from a BCP perspective:  If customers dont care, and operators dont care, and  if Android and iOS do not support DNSSEC, then it does not exist in mobile and the whole point is moot.    

[Jordi] In this ID, I also show that you can just ignore DNSSEC, or not use DNS64, or other choices. I think is describing current practices and also what are others. I know at least one mobile operator (I recall is Orange Poland?) that is not using DNS64. If you have clients using tethering, even if the Android is not using DNSSEC, devices behind it, can use it. Also, I believe even if Android is not including in the OS DNSSEC support, apps can call libraries to use it. Last, but not least, I’m not focusing on just cellular networks here, more on the other way around, and even if in cellular networks DNSSEC is right now ignored, in many countries, non-cellular networks are trying to deploy it, so we can’t present only a deployment model that ignores it.
    
    We went down a similar path with DHCP on LTE interfaces... it does not exist, not due to lack of IETF action, but due to lack of support and desire to support.   

[Jordi] I don’t think is comparable, it makes a lot of sense, probably, not supporting it in smartphones. Furthermore, I’ve seen support of DHCP on LTE broadband routers.

    Regards,
    Jordi

    -----Mensaje original-----
    De: Ca By <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 9 de octubre de 2017, 16:48
    Para: Jordi Palet Martinez <[email-masked]>
    CC: IPv6 Ops WG <[email-masked]>
    Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    
        Hi,

    

    

    
        Regards,
        CB

    
    
        Hi all,

    

        Happy to heard inputs!
    
        Regards,
        Jordi

        -----Mensaje original-----
        De: <[email-masked]>
        Responder a: <[email-masked]>
        Fecha: lunes, 9 de octubre de 2017, 15:30
        Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
        Asunto: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

            Abstract:

    

            until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> <http://tools.ietf.org>.
    
            The IETF Secretariat

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Oct 2017 10:53:39 +0200

Hi Mikael,

So, in your opinion, if I understand it correctly:
1) DNSSEC must not be ignored
2) DNS64 should be supported

Could you agree in a document that describes different deployment models supporting or not 1, 2, above?

Regards,
Jordi

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Oct 2017 11:50:50 +0200 (CEST)

> 2) DNS64 should be supported

Correct. Don't know exactly how to do that, but that's what I'd like to 
see.

> Could you agree in a document that describes different deployment models supporting or not 1, 2, above?

I'm just speculating/brainstorming here... but let me write some text and 
see what people think:

1. A DNS64 resolver should do DNSSEC validation before synthesis.

2. A device behind DNS64 that intends to do DNSSEC validataion should 
identify the NAT64 prefix via the standard means, and then it should (if 
DNSSEC validation fails on AAAA question) do DNSSEC validation of A record 
and perform its own DNS64 function (if the AAAA answer that failed DNSSEC 
validation fell within the discovered NAT64 prefix).

I wasn't there during the DNS64 work, I don't know if these things were 
discussed and rejected for good reasons but... Have at me.

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Oct 2017 11:55:28 +0200

Jordi,

I think you are confused.
There is no DNS64 in 464XLAT.
You seem to be talking about NAT64 (RFC6146), not 464XLAT.

Ole

> On 10 Oct 2017, at 10:53, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Mikael,
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 10 Oct 2017 19:04:12 +0900

On 10 October 2017 at 18:50, Mikael Abrahamsson <[email-masked]> wrote:
> Correct. Don't know exactly how to do that, but that's what I'd like to see.
>

https://tools.ietf.org/html/rfc6147#section-6.2

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Oct 2017 12:10:25 +0200

Hi Ole,

It is not required, but using it allows traffic from non-literals to have a single translation at the NAT64.

Furthermore, I believe several big mobile operator network deployments, are using DNS64.

>From RFC6877:

The 464XLAT architecture described in this document uses IPv4/IPv6
   translation standardized in [RFC6145] and [RFC6146].  It does not
   require DNS64 [RFC6147] since an IPv4 host may simply send IPv4
   packets, including packets to an IPv4 DNS server, that will be
   translated to IPv6 on the customer-side translator (CLAT) and back to
   IPv4 on the provider-side translator (PLAT).  464XLAT networks may
   use DNS64 [RFC6147] to enable single stateful translation [RFC6146]
   instead of 464XLAT double translation where possible.  The 464XLAT
   architecture encourages the IPv6 transition by making IPv4 services
   reachable across IPv6-only networks and providing IPv6 and IPv4
   connectivity to single-stack IPv4 or IPv6 servers and peers.

Regards,
Jordi

-----Mensaje original-----
De: Ole Troan <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 10 de octubre de 2017, 12:03
Para: Jordi Palet Martinez <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    Jordi,

    Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 10 Oct 2017 12:18:38 +0200

Jordi,

> It is not required, but using it allows traffic from non-literals to have a single translation at the NAT64.

Yes, but then it is not 464XLAT. It is NAT64. It's a lot easier having a discussion if we agree on the terminology.

Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Oct 2017 12:31:44 +0200

I don’t think we agree here …

464XLAT sometimes uses just the NAT64 (and optionally DNS64), sometimes uses the CLAT+NAT64 (and optionally DNS64).

In the scope of 464XLAT we talk about both kind of “traffic flows”.

If we talk about just NAT64, you are forced to use the DNS64, otherwise the host don’t have a way to reach IPv4 destinations. It is true that a host itself may include kind of “DNS64” in the stack (for example HEv2 is doing that), but this is not (today) a general case in OS, I think.

Regards,
Jordi

-----Mensaje original-----
De: Ole Troan <[email-masked]>
Responder a: <[email-masked]>
Fecha: martes, 10 de octubre de 2017, 12:24
Para: Jordi Palet Martinez <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    Jordi,

    
    Ole

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Oct 2017 14:25:01 +1100

In message <[email-masked]>, Ole Troan writ
> You seem to be talking about NAT64 (RFC6146), not 464XLAT.

Last I looked, the only defined method for the prefix discovery
involved getting modified AAAA responses (RFC 7050) and that does
not work as ipv4only.arpa is currently configured is it is in a
signed zone which has a trusted path to the root.  RFC 7050 needs
to be updated to state that ipv4only.arpa MUST NOT have a DNSSEC
trusted path from the root.  Give ARPA is signed this means that
ipv4only.arpa needs to be unsigned.  I believe this requires more
than an erratra to achieve.

Now you don't have to use a DNS64 server to generate these answers
but you do have to consider DNSSEC as the response looks like a
MITM attack which is what DNSSEC is designed to detect and reject.

Note: "ad" is set which means that the answer validated as "secure".

;; BADCOOKIE, retrying.

; <<>> DiG 9.12.0a1+hotspot+add-prefetch+marka <<>> ipv4only.arpa +dnssec aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19821
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: c7a3435d3f04ba8eb3fbcdd659dd8bbdf1f958b61f7e862a (good)
;; QUESTION SECTION:
;ipv4only.arpa.			IN	AAAA

;; AUTHORITY SECTION:
ipv4only.arpa.		3600	IN	SOA	sns.dns.icann.org. noc.dns.icann.org. 2017050357 7200 3600 604800 3600
ipv4only.arpa.		3600	IN	RRSIG	SOA 8 2 3600 20171030000756 20171009051708 64003 ipv4only.arpa. eWpK1JWwEDKzh4V+cMF1cHjOTKPfCZAMsllUV3Qcm6PAirGDaq3L+++w D11eTnQ+vOhDl6ZKHjn+frongrEKog8N6Yow1fpK9d6BXl9WbMk2YJz/ Bj17bY5BReehTuFhy3O6EEMm5iCqH/OktRseG3r9J+XY7MPrxqA4bfdB hgnD+kY=
ipv4only.arpa.		3600	IN	RRSIG	NSEC 8 2 3600 20171030172618 20171009051708 64003 ipv4only.arpa. iQh28xkJBapmluL4n+PJyV7CmQbiLxKWuDgtSHYChhu0fUuO7P+cWRNp LnerjWtiJxTKudfC7fpJLGcugYb6kca7aysnYojkQCvTschg0Cje/iD1 U/q3l9FAEquSPkydQ2S5oFYWTqDB8cKomyEFq/mSckv9hwWeNPlBIS1V bwGZpbo=
ipv4only.arpa.		3600	IN	NSEC	ipv4only.arpa. A NS SOA TXT RRSIG NSEC DNSKEY

;; Query time: 729 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct 11 14:10:53 AEDT 2017
;; MSG SIZE  rcvd: 515

Mark

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

---

From: Czerwonka Michał 1 - Hurt <[email-masked]>
Date: Thu, 12 Oct 2017 12:04:53 +0000

Orange Poland does not use DNS64 ( except"ipv4only.arpa" only)
DNS64 is the worst feature in the transition to ipv6. We need to discover nat64 prefix  only and then do 464XLAT CLAT + DNS DS

https://www.ripe.net/participate/meetings/regional-meetings/ipv6-at-orange-poland-tomasz-kossut.pdf

BR,
Mcz

-----Mensaje original-----
De: Ca By <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 9 de octubre de 2017, 17:46
Para: Jordi Palet Martinez <[email-masked]>
CC: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    
    Hi Cameron,

    

    

    

    
    Regards,
    Jordi

    -----Mensaje original-----
    De: Ca By <[email-masked]>
    Responder a: <[email-masked]>
    Fecha: lunes, 9 de octubre de 2017, 16:48
    Para: Jordi Palet Martinez <[email-masked]>
    CC: IPv6 Ops WG <[email-masked]>
    Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    
        Hi,

    

    

    
        Regards,
        CB

    
    
        Hi all,

    

        Happy to heard inputs!
    
        Regards,
        Jordi

        -----Mensaje original-----
        De: <[email-masked]>
        Responder a: <[email-masked]>
        Fecha: lunes, 9 de octubre de 2017, 15:30
        Para: Jordi Palet <[email-masked]>, Jordi Palet Martinez <[email-masked]>
        Asunto: New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

            Abstract:

    

            The IETF Secretariat

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 Oct 2017 11:48:02 -0700

On Oct 12, 2017, at 05:04, Czerwonka Michał 1 - Hurt <[email-masked]> wrote:
> https://www.ripe.net/participate/meetings/regional-meetings/ipv6-at-orange-poland-tomasz-kossut.pdf <https://www.ripe.net/participate/meetings/regional-meetings/ipv6-at-orange-poland-tomasz-kossut.pdf>

When the 464XLAT document was in draft stages, some of us warned that its interoperability problems with DNS64 could lead operators to do this, with the predictable result that hosts on IPv6-only link layers, e.g. 6LoWPAN, would be unable to discover public IPv4 services unless they were invested with sufficient compute resources to implement a full IPv4 stack including the CLAT. Operators are externalizing that cost onto subscribers and the application developers that build technology for them.

Those costs are why everything on those IPv6-only link layers are now being forced to communicate through tunnels at border gateways that connect them to walled-garden services. It’s not like nobody foresaw this consequence. We foresaw it, and decided we liked it. Can we please stop pretending that walled gardens are a bad thing now? We obviously don’t believe that anymore, if we ever did.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 12 Oct 2017 22:07:26 +0200

Hi James,

I fail to see the problem. I think if you build an IPv6-only link layer device (6LoWPAN), that needs to communicate with servers across the Internet, the logic thing, is to make sure that those remote servers are IPv6 enabled.

I don’t see the need/case for a “new” 6LoWPAN device trying to reach an old IPv4-only server AND not getting that upgraded.

Despite, that, I agree that DNS64 sort out the problem, and that’s why in my document I suggest that DNS64 must be there, at the same time that we take measures to avoid breaking DNSSEC.

So, repeating somehow same question I did to Mikael a couple of emails ago … Do you think DNS64 must be there if measures to avoid breaking DNSSEC are taken ?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de james woodyatt <[email-masked]>
Responder a: <[email-masked]>
Fecha: jueves, 12 de octubre de 2017, 20:48
Para: IPv6 Ops WG <[email-masked]>
Asunto: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

    

    

    --james woodyatt <[email-masked]>

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 Oct 2017 14:43:32 -0700

On Oct 12, 2017, at 13:07, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> I fail to see the problem.

Yes, I see that.

> I think if you build an IPv6-only link layer device (6LoWPAN), that needs to communicate with servers across the Internet, the logic thing, is to make sure that those remote servers are IPv6 enabled.

My problem: I want to provide a reference platform for independent 3rd-parties to use in building Internet applications on devices with IPv6-only network interfaces. Those devices are very constrained resource environments, and putting an IPv4 stack on them would apply a significant multiplier to their unit cost. So, to make them capable of communicating with legacy application servers that are not yet IPv6-enabled, we’ve entirely given up on making them reachable via the public Internet. They are only reachable through tunnels to walled-garden services, which are capable of proxying the legacy IPv4 services at the application layer. Which means 3rd-parties have to put their devices into a supported walled-garden if they want their applications to work.

> I don’t see the need/case for a “new” 6LoWPAN device trying to reach an old IPv4-only server AND not getting that upgraded.

It’s only a problem if you don’t want to be forced into deploying walled gardens everywhere to act as application proxies for every little hardware device in your personal network. Many people think nothing of that problem. It’s a very common view. I only want to observe that the various large transitional cloud computing providers (*cough* *cough*) are, without doubt, happy to see that view reinforced by supposedly neutral standards bodies, and I’m certainly not criticizing it here. Just pointing out that the occasional lip service we see paid here to the idea that walled gardens are a problem is pretty silly at this point.

> So, repeating somehow same question I did to Mikael a couple of emails ago … Do you think DNS64 must be there if measures to avoid breaking DNSSEC are taken ?

I did at one time, but I’ve given up on trying to stop 464XLAT from animating the shambling undead corpse of IPv4.

---

From: Paul Marks <[email-masked]>
Date: Thu, 12 Oct 2017 15:47:50 -0700

On Thu, Oct 12, 2017 at 2:43 PM, james woodyatt <[email-masked]> wrote:

>
> My problem: I want to provide a reference platform for independent
> 3rd-parties to use in building Internet applications on devices with
> IPv6-only network interfaces. Those devices are very constrained resource
> environments, and putting an IPv4 stack on them would apply a significant
> multiplier to their unit cost. So, to make them capable of communicating
> with legacy application servers that are not yet IPv6-enabled, we’ve
> entirely given up on making them reachable via the public Internet. They
> are only reachable through tunnels to walled-garden services, which are
> capable of proxying the legacy IPv4 services at the application layer.
> Which means 3rd-parties have to put their devices into a supported
> walled-garden if they want their applications to work.
>
>
>
If the 6LoWPAN device has only an IPv6 stack, then how is it able to tunnel
to the walled garden in the first place?

That would either require 100% IPv6 deployment among users, or an
IPv6->IPv4 gateway on the local link.  Couldn't that gateway just as easily
run a NAT64/DNS64 for the 6LoWPAN device?

Or are you saying that the standards bodies have failed because we haven't
reached 100% end-to-end IPv6 deployment, such that tunnelling to a private
network is the only reliable way to accept incoming connections?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Oct 2017 11:40:07 +1100

In message <[email-masked]>, Mikael Abrah
> discussed and rejected for good reasons but... Have at me.

Behave failed to listen to the fact that there is NO WAY TO TELL
IF A CLIENT IS VALIDATING RESPONSES.  It decided that CD=0 meant
not validating which is NOT the case.

This is what the DNSSEC flag bits mean

	DO=0		Not validating

	DO=1 CD=0	May be validating  (DNS64 says not validating)
			(These are the type of queries many validating
			client issue by default)

	DO=1 CD=1	May be validating, do not validate responses to
			any request you make to resolve this query, just
			include them in your response.
			(DNS64 says is validating)

Both DO=1 CD=0 and DO=1 CD=1 queries need to be sent by validating
clients to get answers through a validating recursive server. DO=1
CD=0 allow the recursive server to reject spoofed or otherwise bad
responses to queries it makes on the clients behalf and retry.  DO=1
CD=1 allow the responses to get through a recusive server with bad
trust anchors or a bad clock.

Just sending DO=1 CD=1 means that there is no reject or retry and
no control over which authoritative servers are queries.  Multiple
authoritative servers are tries with DO=1 CD=0 queries on the clients
behalf.  DO=1 CD=1 are NOT REQUIRED to be validated and are not
cached unless they have been validated as secure or insecure.  They
MUST NOT be returned to DO=1 CD=0 or DO=0 queries without being
validated.

If all the servers are correctly configured and there is no spoofing
happening it doesn't matter if you send DO=1 CD=0 or DO=1 CD=1 when
you are validating you will get a response that will validate as
secure / insecure.  What you send when this is not the case however
is critical.

This was pointed out numerous times but behave went ahead and wrote
a specification that DOES NOT WORK and cannot be made to work (it
is mathematically impossible to do) and due to rough consensus it
was passed.  The "crazy DNSSEC guy" was not listened too.

Mark

---

From: james woodyatt <[email-masked]>
Date: Fri, 13 Oct 2017 11:18:51 -0700

On Oct 12, 2017, at 15:47, Paul Marks <[email-masked]> wrote:
> 
> If the 6LoWPAN device has only an IPv6 stack, then how is it able to tunnel to the walled garden in the first place?

The tunnel to the walled garden terminates at the border gateway to the 6LoWPAN network. The sensor/actuators remain IPv6-only and communicate only via 6LoWPAN. An example of such a device: the Nest Detect™. That particular example is one where it’s not easy to see how it might be useful to deploy it outside the walled garden gated by the Nest Guard. However, my point is that it’s prohibitively difficult to generalize the platform into one where it *would* be useful to deploy it outside a walled garden.

Because IPv6 transition is stalled by continuing efforts to keep the zombie corpse of IPv4 sufficiently animated to depress the utility of IPv6 to public application content providers. It’s 2017, the IPv4 free pool is exhausted, and still there are many Internet service providers going strong without having any IPv6 transition even on their roadmap.

Residential customers don’t care that their ISP has no IPv6 support. They don’t have to care. In 2017. Because IPv4 still works fine for them.

> That would either require 100% IPv6 deployment among users, or an IPv6->IPv4 gateway on the local link.  Couldn't that gateway just as easily run a NAT64/DNS64 for the 6LoWPAN device?

It could, but once you have such a tight coupling between the sensor/actuator and its corresponding border gateway, the tendency is to build the wall around the whole system. The perceived need to support direct reachability between the sensor/actuator clients and their services on the public Internet evaporates at that point. The 6LoWPAN network only needs to be just a private subnet of the walled-garden, and every device on the link can be inside the garden.

This means, of course, that people will have multiple 6LoWPAN meshes in their homes, one for each walled-garden they have joined, and the devices won’t be able to communicate over the walls without intermediation between them by large transnational cloud computing providers. But, who cares about little problems like that? Certainly not first-kilometer Internet service providers, and large transnational cloud computing providers will certainly be happy about the barriers to market entry such problems pose.

Is there anyone else with an important stake to consider?

> Or are you saying that the standards bodies have failed because we haven't reached 100% end-to-end IPv6 deployment, such that tunnelling to a private network is the only reliable way to accept incoming connections?

I wouldn’t say that standards bodies have failed, so much as I would say that network operators have subverted the effort to set a standard that would succeed, and now tunneling from large scale compute centers to exclusive walled-garden networks at the residential premises are the only way to make these applications interoperate reliably.

---

From: "Heatley,N,Nick,TQB R" <[email-masked]>
Date: Wed, 18 Oct 2017 08:51:58 +0000

James,
Have you also ruled out the IPv6-only device performing the synthesis of an AAAA based on A itself? Remo
Nick

From: v6ops [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: 12 October 2017 22:44
To: [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] New Version Notification for draft-palet-v6ops-464xlat-deployment-00.txt

On Oct 12, 2017, at 13:07, JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>> wrote:

Yes, I see that.

--james woodyatt <[email-masked]<mailto:[email-masked]>>