Mailing List Archive

Thomas Schäfer wrote on 27/07/2023 10:16:
> Is there a paper, source, a person with high reputation, who can clearly
> confirm that?

yes and no. In terms of authoritative status of ipv4-mapped ipv6
addresses, these are not globally reachable addresses, which means that
if you jam them into a DNS view which is publicly visible, the behaviour
is at best undefined, and more than likely to cause breakage:

> https://www.iana.org/assignments/iana-ipv6-special-registry

See the "Globally Reachable" field. If you're looking for canon, then
this is probably what you need. Note that it doesn't say anything about
your own internal administrative domain.

There's no document that I'm aware of which says you must not insert
ipv4-mapped ipv6 addresses into the DNS. Generally the IETF steers
clear from issuing documents which advise against doing stupid things
because, well, they're stupid and if you point a gun at your foot, then
take off the safety, then pull the trigger, you'll shoot your foot off,
and you'll quickly learn why doing all these things is considered to be
a bad idea.

In terms of arguing, sometimes people cannot be argued with.

Nick

Hi Thomas,

On Thu, Jul 27, 2023 at 11:16:07AM +0200, Thomas Sch?fer wrote:

> I think
>
> IPv4-Mapped IPv6 Addresses (defined in
> https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.2
> )
> | 80 bits | 16 | 32 bits |
> +--------------------------------------+--------------------------+
> |0000..............................0000|FFFF| IPv4 address |
> +--------------------------------------+----+---------------------+
>
>
>
> must not be announced via DNS-AAAA-records.

same thought, but surprisingly(?) me could not find any recommendation in that
direction. Other than RFC 1918, which has remarks to the extent that
indirect references to private address space are discouraged (final para of section 3),
no such text seems to exist for IPv4-Mapped IPv6 Addresses. Then again,
interpretation of RFC1918 space is context/location dependent which is
not the case for IPv4-Mapped IPv6 Addresses.

The purpose and semantics of IPv4-Mapped IPv6 Addresses apparently has
evolved over time, including a standards track protocol that might have
resulted in actual packets bearing those addresses 'on the wire'
(cf. RFC 4942, section 2.2. IPv4-Mapped IPv6 Addresses).

As Nick pointed out

>> https://www.iana.org/assignments/iana-ipv6-special-registry
>
> See the "Globally Reachable" field. If you're looking for canon, then
> this is probably what you need. Note that it doesn't say anything about
> your own internal administrative domain.

this address space got tagged

| Source | False |
| Destination | False |

in RFC 6890 and even prior to that, in RFC 5156. It is not blatantly
obvious, though, where this determination came from, even though the
aforementioned RFC 4942 might have been instrumental.

Otherwise, the purpose of IPv4-Mapped IPv6 Addresses is limited to

o APIs that offer an 'IPv6 only' interface to applications, so those can be
v4 agnostic

o a variety of protocols that make use of IP addresses (in payload) avoiding
the address family distinction or sub-typing (like PCP, HNCP, ...)

With that in mind, and given that DNS has distinct RR types for v4 and v6, one could
argue that IPv4-Mapped IPv6 Addresses within AAAA RRs are maybe misplaced.
Luckily, they also don't seem to be too popular in the wild ...

> I am despairing in a discussion with a company.

Don't.

-Peter

Hi,

Thank you for answers so far.
Since the support case is public and you may interested in bad
entertainment (today is SysAdminDay)

You can read it here:

https://forum.newrelic.com/s/hubtopic/aAX8W0000015BUvWAM/bamnrdatanet-resolves-with-wrong-aaaarecords

My today's highlight is:

"We did this to drive down the cost with our DNS provider. Queries for
AAAA records that didn't exist, followed by queries for A records, was
costing us significantly and we needed to alleviate that."

Just one comment to the players there:

"new relic" is providing that service to Postbank/DeutscheBank (and
probably more)

ns1, the service with high costs for none existing AAAA-Records, is a
IBM company.

Big companies big mistakes....

Have a nice weekend!

Thomas





--

There’s no place like ::1

Thomas Schäfer (Systemverwaltung)
Ludwig-Maximilians-Universität
Centrum für Informations- und Sprachverarbeitung
Oettingenstraße 67 Raum C109
80538 München ? +49/89/2180-9706 ? +49/89/2180-9701

