Mailing List Archive

1 2 3 4 5 6 7 8 9 ... 11  View All
IPv6 woes - RFC
Hi,

Does anyone have any recommendation for a viable IPv6 tunnel broker /
provider in the U.S.A. /other/ /than/ Hurricane Electric?

I reluctantly just disabled IPv6 on my home network, provided by
Hurricane Electric, because multiple services my wife uses are objecting
to H.E.'s IPv6 address space as so called VPN or proxy provider.
Netflix, HBO Max, Pandora, and other services that I can't remember at
the moment have all objected to H.E.

Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS,
null routing prefixes, firewalling, etc., seems even more wrong.

Is there a contemporary option for home users like myself who's ISP
doesn't offer native IPv6?

Please consider this to be a Request for Comments and suggestions.

Thank you and have a nice day / weekend / holiday.



--
Grant. . . .
unix || die
Re: IPv6 woes - RFC [ In reply to ]
> On 20210904, at 22:26, Grant Taylor via NANOG <nanog@nanog.org> wrote:
>
> Hi,
>
> Does anyone have any recommendation for a viable IPv6 tunnel broker / provider in the U.S.A. /other/ /than/ Hurricane Electric?

SixXS shut down 4 years ago, to get ISPs to move their butts... as long as there are tunnels, they do not have a business case.

See also https://www.sixxs.net/sunset/ and the "Call Your ISP for IPv6" thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 along with plans.

You people keep on giving money to ISPs that are not providing the service you want.

> I reluctantly just disabled IPv6 on my home network, provided by Hurricane Electric, because multiple services my wife uses are objecting to H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO Max, Pandora, and other services that I can't remember at the moment have all objected to H.E

Tunnels are VPNs

So, that makes sense that services that need to 'protect their IP' (silly property) because they did not figure out people might live anywhere in the world might want to pay for things and receive service... [sic]


IPv6 tunnels where meant as a transition mechanism, as a way for engineers to test IPv6 before it was wide spread.

Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have slave monopoly money and can just buy 2% of the address space), you could have spent the last 25 years getting ready for this day. And especially in the last 5 - 10 years, deploying IPv6 has been easy, due to all the work by many many many people around the world in testing and actively deploying IPv6. Of course there are still platforms that don't support DHCPv6 for instance, but things are easy, stable and often properly battle tested.

>
> Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS, null routing prefixes, firewalling, etc., seems even more wrong.
>
> Is there a contemporary option for home users like myself who's ISP doesn't offer native IPv6?

As this is NANOG.... and people on the list are ISPs and it is 2021, thus IPv6 being 25+ years old, the best that is left to do is:

https://www.youtube.com/watch?v=ASXJgvy3mEg

Go Jared!

Greets,
Jeroen
Re: IPv6 woes - RFC [ In reply to ]
Jeroen,

> You people keep on giving money to ISPs that are not providing the
service you want.

Not everyone has the luxury of picking their ISP, and the common consumer
doesn't know or care about IPv6. They want Netflix to work and that's it.

Ryan


On Sat, Sep 4, 2021, 1:47 PM Jeroen Massar via NANOG <nanog@nanog.org>
wrote:

