Subject: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Jul 2018 16:26:06 -0400

Dear DNSOP,

Stuart Cheshire & David Schinazi have asked me to AD sponsor the
draft-cheshire-sudn-ipv4only-dot-arpa document
​[0]​
.

>From the document:
"The specification for how a client discovers its network's NAT64 prefix
[RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but
declares it to be a non-special name in that specification Domain Name
Reservation Considerations section.
Consequently, despite the well articulated special purpose of the name,
'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry
as a name with special properties.
This document formally declares the actual special properties of the name,
and adds similar declarations for the corresponding reverse mapping names."

RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") is
worth reading before reading this. If you are mainly a DNS person,
​this may be...surprising.

When reading draft-cheshire-sudn-ipv4only-dot-arpa there are a few things
​worth
 keeping in mind:

1: This is a fairly specialized function - it is used by NAT64 clients to
discover the prefix used for synthesis ("normal" people / applications
never need to resolve this). The main people who will deal with this are
mobile / stack vendors, and NAT64 providers.
2: RFC7050 has a large amount of text around DNSSEC, what to do with
DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64 device*,
not the ipv4only.arpa name.
3: Devices use this mechanism to discover the IPv6 prefix used for IPv6
address synthesis - different interfaces (e.g cellular and wifi) will have
different prefixes. This means that clients
must
​ ​
do this query using the resolver learned on / appropriate for that
interface. This is the main bit which is weird for a DNS person - the
response from the resolver for your cellular interface connected to
T-Mobile contains T-Mobile's NAT64 prefix; the response from the resolver
learnt over your wifi connection to the IETF network contains the NAT64
prefix you use on the IETF network. DNS isn't really being used here for
resolving names, rather DNS is being used a signalling mechanism (a rude
t-shirt springs to mind here).

What this draft does is:
1: record this in
​ ​
the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't
actually ask the IANA to update the registry.
2: requests that the IANA make ipv4only.arpa be an insecure delegation (see
#2 above) -
​this removes some special handling and complexity.​

3: specifies that you have to use the resolvers learn on an interface for
these queries. The whole purpose of these queries is to learn the *local*
NAT64 prefix - asking a public recursive isn't going to help you here.
4: This is under .arpa (and is already in wide use) - it doesn't have the
sticky policy problems that many SUD names have.

I've
​agreed
 to AD sponsor this, but would really appreciate your review and input.
RFC7050 is deployed - this improves / clarifies things.

1: The authors have previously presented this document at DNSOP meetings -
there was some discussion, but no real interest in adopting or shouts of
outrage about it.
2: I've asked the DNSOP chairs if I can use the DNSOP list for discussion
of this
​ ​
(and they agreed)
3: This was originally a product of the (now closed) BEHAVE WG - I've
spoken with Spencer (the BEHAVE AD) who has no objections.
4: I've asked the IESG and there were no objections either.
5: As this touches .arpa I'm also asking the IAB for input.
6: Dave Thaler (who was the document shepherd for RFC7050) has kindly
agreed to be shepherd for this document too.

W

[0]: note that they asked this before the current "ipv4only.arpa's
delegation should be insecure." thread -
https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY

--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Mark Andrews <[email-masked]>
Date: Thu, 5 Jul 2018 08:55:28 +1000

This paragraph is factually incorrect.

   Possibly this problem could have been avoided if we had forced all
   NAT64 gateways to use the same Well-Known Prefix for IPv6 address
   synthesis [RFC6052].  If the decision had been made to use a single
   fixed Well-Known Prefix, then there would have been no need for
   clients to discover the local network's NAT64 prefix, and no need for
   the 'ipv4only.arpa' [RFC7050] query.  However, that was not the
   decision that was made.

ipv4only.arpa would still be needed even when using the well known prefix
as it is used to discover if the well-known-prefix is being USED or not.

i.e. ipv4only.arpa performs 2 functions.
1) discovery of whether AAAA synthesis is occurring.
2) discovery of the prefix associated with that synthesis.