Thomas Schäfer wrote on 28/07/2023 09:04:
> "We did this to drive down the cost with our DNS provider. Queries for
> AAAA records that didn't exist, followed by queries for A records,
> was costing us significantly and we needed to alleviate that."
>
> "Our AAAA answers follow the standards, and our local dual-stack
> testing has shown no issues."

There's a long tail of ipv6 implementations, and some of them are very
broken indeed. Thoughts and prayers to their user base.

Nick

On Fri, Jul 28, 2023 at 10:27:56AM +0100, Nick Hilliard wrote:

> > "Our AAAA answers follow the standards, and our local dual-stack
> > testing has shown no issues."

so, if it works for them with their applications ...
Looks like no damage.

> There's a long tail of ipv6 implementations, and some of them are very
> broken indeed. Thoughts and prayers to their user base.

While the economic incentives for the case at hand sound 'interesting',
operationally this could inspire some measurements - in a different
sphere, like if someone had, say, ads based tooling.

-Peter

Peter Koch wrote on 28/07/2023 11:15:
> While the economic incentives for the case at hand sound 'interesting',
> operationally this could inspire some measurements - in a different
> sphere, like if someone had, say, ads based tooling.

yep, no doubt there's a case to be made about the query load, but
there's also a case to implement client side measurements here. Whatever
about the impact of happy eyeballs - which should alleviate a chunk of
the theoretical blast radius of a misconfig like this - if an
ipv4-mapped ipv6 address is presented as a reply to a quad-a record,
then unless there are mitigations in the client resolver code, it will
appear as a candidate destination address in the tcp stack. If the
client host is dual-stacked, or ipv6-single-stacked, then unless there
are mitigations in the client tcp stack, a tcp connection attempt may be
made.

I.e. the pathways for this configuration to produce the intended result
depend on explicit mitigations in either or both of the client resolver
and the client tcp stack. Good engineering shouldn't depend on quirk
workarounds.

Nick

On Fri, 2023-07-28 at 10:04 +0200, Thomas Schäfer wrote:

> "We did this to drive down the cost with our DNS provider. Queries for
> AAAA records that didn't exist, followed by queries for A records, was
> costing us significantly and we needed to alleviate that."

Interesting. On my dual-stacked Linux system, this does not reduce the
amount of DNS traffic, as both the A and AAAA queries are issued
simultaneously. Do other platforms behave differently?

Or could it be that their DNS provider's price for a empty (NODATA)
answer is higher than for a regular answer?

If none of the above, I fail to see what they actually gain by doing
this. That said, the approach appears to work well enough as far as I
can tell.

Tore

Am 28.07.23 um 10:04 schrieb Thomas Schäfer:
> Hi,

>
> My today's highlight is:
>
> "We did this to drive down the cost with our DNS provider. Queries for
> AAAA records that didn't exist, followed by queries for A records, was
> costing us significantly and we needed to alleviate that."
>

Now I asked ns1 for the pricing scheme.
To be continued.

Regards,
Thomas

Hi,

On Fri, Jul 28, 2023 at 11:40:24AM +0100, Nick Hilliard wrote:
> If the client host is dual-stacked, or
> ipv6-single-stacked, then unless there are mitigations in the client tcp
> stack, a tcp connection attempt may be made.

This is is all OS stack quirks, but if "all you have is a single socket
on a dual-stack machines", v4 connects will show up on a v6 socket as
magic v6 addresses...

So, in reverse, by specifying v4-mapped v6 addresses on the socket API
(on OSes that have that particular kernel path (*)), you get a v4 connect
on a v6 socket.

Thus, for a dual stack machine, I expect this to actually work on many
cases - and on a v6-only machine, I expect this to fail fast, because
the network layer will return "no route to host" or something.

But indeed, testing :-)

Gert Doering
-- NetMaster

(*) OpenVPN ran into this in many interesting ways, with replies like
"oh we just forgot to implement this particular edge case" from kernel
developers... in retrospective, we should all have followed the OpenBSD
approach to make v6-sockets v6, and v4-sockets v4, and disallow any
mixing.
--
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