>
> > On 20210904, at 22:26, Grant Taylor via NANOG <nanog@nanog.org> wrote:
> >
> > Hi,
> >
> > Does anyone have any recommendation for a viable IPv6 tunnel broker /
> provider in the U.S.A. /other/ /than/ Hurricane Electric?
>
> SixXS shut down 4 years ago, to get ISPs to move their butts... as long as
> there are tunnels, they do not have a business case.
>
> See also https://www.sixxs.net/sunset/ and the "Call Your ISP for IPv6"
> thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 along
> with plans.
>
> You people keep on giving money to ISPs that are not providing the service
> you want.
>
> > I reluctantly just disabled IPv6 on my home network, provided by
> Hurricane Electric, because multiple services my wife uses are objecting to
> H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO
> Max, Pandora, and other services that I can't remember at the moment have
> all objected to H.E
>
> Tunnels are VPNs
>
> So, that makes sense that services that need to 'protect their IP' (silly
> property) because they did not figure out people might live anywhere in the
> world might want to pay for things and receive service... [sic]
>
>
> IPv6 tunnels where meant as a transition mechanism, as a way for engineers
> to test IPv6 before it was wide spread.
>
> Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have slave
> monopoly money and can just buy 2% of the address space), you could have
> spent the last 25 years getting ready for this day. And especially in the
> last 5 - 10 years, deploying IPv6 has been easy, due to all the work by
> many many many people around the world in testing and actively deploying
> IPv6. Of course there are still platforms that don't support DHCPv6 for
> instance, but things are easy, stable and often properly battle tested.
>
> >
> > Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS,
> null routing prefixes, firewalling, etc., seems even more wrong.
> >
> > Is there a contemporary option for home users like myself who's ISP
> doesn't offer native IPv6?
>
> As this is NANOG.... and people on the list are ISPs and it is 2021, thus
> IPv6 being 25+ years old, the best that is left to do is:
>
> https://www.youtube.com/watch?v=ASXJgvy3mEg
>
> Go Jared!
>
> Greets,
> Jeroen
>
>
Re: IPv6 woes - RFC [ In reply to ]
On 2021-09-04 23:02, Ryan Hamel wrote:
> Jeroen,
>
> > You people keep on giving money to ISPs that are not providing the
> service you want.
>
> Not everyone has the luxury of picking their ISP,

But this list is NANOG.... Network Operators. We are the ISPs....

> and the common consumer doesn't know or care about IPv6.

And they indeed should not have to care. Good that this is not a
consumer list, or a ISP complaint line (though, I guess complaining
about peering or broken connectivity is in the charter)

> They want Netflix to work and that's it.

They thus have no need for IPv6, which was the question...

Netflix works mostly fine over IPv4 (or heck CGN as that is what one is
likely headed to if your ISP did not get chunks of free IPv4 address
space), it is actually still IPv6 where they sometimes have a few PMTU
blackholes... ;) [though, have not noticed one in a while now]

Greets,
Jeroen
Re: IPv6 woes - RFC [ In reply to ]
* ryan@rkhtech.org (Ryan Hamel) [Sat 04 Sep 2021, 23:04 CEST]:
>Not everyone has the luxury of picking their ISP, and the common consumer
>doesn't know or care about IPv6. They want Netflix to work and that's it.

We just had a 100+ post thread about Netflix not working because CGNs
were misclassified as VPN endpoints.


-- Niels.
Re: IPv6 woes - RFC [ In reply to ]
According to Jeroen Massar via NANOG <jeroen@massar.ch>:
>On 2021-09-04 23:02, Ryan Hamel wrote:
>> Jeroen,
>>
>> > You people keep on giving money to ISPs that are not providing the
>> service you want.
>>
>> Not everyone has the luxury of picking their ISP,
>
>But this list is NANOG.... Network Operators. We are the ISPs....

Well, some of us are. I have a choice of an excellent local fiber ISP that
does not offer IPv6 or Spectrum cable which is generally awful but does have v6.
So I use a tunnel.

I have asked my ISP about IPv6 and their answer is that that they're not opposed to
it but since I am the only person who has asked for it, it's quite low on the list
of things to do.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: IPv6 woes - RFC [ In reply to ]
On Sat, Sep 4, 2021, 22:49 John Levine <johnl@iecc.com> wrote:

> I have asked my ISP about IPv6 and their answer is that that they're not
> opposed to
> it but since I am the only person who has asked for it, it's quite low on
> the list
> of things to do.
>

Sounds like a consulting opportunity :)

Thank you
jms

>
Re: IPv6 woes - RFC [ In reply to ]
On 9/5/21 04:49, John Levine wrote:

> Well, some of us are. I have a choice of an excellent local fiber ISP that
> does not offer IPv6 or Spectrum cable which is generally awful but does have v6.
> So I use a tunnel.
>
> I have asked my ISP about IPv6 and their answer is that that they're not opposed to
> it but since I am the only person who has asked for it, it's quite low on the list
> of things to do.

Supporting the routing and forwarding of IP addresses is just about the
most basic thing any ISP should do.

If that is low on their to-do list, what else could they possibly be doing?

Mark.
Re: IPv6 woes - RFC [ In reply to ]
On Sat, Sep 4, 2021 at 9:36 PM Mark Tinka <mark@tinka.africa> wrote:

