IPv6 woes - RFC

Grant Taylor gtaylor at tnetconsulting.net
Sun Sep 5 21:22:54 UTC 2021


Hi Toke,

On 9/5/21 3:07 PM, Toke Høiland-Jørgensen via NANOG wrote:
> Well, that's what I used to do back when I didn't have native v6 and 
> ran into this issue: block v6 at the DNS level. I.e., simply filter 
> out all AAAA records for offending service providers. Pretty simple 
> to setup on your home router (it's usually one or a few TLDs per 
> service provider).

I agree that it's not hard to disable AAAA resolution for ... obstinate 
domains.  However, as you say, doing so means breaking DNSSEC more and 
more often.  Of course it's possible to do that, but it's now a second 
thing that's being done per obstinate domain.  :-(

I've considered null routing / rejecting IPv6 traffic to prefixes 
associated with the obstinate domains, but that's not really a set it 
and forget it thing.  Especially if ~> when the obstinate domains use 
shared hosting thus bring collateral damage into the mix.  And yet 
another (3rd) hack ~> workaround.  :-(

> It does fail if your clients do DNSSEC validation, but if you do that 
> at the router (or not at all) it should just work :)

Ya.  I've been doing the DNSSEC validation on the LAN local recursive 
DNS server for this reason.

> And yeah, it's an ugly hack that really shouldn't be necessary,

Yep.  How many ugly hacks does it take before one starts questioning if 
said ugly hack(s) is (are) the proper thing to do?

> but I found it worked quite well back when I used it (a handful of 
> years ago or so), and it keeps IPv6 active and working for everything 
> else...

If you're willing to (break) deal with DNSSEC, yes it does work.

> Another solution that I've used on occasion is to do your own 
> tunnelling: find a hosting provider that can provide you a VPS 
> with a v6 prefix and do your own tunnelling to that. This works by 
> virtue of being "under the radar" of the service providers that do 
> this kind of broken filtering, providing you can find a VPS provider 
> whose prefixes are not blacklisted for some other reason (like being 
> non-residential or something).

The operative phrase being "find a VPS provider whose prefixes are not 
blacklisted".  :-/

The workaround ~> hack is becoming more and more problematic year after 
year.

> Works equally well by tunnelling to a friend (or other trusted third 
> party) who does have native v6 and a prefix that's large enough to 
> sub-delegate some IP space to you.

I conceptually agree.  However, finding a friend with comparable 
bandwidth (~1 Gbps) /with/ native IPv6 is ... problematic.  It sort of 
means that you're into the VPS territory.  And now you're back to the 
whack-a-mole game of /which/ VPS provider.  :-/



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4013 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210905/e49313d4/attachment.bin>


More information about the NANOG mailing list