> On 28 Jul 2023, at 15:56, Gert Doering <gert@space.net> wrote:
[..]
> (*) OpenVPN ran into this in many interesting ways, with replies like
> "oh we just forgot to implement this particular edge case" from kernel
> developers... in retrospective, we should all have followed the OpenBSD
> approach to make v6-sockets v6, and v4-sockets v4, and disallow any
> mixing.

The reason for existence of that was to be able to just change code from AF_INET to AF_INET6 for a socket and then not have to bother with multiple sockets (IPv4 + IPv6) or heck multiple IPv4 + IPv6 addresses...

Indeed, that makes porting code to support IPv6 easier, "look mommy, s/AF_INET/AF_INET6/ it does IPv6" but in the end not the desired results, especially when later one has to bolt on Happy Eyeballs etc anyway :)

The other reason for the map is of course to just store IPv4 inside a IPv6 "address" as 16 bytes can store both. There, there is an argument to have it, especially considering the amount of memory on devices in 1995...

Thus in the end, it should likely not have existed, but eh ;)

Greets,
Jeroen

Hi,

On Fri, Jul 28, 2023 at 04:27:21PM +0200, Jeroen Massar wrote:
> > On 28 Jul 2023, at 15:56, Gert Doering <gert@space.net> wrote:
> [..]
> > (*) OpenVPN ran into this in many interesting ways, with replies like
> > "oh we just forgot to implement this particular edge case" from kernel
> > developers... in retrospective, we should all have followed the OpenBSD
> > approach to make v6-sockets v6, and v4-sockets v4, and disallow any
> > mixing.
>
> The reason for existence of that [..]

Oh, I do fully understand how we got there, and for OpenVPN, this means
we can still slack along without implementing proper multi-socket support
(pointing to kernel folks instead, and complaining about missing kernel
code paths...).

But as I said, in retrospective, code would be better if we had never
taken that shortcut - less rarely-used kernel code (which is never good),
and possibly even better socket APIs in userland to just take care of all
this sh*t...

gert
--
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

Hi, charging a company who do not implement ipv6 for their services. sounds like a smart idea :-D Or did I read something wrong? Enjoy the weekend! Ulrich Gesendet: Freitag, 28. Juli 2023 um 10:04 Uhr
Von: "Thomas Sch&auml;fer" <thomas@cis.uni-muenchen.de>
An: ipv6-ops@lists.cluenet.de
Betreff: Re: IPv4-Mapped IPv6 Address used in DNS with AAAA-records [..]
My today&#39;s highlight is:

"We did this to drive down the cost with our DNS provider. Queries for
AAAA records that didn&#39;t exist, followed by queries for A records, was
costing us significantly and we needed to alleviate that."
[..]
ns1, the service with high costs for none existing AAAA-Records, is a
IBM company.
[..]
There&rsquo;s no place like ::1

Thomas Sch&auml;fer (Systemverwaltung)
Ludwig-Maximilians-Universit&auml;t
Centrum f&uuml;r Informations- und Sprachverarbeitung
Oettingenstra&szlig;e 67 Raum C109
80538 M&uuml;nchen &#9742; +49/89/2180-9706 &#8507; +49/89/2180-9701

On 28-Jul-23 21:27, Nick Hilliard wrote:
> Thomas Schäfer wrote on 28/07/2023 09:04:
>> "We did this to drive down the cost with our DNS provider. Queries for
>> AAAA records that didn't exist, followed by queries for A records,
>> was costing us significantly and we needed to alleviate that."
>>
>> "Our AAAA answers follow the standards, and our local dual-stack
>> testing has shown no issues."
>
> There's a long tail of ipv6 implementations, and some of them are very
> broken indeed. Thoughts and prayers to their user base.

No issues?

I just stuck this in the hosts file on Windows: ::ffff:8.8.8.8 www.google.com
and now I can't reach Google any more... Error code: SSL_ERROR_BAD_CERT_DOMAIN

So I would be surprised if they have got this working in all cases without
any such issues. At least they have to configure tolerant certs.