> Supporting the routing and forwarding of IP addresses is just about the
> most basic thing any ISP should do.
>
> If that is low on their to-do list, what else could they possibly be doing?
>

Counting all the profit they make from a captive audience with no
competition? ;)

-A
Re: IPv6 woes - RFC [ In reply to ]
On 9/4/21 2:44 PM, Jeroen Massar via NANOG wrote:
> SixXS shut down 4 years ago, to get ISPs to move their butts... as
> long as there are tunnels, they do not have a business case.

I saw that.

> See also https://www.sixxs.net/sunset/ and the "Call Your ISP for
> IPv6" thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6
> along with plans.

I have contacted my ISP and inquired about IPv6 one or more times every
year that I've been using them.

> You people keep on giving money to ISPs that are not providing the
> service you want.

Are you talking generally or are you using me as an example (read:
scapegoat)? -- It's okay if you are. I'd like to delve further into
this idea.

I have three ISPs in my town of just shy of 100k people within an hour
drive of the largest city in the state of more than 700k people.

- Municipal fiber - 1 Gbps - IPv4 only - $50 / month
- Local cable co. - ~100 Mbps - IPv4 and IPv6 - for $100 / month
- ILEC xDSL - ~50 Mbps - why would I look - for $100 month

There may be cellular Internet options, but those aren't ... economical,
especially for streaming.

Of those three which would you choose?

So ... I think I'm in quite the same position as John L. is.

> Tunnels are VPNs

I concede the technical point and move on.

> So, that makes sense that services that need to 'protect their IP'
> (silly property) because they did not figure out people might live
> anywhere in the world might want to pay for things and receive
> service... [sic]

I agree there is some questionable ... /thought/ going on somewhere. --
I'm reluctant to call it /logic/.

I agree that some people are trying to circumvent geographical restrictions.

However, my wife and I are not. We want to access content that's for
the address we have on file with the companies, that we have service at,
and that we receive the paper bills at. -- As I've stated before in
other threads, I believe that companies are capable of adding 1 + 1 + 1
to get 3. If they /wanted/ to. As such, I can only surmise that they
do not /want/ to correlate the multiple addresses and allow us to view
content for the same market.

> IPv6 tunnels where meant as a transition mechanism, as a way for
> engineers to test IPv6 before it was wide spread.

And seeing as how I can't get IPv6 natively from multiple providers that
I've worked with in the last 20 years, I can only surmise that we as an
industry are still transitioning from single stack to dual stack.

> Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have
> slave monopoly money and can just buy 2% of the address space), you
> could have spent the last 25 years getting ready for this day. And
> especially in the last 5 - 10 years, deploying IPv6 has been easy, due
> to all the work by many many many people around the world in testing
> and actively deploying IPv6. Of course there are still platforms that
> don't support DHCPv6 for instance, but things are easy, stable and
> often properly battle tested.

And yet here we are.

As a consumer I have no effective influence.

> As this is NANOG.... and people on the list are ISPs and it is 2021,
> thus IPv6 being 25+ years old, the best that is left to do is:
>
> https://www.youtube.com/watch?v=ASXJgvy3mEg

And that's arguably what my city did. They got together and installed
municipal fiber. Save for the lack of IPv6, it wins on all counts;
faster, cheaper, better customer service, and other non-technical perks.
Just no IPv6. Hence why I have historically augmented my municipal
GPON with an H.E. IPv6 tunnel. -- In fact, I am going to continue with
said H.E. IPv6 tunnel, just without advertising it to the network (RA /
DHCPv6). I will have to statically configure IPv6 on things that I want
to use it on. The rest of the home network will be IPv4 only.

I feel like 1995 called and want's their single stack Internet back.
<ASCII tear>

So, Jeroen, what would you recommend that people like John L. and myself do?



--
Grant. . . .
unix || die
Re: IPv6 woes - RFC [ In reply to ]
On Sun, 5 Sept 2021 at 08:25, Grant Taylor via NANOG <nanog@nanog.org> wrote:

> - Municipal fiber - 1 Gbps - IPv4 only - $50 / month
> - Local cable co. - ~100 Mbps - IPv4 and IPv6 - for $100 / month
> - ILEC xDSL - ~50 Mbps - why would I look - for $100 month
>
> There may be cellular Internet options, but those aren't ... economical,
> especially for streaming.
>
> Of those three which would you choose?

