Hulu thinks all my IP addresses are "business class", how to reach them?
I've been offering residential and business ISP services for a long time. Hulu recently blocked my customers from accessing their service, because my ARIN IP address blocks are "business class" instead of residential. I've tried to find a contact for them as I am not a customer, the supportrequest@hulu.com address mentioned in NANOG previously is just an autoresponder that says open a ticket online (once you are logged into your account). Does anybody have a contact for them that I can discuss what they are looking at to determine if my IP addresses are "residential" vs. "business" class? Thanks.
Have you tried reaching out to ipadmin@hulu.com? — Brian Ellwood Senior Systems Engineer INOC Data Centers O: 518-689-4350
On Nov 18, 2019, at 11:41, Doug McIntyre <merlyn@geeks.org> wrote:
I've been offering residential and business ISP services for a long time.
Hulu recently blocked my customers from accessing their service, because my ARIN IP address blocks are "business class" instead of residential.
I've tried to find a contact for them as I am not a customer, the supportrequest@hulu.com address mentioned in NANOG previously is just an autoresponder that says open a ticket online (once you are logged into your account).
Does anybody have a contact for them that I can discuss what they are looking at to determine if my IP addresses are "residential" vs. "business" class?
Thanks.
Doug, out of curiosity, what does Hulu do once they have classified your IP ranges as "business class"? Charge customers a different rate? Offer different content? Refuse service? Doug McIntyre wrote on 11/18/2019 10:41 AM:
I've been offering residential and business ISP services for a long time.
Hulu recently blocked my customers from accessing their service, because my ARIN IP address blocks are "business class" instead of residential.
I've tried to find a contact for them as I am not a customer, the supportrequest@hulu.com address mentioned in NANOG previously is just an autoresponder that says open a ticket online (once you are logged into your account).
Does anybody have a contact for them that I can discuss what they are looking at to determine if my IP addresses are "residential" vs. "business" class?
Thanks.
On Mon, Nov 18, 2019 at 10:55:01AM -0600, Blake Hudson wrote:
Doug, out of curiosity, what does Hulu do once they have classified your IP ranges as "business class"? Charge customers a different rate? Offer different content? Refuse service?
They won't let any of my customers connect, blocking them with a specific error number to reference by their support. When they do, Hulu is either telling them that they are using a VPN (when we don't offer any services like that), and then to whitelist them, they have to have a "residential" IP address and not the "business" IP address we are giving them, and won't go any further. Or they just say they can't connect from the "business" IP addresses. If I knew why they considered my IP addresses "business" IP addresses, I could possibly change something? But this seems to be an arbitrary decision they changed about a week and a half ago for all my netblocks.
Why are "businesses" not allowed to watch HULU? On 11/19/19 1:17 PM, Doug McIntyre wrote:
On Mon, Nov 18, 2019 at 10:55:01AM -0600, Blake Hudson wrote:
Doug, out of curiosity, what does Hulu do once they have classified your IP ranges as "business class"? Charge customers a different rate? Offer different content? Refuse service?
They won't let any of my customers connect, blocking them with a specific error number to reference by their support. When they do, Hulu is either telling them that they are using a VPN (when we don't offer any services like that), and then to whitelist them, they have to have a "residential" IP address and not the "business" IP address we are giving them, and won't go any further. Or they just say they can't connect from the "business" IP addresses.
If I knew why they considered my IP addresses "business" IP addresses, I could possibly change something? But this seems to be an arbitrary decision they changed about a week and a half ago for all my netblocks.
They are essentially equating 'business' with 'VPN provider'. On Tue, Nov 19, 2019 at 1:25 PM Matt Hoppes < mattlists@rivervalleyinternet.net> wrote:
Why are "businesses" not allowed to watch HULU?
On 11/19/19 1:17 PM, Doug McIntyre wrote:
On Mon, Nov 18, 2019 at 10:55:01AM -0600, Blake Hudson wrote:
Doug, out of curiosity, what does Hulu do once they have classified your IP ranges as "business class"? Charge customers a different rate? Offer different content? Refuse service?
They won't let any of my customers connect, blocking them with a specific error number to reference by their support. When they do, Hulu is either telling them that they are using a VPN (when we don't offer any services like that), and then to whitelist them, they have to have a "residential" IP address and not the "business" IP address we are giving them, and won't go any further. Or they just say they can't connect from the "business" IP addresses.
If I knew why they considered my IP addresses "business" IP addresses, I could possibly change something? But this seems to be an arbitrary decision they changed about a week and a half ago for all my netblocks.
On Tue, 19 Nov 2019 13:39:56 -0500, Tom Beecher said:
They are essentially equating 'business' with 'VPN provider'.
Not at all surprised. Many moons ago, I had a Tor *relay* running on one machine in my home network, and Hulu decided that my connections from a *different* home machine were "VPN". Now, if I were running a Tor *exit* node, I'd be totally OK with them rejecting my non-Tor connections because they were NATed to the same outside IP address - but Hulu should never have seen any packets from the relay and if I *was* using a VPN I'd have a *different* IP address. Near as I could determine, they were screen scraping the list of Tor relays and conflating them with exit nodes. Never did figure out if it was stupidity or malice driving that.
Never did figure out if it was stupidity or malice driving that.
Personally I think it's neither; it's just $$$$$. They could invest in a robust system to accurately identify what they chose not to allow to access the service. Or, they can choose to run with a 'close enough' system with some legitimate users caught in the middle. They've most likely done the math and decided that the revenue lost from people getting caught up in inaccurate blocking is small enough that the investment in a more accurate method isn't worth it. This is unfortunately the more common decision in this age of worship at the Altar of Maximum Shareholder Value. On Wed, Nov 20, 2019 at 12:20 AM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Tue, 19 Nov 2019 13:39:56 -0500, Tom Beecher said:
They are essentially equating 'business' with 'VPN provider'.
Not at all surprised.
Many moons ago, I had a Tor *relay* running on one machine in my home network, and Hulu decided that my connections from a *different* home machine were "VPN". Now, if I were running a Tor *exit* node, I'd be totally OK with them rejecting my non-Tor connections because they were NATed to the same outside IP address - but Hulu should never have seen any packets from the relay and if I *was* using a VPN I'd have a *different* IP address.
Near as I could determine, they were screen scraping the list of Tor relays and conflating them with exit nodes. Never did figure out if it was stupidity or malice driving that.
On Nov 20, 2019, at 07:38 , Tom Beecher <beecher@beecher.cc> wrote:
Never did figure out if it was stupidity or malice driving that.
Personally I think it's neither; it's just $$$$$.
They could invest in a robust system to accurately identify what they chose not to allow to access the service. Or, they can choose to run with a 'close enough' system with some legitimate users caught in the middle.
They've most likely done the math and decided that the revenue lost from people getting caught up in inaccurate blocking is small enough that the investment in a more accurate method isn't worth it. This is unfortunately the more common decision in this age of worship at the Altar of Maximum Shareholder Value.
I think you are exactly right here. It’s yet another example of how the incentives around DRM are all messed up and are creating economic bias in favor of screwing consumers as much as possible without loosing too much revenue. What is needed is either a more conscientious consumer base that will see this and react by voting with their wallets, or, regulation which provides more costly penalties for screwing over legitimate consumers. Owen
Owen DeLong wrote on 11/20/2019 11:51 AM:
On Nov 20, 2019, at 07:38 , Tom Beecher <beecher@beecher.cc <mailto:beecher@beecher.cc>> wrote:
Never did figure out if it was stupidity or malice driving that.
Personally I think it's neither; it's just $$$$$.
They could invest in a robust system to accurately identify what they chose not to allow to access the service. Or, they can choose to run with a 'close enough' system with some legitimate users caught in the middle.
They've most likely done the math and decided that the revenue lost from people getting caught up in inaccurate blocking is small enough that the investment in a more accurate method isn't worth it. This is unfortunately the more common decision in this age of worship at the Altar of Maximum Shareholder Value.
I think you are exactly right here. It’s yet another example of how the incentives around DRM are all messed up and are creating economic bias in favor of screwing consumers as much as possible without loosing too much revenue.
What is needed is either a more conscientious consumer base that will see this and react by voting with their wallets, or, regulation which provides more costly penalties for screwing over legitimate consumers.
Owen
I suppose a Hulu subscriber could dispute the charge or file a suit (class action?) for damages: "Hulu took my money, but didn't provide the services they advertised." As an ISP, some of us might even be in a position where we encounter losses due to Hulu's (mis)classification resulting in customers moving to the competition; I would think that would be sufficient grounds for a suit.
I suppose a Hulu subscriber could dispute the charge or file a suit (class action?) for damages: "Hulu took my money, but didn't provide the services they advertised." As an ISP, some of us might even be in a position where we encounter losses due to Hulu's (mis)classification resulting in customers moving to the competition; I would think that would be sufficient grounds for a suit.
The problem here is that identifying class members is very hard (most class members wouldn’t realize why they were not getting Hulu, and Hulu probably either quickly corrects the problem on their end or blames the ISP), meaning they wouldn’t realize their ability to join the class. As an individual customer, Hulu will refund your money and tell you to piss off. That’s about all you’re likely to recover in the court case, too. As an ISP, there might be something there, but, you’d have to prove that you had a significant number of customers that left for that specific reason and you’d have to show the actual damages that resulted. Easy to estimate, very hard to prove. So in this particular case, I think Hulu is tragically safe from being held accountable. I think the best solution would be something like this… If congress were to revise the DMCA to provide a provision similar to the following: 1. Digital Rights Management Content producers and Content owners have the right to enforce their copyright through automated means known as “Digital Rights Management” (DRM). DRM mechanisms may include, but are not limited to any of the following: + IP Address based geographical location inference and content limitations + Efforts to avoid delivery of services to users of Virtual Private Networks + Software locks or limitations preventing playback based on machine configuration, software status, or other variables. + Self-destructive content 2. Duties of Content Producers and Content Owners Content producers and Content owners must, however, ensure that any form of DRM employed in this process does not in any way curtail the legitimate rights of end users who have lawfully purchased, licensed, or otherwise through fair use or other mechanism obtained legitimate rights to the content. 3. Rights of Consumers The fair trade commission shall maintain a mechanism for consumers to report and document instances where their content rights have been infringed, abridged, or otherwise hindered by DRM. Through this process, the FTC shall investigate all credible complaints and make a determination of fact whether the consumer’s rights were violated. In such an instance where the FTC determines consumers rights were violated, the Content Owner, Content Producer, and any Content Providers involved shall be jointly and severally liable for the following damages: + Restitution to each affected consumer of the full cost (if any) born by the consumer in obtaining the infringed rights. + A DRM free copy of the content in the same format(s) and usable with the same playback mechanism(s) provided to each affected consumer. + A fine payable to the united States not to exceed $10,000 per incident per affected consumer. + Reimbursement to the FTC for all costs of the investigation and any process(es) related to enforcement of any judgment resulting from the investigation. In the event that a Content Owner, Producer, or Provider wishes to appeal an FTC ruling, the appeal shall be heard in the circuit court of appeals covering the largest fraction of the affected consumers known to be affected at the time of the ruling. While awaiting said hearing, the restitution to affected consumers and DRM free copy shall be provided not less than 60 days after the initial ruling. Owen
On 11/20/19 3:31 PM, Owen DeLong wrote:
As an ISP, there might be something there, but, you’d have to prove that you had a significant number of customers that left for that specific reason and you’d have to show the actual damages that resulted. Easy to estimate, very hard to prove.
Not only hard to prove, but the armchair lawyer in my has an inkling that you'd have to show that they did it intentionally or went beyond being dumb or knowledgeable about it and were somehow negligent. The former seems even more difficult than proving actual damages, and the latter seems like it may not even apply or be possible. What irks me most about these situations as an operator, and indeed something that may push back on my previous statement of intent or negligence not being possible/applicable, is that the services often make their geofencing/IP classification system failures out as being the fault of the user's telecommunications service provider when, in fact, the user's service provider often has absolutely no direct control over what happens and, even where they do have some form of direct control such as through a documented operations-appeals channel, are still at the mercy of the service doing the fencing/classification to correct the error. At minimum, this could damage customer good will toward their service provider. (And kudos where it's due to the providers who do NOT make such issues appear to be the fault of the user's telecommunications service provider and instead provide a real, useful means for the user to directly contact the content provider to resolve the issue) -- Brandon Martin
On Nov 20, 2019, at 12:44 , Brandon Martin <lists.nanog@monmotha.net> wrote:
On 11/20/19 3:31 PM, Owen DeLong wrote:
As an ISP, there might be something there, but, you’d have to prove that you had a significant number of customers that left for that specific reason and you’d have to show the actual damages that resulted. Easy to estimate, very hard to prove.
Not only hard to prove, but the armchair lawyer in my has an inkling that you'd have to show that they did it intentionally or went beyond being dumb or knowledgeable about it and were somehow negligent. The former seems even more difficult than proving actual damages, and the latter seems like it may not even apply or be possible.
Correct me if I’m wrong, but being dumb about it _IS_ negligent, isn’t it?
What irks me most about these situations as an operator, and indeed something that may push back on my previous statement of intent or negligence not being possible/applicable, is that the services often make their geofencing/IP classification system failures out as being the fault of the user's telecommunications service provider when, in fact, the user's service provider often has absolutely no direct control over what happens and, even where they do have some form of direct control such as through a documented operations-appeals channel, are still at the mercy of the service doing the fencing/classification to correct the error. At minimum, this could damage customer good will toward their service provider.
Yep… Hence what I proposed as regulation to help curtail this BS.
(And kudos where it's due to the providers who do NOT make such issues appear to be the fault of the user's telecommunications service provider and instead provide a real, useful means for the user to directly contact the content provider to resolve the issue)
Who are they? I want to shift my services to them if I can. (So far, I haven’t found any) Owen
The problem here is that identifying class members is very hard (most class members wouldn’t realize why they were not getting Hulu, and Hulu
On Wed, Nov 20, 2019 at 12:32 PM Owen DeLong <owen@delong.com> wrote: probably either quickly corrects the problem on their end or blames the ISP), meaning they wouldn’t realize their ability to join the class.
As an individual customer, Hulu will refund your money and tell you to
piss off. That’s about all you’re likely to recover in the court case, too.
As an ISP, there might be something there, but, you’d have to prove that
you had a significant number of customers that left for that specific reason and you’d have to show the actual damages that resulted. Easy to estimate, very hard to prove. This is why you don't go after Hulu. You go after the content owners who conspired to compel Hulu to limit distribution in a way that tortiously interferes with your contract with your eyeball customers. Then, before you've spent much money (filing lawsuits and notifying the defendants only costs in the hundreds of dollars), you suggest to their respective counsels that they didn't actually intend to exclude your customers and that if Hulu weren't so reckless in their implementation you'd be inclined to drop the matter. -- William Herrin bill@herrin.us https://bill.herrin.us/
This is why you don't go after Hulu. You go after the content owners who conspired to compel Hulu to limit distribution in a way that tortiously interferes with your contract with your eyeball customers. Then, before
Which in many cases is groups like the Screen Actors Guild and the music industry. As I understand it much of the music in TV shows require licensing and sometimes different license holders exist for a song depending on country. While the television industry self-inflicts pain to it's userbase it's easier for the users to just pirate the content. - Ethan
On Wednesday, 20 November, 2019 21:25, "William Herrin" <bill@herrin.us> said:
This is why you don't go after Hulu. You go after the content owners who conspired to compel Hulu to limit distribution in a way that tortiously interferes with your contract with your eyeball customers.
Am I the only one who's baffled in the context of a paid service why so much focus is put on where the consumption takes place (hard), and so little on where the transaction take place (easy)? I understand, even if I don't necessarily always agree with, market segmentation, differentiated pricing, accurate P&L for different business units, etc, that mean for example if you're a US citizen you need to pay Disney US the prevailing US price to watch Disney content, but if you're an EU citizen you need to pay Disney EMEA the prevailing EU price to watch Disney content. Surely that transaction is the thing content creators and distributors care about? If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so. If a US citizen is paying for Hulu, from a US billing address, on a US credit card, but happens to be watching from their hotel in Italy, why does anyone care? I can see why it's different and more complicated for content that's provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid services seems a terrible waste of time and effort on both sides. Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service? Regards, Tim.
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so. If a US citizen is paying for Hulu, from a US billing address, on a US credit card, but happens to be watching from their hotel in Italy, why does anyone care?
Hulu probably doesn't. But many content owners are still riding that Region Locking Hype Train in the face of all the available evidence that it doesn't really do anything but create a nuisance. And they do pretty much have you over the barrel, since you likely don't have another option. On Thu, Nov 21, 2019 at 5:34 AM tim@pelican.org <tim@pelican.org> wrote:
On Wednesday, 20 November, 2019 21:25, "William Herrin" <bill@herrin.us> said:
This is why you don't go after Hulu. You go after the content owners who conspired to compel Hulu to limit distribution in a way that tortiously interferes with your contract with your eyeball customers.
Am I the only one who's baffled in the context of a paid service why so much focus is put on where the consumption takes place (hard), and so little on where the transaction take place (easy)?
I understand, even if I don't necessarily always agree with, market segmentation, differentiated pricing, accurate P&L for different business units, etc, that mean for example if you're a US citizen you need to pay Disney US the prevailing US price to watch Disney content, but if you're an EU citizen you need to pay Disney EMEA the prevailing EU price to watch Disney content. Surely that transaction is the thing content creators and distributors care about?
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so. If a US citizen is paying for Hulu, from a US billing address, on a US credit card, but happens to be watching from their hotel in Italy, why does anyone care?
I can see why it's different and more complicated for content that's provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid services seems a terrible waste of time and effort on both sides.
Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service?
Regards, Tim.
tim@pelican.org wrote on 11/21/2019 4:32 AM:
On Wednesday, 20 November, 2019 21:25, "William Herrin" <bill@herrin.us> said:
This is why you don't go after Hulu. You go after the content owners who conspired to compel Hulu to limit distribution in a way that tortiously interferes with your contract with your eyeball customers. Am I the only one who's baffled in the context of a paid service why so much focus is put on where the consumption takes place (hard), and so little on where the transaction take place (easy)?
I understand, even if I don't necessarily always agree with, market segmentation, differentiated pricing, accurate P&L for different business units, etc, that mean for example if you're a US citizen you need to pay Disney US the prevailing US price to watch Disney content, but if you're an EU citizen you need to pay Disney EMEA the prevailing EU price to watch Disney content. Surely that transaction is the thing content creators and distributors care about?
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so. If a US citizen is paying for Hulu, from a US billing address, on a US credit card, but happens to be watching from their hotel in Italy, why does anyone care?
I can see why it's different and more complicated for content that's provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid services seems a terrible waste of time and effort on both sides.
Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service?
Regards, Tim.
Tim, like you, I've been baffled by this choice as well. Why streaming video providers continue to choose a costly and convoluted path when a less convoluted and cheaper path exists to reach (seemingly) the same destination I will never know. Perhaps one company did it that way so others just copied the mistake? Perhaps providers feel it's necessary because not all of them require transactions with a billing/mailing address all the time (think free/trial services or gift cards)? One can only attempt to conceive of the inconceivable...
On Thu, Nov 21, 2019 at 10:22 AM Blake Hudson <blake@ispn.net> wrote:
tim@pelican.org wrote on 11/21/2019 4:32 AM:
Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service?
1. Buy a prepaid debit card. 2. Rent a mailbox at Mailboxes Etc. or a similar company. 3. Log in to the prepaid card's web site and enter the address of your rented mailbox as the billing address.
Tim, like you, I've been baffled by this choice as well. Why streaming video providers continue to choose a costly and convoluted path when a less convoluted and cheaper path exists to reach (seemingly) the same destination I will never know.
Again, streaming video providers did not make this choice. Content owners did, and made its enforcement a contractual requirement for leasing that content to the streaming video providers. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Probably because a market would quickly pop up to sell or rent accounts created in one region to others. On Thu, Nov 21, 2019, 2:32 AM tim@pelican.org <tim@pelican.org> wrote:
On Wednesday, 20 November, 2019 21:25, "William Herrin" <bill@herrin.us> said:
This is why you don't go after Hulu. You go after the content owners who conspired to compel Hulu to limit distribution in a way that tortiously interferes with your contract with your eyeball customers.
Am I the only one who's baffled in the context of a paid service why so much focus is put on where the consumption takes place (hard), and so little on where the transaction take place (easy)?
I understand, even if I don't necessarily always agree with, market segmentation, differentiated pricing, accurate P&L for different business units, etc, that mean for example if you're a US citizen you need to pay Disney US the prevailing US price to watch Disney content, but if you're an EU citizen you need to pay Disney EMEA the prevailing EU price to watch Disney content. Surely that transaction is the thing content creators and distributors care about?
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so. If a US citizen is paying for Hulu, from a US billing address, on a US credit card, but happens to be watching from their hotel in Italy, why does anyone care?
I can see why it's different and more complicated for content that's provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid services seems a terrible waste of time and effort on both sides.
Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service?
Regards, Tim.
On Thu, Nov 21, 2019, 2:32 AM tim@pelican.org <tim@pelican.org> wrote:
On Wednesday, 20 November, 2019 21:25, "William Herrin" <bill@herrin.us> said:
This is why you don't go after Hulu. You go after the content owners who conspired to compel Hulu to limit distribution in a way that tortiously interferes with your contract with your eyeball customers.
Am I the only one who's baffled in the context of a paid service why so much focus is put on where the consumption takes place (hard), and so little on where the transaction take place (easy)?
I understand, even if I don't necessarily always agree with, market segmentation, differentiated pricing, accurate P&L for different business units, etc, that mean for example if you're a US citizen you need to pay Disney US the prevailing US price to watch Disney content, but if you're an EU citizen you need to pay Disney EMEA the prevailing EU price to watch Disney content. Surely that transaction is the thing content creators and distributors care about?
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so. If a US citizen is paying for Hulu, from a US billing address, on a US credit card, but happens to be watching from their hotel in Italy, why does anyone care?
I can see why it's different and more complicated for content that's provided free but geo-constrained (e.g. BBC iPlayer), but IP geolocation for paid services seems a terrible waste of time and effort on both sides.
Or am I woefully naive, and it's actually trivial for a non-US resident to come up with a US credit card and billing address to pay for the service?
Regards, Tim.
Question: is anyone who is currently suffering this issue also doing 1:many NAT? Or running a proxy server that might cause multiple clients to all appear from the same IP address? I believe NAT might be the cause of one of our customer's complaints wrt content provider blocking.
This is absolutely an issue with Xbox Live/Sony PSN or RBLs used by mail servers for reputation purposes. For better or worse these systems equate one IPv4 address == one user (and possibly one IPv6 /64 == one user). My opinion is that this may be a reasonable or "good enough" assumption as long as you put a time limit on the assumption (so dynamic addresses can be reassigned) and have a rough idea of what a user means (a household, subscriber circuit, or similar). But it obviously goes out the window if you have 10 or 20 unrelated subscribers (possibly in different towns) sharing a single IP address in a 1:many NAT. This may be one of the not-so-obvious support costs that comes up when one decides to run a CGN. Mike Lewinski wrote on 11/21/2019 11:05 PM:
Question: is anyone who is currently suffering this issue also doing 1:many NAT? Or running a proxy server that might cause multiple clients to all appear from the same IP address? I believe NAT might be the cause of one of our customer's complaints wrt content provider blocking.
On Fri, Nov 22, 2019 at 8:52 AM Blake Hudson <blake@ispn.net> wrote:
This is absolutely an issue with Xbox Live/Sony PSN or RBLs used by mail servers for reputation purposes. For better or worse these systems equate one IPv4 address == one user (and possibly one IPv6 /64 == one user). My opinion is that this may be a reasonable or "good enough" assumption
Talk to someone who has been sued for downloading or sharing movies. They'll swear on their own grave that one IP can never equal one user. ;) -A
On Nov 22, 2019, at 17:47 , Aaron C. de Bruyn via NANOG <nanog@nanog.org> wrote:
On Fri, Nov 22, 2019 at 8:52 AM Blake Hudson <blake@ispn.net <mailto:blake@ispn.net>> wrote: This is absolutely an issue with Xbox Live/Sony PSN or RBLs used by mail servers for reputation purposes. For better or worse these systems equate one IPv4 address == one user (and possibly one IPv6 /64 == one user). My opinion is that this may be a reasonable or "good enough" assumption
Talk to someone who has been sued for downloading or sharing movies. They'll swear on their own grave that one IP can never equal one user. ;)
-A
I’ll swear it’s a horrible assumption. Personally, I use many IP addresses each day. Some of them are also used by others. Some of them are not. Equating IP Address <-> Person relationships as being anything remotely resembling 1:1 is beyond absurd. To do so with an IPv6 /64 is even more so. Considering it to be reasonable or “good enough” is so far from valid I don’t even know where to begin. Owen
Bad wording on my part. I wasn't trying to imply their statement was true--just a bit of humor. -A On Fri, Nov 22, 2019 at 6:09 PM Owen DeLong <owen@delong.com> wrote:
On Nov 22, 2019, at 17:47 , Aaron C. de Bruyn via NANOG <nanog@nanog.org> wrote:
On Fri, Nov 22, 2019 at 8:52 AM Blake Hudson <blake@ispn.net> wrote:
This is absolutely an issue with Xbox Live/Sony PSN or RBLs used by mail servers for reputation purposes. For better or worse these systems equate one IPv4 address == one user (and possibly one IPv6 /64 == one user). My opinion is that this may be a reasonable or "good enough" assumption
Talk to someone who has been sued for downloading or sharing movies. They'll swear on their own grave that one IP can never equal one user. ;)
-A
I’ll swear it’s a horrible assumption.
Personally, I use many IP addresses each day. Some of them are also used by others. Some of them are not.
Equating IP Address <-> Person relationships as being anything remotely resembling 1:1 is beyond absurd. To do so with an IPv6 /64 is even more so.
Considering it to be reasonable or “good enough” is so far from valid I don’t even know where to begin.
Owen
Just received a mail that RIPE is out of IPv4: Dear colleagues, Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses. Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature [X]
Nice! Is this what I think it is? a historical moment for the internet for the story books? On Mon, 25 Nov 2019 at 15:59, Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature
-- -- ℱin del ℳensaje.
I think it is less historic than when IANA ran out of blocks to delegate to the regional registries. https://en.wikipedia.org/wiki/IPv4_address_exhaustion Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com On Mon, Nov 25, 2019 at 10:34 AM Tei <oscar.vives@gmail.com> wrote:
Nice!
Is this what I think it is? a historical moment for the internet for the story books?
On Mon, 25 Nov 2019 at 15:59, Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature
-- -- ℱin del ℳensaje.
Thanks I am lurking on this mail list. Sometimes is hard to decipher whats goin on. Always interesting. You guys are awesome. On Mon, 25 Nov 2019 at 16:57, Donald Eastlake <d3e3e3@gmail.com> wrote:
I think it is less historic than when IANA ran out of blocks to delegate to the regional registries. https://en.wikipedia.org/wiki/IPv4_address_exhaustion
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@gmail.com
On Mon, Nov 25, 2019 at 10:34 AM Tei <oscar.vives@gmail.com> wrote:
Nice!
Is this what I think it is? a historical moment for the internet for the story books?
On Mon, 25 Nov 2019 at 15:59, Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature
-- -- ℱin del ℳensaje.
-- -- ℱin del ℳensaje.
On Nov 25, 2019, at 8:56 AM, Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Does this mean we are finally ripe for widespread IPv6 adoption? (Admit it, someone had to say it!) ---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy@andyring.com
This is a great example (but just one of many) of how server software development works: IANA IPv4 runout January 2011. Kubernetes initial release June 2014. Developed by Google engineers. ARIN IPv4 runout September 2015. Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017. Full support including CoreDNS support in 1.13, December 2018. Too bad nobody had warned them about IPv4 exhaustion before they started! On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth <andy@andyring.com> wrote:
On Nov 25, 2019, at 8:56 AM, Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Does this mean we are finally ripe for widespread IPv6 adoption?
(Admit it, someone had to say it!)
---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy@andyring.com
And how did that stop you deploying IPv6? It’s not like you were turning off IPv4. -- Mark Andrews
On 1 Dec 2019, at 04:03, Matthew Kaufman <matthew@matthew.at> wrote:
This is a great example (but just one of many) of how server software development works:
IANA IPv4 runout January 2011.
Kubernetes initial release June 2014. Developed by Google engineers.
ARIN IPv4 runout September 2015.
Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.
Full support including CoreDNS support in 1.13, December 2018.
Too bad nobody had warned them about IPv4 exhaustion before they started!
On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth <andy@andyring.com> wrote:
On Nov 25, 2019, at 8:56 AM, Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Does this mean we are finally ripe for widespread IPv6 adoption?
(Admit it, someone had to say it!)
---- Andy Ringsmuth 5609 Harding Drive Lincoln, NE 68521-5831 (402) 304-0083 andy@andyring.com
User apps prefer IPv6, Netflix stops, users complain On Sat, Nov 30, 2019 at 1:29 PM Mark Andrews <marka@isc.org> wrote:
And how did that stop you deploying IPv6? It’s not like you were turning off IPv4. -- Mark Andrews
On 1 Dec 2019, at 04:03, Matthew Kaufman <matthew@matthew.at> wrote:
This is a great example (but just one of many) of how server software development works:
IANA IPv4 runout January 2011.
Kubernetes initial release June 2014. Developed by Google engineers.
ARIN IPv4 runout September 2015.
Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.
Full support including CoreDNS support in 1.13, December 2018.
Too bad nobody had warned them about IPv4 exhaustion before they started!
On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth <andy@andyring.com> wrote:
On Nov 25, 2019, at 8:56 AM, Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Does this mean we are finally ripe for widespread IPv6 adoption?
(Admit it, someone had to say it!)
---- Andy Ringsmuth 5609 Harding Drive <https://www.google.com/maps/search/5609+Harding+Drive+%0D%0ALincoln,+NE+68521?entry=gmail&source=g> Lincoln, NE 68521 <https://www.google.com/maps/search/5609+Harding+Drive+%0D%0ALincoln,+NE+68521?entry=gmail&source=g> -5831 (402) 304-0083 andy@andyring.com
On 11/30/19 8:55 PM, Valdis Klētnieks wrote:
User apps prefer IPv6, Netflix stops, users complain And fallback to IPv4 fails to happen, why, exactly?
Inability to signal application-level failure on IPv6 and that fallback to IPv4 would succeed. Netflix definitely exhibits this. I've also noticed that a lot of Cloudflare-hosted apps/sites block AS6939 outright which mostly only affects IPv6 as they don't actually originate much end-user-facing IPv4 space. The result is an HTTP/403 which most browsers do not interpret as a response that could be remedied by "happy eyeballs" type behavior. Whether banning an entire ASN like that in precisely a situation where this kind of thing is likely to occur is a good practice or not is left as an exercise to the reader. -- Brandon Martin
On Sat, Nov 30, 2019 at 5:55 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Sat, 30 Nov 2019 13:47:36 -0800, Matthew Kaufman said:
User apps prefer IPv6, Netflix stops, users complain
And fallback to IPv4 fails to happen, why, exactly?
Because of the layer at which failure happens. You get connected successfully to a Netflix that tells you that reaching it via tunnels is prohibited by their terms of service.
I'm still surprised that for $42/mo you can't afford IPv6. If you already have a legacy allocation most cases you can get v6 for "free". I get low budget stuff, but honestly it doesn't have to be you it could be one upstream that gives you a /48 to get you started. Sent from my iCar
On Dec 1, 2019, at 1:10 AM, Matthew Kaufman <matthew@matthew.at> wrote:
On Sat, Nov 30, 2019 at 5:55 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote: On Sat, 30 Nov 2019 13:47:36 -0800, Matthew Kaufman said:
User apps prefer IPv6, Netflix stops, users complain
And fallback to IPv4 fails to happen, why, exactly?
Because of the layer at which failure happens. You get connected successfully to a Netflix that tells you that reaching it via tunnels is prohibited by their terms of service.
Sorry, thought this was the Tunnels part of the thread. Kubernetes Container networking only supported one address per pod until well *after* V6-only clusters were in alpha, so dual-stack want an option. Point is, plenty of popular server-side infrastructure was designed IPv4-first as late as 2014. This is just one example of many. Matthew Kaufman On Sat, Nov 30, 2019 at 1:29 PM Mark Andrews <marka@isc.org> wrote:
And how did that stop you deploying IPv6? It’s not like you were turning off IPv4. -- Mark Andrews
On 1 Dec 2019, at 04:03, Matthew Kaufman <matthew@matthew.at> wrote:
This is a great example (but just one of many) of how server software development works:
IANA IPv4 runout January 2011.
Kubernetes initial release June 2014. Developed by Google engineers.
ARIN IPv4 runout September 2015.
Support for IPv6-only Kubernetes clusters alphas in 1.9, December 2017.
Full support including CoreDNS support in 1.13, December 2018.
Too bad nobody had warned them about IPv4 exhaustion before they started!
On Mon, Nov 25, 2019 at 8:02 AM Andy Ringsmuth <andy@andyring.com> wrote:
On Nov 25, 2019, at 8:56 AM, Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Does this mean we are finally ripe for widespread IPv6 adoption?
(Admit it, someone had to say it!)
---- Andy Ringsmuth 5609 Harding Drive <https://www.google.com/maps/search/5609+Harding+Drive+%0D%0ALincoln,+NE+68521?entry=gmail&source=g> Lincoln, NE 68521 <https://www.google.com/maps/search/5609+Harding+Drive+%0D%0ALincoln,+NE+68521?entry=gmail&source=g> -5831 (402) 304-0083 andy@andyring.com
Matthew Kaufman writes:
This is a great example (but just one of many) of how server software development works:
Small addition/correction to this example (which I find interesting and also sad):
Kubernetes initial release June 2014. Developed by Google engineers. [...] Full support including CoreDNS support in 1.13, December 2018.
Support for dual-stack pods[1]: alpha in 1.16, October 2019. -- Simon. [1] https://kubernetes.io/docs/concepts/services-networking/dual-stack/
Huh. I guess we get to go home early today then? And look into that whole "Aye Pee Vee Sicks" thing next week aye boss? On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman <dmitry@interhost.net> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature
I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6. Best regards, Dmitry Sherman [X] On 25 Nov 2019, at 18:08, Billy Crook <BCrook@unrealservers.net> wrote: Huh. I guess we get to go home early today then? And look into that whole "Aye Pee Vee Sicks" thing next week aye boss? On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman <dmitry@interhost.net<mailto:dmitry@interhost.net>> wrote: Just received a mail that RIPE is out of IPv4: Dear colleagues, Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses. Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il<http://www.interhost.co.il> Dmitry@interhost.net<mailto:Dmitry@interhost.net> Mob: 054-3181182 Sent from Steve's creature [X]
It requires both sides to move to IPv6. Why should the cost of maintaining working networks be borne alone by the eyeball networks? That is what is mostly happening today with CGN. Every server that offers services to the public should be making them available over IPv6. Most of the CDNs support both transports. Why are you scared to tick the box for IPv6? HTTPS doesn’t care which transport is used. -- Mark Andrews
On 26 Nov 2019, at 03:53, Dmitry Sherman <dmitry@interhost.net> wrote:
I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6.
Best regards, Dmitry Sherman
On 25 Nov 2019, at 18:08, Billy Crook <BCrook@unrealservers.net> wrote:
Huh. I guess we get to go home early today then? And look into that whole "Aye Pee Vee Sicks" thing next week aye boss?
On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman <dmitry@interhost.net> wrote: Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature
Because we can’t only use ipv6 on the boxes, each box with ipv6 must have IPv4 until the last eyeball broadband user will have ipv6 support. Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature [X] On 25 Nov 2019, at 21:47, Mark Andrews <marka@isc.org> wrote: It requires both sides to move to IPv6. Why should the cost of maintaining working networks be borne alone by the eyeball networks? That is what is mostly happening today with CGN. Every server that offers services to the public should be making them available over IPv6. Most of the CDNs support both transports. Why are you scared to tick the box for IPv6? HTTPS doesn’t care which transport is used. -- Mark Andrews On 26 Nov 2019, at 03:53, Dmitry Sherman <dmitry@interhost.net> wrote: I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6. Best regards, Dmitry Sherman [X] On 25 Nov 2019, at 18:08, Billy Crook <BCrook@unrealservers.net> wrote: Huh. I guess we get to go home early today then? And look into that whole "Aye Pee Vee Sicks" thing next week aye boss? On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman <dmitry@interhost.net<mailto:dmitry@interhost.net>> wrote: Just received a mail that RIPE is out of IPv4: Dear colleagues, Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses. Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il<http://www.interhost.co.il> Dmitry@interhost.net<mailto:Dmitry@interhost.net> Mob: 054-3181182 Sent from Steve's creature [X]
The two things feed each other. Big content networks have had IPv6 for years now, and the mobile phone networks are primarily, if not exclusively IPv6 on the inside. Adding IPv6 now helps push the cycle forward, whether you are an eyeball, content, or other network. Doug On 11/25/19 11:50 AM, Dmitry Sherman wrote:
Because we can’t only use ipv6 on the boxes, each box with ipv6 must have IPv4 until the last eyeball broadband user will have ipv6 support.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature
On 25 Nov 2019, at 21:47, Mark Andrews <marka@isc.org> wrote:
It requires both sides to move to IPv6. Why should the cost of maintaining working networks be borne alone by the eyeball networks? That is what is mostly happening today with CGN.
Every server that offers services to the public should be making them available over IPv6. Most of the CDNs support both transports. Why are you scared to tick the box for IPv6? HTTPS doesn’t care which transport is used.
-- Mark Andrews
On 26 Nov 2019, at 03:53, Dmitry Sherman <dmitry@interhost.net> wrote:
I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6.
Best regards, Dmitry Sherman
On 25 Nov 2019, at 18:08, Billy Crook <BCrook@unrealservers.net> wrote:
Huh. I guess we get to go home early today then? And look into that whole "Aye Pee Vee Sicks" thing next week aye boss?
On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman <dmitry@interhost.net <mailto:dmitry@interhost.net>> wrote:
Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il <http://www.interhost.co.il> Dmitry@interhost.net <mailto:Dmitry@interhost.net> Mob: 054-3181182 Sent from Steve's creature
That’s absurd… Yes, you have to support both for now. However, you really only need IPv4 addresses on each front-end box and you only need that until the proportion of eyeball users that lack IPv6 capabilities is small enough to be considered no longer worth the cost of support. I doubt seriously that the quantity of eyeball users you would consider cost effective to support is one. Case in point: Do your servers still support non-SNI compliant browsers? Do you limit your pages to compatibility with IE version 10? Owen
On Nov 25, 2019, at 11:50 , Dmitry Sherman <dmitry@interhost.net> wrote:
Because we can’t only use ipv6 on the boxes, each box with ipv6 must have IPv4 until the last eyeball broadband user will have ipv6 support.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il Dmitry@interhost.net Mob: 054-3181182 Sent from Steve's creature
On 25 Nov 2019, at 21:47, Mark Andrews <marka@isc.org> wrote:
It requires both sides to move to IPv6. Why should the cost of maintaining working networks be borne alone by the eyeball networks? That is what is mostly happening today with CGN.
Every server that offers services to the public should be making them available over IPv6. Most of the CDNs support both transports. Why are you scared to tick the box for IPv6? HTTPS doesn’t care which transport is used.
-- Mark Andrews
On 26 Nov 2019, at 03:53, Dmitry Sherman <dmitry@interhost.net> wrote:
I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6.
Best regards, Dmitry Sherman
On 25 Nov 2019, at 18:08, Billy Crook <BCrook@unrealservers.net> wrote:
Huh. I guess we get to go home early today then? And look into that whole "Aye Pee Vee Sicks" thing next week aye boss?
On Mon, Nov 25, 2019 at 8:58 AM Dmitry Sherman <dmitry@interhost.net <mailto:dmitry@interhost.net>> wrote: Just received a mail that RIPE is out of IPv4:
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Best regards, Dmitry Sherman Interhost Networks www.interhost.co.il <http://www.interhost.co.il/> Dmitry@interhost.net <mailto:Dmitry@interhost.net> Mob: 054-3181182 Sent from Steve's creature
On Tue, 26 Nov 2019 06:46:52 +1100, Mark Andrews said:
On 26 Nov 2019, at 03:53, Dmitry Sherman <dmitry@interhost.net> wrote:
I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6.
It requires both sides to move to IPv6. Why should the cost of maintaining working networks be borne alone by the eyeball networks? That is what is mostly happening today with CGN.
I believe that Dmitry's point is that we will still require IPv4 addresses for new organizations deploying dual-stack, and eyeball networks can more easily move a /16 or even bigger to mostly IPv6 and a small CGNAT address space than content providers can free up IPv4 addresses during the time that dual stack is still needed.
Most eyeball networks (by organization count) don't have a /16 in the first place, much less one to give. Obviously something like 90% of the population is in the top 10 providers and the rest of the population is in the other several thousand providers. (Numbers are out of thin air, but illustrate the point.) ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu> To: "Mark Andrews" <marka@isc.org> Cc: "Aaron C. de Bruyn" <aaron@heyaaron.com>, "NANOG mailing list" <nanog@nanog.org> Sent: Monday, November 25, 2019 3:47:37 PM Subject: Re: RIPE our of IPv4 On Tue, 26 Nov 2019 06:46:52 +1100, Mark Andrews said:
On 26 Nov 2019, at 03:53, Dmitry Sherman <dmitry@interhost.net> wrote:
��� I believe it���s Eyeball network���s matter to free IPv4 blocks and move to v6.
It requires both sides to move to IPv6. Why should the cost of maintaining working networks be borne alone by the eyeball networks? That is what is mostly happening today with CGN.
I believe that Dmitry's point is that we will still require IPv4 addresses for new organizations deploying dual-stack, and eyeball networks can more easily move a /16 or even bigger to mostly IPv6 and a small CGNAT address space than content providers can free up IPv4 addresses during the time that dual stack is still needed.
On 2019-11-25 1:47 PM, Valdis Klētnieks wrote:
On Tue, 26 Nov 2019 06:46:52 +1100, Mark Andrews said:
On 26 Nov 2019, at 03:53, Dmitry Sherman <dmitry@interhost.net> wrote:
 I believe it’s Eyeball network’s matter to free IPv4 blocks and move to v6.