Interestingly, since Thomas mentioned IBM, ::ffff:23.43.149.178 www.ibm.com
works without certificate errors (and that's via Akamai). So not everybody
is as strict with their certificates as Google.

Brian

On 7/28/23 16:28, Brian E Carpenter wrote:

> I just stuck this in the hosts file on Windows: ::ffff:8.8.8.8
> www.google.com
> and now I can't reach Google any more... Error code:
> SSL_ERROR_BAD_CERT_DOMAIN

www.google.com isn't hosted on 8.8.8.8.

Try:

::ffff:8.8.8.8 dns.google

for a valid test.

> So I would be surprised if they have got this working in all cases without
> any such issues. At least they have to configure tolerant certs.
>
> Interestingly, since Thomas mentioned IBM, ::ffff:23.43.149.178 www.ibm.com
> works without certificate errors (and that's via Akamai). So not everybody
> is as strict with their certificates as Google.
>
>    Brian

--
Jay Hennigan - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

On 29-Jul-23 11:58, Jay Hennigan wrote:
> On 7/28/23 16:28, Brian E Carpenter wrote:
>
>> I just stuck this in the hosts file on Windows: ::ffff:8.8.8.8
>> www.google.com
>> and now I can't reach Google any more... Error code:
>> SSL_ERROR_BAD_CERT_DOMAIN
>
> www.google.com isn't hosted on 8.8.8.8.

Oh spit, brain glitch there...

>
> Try:
>
> ::ffff:8.8.8.8 dns.google

I don't think that serves HTTPS, but
::ffff:142.250.204.4 www.google.com
works OK, so maybe the horrible hack does actually work.

Sorry for the interruption.

Brian


>
> for a valid test.
>
>> So I would be surprised if they have got this working in all cases without
>> any such issues. At least they have to configure tolerant certs.
>>
>> Interestingly, since Thomas mentioned IBM, ::ffff:23.43.149.178 www.ibm.com
>> works without certificate errors (and that's via Akamai). So not everybody
>> is as strict with their certificates as Google.
>>
>>    Brian
>

On 7/28/23 18:50, Brian E Carpenter wrote:
> On 29-Jul-23 11:58, Jay Hennigan wrote:
>>
>> Try:
>>
>> ::ffff:8.8.8.8  dns.google
>
> I don't think that serves HTTPS,

Actually, it does. https://dns.google/

--
Jay Hennigan - jay@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

Hi,

On Sat, Jul 29, 2023 at 11:28:30AM +1200, Brian E Carpenter wrote:
> I just stuck this in the hosts file on Windows: ::ffff:8.8.8.8 www.google.com
> and now I can't reach Google any more... Error code: SSL_ERROR_BAD_CERT_DOMAIN

Well, I could argue that is because 8.8.8.8 is not *www*.google.com :-)

Try

www.google.com has address 142.251.36.164

-> ::ffff:142.251.36.164

instead...

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

Dan Wing has been tracking these for years. You can see the current set
and history of these going back to 2009:
https://www.employees.org/~dwing/aaaa-stats/

Current set from Alexa top-N is
https://www.employees.org/~dwing/aaaa-stats/ipv6-map.2023-07-29_0800.txt
contains mostly this case right now, but also a few others from opendns.com:

> bam-cell.cell.nr-data.net has IPv4 has IPv6 ::ffff:162.247.243.30 (errno=22) (time=0.000037)bam-cell.nr-data.net has IPv4 has IPv6 ::ffff:162.247.243.30 (errno=22) (time=0.000005)bam.cell.nr-data.net has IPv4 has IPv6 ::ffff:162.247.243.29 (errno=22) (time=0.000007)bam.eu01.nr-data.net has IPv4 has IPv6 ::ffff:185.221.87.23 (errno=22) (time=0.000003)bam.nr-data.net has IPv4 has IPv6 ::ffff:162.247.243.29 (errno=22) (time=0.000006)block.opendns.com has IPv4 has IPv6 ::ffff:208.67.219.157 (errno=22) (time=0.000003)bpb.opendns.com has IPv4 has IPv6 ::ffff:208.67.219.158 (errno=22) (time=0.000006)fastly-mobile-collector.newrelic.com has IPv4 has IPv6 ::ffff:162.247.243.24 (errno=22) (time=0.000003)fastly-tls12-bam-cell.nr-data.net has IPv4 has IPv6 ::ffff:162.247.243.30 (errno=22) (time=0.000002)fastly-tls12-bam.nr-data.net has IPv4 has IPv6 ::ffff:162.247.243.29 (errno=22) (time=0.000003)malware.opendns.com has IPv4 has IPv6 ::ffff:208.67.219.152 (errno=22) (time=0.000004)
>
> As long as you have IPv4 on a client then most clients seem to just work.
Amusingly, curl will actually connect to this with "-6" but will just use
IPv4 (which might be a bug):

$ curl -v -6 bam-cell.nr-data.net
> * Trying ::ffff:162.247.243.30:80...
> * TCP_NODELAY set
> * Connected to bam-cell.nr-data.net (::ffff:162.247.243.30) port 80 (#0)
> > GET / HTTP/1.1
> > Host: bam-cell.nr-data.net
> > User-Agent: curl/7.68.0
> [...]
>








On Fri, Jul 28, 2023 at 1:05?AM Thomas Schäfer <thomas@cis.uni-muenchen.de>
wrote:

> Hi,
>
> Thank you for answers so far.
> Since the support case is public and you may interested in bad
> entertainment (today is SysAdminDay)
>
> You can read it here:
>
>
> https://forum.newrelic.com/s/hubtopic/aAX8W0000015BUvWAM/bamnrdatanet-resolves-with-wrong-aaaarecords
>
> My today's highlight is:
>
> "We did this to drive down the cost with our DNS provider. Queries for
> AAAA records that didn't exist, followed by queries for A records, was
> costing us significantly and we needed to alleviate that."
>
> Just one comment to the players there:
>
> "new relic" is providing that service to Postbank/DeutscheBank (and
> probably more)
>
> ns1, the service with high costs for none existing AAAA-Records, is a
> IBM company.
>
> Big companies big mistakes....
>
> Have a nice weekend!
>
> Thomas
>
>
>
>
>
> --
>
> There’s no place like ::1
>
> Thomas Schäfer (Systemverwaltung)
> Ludwig-Maximilians-Universität
> Centrum für Informations- und Sprachverarbeitung
> Oettingenstraße 67 Raum C109
> 80538 München ? +49/89/2180-9706 ? +49/89/2180-9701
>
>
>

Hi,

On Sat, Jul 29, 2023 at 03:33:16PM -0700, Erik Nygren wrote:
> > As long as you have IPv4 on a client then most clients seem to just work.
> Amusingly, curl will actually connect to this with "-6" but will just use
> IPv4 (which might be a bug):

That's not a particular "curl" beviour, just the way dual-stacked IPv6
sockets work (so, it won't work on OpenBSD).

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

Ond?ej Caletka

(https://mastodon.social/@Oskar456/110807321268094472 )

was so nice to provide a test setup.


So I've set up some testing DNS records. The results are a bit
surprising. Try it yourself:

https://ipv4-mapped.0skar.cz/ (AAAA with IPv4-mapped, should not be
reachable from anywhere)
https://ipv4-mapped-pref.0skar.cz/ (dual stack A plus AAAA with IPv4-mapped)


Despite it works in most dual stack environments and most
ipv6-mostly/only environments, it breaks when nat64 without clat is used.

Thomas


--

There’s no place like ::1

Thomas Schäfer (Systemverwaltung)
Ludwig-Maximilians-Universität
Centrum für Informations- und Sprachverarbeitung
Oettingenstraße 67 Raum C109
80538 München ? +49/89/2180-9706 ? +49/89/2180-9701

On 31-Jul-23 22:11, Thomas Schäfer wrote:
> Ond?ej Caletka
>
> (https://mastodon.social/@Oskar456/110807321268094472 )
>
> was so nice to provide a test setup.
>
>
> So I've set up some testing DNS records. The results are a bit
> surprising. Try it yourself:
>
> https://ipv4-mapped.0skar.cz/ (AAAA with IPv4-mapped, should not be
> reachable from anywhere)
> https://ipv4-mapped-pref.0skar.cz/ (dual stack A plus AAAA with IPv4-mapped)

Both OK from my Auckland NZ dual stack, and Firefox/SixOrNot reports an IPv4
connection (as expected).

>
> Despite it works in most dual stack environments and most
> ipv6-mostly/only environments, it breaks when nat64 without clat is used.

This seems normal. I like discovering things that are broken with nat64.

Thanks Thomas and Ond?ej,

Brian