Municipal fiber. Which is the point, you cannot capitalise offering
IPv6, so offering it is bad for business. People who have adopted IPv6
have eaten into their margins for no utility.
I view IPv6 as the biggest mistake of my career and feel responsible
for this horrible outcome and I do apologise to Internet users for
it. This dual-stack is the worst possible outcome, and we've been here
over two decades, increasing cost and reducing service quality. We
should have performed better, we should have been IPv6 only years ago.

I wish 20 years ago big SPs would have signed a contract to drop IPv4
at the edge 20 years from now, so that we'd given everyone a 20 year
deadline to migrate away.
20 years ago was the best time to do it, the 2nd best time is today.
If we don't do it, 20 years from now, we are in the same position,
inflating costs and reducing quality and transferring those costs to
our end users who have to suffer from our incompetence.

--
++ytti
Re: IPv6 woes - RFC [ In reply to ]
On 9/4/21 11:43 PM, Saku Ytti wrote:
> Municipal fiber.

;-)

> Which is the point, you cannot capitalise offering IPv6, so offering
> it is bad for business. People who have adopted IPv6 have eaten into
> their margins for no utility.

I don't understand. :-/

> I view IPv6 as the biggest mistake of my career and feel responsible
> for this horrible outcome and I do apologise to Internet users for
> it.

*blink* ... *blink*

First, thank you. I say that sincerely from and end user point of view
feeling like I'm between a rock and a hard place, one of which is
closing in.

Second, I can't say that similar thoughts haven't crossed my mind.

> This dual-stack is the worst possible outcome, and we've been here
> over two decades, increasing cost and reducing service quality. We
> should have performed better, we should have been IPv6 only years ago.

I remember LAN networking back in the '90s where multiple / mixed
protocols was a Bad Thing™. I view IPv4 and IPv6 as tantamount to the
same (or at least very similar) thing. What's worse is that IPv4 and
IPv6 have extremely similar sounding names. Though I think in some ways
that IPv4 and IPv6 are effectively as technically different from each
other as IP(v4) and IPX. Though at least they had the decency to have
more different names.

> I wish 20 years ago big SPs would have signed a contract to drop IPv4
> at the edge 20 years from now, so that we'd given everyone a 20 year
> deadline to migrate away.

Hindsight is 20/20 for a while. Then ... bit rot.

> 20 years ago was the best time to do it, the 2nd best time is today.
> If we don't do it, 20 years from now, we are in the same position,
> inflating costs and reducing quality and transferring those costs to
> our end users who have to suffer from our incompetence.

Sadly, I think that we are back to the multi-protocol days of old. And
I believe that we are going to be stuck here for much of my career. :-(



--
Grant. . . .
unix || die
Re: IPv6 woes - RFC [ In reply to ]
> In fact, I am going to continue with said H.E. IPv6 tunnel, just without advertising it to the network (RA / DHCPv6). I will have to statically configure IPv6 on things that I want to use it on.

There we get to the heart of things.

The problem is not with IPv6 or your ISP (*), but with the Netflix software.
Doing happy eyeballs and selecting an IP address out of the ones available that they *then* reject because they don’t like it: beyond broken, just plain stupid.
Netflix should be using only those IP addresses that it likes (**).

Grüße, Carsten

(*) Well, an ISP that does not offer 128-bit IP *is* a problem, but not the one that led to this thread.

(**) if it needs to deal in address liking at all, which is also fundamentally broken, but seems to be an addiction of their specific industry.
Re: IPv6 woes - RFC [ In reply to ]
On 9/5/21 06:44, Aaron C. de Bruyn wrote:

>
> Counting all the profit they make from a captive audience with no
> competition? ;)

Well, with no more IPv4 to route and no IPv6 to deliver, those profits
won't be lasting many more years.

Mark.
Re: IPv6 woes - RFC [ In reply to ]
On 2021-09-04 23:33, Mark Tinka wrote:
> On 9/5/21 04:49, John Levine wrote:
>
>> I have asked my ISP about IPv6 and their answer is that that they're
>> not opposed to
>> it but since I am the only person who has asked for it, it's quite low
>> on the list
>> of things to do.
>
> Supporting the routing and forwarding of IP addresses is just about
> the most basic thing any ISP should do.
>
> If that is low on their to-do list, what else could they possibly be
> doing?