It requires both sides to move to IPv6. Why should the cost of maintaining working networks be borne alone by the eyeball networks? That is what is mostly happening today with CGN.
I believe that Dmitry's point is that we will still require IPv4 addresses for new organizations deploying dual-stack
Right, which is why we started warning folks about this issue 10+ years ago, when IPv4 was still plentiful and cheap. But even content networks have NAT options, and while most of them are not pretty, the options become more limited every day that passes. I get that some people still don't like it, but the answer is IPv6. Or, folks can keep playing NAT games, etc. But one wonders at what point rolling out IPv6 costs less than all the fun you get with [CG]NAT. Doug
On 11/26/19 4:36 AM, Doug Barton wrote:
I get that some people still don't like it, but the answer is IPv6. Or, folks can keep playing NAT games, etc. But one wonders at what point rolling out IPv6 costs less than all the fun you get with [CG]NAT.
If it weren't for the ongoing need to continue to support IPv4 reachability (i.e. if we'd flag-day'd several years ago), I think the (admittedly non-scientific) answer to that question is that we have already passed it. However, in the face of continuing need for IPv4 reachability, I'm less sure. I think that the incremental cost to deploy and support IPv6 is probably no more than the incremental savings of CGNAT headaches for service providers caused by offloading what traffic you can to native IPv6. Those savings from not just from capacity savings (which can be extreme to totally trivial depending on your size) but also support for having 3rd party services properly treat an SP customer as an individual customer rather than the results of multiple SP customers being lumped onto a small CGNAT target pool. That is, even if you are 100% committed to needing to run a functional CGNAT as a service provider and deal with everything that entails, I think it's probably STILL in your short-term economic best interest to deploy IPv6 simply due to the reduction in scope of "everything that entails". -- Brandon Martin
On 2019-11-25 20:26, Brandon Martin wrote:
On 11/26/19 4:36 AM, Doug Barton wrote:
I get that some people still don't like it, but the answer is IPv6. Or, folks can keep playing NAT games, etc. But one wonders at what point rolling out IPv6 costs less than all the fun you get with [CG]NAT.
If it weren't for the ongoing need to continue to support IPv4 reachability (i.e. if we'd flag-day'd several years ago), I think the (admittedly non-scientific) answer to that question is that we have already passed it.
However, in the face of continuing need for IPv4 reachability, I'm less sure. I think that the incremental cost to deploy and support IPv6 is probably no more than the incremental savings of CGNAT headaches for service providers caused by offloading what traffic you can to native IPv6. Those savings from not just from capacity savings (which can be extreme to totally trivial depending on your size) but also support for having 3rd party services properly treat an SP customer as an individual customer rather than the results of multiple SP customers being lumped onto a small CGNAT target pool.
That is, even if you are 100% committed to needing to run a functional CGNAT as a service provider and deal with everything that entails, I think it's probably STILL in your short-term economic best interest to deploy IPv6 simply due to the reduction in scope of "everything that entails".
I think this is spot on. The only thing I'd add is that the costs to deploy IPv6 will remain fairly constant or perhaps go down some over time as economies of scale continue to grow, whereas the costs for continuing to prop up IPv4 will only increase. Doug
If the commitment really was to spread IPv6 far and wide IPv6 blocks would be handed out for free, one per qualified customer (e.g., if you have an IPv4 allocation you get one IPv6 block free), or perhaps some trivial administrative fee like $10 per year. But the RIRs can't live on that. We have put them under the management of a group of five organizations which are very dependent on the income from block allocations and no doubt were hoping IPv6 allocations would be a boon since there will be very little if any income growth from future IPv4 block allocations. Worse, once acquired an IPv6 block has so many billions of addresses very few if any would ever need another allocation so it would hardly act as a loss leader. I realize many still would not deploy IPv6 for various reasons such as their equipment doesn't support it or they don't have the in-house expertise to support it, etc tho I can't think of much other etc, a few points of resistance do come up. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On Tue, Nov 26, 2019 at 05:26:44PM -0500, bzs@theworld.com wrote:
If the commitment really was to spread IPv6 far and wide IPv6 blocks would be handed out for free, one per qualified customer (e.g., if you have an IPv4 allocation you get one IPv6 block free), or perhaps some trivial administrative fee like $10 per year.
It has been some time since I had to deal with RIRs directly, but my understanding was that if you had an IPv4 allocation, you got a reasonably sized chunk of IPv6 alongside for free. Not even an extra $10/year. FREE! Looking at ARIN's fee schedule (https://www.arin.net/resources/fees/fee_schedule/), it does seem like that is still the case:
For organizations holding both ARIN-issued IPv4 and IPv6 allocations, the fee is based on the larger of the two service categories.
So you only need to pay extra for your IPv6 numbers if you've got a lot more of them than you've got IPv4. The only situation in which I could imagine that happening is if you were a (very) late-start eyeball network that had a tiny IPv4 allocation (and a *lot* of CGNAT), but were planning on handing out IPv6 /48s to every customer. - Matt
I administer two networks that use legacy IPv4 blocks (one also uses an allocation from the 44 net) Both could have IPv6 if it was free, but neither organization has the funds to waste on a paid IPv6 allocation. We should have given every legacy block matching free IPv6 space, because early adopters are still sometimes early adopters. But you’re right, what could have been supported on a volunteer basis is now a profit center. Especially for IPv6, which is once-and-done if sized properly. Matthew Kaufman On Tue, Nov 26, 2019 at 2:29 PM <bzs@theworld.com> wrote:
If the commitment really was to spread IPv6 far and wide IPv6 blocks would be handed out for free, one per qualified customer (e.g., if you have an IPv4 allocation you get one IPv6 block free), or perhaps some trivial administrative fee like $10 per year.
But the RIRs can't live on that.
We have put them under the management of a group of five organizations which are very dependent on the income from block allocations and no doubt were hoping IPv6 allocations would be a boon since there will be very little if any income growth from future IPv4 block allocations.
Worse, once acquired an IPv6 block has so many billions of addresses very few if any would ever need another allocation so it would hardly act as a loss leader.
I realize many still would not deploy IPv6 for various reasons such as their equipment doesn't support it or they don't have the in-house expertise to support it, etc tho I can't think of much other etc, a few points of resistance do come up.
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
You’re saying that there are two networks that are of sufficient complexity/size/whatever to require PA addressing, yet lack the resources for $150/year in registration fees? I suppose it’s not impossible, but I’m wondering how they afford the other expenses associated with maintaining such a network. Owen
On Nov 30, 2019, at 09:00 , Matthew Kaufman <matthew@matthew.at> wrote:
I administer two networks that use legacy IPv4 blocks (one also uses an allocation from the 44 net)
Both could have IPv6 if it was free, but neither organization has the funds to waste on a paid IPv6 allocation.
We should have given every legacy block matching free IPv6 space, because early adopters are still sometimes early adopters.
But you’re right, what could have been supported on a volunteer basis is now a profit center. Especially for IPv6, which is once-and-done if sized properly.
Matthew Kaufman
On Tue, Nov 26, 2019 at 2:29 PM <bzs@theworld.com <mailto:bzs@theworld.com>> wrote:
If the commitment really was to spread IPv6 far and wide IPv6 blocks would be handed out for free, one per qualified customer (e.g., if you have an IPv4 allocation you get one IPv6 block free), or perhaps some trivial administrative fee like $10 per year.
But the RIRs can't live on that.
We have put them under the management of a group of five organizations which are very dependent on the income from block allocations and no doubt were hoping IPv6 allocations would be a boon since there will be very little if any income growth from future IPv4 block allocations.
Worse, once acquired an IPv6 block has so many billions of addresses very few if any would ever need another allocation so it would hardly act as a loss leader.
I realize many still would not deploy IPv6 for various reasons such as their equipment doesn't support it or they don't have the in-house expertise to support it, etc tho I can't think of much other etc, a few points of resistance do come up.
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com <http://www.theworld.com/> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
I get $500, not $150, when I read the price list. On Sun, Dec 1, 2019 at 4:06 PM Owen DeLong <owen@delong.com> wrote:
You’re saying that there are two networks that are of sufficient complexity/size/whatever to require PA addressing, yet lack the resources for $150/year in registration fees?
I suppose it’s not impossible, but I’m wondering how they afford the other expenses associated with maintaining such a network.
Owen
On Nov 30, 2019, at 09:00 , Matthew Kaufman <matthew@matthew.at> wrote:
I administer two networks that use legacy IPv4 blocks (one also uses an allocation from the 44 net)
Both could have IPv6 if it was free, but neither organization has the funds to waste on a paid IPv6 allocation.
We should have given every legacy block matching free IPv6 space, because early adopters are still sometimes early adopters.
But you’re right, what could have been supported on a volunteer basis is now a profit center. Especially for IPv6, which is once-and-done if sized properly.
Matthew Kaufman
On Tue, Nov 26, 2019 at 2:29 PM <bzs@theworld.com> wrote:
If the commitment really was to spread IPv6 far and wide IPv6 blocks would be handed out for free, one per qualified customer (e.g., if you have an IPv4 allocation you get one IPv6 block free), or perhaps some trivial administrative fee like $10 per year.
But the RIRs can't live on that.
We have put them under the management of a group of five organizations which are very dependent on the income from block allocations and no doubt were hoping IPv6 allocations would be a boon since there will be very little if any income growth from future IPv4 block allocations.
Worse, once acquired an IPv6 block has so many billions of addresses very few if any would ever need another allocation so it would hardly act as a loss leader.
I realize many still would not deploy IPv6 for various reasons such as their equipment doesn't support it or they don't have the in-house expertise to support it, etc tho I can't think of much other etc, a few points of resistance do come up.
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com <http://www.theworld.com/> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
End Users End users receive IP addresses for use in their internal networks only, and not for distribution to external users of their Internet services. End Users with Registration Services Plan End users may opt to pay for ARIN registration services on the same schedule as ISPs detailed above by subscribing to a Registration Services Plan. End users who do so receive additional services, including ARIN Membership and the ability to report reassignment information and/or provide utilization data via the Shared Whois Project (SWIP). Organizations that choose to convert to the Registration Services Plan will be evaluated as an ISP from a policy perspective when requesting future Internet number resources from ARIN. The applicable annual Registration Services Plan will be invoiced annually based on the organization resources in the ARIN registry. End Users Paying Per Resource End-user customers who do not have a Registration Services Plan pay fees per number resource, as specified below: IPv4 / IPv6 Number Resources Initial An organization will be assessed an initial fee for each new IPv4, IPv6, or experimental address assignment based on the service category approved for them by Registration Services. After an assignment has been approved, ARIN will invoice for payment. Payment and the executed Registration Services Agreement (RSA) must be received before resources are issued. Annual An organization’s annual fee is due each year at the end of their anniversary month (the month of their initial assignment). Annual maintenance fees are $150 USD for each IPv4 address block, $150 USD for each IPv6 address block, and $150 USD for each ASN assigned to the organization. Note: ARIN Membership is also available to end-user customers who pay fees on a per resource basis. https://www.arin.net/resources/fees/fee_schedule/#ipv4-ipv6-number-resources
On 2 Dec 2019, at 12:23, Matthew Kaufman <matthew@matthew.at> wrote:
I get $500, not $150, when I read the price list.
On Sun, Dec 1, 2019 at 4:06 PM Owen DeLong <owen@delong.com> wrote: You’re saying that there are two networks that are of sufficient complexity/size/whatever to require PA addressing, yet lack the resources for $150/year in registration fees?
I suppose it’s not impossible, but I’m wondering how they afford the other expenses associated with maintaining such a network.
Owen
On Nov 30, 2019, at 09:00 , Matthew Kaufman <matthew@matthew.at> wrote:
I administer two networks that use legacy IPv4 blocks (one also uses an allocation from the 44 net)
Both could have IPv6 if it was free, but neither organization has the funds to waste on a paid IPv6 allocation.
We should have given every legacy block matching free IPv6 space, because early adopters are still sometimes early adopters.
But you’re right, what could have been supported on a volunteer basis is now a profit center. Especially for IPv6, which is once-and-done if sized properly.
Matthew Kaufman
On Tue, Nov 26, 2019 at 2:29 PM <bzs@theworld.com> wrote:
If the commitment really was to spread IPv6 far and wide IPv6 blocks would be handed out for free, one per qualified customer (e.g., if you have an IPv4 allocation you get one IPv6 block free), or perhaps some trivial administrative fee like $10 per year.
But the RIRs can't live on that.
We have put them under the management of a group of five organizations which are very dependent on the income from block allocations and no doubt were hoping IPv6 allocations would be a boon since there will be very little if any income growth from future IPv4 block allocations.
Worse, once acquired an IPv6 block has so many billions of addresses very few if any would ever need another allocation so it would hardly act as a loss leader.
I realize many still would not deploy IPv6 for various reasons such as their equipment doesn't support it or they don't have the in-house expertise to support it, etc tho I can't think of much other etc, a few points of resistance do come up.
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 12/1/19 8:56 PM, Mark Andrews wrote:
End Users End users receive IP addresses for use in their internal networks only, and not for distribution to external users of their Internet services.
I guess it's possible that these networks would be considered end users, but I get the impression that they would probably be classified as ISPs, and then the fee would indeed be $500/yr for 2X-Small. A bit ridiculous for IPv6-only, but still probably approaching noise in the budget for a service provider who has a legacy allocation unless they have remained tiny somehow (in which case, sell off some of that IP space you have and pay your $500/yr for the next decade or so). FWIW, if you need it, you should also be immediately eligible for a /24 for IPv6 deployment and transition tech at no additional cost since your legacy space wouldn't be considered by ARIN unless you specifically brought it under their purview AFAIK. Even if you don't need the space, per se, there are often times where it's useful to have a disjoint /24 e.g. for traffic engineering, anycast, DNS servers, etc. All depends on how much legacy space you have, I guess. I'm also somewhat hopeful that, as those allocations all come from a known block, the various content networks will recognize them as being likely to house the inevitable (eventually) CGN sources, but I won't hold my breath. I guess you also get to vote in ARIN elections and comment on policy matters as a member, if that matters to you. -- Brandon Martin
On Dec 1, 2019, at 18:05 , Brandon Martin <lists.nanog@monmotha.net> wrote:
On 12/1/19 8:56 PM, Mark Andrews wrote:
End Users End users receive IP addresses for use in their internal networks only, and not for distribution to external users of their Internet services.
I guess it's possible that these networks would be considered end users, but I get the impression that they would probably be classified as ISPs, and then the fee would indeed be $500/yr for 2X-Small. A bit ridiculous for IPv6-only, but still probably approaching noise in the budget for a service provider who has a legacy allocation unless they have remained tiny somehow (in which case, sell off some of that IP space you have and pay your $500/yr for the next decade or so).
FWIW, if you need it, you should also be immediately eligible for a /24 for IPv6 deployment and transition tech at no additional cost since your legacy space wouldn't be considered by ARIN unless you specifically brought it under their purview AFAIK. Even if you don't need the space, per se, there are often times where it's useful to have a disjoint /24 e.g. for traffic engineering, anycast, DNS servers, etc. All depends on how much legacy space you have, I guess. I'm also somewhat hopeful that, as those allocations all come from a known block, the various content networks will recognize them as being likely to house the inevitable (eventually) CGN sources, but I won't hold my breath.
I would like to clarify that the idea of Legacy “Space” i somewhat fallacious. In reality there are only legacy registrations. Once the registration is brought under an RSA (or LRSA) either by the original holder, or through the transfer process, the resulting registration loses its “Legacy” status. In the case of LRSA, there are some additional rights afforded to the original holder, but in the event of a subsequent transfer, that space would move to a standard RSA. ARIN will consider all space held by an organization, whether legacy or otherwise in computing need. However, to the best of my knowledge, need under a section 4.10 request is computed independent of other IPv4 holdings. As such, I believe that the first /24 issued to an organization under section 4.10 would not consider their existing IPv4 holdings. Subsequent 4.10 requests are evaluated based on the utilization of the previous 4.10 space for its intended purpose.
I guess you also get to vote in ARIN elections and comment on policy matters as a member, if that matters to you.
Membership is not required to comment on policy matters. Anyone with an email address may comment on policy matters simply by subscribing to and participating in the ARIN public policy mailing list. Membership is required to vote in ARIN elections for the Advisory Council and the Board of Trustees. Owen
That’s a one-time fee for end-users (and it can be as low as $250 unless you need a /40 or more). If you’re an ISP, then yes, it’s $500 per year if you need a /40 or more (or as little as $250 if you can get buy on less than a /40). Owen
On Dec 1, 2019, at 17:23 , Matthew Kaufman <matthew@matthew.at> wrote:
I get $500, not $150, when I read the price list.
On Sun, Dec 1, 2019 at 4:06 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote: You’re saying that there are two networks that are of sufficient complexity/size/whatever to require PA addressing, yet lack the resources for $150/year in registration fees?
I suppose it’s not impossible, but I’m wondering how they afford the other expenses associated with maintaining such a network.
Owen
On Nov 30, 2019, at 09:00 , Matthew Kaufman <matthew@matthew.at <mailto:matthew@matthew.at>> wrote:
I administer two networks that use legacy IPv4 blocks (one also uses an allocation from the 44 net)
Both could have IPv6 if it was free, but neither organization has the funds to waste on a paid IPv6 allocation.
We should have given every legacy block matching free IPv6 space, because early adopters are still sometimes early adopters.
But you’re right, what could have been supported on a volunteer basis is now a profit center. Especially for IPv6, which is once-and-done if sized properly.
Matthew Kaufman
On Tue, Nov 26, 2019 at 2:29 PM <bzs@theworld.com <mailto:bzs@theworld.com>> wrote:
If the commitment really was to spread IPv6 far and wide IPv6 blocks would be handed out for free, one per qualified customer (e.g., if you have an IPv4 allocation you get one IPv6 block free), or perhaps some trivial administrative fee like $10 per year.
But the RIRs can't live on that.
We have put them under the management of a group of five organizations which are very dependent on the income from block allocations and no doubt were hoping IPv6 allocations would be a boon since there will be very little if any income growth from future IPv4 block allocations.
Worse, once acquired an IPv6 block has so many billions of addresses very few if any would ever need another allocation so it would hardly act as a loss leader.
I realize many still would not deploy IPv6 for various reasons such as their equipment doesn't support it or they don't have the in-house expertise to support it, etc tho I can't think of much other etc, a few points of resistance do come up.
-- -Barry Shein
Software Tool & Die | bzs@TheWorld.com <mailto:bzs@TheWorld.com> | http://www.TheWorld.com <http://www.theworld.com/> Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
I get that some people still don't like it, but the answer is IPv6. Or, folks can keep playing NAT games, etc. But one wonders at what point rolling out IPv6 costs less than all the fun you get with [CG]NAT.
When the MBAs start realizing the risk of not deploying it. I have some inside knowledge about the IPv6 efforts of a large eyeball network. In that particular case, the cost of deploying IPv6 internally is not simply configuring it on the network gear; that has already been done. The cost of fully supporting IPv6 includes (but is probably not limited to): - Support for deploying IPv6 across more than 20 different teams; - Modifying old (ancient) internal code; - Modifying old (ancient) database structures (think 16 character fields for IP addresses); - Upgrading/replacing load balancers and other legacy crap that only support IPv4 (yeah, they still exist); - Modifying the countless home-grown tools that automate firewalls etc; - Auditing the PCI infrastructure to ensure it is still compliant after deploying IPv6; If it was as simple as upgrading a few IP stacks here and there, it would be a non-issue. Don't get me wrong, I'm not advocating against IPv6 deployment; on the contrary. But it is not that simple in the real corporate world. Execs have bonus targets. IPv6 is not yet important enough to become part of that bonus target: there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6. IPv6 must be supported on the CxO level in order to be deployed. Thanks, Sabri, (Badum tsss) MBA
On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
I get that some people still don't like it, but the answer is IPv6. Or, folks can keep playing NAT games, etc. But one wonders at what point rolling out IPv6 costs less than all the fun you get with [CG]NAT.
When the MBAs start realizing the risk of not deploying it.
Hey, i have an mba. That and $5 will get me cup of coffee.
I have some inside knowledge about the IPv6 efforts of a large eyeball network.
Me too. In that particular case, the cost of deploying IPv6 internally is not
simply configuring it on the network gear; that has already been done. The cost of fully supporting IPv6 includes (but is probably not limited to):
- Support for deploying IPv6 across more than 20 different teams;
Wow. I support 80M mobile subscribers, 90% of which are ipv6-only. I think 20 people in the company can spell ipv6, but somehow you need 20 teams.... how many teams speak ipv4 ?
- Modifying old (ancient) internal code;
Ancient in 2019 means what? Is this code not in security compliance ?
- Modifying old (ancient) database structures (think 16 character fields for IP addresses);
Hash 128 bits into 240/4 is how i heard Google handled it early on
- Upgrading/replacing load balancers and other legacy crap that only support IPv4 (yeah, they still exist);
Again, with all the CVEs, this code is always moving in the real world.
- Modifying the countless home-grown tools that automate firewalls etc;
Home grown means it can be fixed instead of replaced.
- Auditing the PCI infrastructure to ensure it is still compliant after deploying IPv6;
Ah, so you are keeping up with compliance / cve and are upgrading at regular intervals?
If it was as simple as upgrading a few IP stacks here and there, it would be a non-issue.
Usually is just a few edge stacks to start and scale the edge
Don't get me wrong, I'm not advocating against IPv6 deployment; on the contrary. But it is not that simple in the real corporate world. Execs have bonus targets.
Why would an exec care? Ipv6 is just normal work like ipv4. IPv6 is not yet important enough to become part of that bonus target: The bonus target was normal business continuity planning... in 2008. Sorry you missed that one. Here you go, just put 1 in 2009 to make it 2019 so you dont look so bad https://www.arin.net/vault/knowledge/about_resources/ceo_letter.pdf there is no ROI at this point. In this kind of environment there needs to
be a strong case to invest the capex to support IPv6.
IPv6 must be supported on the CxO level in order to be deployed.
Thanks,
Sabri, (Badum tsss) MBA
I see....well let me translate it you MBA-eese for you: FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile providers in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets.
On 2019-11-26 17:11, Ca By wrote:
On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
[snip]
there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6.
IPv6 must be supported on the CxO level in order to be deployed.
Thanks,
Sabri, (Badum tsss) MBA
I see....well let me translate it you MBA-eese for you:
FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile providers in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets.
None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019. I regularly vet deals for our sales team, and out of the hundreds of deals we sold this year, I can count on one hand the number of deals where customers wanted IPv6. We sold them IPv6 access, but we didn't put it on our own network, because we face the same internal challenges Sabri mentioned. (SD-WAN, OTOH, was far more popular. I'll give you three guesses why. Hint - it's not because tunnel technology is awesome and allows us to scale our networks further and everyone is doing it.) Though their participation has been key in making IPv6 more useful for eyeballs, content hasn't driven adoption. The only thing eyeballs care about is getting to 100% of what they need and want at minimal cost. Until eyeball networks start charging eyeballs for IPv4, IPv4 will linger. The day eyeballs start bitching on forums, opening tickets, complaining on Twitter, etc. because they have only IPv6 is when IPv4 will start to lose relevance. As an aside, I would guess that it's the corporate eyeball customers with servers, not resi/mobile behind CGNAT, that will bear the brunt of the IPv4 cost first. But what enterprise wants to tell its non-IPv6 customers "your Internet needs to be upgraded, come back to us when you're done?" That doesn't bode well for the short-term future. -Brian
On Wed Nov 27, 2019 at 01:08:04PM -0600, Brian Knight wrote:
None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019. I regularly vet deals for our sales team, and out of the hundreds of deals we sold this year, I can count on one hand the number of deals where customers wanted IPv6. We sold them IPv6 access, but we didn't put it on our own network, because we face the same internal challenges Sabri mentioned. (SD-WAN, OTOH, was far more popular
A few year later customer wakes up: "wait you sold us all those toys we didn't need but didn't include the basic transport capabilites everyone apparently has been saying for over a decade are required minimum?" "and now you want us to pay you to rebuild it again and trust that you got the basics right this time?" If you're an internet professional you are a negligent one if by now you are not ensuring all you build quietly includes IPv6, no customer should need to know to ask for it. It's not like it needs different kit.
As an aside, I would guess that it's the corporate eyeball customers with servers, not resi/mobile behind CGNAT, that will bear the brunt of the IPv4 cost first. But what enterprise wants to tell its non-IPv6 customers "your Internet needs to be upgraded, come back to us when you're done?" That doesn't bode well for the short-term future.
"all that multi natted into same address space VPN firewall complicated knitting we never got right wasn't needed if you'd told us to use IPv6?" brandon
On Nov 27, 2019, at 2:54 PM, Brandon Butterworth <brandon@rd.bbc.co.uk> wrote:
On Wed Nov 27, 2019 at 01:08:04PM -0600, Brian Knight wrote: None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019. I regularly vet deals for our sales team, and out of the hundreds of deals we sold this year, I can count on one hand the number of deals where customers wanted IPv6. We sold them IPv6 access, but we didn't put it on our own network, because we face the same internal challenges Sabri mentioned. (SD-WAN, OTOH, was far more popular
A few year later customer wakes up:
"wait you sold us all those toys we didn't need but didn't include the basic transport capabilites everyone apparently has been saying for over a decade are required minimum?"
"and now you want us to pay you to rebuild it again and trust that you got the basics right this time?"
If you're an internet professional you are a negligent one if by now you are not ensuring all you build quietly includes IPv6, no customer should need to know to ask for it. It's not like it needs different kit.
Possibly some customers may react this way, but I’m thinking many more would ask “what does it take to enable it?” Most are reasonable and show good faith, even if an equipment swap is needed. And if the demand for IPv6 is there, the providers will get the work prioritized.
As an aside, I would guess that it's the corporate eyeball customers with servers, not resi/mobile behind CGNAT, that will bear the brunt of the IPv4 cost first. But what enterprise wants to tell its non-IPv6 customers "your Internet needs to be upgraded, come back to us when you're done?" That doesn't bode well for the short-term future.
"all that multi natted into same address space VPN firewall complicated knitting we never got right wasn't needed if you'd told us to use IPv6?"
IPv6 doesn’t help anyone get access to their IPv4-only customers. (Too bad that it doesn’t.) My point was that, if eyeball networks start charging a premium for IPv4, their likely first customers to be charged are business customers not behind CGNAT. Those that don’t wish to pay the IPv4 premium would have to force *their* customers to go IPv6. That would be a much more difficult conversation than simply paying the premium. So out of all the forces at work, which gives way first?
brandon
Thanks, -Brian
IPv6 significantly offloads the CGN servers. If you are not yet using CGN you probably won't care, but sooner or later you will. Thanks to the content providers that make this possible by offering enough content by volume available on the IPv6 internet. Regards Baldur
Brian Knight wrote : None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019.
And will for the foreseable future. I am not one of your customers, but I like your realistic views. I vote with my wallet and buy my transit from the ISP who understands my needs.
I regularly vet deals for our sales team, and out of the hundreds of deals we sold this year, I can count on one hand the number of deals where customers wanted IPv6.
Won't change any time soon. For the vast majority of business eyballs and entreprises, IPv6 is not even on the agenda.
But what enterprise wants to tell its non-IPv6 customers "your Internet needs to be upgraded, come back to us when you're done?" That doesn't bode well for the short-term future.
None of my customers has IPv6. None of my suppliers has IPv6. Nobody wants The business / enterprise ecosystem is and will remain of a size large enough to keep the IPv4 services for the foreseeable future. Facebook going IPv6-only ? that would be a blessing. That is not what we pay employees to do at the office. As Sabri would have said, why should I look like an idiot and go to the board and the investors for money to invest in something that has zero ROI ? I was on the 6bone. I heard the IPv6 FUD for 20 years. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
On 28 Nov 2019, at 06:08, Brian Knight <ml@knight-networks.com> wrote:
On 2019-11-26 17:11, Ca By wrote:
On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
[snip]
there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6. IPv6 must be supported on the CxO level in order to be deployed. Thanks, Sabri, (Badum tsss) MBA I see....well let me translate it you MBA-eese for you: FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile providers in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets.
None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019.
No you can’t. You can’t reach the machine I’m typing on via IPv4 and it is ON THE INTERNET. It is directly reachable via IPv6. Selling Internet connectivity without IPv6 should be considered fraud these days. Don’t you believe in “Truth in Advertising”?
I regularly vet deals for our sales team, and out of the hundreds of deals we sold this year, I can count on one hand the number of deals where customers wanted IPv6. We sold them IPv6 access, but we didn't put it on our own network, because we face the same internal challenges Sabri mentioned. (SD-WAN, OTOH, was far more popular. I'll give you three guesses why. Hint - it's not because tunnel technology is awesome and allows us to scale our networks further and everyone is doing it.)
Though their participation has been key in making IPv6 more useful for eyeballs, content hasn't driven adoption. The only thing eyeballs care about is getting to 100% of what they need and want at minimal cost. Until eyeball networks start charging eyeballs for IPv4, IPv4 will linger. The day eyeballs start bitching on forums, opening tickets, complaining on Twitter, etc. because they have only IPv6 is when IPv4 will start to lose relevance.
As an aside, I would guess that it's the corporate eyeball customers with servers, not resi/mobile behind CGNAT, that will bear the brunt of the IPv4 cost first. But what enterprise wants to tell its non-IPv6 customers "your Internet needs to be upgraded, come back to us when you're done?" That doesn't bode well for the short-term future.
-Brian
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Brian Knight wrote : None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019.
Mark Andrews wrote : No you can’t. You can’t reach the machine I’m typing on via IPv4 and it is ON THE INTERNET.
Why should I care ? it contains zero content of value to me. It's on a subset of the Internet that contains zero content that interests me. Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
On Nov 27, 2019, at 4:04 PM, Mark Andrews <marka@isc.org> wrote:
On 28 Nov 2019, at 06:08, Brian Knight <ml@knight-networks.com> wrote:
On 2019-11-26 17:11, Ca By wrote: On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
[snip]
there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6. IPv6 must be supported on the CxO level in order to be deployed. Thanks, Sabri, (Badum tsss) MBA I see....well let me translate it you MBA-eese for you: FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile providers in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets.
None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019.
No you can’t. You can’t reach the machine I’m typing on via IPv4 and it is ON THE INTERNET. It is directly reachable via IPv6. Selling Internet connectivity without IPv6 should be considered fraud these days. Don’t you believe in “Truth in Advertising”?
I had meant to write “They can still get from our network to 100% of all Internet content and services that matter to them [our customers] via IPv4...” 0% of my IPv4-only customers have opened tickets saying they cannot reach some service that is only IPv6 accessible. So if they do care about IPv6 connectivity, they haven’t communicated that to us.
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Thanks, -Brian
"So if they do care about IPv6 connectivity, they haven’t communicated that to us." Nor will they, but that doesn't mean IPv6 isn't important. Frankly, I'm surprised anti-IPv6 people still have employment. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Brian Knight" <ml@knight-networks.com> To: "Mark Andrews" <marka@isc.org> Cc: "nanog" <nanog@nanog.org> Sent: Friday, November 29, 2019 10:29:17 AM Subject: Re: RIPE our of IPv4
On Nov 27, 2019, at 4:04 PM, Mark Andrews <marka@isc.org> wrote:
On 28 Nov 2019, at 06:08, Brian Knight <ml@knight-networks.com> wrote:
On 2019-11-26 17:11, Ca By wrote: On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
[snip]
there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6. IPv6 must be supported on the CxO level in order to be deployed. Thanks, Sabri, (Badum tsss) MBA I see....well let me translate it you MBA-eese for you: FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile providers in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets.
None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019.
No you can’t. You can’t reach the machine I’m typing on via IPv4 and it is ON THE INTERNET. It is directly reachable via IPv6. Selling Internet connectivity without IPv6 should be considered fraud these days. Don’t you believe in “Truth in Advertising”?
I had meant to write “They can still get from our network to 100% of all Internet content and services that matter to them [our customers] via IPv4...” 0% of my IPv4-only customers have opened tickets saying they cannot reach some service that is only IPv6 accessible. So if they do care about IPv6 connectivity, they haven’t communicated that to us.
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Thanks, -Brian
On Nov 29, 2019, at 5:28 PM, Mike Hammett <nanog@ics-il.net> wrote: "So if they do care about IPv6 connectivity, they haven’t communicated that to us."
Nor will they, but that doesn't mean IPv6 isn't important.
Personally, I don’t disagree. We engineers do what we can to support IPv6: We build it into our tooling and switch it on in our gear. Our network is dual stack v4/v6 and has been for quite a while. But with other tools we don’t control, and particularly in terms of business process, we have a ways to go, and it’s not a priority. I want IPv6 to succeed, really. But the global end game picture looks more and more bleak to me.
Frankly, I'm surprised anti-IPv6 people still have employment.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
-Brian
From: "Brian Knight" <ml@knight-networks.com> To: "Mark Andrews" <marka@isc.org> Cc: "nanog" <nanog@nanog.org> Sent: Friday, November 29, 2019 10:29:17 AM Subject: Re: RIPE our of IPv4
On Nov 27, 2019, at 4:04 PM, Mark Andrews <marka@isc.org> wrote:
On 28 Nov 2019, at 06:08, Brian Knight <ml@knight-networks.com> wrote:
On 2019-11-26 17:11, Ca By wrote: On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
[snip]
there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6. IPv6 must be supported on the CxO level in order to be deployed. Thanks, Sabri, (Badum tsss) MBA I see....well let me translate it you MBA-eese for you: FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile providers in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets.
None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019.
No you can’t. You can’t reach the machine I’m typing on via IPv4 and it is ON THE INTERNET. It is directly reachable via IPv6. Selling Internet connectivity without IPv6 should be considered fraud these days. Don’t you believe in “Truth in Advertising”?
I had meant to write “They can still get from our network to 100% of all Internet content and services that matter to them [our customers] via IPv4...”
0% of my IPv4-only customers have opened tickets saying they cannot reach some service that is only IPv6 accessible. So if they do care about IPv6 connectivity, they haven’t communicated that to us.
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Thanks,
-Brian
On Sat, Nov 30, 2019 at 8:06 AM Brian Knight <ml@knight-networks.com> wrote:
On Nov 29, 2019, at 5:28 PM, Mike Hammett <nanog@ics-il.net> wrote:
"So if they do care about IPv6 connectivity, they haven’t communicated that to us."
Nor will they, but that doesn't mean IPv6 isn't important.
Personally, I don’t disagree. We engineers do what we can to support IPv6: We build it into our tooling and switch it on in our gear. Our network is dual stack v4/v6 and has been for quite a while. But with other tools we don’t control, and particularly in terms of business process, we have a ways to go, and it’s not a priority.
I want IPv6 to succeed, really. But the global end game picture looks more and more bleak to me.
I can see how your situation is bleak That said, google see nearly 40% of their traffic on ipv6 in the usa , growth trend looks strong https://www.google.com/intl/en/ipv6/statistics.html And Comcast (71%), Charter (52%), VZ (85%), ATT (60 and 78%) , and T-Mobile (95%) have the majority of their subs on ipv6 https://www.worldipv6launch.org/measurements/ Sadly, ipv6 is creating a bifurcation of the internet. Scale shops have v6, and non-scale shops don’t. The big players are pulling away, and that makes things bleak for the folks just trying to tread water in ipv4.
Frankly, I'm surprised anti-IPv6 people still have employment.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
-Brian
------------------------------ *From: *"Brian Knight" <ml@knight-networks.com> *To: *"Mark Andrews" <marka@isc.org> *Cc: *"nanog" <nanog@nanog.org> *Sent: *Friday, November 29, 2019 10:29:17 AM *Subject: *Re: RIPE our of IPv4
On Nov 27, 2019, at 4:04 PM, Mark Andrews <marka@isc.org> wrote:
On 28 Nov 2019, at 06:08, Brian Knight <ml@knight-networks.com> wrote:
On 2019-11-26 17:11, Ca By wrote: On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri@cluecentral.net> wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6. IPv6 must be supported on the CxO level in order to be deployed. Thanks, Sabri, (Badum tsss) MBA I see....well let me translate it you MBA-eese for you: FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile
[snip] providers
in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets.
None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019.
No you can’t. You can’t reach the machine I’m typing on via IPv4 and it is ON THE INTERNET. It is directly reachable via IPv6. Selling Internet connectivity without IPv6 should be considered fraud these days. Don’t you believe in “Truth in Advertising”?
I had meant to write “They can still get from our network to 100% of all Internet content and services that matter to them [our customers] via IPv4...”
0% of my IPv4-only customers have opened tickets saying they cannot reach some service that is only IPv6 accessible. So if they do care about IPv6 connectivity, they haven’t communicated that to us.
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW <https://www.google.com/maps/search/1+Seymour+St.,+Dundas+Valley,+NSW?entry=gmail&source=g> 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Thanks,
-Brian
On Sat, Nov 30, 2019 at 11:46 AM Ca By <cb.list6@gmail.com> wrote:
That said, google see nearly 40% of their traffic on ipv6 in the usa , growth trend looks strong
https://www.google.com/intl/en/ipv6/statistics.html
And
Comcast (71%), Charter (52%), VZ (85%), ATT (60 and 78%) , and T-Mobile (95%) have the majority of their subs on ipv6
Verizon is an interesting case. While IPv6 penetration on the wireless side is very high, the same is not true on the Fios/DSL side. IPv6 deployment there is nearly nonexistent. I've heard rumblings that some early Fios users will need to have their ONTs replaced to be able to get v6, regardless if the router itself supports it. I don't know if this is true, because I've never been able to get a straight/authoritative answer from Verizon. While a tunnel from HE works perfectly well, it would be nice to have native v6 from VZ. jms
Sadly, ipv6 is creating a bifurcation of the internet. Scale shops have v6, and non-scale shops don’t. The big players are pulling away, and that makes things bleak for the folks just trying to tread water in ipv4.
Frankly, I'm surprised anti-IPv6 people still have employment.
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest-IX http://www.midwest-ix.com
-Brian
------------------------------ *From: *"Brian Knight" <ml@knight-networks.com> *To: *"Mark Andrews" <marka@isc.org> *Cc: *"nanog" <nanog@nanog.org> *Sent: *Friday, November 29, 2019 10:29:17 AM *Subject: *Re: RIPE our of IPv4
On Nov 27, 2019, at 4:04 PM, Mark Andrews <marka@isc.org> wrote:
On 28 Nov 2019, at 06:08, Brian Knight <ml@knight-networks.com> wrote:
On 2019-11-26 17:11, Ca By wrote: On Tue, Nov 26, 2019 at 12:15 AM Sabri Berisha <sabri@cluecentral.net
wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
there is no ROI at this point. In this kind of environment there needs to be a strong case to invest the capex to support IPv6. IPv6 must be supported on the CxO level in order to be deployed. Thanks, Sabri, (Badum tsss) MBA I see....well let me translate it you MBA-eese for you: FANG deployed ipv6 nearly 10 years ago. Since deploying ipv6, the cohort experienced 300% CAGR. Also, everything is mobile, and all mobile
[snip] providers
in the usa offer ipv6 by default in most cases. Latency! Scale! As your company launches its digital transformation iot 2020 virtualization container initiatives, ipv6 will be an integral part of staying relevant on the blockchain. Also, FANG did it nearly 10 years ago. Big content and big eyeballs are on ipv6, ipv4 is a winnowing longtail of irrelevance and iot botnets.
None of which matters a damn to almost all of my business eyeball customers. They can still get from our network to 100% of all Internet content & services via IPv4 in 2019.
No you can’t. You can’t reach the machine I’m typing on via IPv4 and it is ON THE INTERNET. It is directly reachable via IPv6. Selling Internet connectivity without IPv6 should be considered fraud these days. Don’t you believe in “Truth in Advertising”?
I had meant to write “They can still get from our network to 100% of all Internet content and services that matter to them [our customers] via IPv4...”
0% of my IPv4-only customers have opened tickets saying they cannot reach some service that is only IPv6 accessible. So if they do care about IPv6 connectivity, they haven’t communicated that to us.
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW <https://www.google.com/maps/search/1+Seymour+St.,+Dundas+Valley,+NSW?entry=gmail&source=g> 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Thanks,
-Brian
On Sat, Nov 30, 2019 at 9:21 AM Justin Streiner <streinerj@gmail.com> wrote:
While a tunnel from HE works perfectly well, it would be nice to have native v6 from VZ.
Worked perfectly well. Until Netflix blocked all known tunnel providers. Then my users demanded I turn IPv6 off... so I did. Won’t come back until both my up streams properly support it. Matthew Kaufman
You can announce your own IPv6 subnets through TunnelBroker. Filip On 30 November 2019 8:37:33 pm GMT+01:00, Matthew Kaufman <matthew@matthew.at> wrote:
On Sat, Nov 30, 2019 at 9:21 AM Justin Streiner <streinerj@gmail.com> wrote:
While a tunnel from HE works perfectly well, it would be nice to have native v6 from VZ.
Worked perfectly well. Until Netflix blocked all known tunnel providers. Then my users demanded I turn IPv6 off... so I did. Won’t come back until both my up streams properly support it.
Matthew Kaufman
-- Sent from my mobile device. Please excuse my brevity.
See previous message about legacy IPv4 holders without budget for IPv6 blocks On Sat, Nov 30, 2019 at 12:15 PM Filip Hruska <fhr@fhrnet.eu> wrote:
You can announce your own IPv6 subnets through TunnelBroker.
Filip
On 30 November 2019 8:37:33 pm GMT+01:00, Matthew Kaufman < matthew@matthew.at> wrote:
On Sat, Nov 30, 2019 at 9:21 AM Justin Streiner <streinerj@gmail.com> wrote:
While a tunnel from HE works perfectly well, it would be nice to have native v6 from VZ.
Worked perfectly well. Until Netflix blocked all known tunnel providers. Then my users demanded I turn IPv6 off... so I did. Won’t come back until both my up streams properly support it.
Matthew Kaufman
-- Sent from my mobile device. Please excuse my brevity.
On 11/30/19 4:48 PM, Matthew Kaufman wrote:
See previous message about legacy IPv4 holders without budget for IPv6 blocks
How slim are your margins to have been around long enough to have a legacy IPv4 block but not be able to afford the ARIN fees to get a comparable/very usable (/48 to /52 for each IPv4) amount of IPv6? And if you don't need a "comparable" amount of IPv6, presumably you aren't using all your legacy IPv4 and can sell off part of its presumably huge allocation to get some funds. -- Brandon Martin
On Sat, Nov 30, 2019 at 4:57 PM Brandon Martin <lists.nanog@monmotha.net> wrote:
On 11/30/19 4:48 PM, Matthew Kaufman wrote:
See previous message about legacy IPv4 holders without budget for IPv6 blocks
How slim are your margins to have been around long enough to have a legacy IPv4 block but not be able to afford the ARIN fees to get a comparable/very usable (/48 to /52 for each IPv4) amount of IPv6? And if you don't need a "comparable" amount of IPv6, presumably you aren't using all your legacy IPv4 and can sell off part of its presumably huge allocation to get some funds. --
Nonprofit that acts as an ISP with a budget of a few thousand a year, smallest allocation to an ISP would be $500/yr in fees, a substantial fraction of budget.
On 1/Dec/19 02:54, Brandon Martin wrote:
How slim are your margins to have been around long enough to have a legacy IPv4 block but not be able to afford the ARIN fees to get a comparable/very usable (/48 to /52 for each IPv4) amount of IPv6? And if you don't need a "comparable" amount of IPv6, presumably you aren't using all your legacy IPv4 and can sell off part of its presumably huge allocation to get some funds.
AFRINIC offered IPv6 /32's for free for every member that paid for their IPv4. Not sure if they still do, but my annual bill does mention that amount of IPv6 space we have. Mark.
This is that reasoning that because this particular shiny bauble is laying right here on the table then that's the whole picture. More likely if some of them decided to sell that IPv4 block they'd catch up on the rent or cut deductibles on the health care plan or or get rid of some of that 100mb ethernet or something. IPv6 would be way, way down on that list. That's how small businesses run. On November 30, 2019 at 19:54 lists.nanog@monmotha.net (Brandon Martin) wrote:
On 11/30/19 4:48 PM, Matthew Kaufman wrote:
See previous message about legacy IPv4 holders without budget for IPv6 blocks
How slim are your margins to have been around long enough to have a legacy IPv4 block but not be able to afford the ARIN fees to get a comparable/very usable (/48 to /52 for each IPv4) amount of IPv6? And if you don't need a "comparable" amount of IPv6, presumably you aren't using all your legacy IPv4 and can sell off part of its presumably huge allocation to get some funds. -- Brandon Martin
-- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
On 11/30/19 12:18 PM, Justin Streiner wrote:
Verizon is an interesting case. While IPv6 penetration on the wireless side is very high, the same is not true on the Fios/DSL side. IPv6 deployment there is nearly nonexistent. I've heard rumblings that some early Fios users will need to have their ONTs replaced to be able to get v6, regardless if the router itself supports it. I don't know if this is true, because I've never been able to get a straight/authoritative answer from Verizon.
Does Verizon still own/manage ANY of their Fios territories? I thought it was all sold off to Frontier at this point. It certainly all is, along with all their legacy LEC territories not having FTTx and having some form of DSL, around here. The latter DSL offerings are usually pretty hilarious. It's mostly run out of the CO or existing RTUs from the POTS era. I can't imagine they have a ton of subscribers outside of areas with literally no other wireline options, and I'm guessing a lot of that infrastructure hasn't been touched in a decade-plus. Is Frontier-managed Fios included in those numbers regardless, or are they separate like I'd expect them to be? -- Brandon Martin
On Sat, Nov 30, 2019 at 7:58 PM Brandon Martin <lists.nanog@monmotha.net> wrote:
Does Verizon still own/manage ANY of their Fios territories? I thought it was all sold off to Frontier at this point. It certainly all is, along with all their legacy LEC territories not having FTTx and having some form of DSL, around here. The latter DSL offerings are usually pretty hilarious. It's mostly run out of the CO or existing RTUs from the POTS era. I can't imagine they have a ton of subscribers outside of areas with literally no other wireline options, and I'm guessing a lot of that infrastructure hasn't been touched in a decade-plus.
Is Frontier-managed Fios included in those numbers regardless, or are they separate like I'd expect them to be?
I don't think those numbers include wireline territories that were transferred from Verizon to Frontier, but in my area (western Pennsylvania), Fios service is provided by Verizon. Verizon hasn't updated their IPv6 resource site since at least 2012. It still includes a subtle but significant typo. A /56 does not give you "56 LANs".... Requests for updates from front-line customer service go into a black hole, as do sidebar questions to our Verizon account team at $dayjob. jms
On Dec 2, 2019, at 12:09 AM, Justin Streiner <streinerj@gmail.com> wrote:
Requests for updates from front-line customer service go into a black hole, as do sidebar questions to our Verizon account team at $dayjob.
Most of the cellular + wireline providers are looking to bring FTT(area) and then just do cellular backhaul. This is going to let them overlay the existing areas outside their primary service area and compete in last-mile in ways they couldn’t do years ago. T-Mobile and ATT both have these services today. I haven’t seen a Verizon announcement but expect it. Much of the ATT expansion was funded out of CAF II funds. https://www.fcc.gov/reports-research/maps/caf2-auction903-results/ Any new developments the providers are all doing fiber on poles or underground (which makes sense in a joint trench situation). I expect those services will remain at the IPv6 density they are at present and only increase over time as services continue to put AAAA on their front-side. I’m not expecting Verizon to invest any more into existing FIOS than they did in the areas they divested. - Jared
On 30/Nov/19 18:45, Ca By wrote:
Sadly, ipv6 is creating a bifurcation of the internet. Scale shops have v6, and non-scale shops don’t. The big players are pulling away, and that makes things bleak for the folks just trying to tread water in ipv4.
Well, China have scale, but perhaps Google's data sets aren't reliable in that region. Mark.
On 11/29/19 11:29 AM, Brian Knight wrote:
0% of my IPv4-only customers have opened tickets saying they cannot reach some service that is only IPv6 accessible. So if they do care about IPv6 connectivity, they haven’t communicated that to us.
I help admin a very small (<1k subs, but growing) municipal ISP. We have had a couple requests from residential subscribers for IPv6 which is not yet enabled due to lack of support for a nice, but not strictly required, feature from one vendor in our stack (and they have opened a feature request and promised support in the next release - we'll see if they deliver). If a SP with <1k subs has ANY registered interest, I'd say a non-trivial SP is going to have some even if it's not being communicated. Certainly, to me, if I have a choice of service providers, and one offers native IPv6 (or even well-supported 6rd) while the other offers no IPv6 and has no plans or is even downright IPv6-hostile (e.g. mucking with protocol 41), that's certainly going to factor into my decision. This is a pre-sales issue which, on standard consumer services, is unlikely to ever be communicated to the provider. However, I'll admit that I'm not a normal customer. Interestingly, albeit somewhat unsurprisingly, interest from enterprises on DIA services (where the aforementioned feature is irrelevant) has been not just nonexistent but outright hostile. Every one of them has asked to have it explicitly disabled when prompted. Enterprise is definitely the lagging factor, here. I suspect it's at least partially because high-ratio NAT44 has been the norm for enterprise deployments for some time, and, among those who might otherwise be willing to support first-class dual stack, many enterprise IT folks lack the education to recognize the nuance between public addressing and unfiltered public reachability of a given host. I suspect many of them are already using IPv6 for LAN traffic without even realizing it given Windows' penchant for doing so since Vista. -- Brandon Martin
On Fri, 29 Nov 2019 23:26:04 -0500, Brandon Martin said:
definitely the lagging factor, here. I suspect it's at least partially because high-ratio NAT44 has been the norm for enterprise deployments for some time, and, among those who might otherwise be willing to support first-class dual stack, many enterprise IT folks lack the education to recognize the nuance between public addressing and unfiltered public reachability of a given host. I suspect many of them are already using IPv6 for LAN traffic without even realizing it given Windows' penchant for doing so since Vista.
Judging how long it took to (mostly) stamp out CLASSA/B/C nonsense, we're in for at least a decade of IPv6 firewalls that block all ICMP, plus whatever common IPv6 misconfigurations and misconceptions are out there (I was deploying this stuff literally last century, so I admit not knowing what people are screwing up currently).
On Tuesday 2019-11-26 00:13, Sabri Berisha wrote:
Don't get me wrong, I'm not advocating against IPv6 deployment; on the contrary. But it is not that simple in the real corporate world. Execs have bonus targets. IPv6 is not yet important enough to become part of that bonus target: there is no ROI at this point.
Though eyeballs need to change, so does content. And eyeballs will invest if the content were to demand it. So, perhaps Google will give IPv6 hosted content the same tiny boost they gave HTTPS content. /mark
On 11/26/19 12:13 AM, Sabri Berisha wrote:
----- On Nov 26, 2019, at 1:36 AM, Doug Barton dougb@dougbarton.us wrote:
I get that some people still don't like it, but the answer is IPv6. Or, folks can keep playing NAT games, etc. But one wonders at what point rolling out IPv6 costs less than all the fun you get with [CG]NAT.
When the MBAs start realizing the risk of not deploying it.
I have some inside knowledge about the IPv6 efforts of a large eyeball network.
For what it's worth, I have extensive experience in both eyeball and content networks.
In that particular case, the cost of deploying IPv6 internally is not simply configuring it on the network gear;
We're rehashing old ground here. Perhaps you weren't on the list the last N times this has come up. My short answer, I didn't say it would be easy, I said it is less expensive than the alternatives over time.
that has already been done. The cost of fully supporting IPv6 includes (but is probably not limited to):
- Support for deploying IPv6 across more than 20 different teams;
I don't understand how you're using "teams" here. For the most part you turn it on, and end-user systems pick up the RA and do the right thing. If you want something fancier, you can do that with DHCP, static addressing, etc. In other words, this works the exact same way that IPv4 does.
- Modifying old (ancient) internal code;
What code? IPv4 isn't going away on the inside, so what needs to be modified? If you're talking monitoring software, etc., if you're still using software that doesn't understand IPv6, you're way overdue for an upgrade already.
- Modifying old (ancient) database structures (think 16 character fields for IP addresses);
Either see above, or much more likely you'd be adding a field, not modifying the existing one.
- Upgrading/replacing load balancers and other legacy crap that only support IPv4 (yeah, they still exist);
If we're talking about an enterprise that is seriously still using stuff this old, it's more likely than not that IPv6 is the least of their worries. And I'm not being flippant or disrespectful here. For at least the last 10 years or so, and definitely in the last 5, all of the enterprise level network gear sold has had support for IPv6. So again, way overdue for an update, but if this is all you have available, then you likely have bigger fish to fry. (And feel free to save the obligatory, "My favorite network widget that I use in my 100% enterprise-class network does not support IPv6." Yes, I realize that there are exceptions, but they are the exceptions, not the rule.)
- Modifying the countless home-grown tools that automate firewalls etc;
Yes, this is actually a legitimate point.
- Auditing the PCI infrastructure to ensure it is still compliant after deploying IPv6;
Also legit, where it applies, although you also have the option of not deploying on the network with the PCI data. For internal-only things, it's great to have IPv6, and will become increasingly important as time goes on, but it's not required.
Execs have bonus targets. IPv6 is not yet important enough to become part of that bonus target: there is no ROI at this point.
That depends heavily on what enterprise you're talking about. The point I'm trying to make is that there IS an ROI here. For content providers it's the ability to create a stable network architecture across all of your sites, and connect directly to the many eyeballs that are already on IPv6 (cell networks, many ISPs, etc.). There is also the much harder to define ROI for future-proofing the network, but that's part of the master class. :) For eyeball networks the same stable network architecture argument applies. The immediate ROI is harder to define, but similar, in the sense that connect directly to the many content networks that have already deployed IPv6 and future-proofing are both relevant. Much harder for the eyeball networks to quantify are the savings related to NOT having to do [CG]NAT, etc. To create that slide you need an exec who truly understands the (rising over time) costs of twiddling around with the NATs, as well as the realistic costs involved in rolling out IPv6 balanced by the long term support. Then you also need an executive team and board that can understand those slides when they see them. But it's not all in vain. I'm on Spectrum here at home, and I have native IPv6 that "just worked" from the moment I plugged my router into my cable modem. So there are a non-trivial number of both eyeball and content networks that already get it. The value proposition obviously does exist, we just need more people in the right places with the right knowledge and experience to make it happen. Doug
----- On Nov 27, 2019, at 8:03 PM, Doug Barton dougb@dougbarton.us wrote:
I don't understand how you're using "teams" here. For the most part you turn it on, and end-user systems pick up the RA and do the right thing. If you want something fancier, you can do that with DHCP, static addressing, etc. In other words, this works the exact same way that IPv4 does.
Different teams support different parts of the business. Also, most large enterprises today have been through multiple acquisitions, with different systems that are somehow merged into each other. Those that know how it works have left a long time ago, and those that don't won't touch it.
- Modifying old (ancient) internal code;
What code? IPv4 isn't going away on the inside, so what needs to be modified? If you're talking monitoring software, etc., if you're still using software that doesn't understand IPv6, you're way overdue for an upgrade already.
There can be many things that need to be modified. And I'm not saying an upgrade is not long overdue, I'm saying it must make sense on the business side before the engineering side gets the go ahead to spend time and resources (and thus, cash) on it.
- Modifying old (ancient) database structures (think 16 character fields for IP addresses);
Either see above, or much more likely you'd be adding a field, not modifying the existing one.
Yeah, maybe yes, maybe no. That will be part of a feasibility/cost study.
- Upgrading/replacing load balancers and other legacy crap that only support IPv4 (yeah, they still exist);
If we're talking about an enterprise that is seriously still using stuff this old, it's more likely than not that IPv6 is the least of their worries. And I'm not being flippant or disrespectful here. For at least the last 10 years or so, and definitely in the last 5, all of the enterprise level network gear sold has had support for IPv6.
Let me give you one example: old APC remotely accessible powerstrips. Plenty in use today. IPv4 only.
Execs have bonus targets. IPv6 is not yet important enough to become part of that bonus target: there is no ROI at this point.
That depends heavily on what enterprise you're talking about.
The point I'm trying to make is that there IS an ROI here.
You are preaching to the choir here. I have made those points many times. However, the ROI is in the distant future, and won't be easily measurable. So execs just don't prioritize; they are motivated by their own targets for the year so they get their bonuses. And let's be honest: can you blame them? Again, I'm not saying there is no need to implement it, I'm saying that the reality is that large businesses have not prioritized it enough because it is difficult to measure the need and ROI. And that's a problem I have, unfortunately, witnessed firsthand over the course of my career at different employers. Thanks, Sabri
On Fri, Nov 22, 2019 at 05:05:20AM +0000, Mike Lewinski wrote:
Question: is anyone who is currently suffering this issue also doing 1:many NAT? Or running a proxy server that might cause multiple clients to all appear from the same IP address? I believe NAT might be the cause of one of our customer's complaints wrt content provider blocking.
I'm the OP. We do not do CGNAT or any sort of proxying. It is straight up one public IP per access customer, with their NAT'd DSL router taking the public IP. Nor do we offer any sort of VPN services. Just because of our past history, all access customers are static IPs, so many of them have had the same IP for over a decade (ie. highly unlikely that I have a bad apple hopping a dynamic pool and ruining it for all). Furthermore, we have 3 disjoint ARIN PIR blocks. All three of them are blocked across the whole range. So, somebody at Hulu took a look at our AS, and blocked all we announce.
On 21/Nov/19 12:32, tim@pelican.org wrote:
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so.
They would if it was possible to track you. Whenever I played DVD's or BD's with my PS3/PS4, I sometimes hit issue because those boxes were online, vs. my regular DVD player which wasn't. Offline DVD tech. is old school. Because tracking can be done with 2019 tech. due to VoD and its use of the Internet, they will scream. Mark.
This happened to us as well. We've had probably over 100 requests over the last few years, but thankfully most of our customers are fine with just not purchasing Hulu. We've only lost below 5 customers from this issue. EF Treasure State Internet & Telegraph 406.204.4777 http://tsi.io On Wed, Nov 27, 2019 at 3:32 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 21/Nov/19 12:32, tim@pelican.org wrote:
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so.
They would if it was possible to track you. Whenever I played DVD's or BD's with my PS3/PS4, I sometimes hit issue because those boxes were online, vs. my regular DVD player which wasn't.
Offline DVD tech. is old school.
Because tracking can be done with 2019 tech. due to VoD and its use of the Internet, they will scream.
Mark.
We’ve had success contacting Hulu and having them mark the tiny range of applicable IPs as not being “cloud”. From: NANOG <nanog-bounces+drew.weaver=thenap.com@nanog.org> On Behalf Of Eric Fulton Sent: Thursday, December 5, 2019 2:37 PM To: Mark Tinka <mark.tinka@seacom.mu> Cc: nanog@nanog.org Subject: Re: Hulu thinks all my IP addresses are "business class", how to reach them? This happened to us as well. We've had probably over 100 requests over the last few years, but thankfully most of our customers are fine with just not purchasing Hulu. We've only lost below 5 customers from this issue. EF Treasure State Internet & Telegraph 406.204.4777 http://tsi.io On Wed, Nov 27, 2019 at 3:32 AM Mark Tinka <mark.tinka@seacom.mu<mailto:mark.tinka@seacom.mu>> wrote: On 21/Nov/19 12:32, tim@pelican.org<mailto:tim@pelican.org> wrote:
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so.
They would if it was possible to track you. Whenever I played DVD's or BD's with my PS3/PS4, I sometimes hit issue because those boxes were online, vs. my regular DVD player which wasn't. Offline DVD tech. is old school. Because tracking can be done with 2019 tech. due to VoD and its use of the Internet, they will scream. Mark.
Can you share the contact information for the next person that runs into this problem? Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 On Thu, Dec 12, 2019 at 2:01 PM Drew Weaver <drew.weaver@thenap.com> wrote:
We’ve had success contacting Hulu and having them mark the tiny range of applicable IPs as not being “cloud”.
*From:* NANOG <nanog-bounces+drew.weaver=thenap.com@nanog.org> *On Behalf Of *Eric Fulton *Sent:* Thursday, December 5, 2019 2:37 PM *To:* Mark Tinka <mark.tinka@seacom.mu> *Cc:* nanog@nanog.org *Subject:* Re: Hulu thinks all my IP addresses are "business class", how to reach them?
This happened to us as well. We've had probably over 100 requests over the last few years, but thankfully most of our customers are fine with just not purchasing Hulu. We've only lost below 5 customers from this issue.
EF
Treasure State Internet & Telegraph
406.204.4777
On Wed, Nov 27, 2019 at 3:32 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 21/Nov/19 12:32, tim@pelican.org wrote:
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so.
They would if it was possible to track you. Whenever I played DVD's or BD's with my PS3/PS4, I sometimes hit issue because those boxes were online, vs. my regular DVD player which wasn't.
Offline DVD tech. is old school.
Because tracking can be done with 2019 tech. due to VoD and its use of the Internet, they will scream.
Mark.
Would love to have the hulu contact as well. Thanks, Drew and Josh. On Fri, Dec 13, 2019 at 4:05 AM Josh Luthman <josh@imaginenetworksllc.com> wrote:
Can you share the contact information for the next person that runs into this problem?
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373
On Thu, Dec 12, 2019 at 2:01 PM Drew Weaver <drew.weaver@thenap.com> wrote:
We’ve had success contacting Hulu and having them mark the tiny range of applicable IPs as not being “cloud”.
*From:* NANOG <nanog-bounces+drew.weaver=thenap.com@nanog.org> *On Behalf Of *Eric Fulton *Sent:* Thursday, December 5, 2019 2:37 PM *To:* Mark Tinka <mark.tinka@seacom.mu> *Cc:* nanog@nanog.org *Subject:* Re: Hulu thinks all my IP addresses are "business class", how to reach them?
This happened to us as well. We've had probably over 100 requests over the last few years, but thankfully most of our customers are fine with just not purchasing Hulu. We've only lost below 5 customers from this issue.
EF
Treasure State Internet & Telegraph
406.204.4777
On Wed, Nov 27, 2019 at 3:32 AM Mark Tinka <mark.tinka@seacom.mu> wrote:
On 21/Nov/19 12:32, tim@pelican.org wrote:
If I, as a UK citizen, buy region 2 DVDs at home, take them on my trip to the US and watch them on my laptop, no-one is screaming that I'm violating someone's geographic distribution rights by doing so.
They would if it was possible to track you. Whenever I played DVD's or BD's with my PS3/PS4, I sometimes hit issue because those boxes were online, vs. my regular DVD player which wasn't.
Offline DVD tech. is old school.
Because tracking can be done with 2019 tech. due to VoD and its use of the Internet, they will scream.
Mark.
Doug McIntyre wrote on 11/19/2019 12:17 PM:
On Mon, Nov 18, 2019 at 10:55:01AM -0600, Blake Hudson wrote:
Doug, out of curiosity, what does Hulu do once they have classified your IP ranges as "business class"? Charge customers a different rate? Offer different content? Refuse service? They won't let any of my customers connect, blocking them with a specific error number to reference by their support. When they do, Hulu is either telling them that they are using a VPN (when we don't offer any services like that), and then to whitelist them, they have to have a "residential" IP address and not the "business" IP address we are giving them, and won't go any further. Or they just say they can't connect from the "business" IP addresses.
If I knew why they considered my IP addresses "business" IP addresses, I could possibly change something? But this seems to be an arbitrary decision they changed about a week and a half ago for all my netblocks.
Thanks Doug. I'm interested in following your thread because we have some IP ranges we intentionally wanted to be classified as static or non-residential by other entities so that our customers on these ranges could operate their own email servers. This was done through a combination of reverse DNS including the word "static" (or similar) and the SpamHaus PBL listings (or similar). At the same time, we would not want Hulu to stop providing services to these customers due to this classification. Ultimately, I guess it's up to Hulu who they want to serve as a customer of theirs, but as a network operator providing access to to the internet (including access to services like Hulu) I'm sure we would be negatively impacted by such a decision on the part of Hulu causing to devalue the utility our services.
On 19/Nov/19 20:38, Blake Hudson wrote:
Thanks Doug. I'm interested in following your thread because we have some IP ranges we intentionally wanted to be classified as static or non-residential by other entities so that our customers on these ranges could operate their own email servers. This was done through a combination of reverse DNS including the word "static" (or similar) and the SpamHaus PBL listings (or similar). At the same time, we would not want Hulu to stop providing services to these customers due to this classification. Ultimately, I guess it's up to Hulu who they want to serve as a customer of theirs, but as a network operator providing access to to the internet (including access to services like Hulu) I'm sure we would be negatively impacted by such a decision on the part of Hulu causing to devalue the utility our services.
Dropped Hulu within 2 months of signing up, back in 2016. If it ain't local, we ain't buyin', and Hulu seem to have little interest in spreading. Mark.
On 19/Nov/19 20:17, Doug McIntyre wrote:
If I knew why they considered my IP addresses "business" IP addresses, I could possibly change something?
Perhaps because it's static :-)? Also, why are business people on Hulu during business hours :-). Mark <= who asks while taking a work Zoom call in nothing + slippers with a glass of wine in front of Netflix at home :-)...
Hulu is the worst-run streaming service, mostly because they don't cooperate with ISPs in the least. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Doug McIntyre" <merlyn@geeks.org> To: nanog@nanog.org Sent: Monday, November 18, 2019 10:41:06 AM Subject: Hulu thinks all my IP addresses are "business class", how to reach them? I've been offering residential and business ISP services for a long time. Hulu recently blocked my customers from accessing their service, because my ARIN IP address blocks are "business class" instead of residential. I've tried to find a contact for them as I am not a customer, the supportrequest@hulu.com address mentioned in NANOG previously is just an autoresponder that says open a ticket online (once you are logged into your account). Does anybody have a contact for them that I can discuss what they are looking at to determine if my IP addresses are "residential" vs. "business" class? Thanks.
participants (41)
-
Aaron C. de Bruyn -
Andy Ringsmuth -
Baldur Norddahl -
Billy Crook -
Blake Hudson -
Brandon Butterworth -
Brandon Martin -
Brian Ellwood -
Brian Knight -
bzs＠theworld.com -
Ca By -
Crist Clark -
Dmitry Sherman -
Donald Eastlake -
Doug Barton -
Doug McIntyre -
Drew Weaver -
Eric Fulton -
Ethan O'Toole -
Filip Hruska -
Jared Mauch -
Josh Luthman -
Justin Streiner -
Mark Andrews -
Mark Milhollan -
Mark Tinka -
Matt Hoppes -
Matt Palmer -
Matthew Kaufman -
Michel Py -
Mike Hammett -
Mike Lewinski -
Owen DeLong -
Sabri Berisha -
Simon Leinen -
Tei -
tim＠pelican.org -
Tom Beecher -
Valdis Klētnieks -
William Guo -
William Herrin