Hi,
As I already indicated several times, I think this is needed and agree with
this document. In fact, I've included a reference to this document in RFC8683.
Just a minor point regarding the abstract. I think it should be a single
paragraph, and moving most of the text to the intro (I've been
Hi there all,
Back in 2018, I've mentioned that I've agreed to AD sponsor
draft-cheshire-sudn-ipv4only-dot-arpa (
https://datatracker.ietf.org/doc/draft-cheshire-sudn-ipv4only-dot-arpa/
), and asked for review / feedback.
When RFC7050 was written, the name 'ipv4only.arpa' was not requested
to be
I'm with you, ideally they should use DHCPv6 ... so tell them :-)
Regards,
Jordi
-Mensaje original-
De: en nombre de Philip Homburg
Fecha: lunes, 9 de julio de 2018, 18:26
Para:
CC: JORDI PALET MARTINEZ
Asunto: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv
> 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 ev
e original-
De: DNSOP en nombre de Philip Homburg
Fecha: viernes, 6 de julio de 2018, 11:00
Para:
Asunto: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote:
>All it does is ensure that the DNS queries get
non-cellular, Android is not using it either.
Regards,
Jordi
-Mensaje original-
De: DNSOP en nombre de Philip Homburg
Fecha: jueves, 5 de julio de 2018, 12:06
Para:
Asunto: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
>draft-cheshire-s
proceed the normal way.
Regards,
Jordi
De: DNSOP en nombre de Warren Kumari
Fecha: miércoles, 4 de julio de 2018, 22:27
Para: dnsop
Asunto: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
Dear DNSOP,
Stuart Cheshire & David Schinazi have asked me to AD sponsor
> On 6 Jul 2018, at 6:59 pm, Philip Homburg wrote:
>
> In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote:
>> 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
In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote:
>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
All it does is ensure that the DNS queries get to the DNS64 server.
--
Mark Andrews
On 6 Jul 2018, at 18:33, Philip Homburg 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
> 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.
>
> Perhaps 2 address b
> On 6 Jul 2018, at 10:28 am, Ted Lemon 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
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 practic
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 cou
>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 f
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
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
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, bu
18 matches
Mail list logo