$DAYJOB (at a business SP) is much busier installing more VPNs in the
form of SDWAN than anything IPv6 related. There is a hell of a lot more
customer demand for tools that route packets with finer control than
just dest-based routing, not to mention the security add-ons.

The fact that folks can achieve multi-homed Internet connectivity
without the financial burden of a /24 helps SDWAN's case. Turns out Mom
and Pop, and even John Q. down the street, wants fast failover in case
of circuit trouble just like the big boys.

That said, I do hear prospects and customers asking for IPv6 more often
now than a year ago. But it's nowhere near the popularity of SDWAN:
It's gone from maybe 2-4 requests per year in 2019 to 2-4 requests per
quarter today.

Sorry, the market *still* doesn't care much about IPv6. Believe me, I
hope people will continue getting interested, but I'm done holding my
breath.

Maybe we should collectively focus instead on raising the default MTU
for the Internet to 2000 bytes to accommodate all these tunnels. ;)


> Mark.


-Brian
Re: IPv6 woes - RFC [ In reply to ]
On 9/5/21 12:48 AM, Carsten Bormann wrote:
> There we get to the heart of things.
>
> The problem is not with IPv6 or your ISP (*), but with the Netflix software.

Hum....

> Doing happy eyeballs and selecting an IP address out of the ones
> available that they *then* reject because they don’t like it:
> beyond broken, just plain stupid.

I feel like that might be conflating a couple of things; the selection
of $SERVICE's destination IP address, and the $CLIENT's inherent source
is coming from.

The $SERVICE can choose any number of destination IP addresses. The
$CLIENT only has minimal control over which protocol is used; IPv4 or IPv6.

I do feel like the $SERVICE could rely on something a bit more
intelligent than DNS such that they make a more informed decision based
on the $CLIENT's inherent source address(es).

> Netflix should be using only those IP addresses that it likes (**).

I don't know if it's the case or not, but I believe that simple DNS
based name resolution tends to be largely ignorant of knowledge of the
$CLIENT's IP address. -- Yes, there are some options, but those tend
to take us way off into the weeds.

> (*) Well, an ISP that does not offer 128-bit IP *is* a problem,
> but not the one that led to this thread.

Agreed.

> (**) if it needs to deal in address liking at all, which is also
> fundamentally broken, but seems to be an addiction of their specific
> industry.

First: I like the "seems to be an addition of their specific industry".

Second: I think that there are technological solutions that would
present a better end user experience. E.g. serve a page / redirect that
sends the client to an IPv4 only destination. Or at the very least
provide a more graceful UX that briefly describes the problem instead of
the service falling over leaving the end user -> consumer -> paying
customer holding the ball and wondering what's wrong. In many cases,
the end user -> consumer -> paying customer is quite likely the party
least equipped / ill-equipped to deal with the ""problem. Especially
when the so called problem is really something that the $SERVICE
provider dislikes and is not a real technological problem preventing
communications.



--
Grant. . . .
unix || die
Re: IPv6 woes - RFC [ In reply to ]
Saku Ytti <saku@ytti.fi> writes:

> I view IPv6 as the biggest mistake of my career and feel responsible
> for this horrible outcome and I do apologise to Internet users for
> it. This dual-stack is the worst possible outcome, and we've been here
> over two decades, increasing cost and reducing service quality. We
> should have performed better, we should have been IPv6 only years ago.

I believe this is slowly sinking in among the technology evangelists and
geeks who managed to drive the half-assed dual-stack transition a decade
or two ago. No one will argue for dual-stack anymore.

So where does that put us in a decade or two? Which protocol is
optional?



Bjørn
Re: IPv6 woes - RFC [ In reply to ]
* bjorn@mork.no (Bjørn Mork) [Sun 05 Sep 2021, 18:24 CEST]:
>So where does that put us in a decade or two? Which protocol is
>optional?

The one that costs money. You can already see this in mobile networks.


-- Niels.
Re: IPv6 woes - RFC [ In reply to ]
On 9/5/21 17:43, Brian Knight wrote:

>
> $DAYJOB (at a business SP) is much busier installing more VPNs in the
> form of SDWAN than anything IPv6 related.  There is a hell of a lot
> more customer demand for tools that route packets with finer control
> than just dest-based routing, not to mention the security add-ons.