Forcing everyone to use the WKP would remove 2 but 1 would still remain.

This paragraph is wrong.

       Traditional recursive resolvers SHOULD NOT recognize
       'ipv4only.arpa' as special or give that name, or subdomains of
       that name, any special treatment.  The rationale for this is that
       a traditional recursive resolver, such as built in to a home
       gateway, may itself be downstream of a DNS64 recursive resolver.
       Passing though the 'ipv4only.arpa' queries to the upstream DNS64
       recursive resolver will allow the correct NAT64 prefix to be
       discovered.

A FORWARDING recursive server needs to pass through the queries.
(For BIND9 that is forward-only)
A ITERATIVE recursive server needs to answer the queries locally
except for ipv4only.arpa/DS.
(For BIND9 that is plain forwarding and not forwarding modes)

CPE recursive servers are often FORWARDING recursive servers.

There is not such thing as a TRADITIONAL recursive server.

This paragraph needs to be re-worded to permit DS queries for ipv4only.arpa
to hit the ARPA servers.  Also “domain" should be replaced with “zone”.  You
want the servers to serve the ipv4only.arpa zone.  

       All DNS64 recursive resolvers MUST recognize 'ipv4only.arpa' as
       special and MUST NOT attempt to look up NS records for it, or
       otherwise query authoritative name servers in an attempt to
       resolve this name.  Instead, DNS64 recursive resolvers MUST act
       as authoritative for this domain and generate immediate responses
       for all such queries.

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 5 Jul 2018 15:20:42 +1000

This paragraph needs to be re-written to ensure that the two reverse
zones (170.0.0.192.in-addr.arpa and 171.0.0.192.in-addr.arpa)
are created and are insecurely delegated from the parent zone.  Otherwise
there is no point in having recursive servers answer for them.  

       As a practical matter, only the administrators of the
       '192.in-addr.arpa' namespace will configure their name servers to
       be authoritative for these names and to generate the appropriate
       answers; all other authoritative name servers will not be
       configured to know anything about these names and will reject
       queries for them as they would reject queries for any other name
       about which they have no information.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 05 Jul 2018 12:05:49 +0200

>draft-cheshire-sudn-ipv4only-dot-arpa document

Section 7.1:
"Name resolution APIs and libraries MUST recognize 'ipv4only.arpa' as
"special and MUST give it special treatment. 

It seems to me that it is going way to far to require all DNS software to
implement support for a hack that abuses DNS for configuration management of
a rather poor IPv4 transition technology.

I think the more obvious approach is to formally deprecate RFC 7050 and
require nodes that need to do NAT64 address synthesis use one of the other
methods for obtaining the NAT64 prefix.

The only part of the draft that makes sense to me is to make ipv4only.arpa
an insecure delegation. 

Any other problems are better solved by deprecating RFC 7050.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 6 Jul 2018 08:37:51 +1000

Most of the special handling could be avoided if IANA was instructed to run the servers for ipv4only.arpa on dedicated addresses. Hosts routes could then be installed for those address that redirect traffic for ipv4only.arpa to the ISP’s DNS64/ipv4only.arpa server. 

Perhaps 2 address blocks could be allocated for this purpose. One for ipv4 and one for ipv6. 

-- 
Mark Andrews

On 5 Jul 2018, at 20:05, Philip Homburg <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Jul 2018 20:28:05 -0400

If special handling is required for ipv4only.arpa, isn't it also required
for home.arpa?   I tested this a bit and it doesn't appear to be necessary.
  I suppose a stub resolver could in principle walk down from the root and
notice the discrepancy in the NS records in the delegation, but in practice
they don't do this, because it's not necessary: if it were intended that
the zone be secure, it would be signed and have a signed delegation.

On Thu, Jul 5, 2018 at 6:37 PM, Mark Andrews <[email-masked]> wrote:

