| Newsgroups |
gmane.ietf.dnsop,gmane.ietf.v6ops |
| Message-ID |
<[email protected]> |
--===============5215602874887234569==
Content-Type: multipart/alternative;
boundary="Apple-Mail=_74A27B27-0B16-4D2C-B8B8-A26938083B07"
--Apple-Mail=_74A27B27-0B16-4D2C-B8B8-A26938083B07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Hi Mark,
You don=E2=80=99t think this is an implementation issue, not a DNS64 protoc=
ol? Or even the problem of RFC6052 that doesn=E2=80=99t accept RFC1918 addr=
esses?
This is being fixed by draft-ietf-v6ops-nat64-wkp-1918
Saludos,
Jordi
@jordipalet
> El 14 abr 2026, a las 22:42, Mark Andrews <[email protected]> escribi=C3=B3:
>=20
> Even local synthesis es wrong. It is at the wrong level in the stack. I =
had test fail on my Mac because curl decided that 10.53.0.4 was out on the =
internet despite it being an address on the loopback interface.
>=20
> The=20
> --=20
> Mark Andrews
>=20
>> On 15 Apr 2026, at 04:42, Ted Lemon <[email protected]> wrote:
>>=20
>> =EF=BB=BFI think it's also worth asking whether the devices that care ab=
out DNSSEC or DOH are the devices that don't do local synthesis. E.g. I'm p=
retty sure Apple devices will do local synthesis. I get the sense that Goog=
le devices will as well. Not sure about Windows, maybe Jen Linkova knows? A=
lso not sure about Linux, probably varies. Of course, if e.g. your browser =
is doing DoH, it may not bother with DNSSEC anyway, even if your local reso=
lver does do DNSSEC. But it had better do local synthesis, or it's not goin=
g to work in a v6only NAT64 environment regardless of whether or not DNS64 =
is present.
>>=20
>> But my point is, your printer that's downloading firmware probably isn't=
doing DNSSEC validation, although it should, and it's probably not using D=
oH to bypass the local resolver either.
>>=20
>>>> On 14 Apr 2026, at 19:57, Philip Homburg <[email protected]> =
wrote:
>>>>=20
>>>> I will like to see that long list of things that dont work with
>>>> DNS64 in the real world.
>>>=20
>>> I don't have a complete list, but here is a start. Let's assume a host
>>> that relies on DNS64 to obtain IPv4 connectivity. What doesn't work in
>>> that case:
>>> 1) An IPv4 literal
>>> 2) Any kind of local DNSSEC validation, either in the stub resolver or =
in
>>> a local DNS forwarder.
>>> 3) Any resolver configuration that by-passes the local (DNS64) resolver
>>> such as an (optionally DoH, DoT) connection to a public resolver.
>>> 4) Any kind of code that implement STUN for IPv4 but not for
>>> IPv6.
>>> 5) As far as I can tell, any kind of code that tries STUN on an IPv6 ad=
dress
>>> that was mapped by the DNS64 resolver.
>>>=20
>>> A few corners cases:
>>> 6) A DNS recursive resolver
>>> 7) DNS code that tries to disable EDNS Client Subnet
>>>=20
>>> I think there are more protocols that somehow encode whether IPv4 or IP=
v6
>>> is used, but this is just from the top of my head.
>>>=20
>>> _______________________________________________
>>> v6ops mailing list -- [email protected]
>>> To unsubscribe send an email to [email protected]
>>=20
>> _______________________________________________
>> v6ops mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>=20
> _______________________________________________
> v6ops mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.
--Apple-Mail=_74A27B27-0B16-4D2C-B8B8-A26938083B07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" c=
ontent=3D"text/html; charset=3Dutf-8"></head><body style=3D"overflow-wrap: =
break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Ma=
rk,<div><br></div><div>You don=E2=80=99t think this is an implementation is=
sue, not a DNS64 protocol? Or even the problem of RFC6052 that doesn=E2=80=
=99t accept RFC1918 addresses?</div><div><br></div><div>This is being fixed=
by draft-ietf-v6ops-nat64-wkp-1918</div><div><br id=3D"lineBreakAtBeg=
inningOfMessage"><div>
<div>Saludos,<br>Jordi<br><br>@jordipalet<br><br></div>
</div>
<div><br><blockquote type=3D"cite"><div>El 14 abr 2026, a las 22:42, Mark A=
ndrews <[email protected]> escribi=C3=B3:</div><br class=3D"Apple-interch=
ange-newline"><div><div>Even local synthesis es wrong. It is at the wrong l=
evel in the stack. I had test fail on my Mac because curl decided tha=
t 10.53.0.4 was out on the internet despite it being an address on the loop=
back interface.<br><br>The <br>-- <br>Mark Andrews<br><br><blockquote type=
=3D"cite">On 15 Apr 2026, at 04:42, Ted Lemon <[email protected]> wrot=
e:<br><br>=EF=BB=BFI think it's also worth asking whether the devices that =
care about DNSSEC or DOH are the devices that don't do local synthesis. E.g=
. I'm pretty sure Apple devices will do local synthesis. I get the sense th=
at Google devices will as well. Not sure about Windows, maybe Jen Linkova k=
nows? Also not sure about Linux, probably varies. Of course, if e.g. your b=
rowser is doing DoH, it may not bother with DNSSEC anyway, even if your loc=
al resolver does do DNSSEC. But it had better do local synthesis, or it's n=
ot going to work in a v6only NAT64 environment regardless of whether or not=
DNS64 is present.<br><br>But my point is, your printer that's downloading =
firmware probably isn't doing DNSSEC validation, although it should, and it=
's probably not using DoH to bypass the local resolver either.<br><br><bloc=
kquote type=3D"cite"><blockquote type=3D"cite">On 14 Apr 2026, at 19:57, Ph=
ilip Homburg <[email protected]> wrote:<br><br>I will like t=
o see that long list of things that dont work with<br>DNS64 in the real wor=
ld.<br></blockquote><br>I don't have a complete list, but here is a start. =
Let's assume a host<br>that relies on DNS64 to obtain IPv4 connectivity. Wh=
at doesn't work in<br>that case:<br>1) An IPv4 literal<br>2) Any kind of lo=
cal DNSSEC validation, either in the stub resolver or in<br> a local DNS fo=
rwarder.<br>3) Any resolver configuration that by-passes the local (DNS64) =
resolver<br> such as an (optionally DoH, DoT) connection to a public resolv=
er.<br>4) Any kind of code that implement STUN for IPv4 but not for<br> IPv=
6.<br>5) As far as I can tell, any kind of code that tries STUN on an IPv6 =
address<br> that was mapped by the DNS64 resolver.<br><br>A few corners cas=
es:<br>6) A DNS recursive resolver<br>7) DNS code that tries to disable EDN=
S Client Subnet<br><br>I think there are more protocols that somehow encode=
whether IPv4 or IPv6<br>is used, but this is just from the top of my head.=
<br><br>_______________________________________________<br>v6ops mailing li=
st -- [email protected]<br>To unsubscribe send an email to [email protected]=
g<br></blockquote><br>_______________________________________________<br>v6=
ops mailing list -- [email protected]<br>To unsubscribe send an email to v6ops=
[email protected]<br></blockquote><br>_______________________________________=
________<br>v6ops mailing list -- [email protected]<br>To unsubscribe send an =
email to [email protected]<br></div></div></blockquote></div><br></div><=
br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
This electronic message contains information which may be privileged or con=
fidential. The information is intended to be for the exclusive use of the i=
ndividual(s) named above and further non-explicilty authorized disclosure, =
copying, distribution or use of the contents of this information, even if p=
artially, including attached files, is strictly prohibited and will be cons=
idered a criminal offense. If you are not the intended recipient be aware t=
hat any disclosure, copying, distribution or use of the contents of this in=
formation, even if partially, including attached files, is strictly prohibi=
ted, will be considered a criminal offense, so you must reply to the origin=
al sender to inform about this communication and delete it.<br>
<br>
</body></html>
--Apple-Mail=_74A27B27-0B16-4D2C-B8B8-A26938083B07--
--===============5215602874887234569==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRE5TT1AgbWFp
bGluZyBsaXN0IC0tIGRuc29wQGlldGYub3JnClRvIHVuc3Vic2NyaWJlIHNlbmQgYW4gZW1haWwg
dG8gZG5zb3AtbGVhdmVAaWV0Zi5vcmcK
--===============5215602874887234569==--