My question wasn't serious, if you've been around long enough :-).


> Sorry, the market *still* doesn't care much about IPv6.

I doubt it's me (or those who have deployed IPv6) that will be sorry, in
the long run.

Mark.
Re: IPv6 woes - RFC [ In reply to ]
On 9/5/21 18:22, Bjørn Mork wrote:

> I believe this is slowly sinking in among the technology evangelists and
> geeks who managed to drive the half-assed dual-stack transition a decade
> or two ago. No one will argue for dual-stack anymore.
>
> So where does that put us in a decade or two? Which protocol is
> optional?

You will join the IPv6 train whenever you do.

I don't waste anymore time asking people to deploy it. I'm better off
spending my time drinking wine.

Mark.
Re: IPv6 woes - RFC [ In reply to ]
Grant Taylor via NANOG <nanog@nanog.org> writes:

> Hi,
>
> Does anyone have any recommendation for a viable IPv6 tunnel broker /
> provider in the U.S.A. /other/ /than/ Hurricane Electric?
>
> I reluctantly just disabled IPv6 on my home network, provided by
> Hurricane Electric, because multiple services my wife uses are objecting
> to H.E.'s IPv6 address space as so called VPN or proxy provider.
> Netflix, HBO Max, Pandora, and other services that I can't remember at
> the moment have all objected to H.E.
>
> Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS,
> null routing prefixes, firewalling, etc., seems even more wrong.

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).
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 :)

And yeah, it's an ugly hack that really shouldn't be necessary, 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...

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). 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.

-Toke
Re: IPv6 woes - RFC [ In reply to ]
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
Re: IPv6 woes - RFC [ In reply to ]
On Sun, Sep 05, 2021 at 11:07:22PM +0200, Toke H?iland-J?rgensen via NANOG wrote:
> 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...

The content providers are also _currently_ classifying IPv4 and IPv6 blocks as
cloud hosting, business access, residential access, etc.

You'll have to find a VPS cloud provider that is too low under the
content provider's radar to have been already classified as well.
Re: IPv6 woes - RFC [ In reply to ]
On Sun, 5 Sept 2021 at 19:22, Bjørn Mork <bjorn@mork.no> wrote:

> So where does that put us in a decade or two? Which protocol is
> optional?

If we don't get regulatory enforcement or voluntary commitments to
sunset IPv4, we are doomed for dual-stack for the foreseeable future
(decades).
I absolutely HATE testing, developing and supporting IPv4+IPv6, more
than doubling my time, adding 3rd stack would actually not increase
cost that much, it's the 1=>2 which is fantastically expensive. And
costs are transferred to customers.
Those who have not done _anything_ with IPv6, have done the right
thing from business POV, they've had lowest cost, least issues and
have had other people pay for the improvements of the stack. And even
today, I see no business sense deploying IPv6.

Now if we'd know, all of our CDN, cloudyshops and tier1 will start
dropping IPV4 at edge in 2040, this would create good business reason
to start developing to IPv6, you'd know you need to have it, and you'd
know you have finite window when you need to support both.
And this is something we should commit to do, and everyone would
benefit from the comment.

--
++ytti
Re: IPv6 woes - RFC [ In reply to ]
Hello,


> I absolutely HATE testing, developing and supporting IPv4+IPv6, more
> than doubling my time, adding 3rd stack would actually not increase
> cost that much, it's the 1=>2 which is fantastically expensive. And
> costs are transferred to customers.

Dual stack is doubling dev time ? Ok... this is quite strange...
Maybe on testing... but using some standards protocols....?

(...)

> Now if we'd know, all of our CDN, cloudyshops and tier1 will start
> dropping IPV4 at edge in 2040, this would create good business reason
> to start developing to IPv6, you'd know you need to have it, and you'd
> know you have finite window when you need to support both.
> And this is something we should commit to do, and everyone would
> benefit from the comment.

Really, the ONLY thing that make IPv6 hell is the bloody war between
Cogent and HE. Imagine this kind of war with IPv4...
Really guys stop this stupid stuff and make IPv6 Great Again...

Regards,
Xavier

1 2 3 4 5 6 7 8 9 ... 11  View All