> Most of the special handling could be avoided if IANA was instructed to
> run the servers for ipv4only.arpa on dedicated addresses. Hosts routes
> could then be installed for those address that redirect traffic for
> ipv4only.arpa to the ISP’s DNS64/ipv4only.arpa server.
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 6 Jul 2018 10:54:23 +1000

> On 6 Jul 2018, at 10:28 am, Ted Lemon <[email-masked]> wrote:
> 
> If special handling is required for ipv4only.arpa, isn't it also required for home.arpa?   I tested this a bit and it doesn't appear to be necessary.   I suppose a stub resolver could in principle walk down from the root and notice the discrepancy in the NS records in the delegation, but in practice they don't do this, because it's not necessary: if it were intended that the zone be secure, it would be signed and have a signed delegation.

For HOME.ARPA the border is the CPE routers.  They can just intercept/redirect/proxy
queries as they are on path.  That said dedicated servers would allow for clients
to cleanly tie server properties to addresses (EDNS, DNS-COOKIE, whatever else we
dream up).  CPE’s could instantiate the well know address.  We don’t want to force
the CPE devices to have to do DPI for HOME.ARPA.

It would help but is not a critical.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 Jul 2018 10:33:18 +0200

> Most of the special
> handling could be avoided if IANA was instructed to run the servers
> for ipv4only.arpa on dedicated addresses. Hosts routes could then
> be installed for those address that redirect traffic for ipv4only.arpa
> to the ISPs DNS64/ipv4only.arpa server.
> 

If I understand the implications correctly, that would introduce a
completely new way of discovering the NAT64 prefix. We allready have 3,
do we need a 4th one?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 6 Jul 2018 18:50:44 +1000

All it does is ensure that the DNS queries get to the DNS64 server. 

-- 
Mark Andrews

---

From: Philip Homburg <[email-masked]>
Date: Fri, 06 Jul 2018 10:59:57 +0200

>All it does is ensure that the DNS queries get to the DNS64 server. 

The way RFC 7050 works that you send queries to your local recursive
resolver. The problem there is that if the user manually configured
a public recursive resolver then you don't learn the translation prefix.

In this context I don't see how serving ipv4only.arpa from dedicated addresses
would help. 

We can define a new prefix discovery protocol where the node that needs to
discover the prefix directly queries the authoritative servers for
ipv4only.arpa. That would solved the issue with manually configured 
resolvers. But it would also add yet another way off discovering the prefix
that needs to be supported.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 6 Jul 2018 21:36:51 +1000

> On 6 Jul 2018, at 6:59 pm, Philip Homburg <[email-masked]> wrote:
> 

When the local recursive server forwards the query to the ISP’s servers
they get the AAAA records.

With a dedicated prefix if the recursive server is iterative it will get
the delegation from the ARPA servers and find the ISP’s servers ipv4only.arpa 
which will return the prefix.  This is how I run my servers though it will
be a cold day in hell by the time my ISP delivers IPv6 let alone IPv6-only.
(I’ve only been asking for IPv6 since 2003).

This doesn’t help with those that send queries to 8.8.8.8, only DPI or
having the recursive server follow the learned DNS server for ipv4only.arpa 
will help with that scenario.

It’s all about closing off failure paths.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 07 Jul 2018 13:50:59 +0200

Hi Warren,

I agree this is needed, as RFC7050 is widely implemented, even in the case of RFC8305 for allowing a somehow “equivalent” functionality as the CLAT for literal addresses.

For the same reasons this document mention, in draft-ietf-v6ops-nat64-deployment, I have:

   The learning of the IPv6 prefix could be solved by means of adding

   the relevant AAAA records to the ipv4only.arpa. zone of the service

   provider recursive servers, i.e., if using the WKP (64:ff9b::/96):

               ipv4only.arpa.  SOA     . . 0 0 0 0 0

               ipv4only.arpa.  NS      .

               ipv4only.arpa.  AAAA    64:ff9b::192.0.0.170

               ipv4only.arpa.  AAAA    64:ff9b::192.0.0.171

               ipv4only.arpa.  A       192.0.0.170

               ipv4only.arpa.  A       192.0.0.171

and:

8. IANA Considerations

This document does not have any new specific IANA considerations.

Note: This section is assuming that https://www.rfc-editor.org/errata/eid5152 is resolved, otherwise, this section may include the required text to resolve the issue.

So I support this.

I wonder if we should ask DNSOP WG to reconsider this as a WG document and proceed the normal way.

Regards,

Jordi

De: DNSOP <[email-masked]> en nombre de Warren Kumari <[email-masked]>
Fecha: miércoles, 4 de julio de 2018, 22:27
Para: dnsop <[email-masked]>
Asunto: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

Dear DNSOP,

Stuart Cheshire & David Schinazi have asked me to AD sponsor the draft-cheshire-sudn-ipv4only-dot-arpa document

​[0]​

.

>From the document:
"The specification for how a client discovers its network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but declares it to be a non-special name in that specification Domain Name Reservation Considerations section.
Consequently, despite the well articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties.
This document formally declares the actual special properties of the name, and adds similar declarations for the corresponding reverse mapping names."

RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") is worth reading before reading this. If you are mainly a DNS person, 

​worth

 keeping in mind:

1: This is a fairly specialized function - it is used by NAT64 clients to discover the prefix used for synthesis ("normal" people / applications never need to resolve this). The main people who will deal with this are mobile / stack vendors, and NAT64 providers.
2: RFC7050 has a large amount of text around DNSSEC, what to do with DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64 device*, not the ipv4only.arpa name.
3: Devices use this mechanism to discover the IPv6 prefix used for IPv6 address synthesis - different interfaces (e.g cellular and wifi) will have different prefixes. This means that clients
must

​ ​

do this query using the resolver learned on / appropriate for that interface. This is the main bit which is weird for a DNS person - the response from the resolver for your cellular interface connected to T-Mobile contains T-Mobile's NAT64 prefix; the response from the resolver learnt over your wifi connection to the IETF network contains the NAT64 prefix you use on the IETF network. DNS isn't really being used here for resolving names, rather DNS is being used a signalling mechanism (a rude t-shirt springs to mind here). 

What this draft does is:
1: record this in

​ ​

the SUDN registry; RFC7050 answered the RFC6761 questions, but didn't actually ask the IANA to update the registry.
2: requests that the IANA make ipv4only.arpa be an insecure delegation (see #2 above) - 

3: specifies that you have to use the resolvers learn on an interface for these queries. The whole purpose of these queries is to learn the *local* NAT64 prefix - asking a public recursive isn't going to help you here.
4: This is under .arpa (and is already in wide use) - it doesn't have the sticky policy problems that many SUD names have.

I've 

​agreed

 to AD sponsor this, but would really appreciate your review and input. RFC7050 is deployed - this improves / clarifies things.

1: The authors have previously presented this document at DNSOP meetings - there was some discussion, but no real interest in adopting or shouts of outrage about it.
2: I've asked the DNSOP chairs if I can use the DNSOP list for discussion of this

​ ​

(and they agreed)
3: This was originally a product of the (now closed) BEHAVE WG - I've spoken with Spencer (the BEHAVE AD) who has no objections.
4: I've asked the IESG and there were no objections either.
5: As this touches .arpa I'm also asking the IAB for input.
6: Dave Thaler (who was the document shepherd for RFC7050) has kindly agreed to be shepherd for this document too.

W

[0]: note that they asked this before the current "ipv4only.arpa's delegation should be insecure." thread - https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

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

**********************************************
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: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 07 Jul 2018 13:55:37 +0200

I think deprecating RFC7050 will be a bad idea, there are too many implementations that really need that, while updating APIs/libraries to make sure they comply with this seems easier.

For example, we could have a DHCPv6 option, but in the cellular world DHCPv6 is not used ... and even in non-cellular, Android is not using it either.

Regards,

Jordi

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

De: DNSOP <[email-masked]> en nombre de Philip Homburg <[email-masked]>

Fecha: jueves, 5 de julio de 2018, 12:06

Para: <[email-masked]>

Asunto: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

    Section 7.1:

    an insecure delegation. 

    DNSOP mailing list

    [email-masked]

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 07 Jul 2018 14:05:02 +0200

I agree that users changing DNS is a problem, but as said in my previous email the alternative is forcing DHCPv6 (and an option for that) as a MUST for any IPv6 implementation, or forcing a MUST for PCP support, so then RFC7225 can be used.

I see both of those two options as a utopia right now.

Operators should try to avoid impact on DNS changed by users, and the best way to sort that problem (in a bigger % of cases) is making sure that if DNS64 is not used, it still works, which means supporting CLAT.

I think I've described the case for that in draft-ietf-v6ops-nat64-deployment.

Another possible alternative is also to tell the host implementations that if they can't find a NAT64 prefix using RFC7050, they should try with the WKP 64:ff9b::/96.

May be is something to consider in draft-ietf-6man-rfc6434-bis ?

Regards,

Jordi

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

Fecha: viernes, 6 de julio de 2018, 11:00

Para: <[email-masked]>

    would help. 

    

    DNSOP mailing list

    [email-masked]

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Jul 2018 18:26:02 +0200

> I think deprecating
> RFC7050 will be a bad idea, there are too many implementations that
> really need that, while updating APIs/libraries to make sure they
> comply with this seems easier.
> 
> For example, we could have a DHCPv6 option, but in the cellular
> world DHCPv6 is not used ... and even in non-cellular, Android is
> not using it either.

You are saying that countless stub resolvers should special case
ipv4only.arpa just because some operators don't want to deploy DHCPv6?

In many cases, there is not even a sensible mechanism to make this work.
A stub resolver often reads /etc/resolv.conf. If that contains just a
public resolver, then there is not much that can be done.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Jul 2018 18:31:34 +0200

I'm with you, ideally they should use DHCPv6 ... so tell them :-)

Regards,

Jordi

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

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

Fecha: lunes, 9 de julio de 2018, 18:26

Para: <[email-masked]>

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

---

From: Warren Kumari <[email-masked]>
Date: Thu, 19 Jul 2018 13:38:01 -0400

[ + DNSOP ]

On Mon, Jul 16, 2018 at 4:15 PM Christian Huitema <[email-masked]> wrote:
>
> I have never been a great fan of the DNS64 hacks. The DNS64
> specification, and RFC7050, are making a set of assumptions about the
> DNS infrastructure, the way stub resolvers are configured, and the
> possibility for intermediate resolvers to spoof AAAA records on the fly.
>
> One of these assumptions was already on shaky ground when the spec was
> written. It is only OK to spoof DNS records if the clients do not insist
> on DNSSEC. I don't have good numbers on clients, by I see measurements
> showing that over 90% of clients are served by recursive DNS resolvers
> that request DNSSEC validation (setting the DNSSEC OK option flage to
> 1), and over 50% of clients are served by recursive DNS resolvers that
> perform DNSSEC validation.
>
> Another assumption is that clients use DNS resolvers that are under the
> control of the network provider. Again, current measurement show that
> more than 25% of clients are server by third party DNS resolvers. That
> number is actually growing steadily. New DNS transports like DNS over
> TLS or DNS over HTTPS ensure that the exchanges between clients and
> third party resolvers will be pretty much immune to hacking by on-path
> middleboxes.
>
> Yet another assumption is that clients expect DNS responses to vary
> depending on the interface over which the DNS queries are sent. Again,
> this is incompatible with the current trend of using third party
> resolvers. That assumption might have worked when applications were only
> using DNS resolvers provided by the operating system. But then, we see a
> solid trend of moving transport services out of the kernel and into
> application libraries. QUIC is an example of that.
>
> These numbers and these trends tell me that technologies like DNS64 will
> be very hard to deploy, and also very unreliable when deployed. These
> technologies make a number of unwarranted assumptions about the nature
> of the DNS service. I don't think that attempting yet another patch like
> ipv4only.arpa will help all that much. In fact, I would much prefer to
> let 7050 die a deserved death, and maybe hasten that death by
> deprecating its status.

RFC7050 is already widely deployed -- I must admit that I personally
also view it as a hack, but I'd much rather that, as it will continue
to be used, it is at least well described, and has less pointy edges
on it....

W
>
> -- Christian Huitema
>
>
>
> On 7/15/2018 7:20 PM, Warren Kumari wrote:
> > Dear BEHAVE,
> >
> > I sent this to DNSOP a while back, but didn't think to send it to
> > behave as well - sorry.
> >
> > Please see below, and if you have comments, please comment in the
> > DNSOP list (so that we don't have overlapping discussions)...
> >
> >
> > Thank you!
> > W
> >
> >
> > ---------- Forwarded message ---------
> > From: Warren Kumari <[email-masked]>
> > Date: Wed, Jul 4, 2018 at 4:26 PM
> > Subject: AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
> > To: dnsop <[email-masked]>
> >
> >
> > Dear DNSOP,
> >
> > [0]
> > ..
> > "The specification for how a client discovers its network's NAT64
> > prefix [RFC7050] defines the special name 'ipv4only.arpa' for this
> > purpose, but declares it to be a non-special name in that
> > specification Domain Name Reservation Considerations section.
> > Consequently, despite the well articulated special purpose of the
> > name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names
> > registry as a name with special properties.
> > This document formally declares the actual special properties of the
> > name, and adds similar declarations for the corresponding reverse
> > mapping names."
> >
> > RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address
> > Synthesis") is worth reading before reading this. If you are mainly a
> > DNS person,
> > this may be...surprising.
> >
> >
> > worth
> > 1: This is a fairly specialized function - it is used by NAT64 clients
> > to discover the prefix used for synthesis ("normal" people /
> > applications never need to resolve this). The main people who will
> > deal with this are mobile / stack vendors, and NAT64 providers.
> > DNSSEC, etc. Note that this DNSSEC is for the FQDN of the *NAT64
> > device*, not the ipv4only.arpa name.
> > 3: Devices use this mechanism to discover the IPv6 prefix used for
> > IPv6 address synthesis - different interfaces (e.g cellular and wifi)
> > will have different prefixes. This means that clients
> > must
> > T-Mobile contains T-Mobile's NAT64 prefix; the response from the
> > resolver learnt over your wifi connection to the IETF network contains
> > the NAT64 prefix you use on the IETF network. DNS isn't really being
> > used here for resolving names, rather DNS is being used a signalling
> > mechanism (a rude t-shirt springs to mind here).
> >
> > What this draft does is:
> > 1: record this in
> > this removes some special handling and complexity.
> >
> > 3: specifies that you have to use the resolvers learn on an interface
> > for these queries. The whole purpose of these queries is to learn the
> > *local* NAT64 prefix - asking a public recursive isn't going to help
> > you here.
> > 4: This is under .arpa (and is already in wide use) - it doesn't have
> > the sticky policy problems that many SUD names have.
> >
> > I've
> > agreed
> >  to AD sponsor this, but would really appreciate your review and
> > input. RFC7050 is deployed - this improves / clarifies things.
> >
> > 1: The authors have previously presented this document at DNSOP
> > meetings - there was some discussion, but no real interest in adopting
> > or shouts of outrage about it.
> > regret at having chosen those particular rabid weasels and that pair
> > of pants.
> >    ---maf
> >
> >
> > --
> > regret at having chosen those particular rabid weasels and that pair
> > of pants.
> >    ---maf
> >
> > Behave mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/behave
>
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf