Hi, Does anyone have any recommendation for a viable IPv6 tunnel broker / provider in the U.S.A. /other/ /than/ Hurricane Electric? I reluctantly just disabled IPv6 on my home network, provided by Hurricane Electric, because multiple services my wife uses are objecting to H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO Max, Pandora, and other services that I can't remember at the moment have all objected to H.E. Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS, null routing prefixes, firewalling, etc., seems even more wrong. Is there a contemporary option for home users like myself who's ISP doesn't offer native IPv6? Please consider this to be a Request for Comments and suggestions. Thank you and have a nice day / weekend / holiday. -- Grant. . . . unix || die
On 20210904, at 22:26, Grant Taylor via NANOG <nanog@nanog.org> wrote:
Hi,
Does anyone have any recommendation for a viable IPv6 tunnel broker / provider in the U.S.A. /other/ /than/ Hurricane Electric?
SixXS shut down 4 years ago, to get ISPs to move their butts... as long as there are tunnels, they do not have a business case. See also https://www.sixxs.net/sunset/ and the "Call Your ISP for IPv6" thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 along with plans. You people keep on giving money to ISPs that are not providing the service you want.
I reluctantly just disabled IPv6 on my home network, provided by Hurricane Electric, because multiple services my wife uses are objecting to H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO Max, Pandora, and other services that I can't remember at the moment have all objected to H.E
Tunnels are VPNs So, that makes sense that services that need to 'protect their IP' (silly property) because they did not figure out people might live anywhere in the world might want to pay for things and receive service... [sic] IPv6 tunnels where meant as a transition mechanism, as a way for engineers to test IPv6 before it was wide spread. Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have slave monopoly money and can just buy 2% of the address space), you could have spent the last 25 years getting ready for this day. And especially in the last 5 - 10 years, deploying IPv6 has been easy, due to all the work by many many many people around the world in testing and actively deploying IPv6. Of course there are still platforms that don't support DHCPv6 for instance, but things are easy, stable and often properly battle tested.
Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS, null routing prefixes, firewalling, etc., seems even more wrong.
Is there a contemporary option for home users like myself who's ISP doesn't offer native IPv6?
As this is NANOG.... and people on the list are ISPs and it is 2021, thus IPv6 being 25+ years old, the best that is left to do is: https://www.youtube.com/watch?v=ASXJgvy3mEg Go Jared! Greets, Jeroen
Jeroen,
You people keep on giving money to ISPs that are not providing the service you want.
Not everyone has the luxury of picking their ISP, and the common consumer doesn't know or care about IPv6. They want Netflix to work and that's it. Ryan On Sat, Sep 4, 2021, 1:47 PM Jeroen Massar via NANOG <nanog@nanog.org> wrote:
On 20210904, at 22:26, Grant Taylor via NANOG <nanog@nanog.org> wrote:
Hi,
Does anyone have any recommendation for a viable IPv6 tunnel broker / provider in the U.S.A. /other/ /than/ Hurricane Electric?
SixXS shut down 4 years ago, to get ISPs to move their butts... as long as there are tunnels, they do not have a business case.
See also https://www.sixxs.net/sunset/ and the "Call Your ISP for IPv6" thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 along with plans.
You people keep on giving money to ISPs that are not providing the service you want.
I reluctantly just disabled IPv6 on my home network, provided by Hurricane Electric, because multiple services my wife uses are objecting to H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO Max, Pandora, and other services that I can't remember at the moment have all objected to H.E
Tunnels are VPNs
So, that makes sense that services that need to 'protect their IP' (silly property) because they did not figure out people might live anywhere in the world might want to pay for things and receive service... [sic]
IPv6 tunnels where meant as a transition mechanism, as a way for engineers to test IPv6 before it was wide spread.
Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have slave monopoly money and can just buy 2% of the address space), you could have spent the last 25 years getting ready for this day. And especially in the last 5 - 10 years, deploying IPv6 has been easy, due to all the work by many many many people around the world in testing and actively deploying IPv6. Of course there are still platforms that don't support DHCPv6 for instance, but things are easy, stable and often properly battle tested.
Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS,
null routing prefixes, firewalling, etc., seems even more wrong.
Is there a contemporary option for home users like myself who's ISP
doesn't offer native IPv6?
As this is NANOG.... and people on the list are ISPs and it is 2021, thus IPv6 being 25+ years old, the best that is left to do is:
https://www.youtube.com/watch?v=ASXJgvy3mEg
Go Jared!
Greets, Jeroen
On 2021-09-04 23:02, Ryan Hamel wrote:
Jeroen,
You people keep on giving money to ISPs that are not providing the service you want.
Not everyone has the luxury of picking their ISP,
But this list is NANOG.... Network Operators. We are the ISPs....
and the common consumer doesn't know or care about IPv6.
And they indeed should not have to care. Good that this is not a consumer list, or a ISP complaint line (though, I guess complaining about peering or broken connectivity is in the charter)
They want Netflix to work and that's it.
They thus have no need for IPv6, which was the question... Netflix works mostly fine over IPv4 (or heck CGN as that is what one is likely headed to if your ISP did not get chunks of free IPv4 address space), it is actually still IPv6 where they sometimes have a few PMTU blackholes... ;) [though, have not noticed one in a while now] Greets, Jeroen
* ryan@rkhtech.org (Ryan Hamel) [Sat 04 Sep 2021, 23:04 CEST]:
Not everyone has the luxury of picking their ISP, and the common consumer doesn't know or care about IPv6. They want Netflix to work and that's it.
We just had a 100+ post thread about Netflix not working because CGNs were misclassified as VPN endpoints. -- Niels.
According to Jeroen Massar via NANOG <jeroen@massar.ch>:
On 2021-09-04 23:02, Ryan Hamel wrote:
Jeroen,
You people keep on giving money to ISPs that are not providing the service you want.
Not everyone has the luxury of picking their ISP,
But this list is NANOG.... Network Operators. We are the ISPs....
Well, some of us are. I have a choice of an excellent local fiber ISP that does not offer IPv6 or Spectrum cable which is generally awful but does have v6. So I use a tunnel. I have asked my ISP about IPv6 and their answer is that that they're not opposed to it but since I am the only person who has asked for it, it's quite low on the list of things to do. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On Sat, Sep 4, 2021, 22:49 John Levine <johnl@iecc.com> wrote:
I have asked my ISP about IPv6 and their answer is that that they're not opposed to it but since I am the only person who has asked for it, it's quite low on the list of things to do.
Sounds like a consulting opportunity :) Thank you jms
On 9/5/21 04:49, John Levine wrote:
Well, some of us are. I have a choice of an excellent local fiber ISP that does not offer IPv6 or Spectrum cable which is generally awful but does have v6. So I use a tunnel.
I have asked my ISP about IPv6 and their answer is that that they're not opposed to it but since I am the only person who has asked for it, it's quite low on the list of things to do.
Supporting the routing and forwarding of IP addresses is just about the most basic thing any ISP should do. If that is low on their to-do list, what else could they possibly be doing? Mark.
On Sat, Sep 4, 2021 at 9:36 PM Mark Tinka <mark@tinka.africa> wrote:
Supporting the routing and forwarding of IP addresses is just about the most basic thing any ISP should do.
If that is low on their to-do list, what else could they possibly be doing?
Counting all the profit they make from a captive audience with no competition? ;) -A
On 2021-09-04 23:33, Mark Tinka wrote:
On 9/5/21 04:49, John Levine wrote:
I have asked my ISP about IPv6 and their answer is that that they're not opposed to it but since I am the only person who has asked for it, it's quite low on the list of things to do.
Supporting the routing and forwarding of IP addresses is just about the most basic thing any ISP should do.
If that is low on their to-do list, what else could they possibly be doing?
$DAYJOB (at a business SP) is much busier installing more VPNs in the form of SDWAN than anything IPv6 related. There is a hell of a lot more customer demand for tools that route packets with finer control than just dest-based routing, not to mention the security add-ons. The fact that folks can achieve multi-homed Internet connectivity without the financial burden of a /24 helps SDWAN's case. Turns out Mom and Pop, and even John Q. down the street, wants fast failover in case of circuit trouble just like the big boys. That said, I do hear prospects and customers asking for IPv6 more often now than a year ago. But it's nowhere near the popularity of SDWAN: It's gone from maybe 2-4 requests per year in 2019 to 2-4 requests per quarter today. Sorry, the market *still* doesn't care much about IPv6. Believe me, I hope people will continue getting interested, but I'm done holding my breath. Maybe we should collectively focus instead on raising the default MTU for the Internet to 2000 bytes to accommodate all these tunnels. ;)
Mark.
-Brian
On 9/5/21 17:43, Brian Knight wrote:
$DAYJOB (at a business SP) is much busier installing more VPNs in the form of SDWAN than anything IPv6 related. There is a hell of a lot more customer demand for tools that route packets with finer control than just dest-based routing, not to mention the security add-ons.
My question wasn't serious, if you've been around long enough :-).
Sorry, the market *still* doesn't care much about IPv6.
I doubt it's me (or those who have deployed IPv6) that will be sorry, in the long run. Mark.
On 9/4/21 2:44 PM, Jeroen Massar via NANOG wrote:
SixXS shut down 4 years ago, to get ISPs to move their butts... as long as there are tunnels, they do not have a business case.
I saw that.
See also https://www.sixxs.net/sunset/ and the "Call Your ISP for IPv6" thing in 2016: https://www.sixxs.net/wiki/Call_Your_ISP_for_IPv6 along with plans.
I have contacted my ISP and inquired about IPv6 one or more times every year that I've been using them.
You people keep on giving money to ISPs that are not providing the service you want.
Are you talking generally or are you using me as an example (read: scapegoat)? -- It's okay if you are. I'd like to delve further into this idea. I have three ISPs in my town of just shy of 100k people within an hour drive of the largest city in the state of more than 700k people. - Municipal fiber - 1 Gbps - IPv4 only - $50 / month - Local cable co. - ~100 Mbps - IPv4 and IPv6 - for $100 / month - ILEC xDSL - ~50 Mbps - why would I look - for $100 month There may be cellular Internet options, but those aren't ... economical, especially for streaming. Of those three which would you choose? So ... I think I'm in quite the same position as John L. is.
Tunnels are VPNs
I concede the technical point and move on.
So, that makes sense that services that need to 'protect their IP' (silly property) because they did not figure out people might live anywhere in the world might want to pay for things and receive service... [sic]
I agree there is some questionable ... /thought/ going on somewhere. -- I'm reluctant to call it /logic/. I agree that some people are trying to circumvent geographical restrictions. However, my wife and I are not. We want to access content that's for the address we have on file with the companies, that we have service at, and that we receive the paper bills at. -- As I've stated before in other threads, I believe that companies are capable of adding 1 + 1 + 1 to get 3. If they /wanted/ to. As such, I can only surmise that they do not /want/ to correlate the multiple addresses and allow us to view content for the same market.
IPv6 tunnels where meant as a transition mechanism, as a way for engineers to test IPv6 before it was wide spread.
And seeing as how I can't get IPv6 natively from multiple providers that I've worked with in the last 20 years, I can only surmise that we as an industry are still transitioning from single stack to dual stack.
Deploying IPv6 is easy, and due to IPv4-squeeze (unless you have slave monopoly money and can just buy 2% of the address space), you could have spent the last 25 years getting ready for this day. And especially in the last 5 - 10 years, deploying IPv6 has been easy, due to all the work by many many many people around the world in testing and actively deploying IPv6. Of course there are still platforms that don't support DHCPv6 for instance, but things are easy, stable and often properly battle tested.
And yet here we are. As a consumer I have no effective influence.
As this is NANOG.... and people on the list are ISPs and it is 2021, thus IPv6 being 25+ years old, the best that is left to do is:
And that's arguably what my city did. They got together and installed municipal fiber. Save for the lack of IPv6, it wins on all counts; faster, cheaper, better customer service, and other non-technical perks. Just no IPv6. Hence why I have historically augmented my municipal GPON with an H.E. IPv6 tunnel. -- In fact, I am going to continue with said H.E. IPv6 tunnel, just without advertising it to the network (RA / DHCPv6). I will have to statically configure IPv6 on things that I want to use it on. The rest of the home network will be IPv4 only. I feel like 1995 called and want's their single stack Internet back. <ASCII tear> So, Jeroen, what would you recommend that people like John L. and myself do? -- Grant. . . . unix || die
On Sun, 5 Sept 2021 at 08:25, Grant Taylor via NANOG <nanog@nanog.org> wrote:
- Municipal fiber - 1 Gbps - IPv4 only - $50 / month - Local cable co. - ~100 Mbps - IPv4 and IPv6 - for $100 / month - ILEC xDSL - ~50 Mbps - why would I look - for $100 month
There may be cellular Internet options, but those aren't ... economical, especially for streaming.
Of those three which would you choose?
Municipal fiber. Which is the point, you cannot capitalise offering IPv6, so offering it is bad for business. People who have adopted IPv6 have eaten into their margins for no utility. I view IPv6 as the biggest mistake of my career and feel responsible for this horrible outcome and I do apologise to Internet users for it. This dual-stack is the worst possible outcome, and we've been here over two decades, increasing cost and reducing service quality. We should have performed better, we should have been IPv6 only years ago. I wish 20 years ago big SPs would have signed a contract to drop IPv4 at the edge 20 years from now, so that we'd given everyone a 20 year deadline to migrate away. 20 years ago was the best time to do it, the 2nd best time is today. If we don't do it, 20 years from now, we are in the same position, inflating costs and reducing quality and transferring those costs to our end users who have to suffer from our incompetence. -- ++ytti
On 9/4/21 11:43 PM, Saku Ytti wrote:
Municipal fiber.
;-)
Which is the point, you cannot capitalise offering IPv6, so offering it is bad for business. People who have adopted IPv6 have eaten into their margins for no utility.
I don't understand. :-/
I view IPv6 as the biggest mistake of my career and feel responsible for this horrible outcome and I do apologise to Internet users for it.
*blink* ... *blink* First, thank you. I say that sincerely from and end user point of view feeling like I'm between a rock and a hard place, one of which is closing in. Second, I can't say that similar thoughts haven't crossed my mind.
This dual-stack is the worst possible outcome, and we've been here over two decades, increasing cost and reducing service quality. We should have performed better, we should have been IPv6 only years ago.
I remember LAN networking back in the '90s where multiple / mixed protocols was a Bad Thing™. I view IPv4 and IPv6 as tantamount to the same (or at least very similar) thing. What's worse is that IPv4 and IPv6 have extremely similar sounding names. Though I think in some ways that IPv4 and IPv6 are effectively as technically different from each other as IP(v4) and IPX. Though at least they had the decency to have more different names.
I wish 20 years ago big SPs would have signed a contract to drop IPv4 at the edge 20 years from now, so that we'd given everyone a 20 year deadline to migrate away.
Hindsight is 20/20 for a while. Then ... bit rot.
20 years ago was the best time to do it, the 2nd best time is today. If we don't do it, 20 years from now, we are in the same position, inflating costs and reducing quality and transferring those costs to our end users who have to suffer from our incompetence.
Sadly, I think that we are back to the multi-protocol days of old. And I believe that we are going to be stuck here for much of my career. :-( -- Grant. . . . unix || die
Saku Ytti <saku@ytti.fi> writes:
I view IPv6 as the biggest mistake of my career and feel responsible for this horrible outcome and I do apologise to Internet users for it. This dual-stack is the worst possible outcome, and we've been here over two decades, increasing cost and reducing service quality. We should have performed better, we should have been IPv6 only years ago.
I believe this is slowly sinking in among the technology evangelists and geeks who managed to drive the half-assed dual-stack transition a decade or two ago. No one will argue for dual-stack anymore. So where does that put us in a decade or two? Which protocol is optional? Bjørn
On 9/5/21 18:22, Bjørn Mork wrote:
I believe this is slowly sinking in among the technology evangelists and geeks who managed to drive the half-assed dual-stack transition a decade or two ago. No one will argue for dual-stack anymore.
So where does that put us in a decade or two? Which protocol is optional?
You will join the IPv6 train whenever you do. I don't waste anymore time asking people to deploy it. I'm better off spending my time drinking wine. Mark.
On Sun, 5 Sept 2021 at 19:22, Bjørn Mork <bjorn@mork.no> wrote:
So where does that put us in a decade or two? Which protocol is optional?
If we don't get regulatory enforcement or voluntary commitments to sunset IPv4, we are doomed for dual-stack for the foreseeable future (decades). I absolutely HATE testing, developing and supporting IPv4+IPv6, more than doubling my time, adding 3rd stack would actually not increase cost that much, it's the 1=>2 which is fantastically expensive. And costs are transferred to customers. Those who have not done _anything_ with IPv6, have done the right thing from business POV, they've had lowest cost, least issues and have had other people pay for the improvements of the stack. And even today, I see no business sense deploying IPv6. Now if we'd know, all of our CDN, cloudyshops and tier1 will start dropping IPV4 at edge in 2040, this would create good business reason to start developing to IPv6, you'd know you need to have it, and you'd know you have finite window when you need to support both. And this is something we should commit to do, and everyone would benefit from the comment. -- ++ytti
Hello,
I absolutely HATE testing, developing and supporting IPv4+IPv6, more than doubling my time, adding 3rd stack would actually not increase cost that much, it's the 1=>2 which is fantastically expensive. And costs are transferred to customers.
Dual stack is doubling dev time ? Ok... this is quite strange... Maybe on testing... but using some standards protocols....? (...)
Now if we'd know, all of our CDN, cloudyshops and tier1 will start dropping IPV4 at edge in 2040, this would create good business reason to start developing to IPv6, you'd know you need to have it, and you'd know you have finite window when you need to support both. And this is something we should commit to do, and everyone would benefit from the comment.
Really, the ONLY thing that make IPv6 hell is the bloody war between Cogent and HE. Imagine this kind of war with IPv4... Really guys stop this stupid stuff and make IPv6 Great Again... Regards, Xavier
On Mon, Sep 06, 2021 at 08:38:44AM +0200, Xavier Beaudouin via NANOG wrote:
Hello,
I absolutely HATE testing, developing and supporting IPv4+IPv6, more than doubling my time, adding 3rd stack would actually not increase cost that much, it's the 1=>2 which is fantastically expensive. And costs are transferred to customers.
Dual stack is doubling dev time ? Ok... this is quite strange...
Nope, entirely normal and expected. Coding for one case is very straightforward: Do thing Do other thing Do this as well Coding for two cases involves identifying each step which needs to be done differently for the two cases and coding up the things to be done differently: if case1: Do thing this way elif case2: Do same thing this other way Do other thing the same way regardless if case1: Do this as well elif case2: Don't do anything Adding a third case is *usually* not as hard, as you've identified at least most of the places that need to be done differently for different cases, and if you're lucky then some of the doings can be the same both ways: if case1: Do thing this way elif case2: Do same thing this other way elif case3: Do same thing in *yet another* way Do other thing the same way for everyone if case1 or case3: Do this as well elif case2: Don't do anything It's not just program control flow either; there's also data structures and data storage to think of. That can end up being even *more* complicated than the control flow, especially if you're interoperating with other systems that need to consume the same data. For example, in the IPAM software world, imagine you named a field "ip_address", that contains an IPv4 address, and now you want to add IPv6. But that database is also used by some other software (that you might not even control), so you can't just rename it to "ipv4_address" and change all the references in your code. Do you add "ipv6_address" and hope that everyone figures out that "ip_address" *means* "ipv4_address"? What about in the future, when you have the first device that is IPv6-only... what goes into that "ip_address" field? - Matt
this amazing thread is so new, fresh, and enlightening. why has no one brought these facts and ideas up before? just wow! randy
On Sep 6, 2021, at 3:55 PM, Matt Palmer <mpalmer@hezmatt.org> wrote:
On Mon, Sep 06, 2021 at 08:38:44AM +0200, Xavier Beaudouin via NANOG wrote:
Hello,
I absolutely HATE testing, developing and supporting IPv4+IPv6, more than doubling my time, adding 3rd stack would actually not increase cost that much, it's the 1=>2 which is fantastically expensive. And costs are transferred to customers.
Dual stack is doubling dev time ? Ok... this is quite strange...
Nope, entirely normal and expected. Coding for one case is very straightforward:
Do thing Do other thing Do this as well
Coding for two cases involves identifying each step which needs to be done differently for the two cases and coding up the things to be done differently:
if case1: Do thing this way elif case2: Do same thing this other way Do other thing the same way regardless if case1: Do this as well elif case2: Don't do anything
Sure, but most of this can be obviated with IPV6_V6ONLY=false. From that point on, your software doesn’t need to know or care whether the connection is IPv4 or IPv6, everything looks like IPv6. Owen
Saku Ytti <saku@ytti.fi> writes:
I absolutely HATE testing, developing and supporting IPv4+IPv6, more than doubling my time, adding 3rd stack would actually not increase cost that much, it's the 1=>2 which is fantastically expensive. And costs are transferred to customers.
+1
Those who have not done _anything_ with IPv6, have done the right thing from business POV, they've had lowest cost, least issues and have had other people pay for the improvements of the stack. And even today, I see no business sense deploying IPv6.
The state is not static. The difference is there for any (partially) new deployment. Adding new access infrastructure of any sort (Fixed Wireless is the hype...)? Why would you want to continue being stupid even if you implemented dual-stack for all your fibre, hfc and dsl customers? You can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs, even if we assume most of the fibre/hfc/dsl value chain is reused. Bjørn
On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:
Adding new access infrastructure of any sort (Fixed Wireless is the hype...)? Why would you want to continue being stupid even if you implemented dual-stack for all your fibre, hfc and dsl customers? You can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs, even if we assume most of the fibre/hfc/dsl value chain is reused.
Can you? You need to offer IPv4 anyhow and all the complexities related to that, i.e. some stateful box. Why would I offer in addition to that IPv6, which is not being requested by anyone. And by anyone I mean anyone I want as customer, as those who request it, are probably going to be expensive to support and I need to subsidise those with my regular customers, so I'd rather not cater to those. -- ++ytti
Saku Ytti <saku@ytti.fi> writes:
On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:
Adding new access infrastructure of any sort (Fixed Wireless is the hype...)? Why would you want to continue being stupid even if you implemented dual-stack for all your fibre, hfc and dsl customers? You can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs, even if we assume most of the fibre/hfc/dsl value chain is reused.
Can you? You need to offer IPv4 anyhow and all the complexities related to that, i.e. some stateful box. Why would I offer in addition to that IPv6, which is not being requested by anyone. And by anyone I mean anyone I want as customer, as those who request it, are probably going to be expensive to support and I need to subsidise those with my regular customers, so I'd rather not cater to those.
Exactly. The existing dual-stack deployments will die out as access infra-structure is replaced. Bjørn
All this is resolved using IPv6-only and IPv4aaS, the same way as cellular providers are doing with 464XLAT. This means you don't need to invest in more IPv4 addressses (at some point you can even transfer some of them to the laggers), you still provide IPv4 service to the edge, but the access is IPv4-ignorant. Reduced Capex and Opex in general. El 6/9/21 9:29, "NANOG en nombre de Saku Ytti" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de saku@ytti.fi> escribió: On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote: > Adding new access infrastructure of any sort (Fixed Wireless is the > hype...)? Why would you want to continue being stupid even if you > implemented dual-stack for all your fibre, hfc and dsl customers? You > can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs, > even if we assume most of the fibre/hfc/dsl value chain is reused. Can you? You need to offer IPv4 anyhow and all the complexities related to that, i.e. some stateful box. Why would I offer in addition to that IPv6, which is not being requested by anyone. And by anyone I mean anyone I want as customer, as those who request it, are probably going to be expensive to support and I need to subsidise those with my regular customers, so I'd rather not cater to those. -- ++ytti ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
It is simple, most of your traffic will use IPv6. Depending on your network/customer base 65-85%. You need less and less IPv4 addresses in the NAT64, less NAT64 boxes. Less resources to operate IPv6-only vs dual-stack. And because the IPv6 traffic is going up more and more with the time, you can keep reducing IPv4 addresses and NAT64 boxes. If you are using boxes that can be used for other functionalities, you even "recover" part of you initial investment. El 6/9/21 10:06, "Saku Ytti" <saku@ytti.fi> escribió: On Mon, 6 Sept 2021 at 10:48, JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> wrote: > Reduced Capex and Opex in general. Can you show the work? -- ++ytti ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:
It is simple, most of your traffic will use IPv6. Depending on your network/customer base 65-85%.
You need less and less IPv4 addresses in the NAT64, less NAT64 boxes.
Less resources to operate IPv6-only vs dual-stack.
And because the IPv6 traffic is going up more and more with the time, you can keep reducing IPv4 addresses and NAT64 boxes. If you are using boxes that can be used for other functionalities, you even "recover" part of you initial investment.
You're assuming that IPv6 is required. There is no reason do do that in the current Internet. IPv6 is still optional. The number of users who care about IPv6 access is very close to 0 and dropping. And as demonstrated in this thread: Even the few who still do care are not willing to pay extra, or sacrifice anything, for IPv6. They will run off to your competitor as soon as they discover the price is lower there. Which it will be since they saved a lot by building and running an IPv4 only access network. Bjørn
* bjorn@mork.no (Bjørn Mork) [Mon 06 Sep 2021, 15:08 CEST]:
And as demonstrated in this thread: Even the few who still do care are not willing to pay extra, or sacrifice anything, for IPv6. They will run off to your competitor as soon as they discover the price is lower there. Which it will be since they saved a lot by building and running an IPv4 only access network.
Is that why cable operators are shifting to native IPv6 + CGNAT for IPv4 instead of following your advice to build only native IPv4? -- Niels.
Users don't care about IP at all. They just want to make sure that their apps keep working. If you switch them to IPv6, and they have faster access for IPv6 enables sites and apps (40% faster time to complete HTTP get), and they don't notice that the WAN is IPv6-only, because inside the LANs they still have dual-stack, problem solved. El 6/9/21 15:08, "NANOG en nombre de Bjørn Mork" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de bjorn@mork.no> escribió: JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes: > It is simple, most of your traffic will use IPv6. Depending on your > network/customer base 65-85%. > > You need less and less IPv4 addresses in the NAT64, less NAT64 boxes. > > Less resources to operate IPv6-only vs dual-stack. > > And because the IPv6 traffic is going up more and more with the time, > you can keep reducing IPv4 addresses and NAT64 boxes. If you are using > boxes that can be used for other functionalities, you even "recover" > part of you initial investment. You're assuming that IPv6 is required. There is no reason do do that in the current Internet. IPv6 is still optional. The number of users who care about IPv6 access is very close to 0 and dropping. And as demonstrated in this thread: Even the few who still do care are not willing to pay extra, or sacrifice anything, for IPv6. They will run off to your competitor as soon as they discover the price is lower there. Which it will be since they saved a lot by building and running an IPv4 only access network. Bjørn ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes:
All this is resolved using IPv6-only and IPv4aaS, the same way as cellular providers are doing with 464XLAT.
Sure, there are a gazillion ways to provde edge access to both IPv4 and IPv6. You can pick anyone you like. But the extra layers still do not come for free. And cellular providers give you a single /64. Not even useful as IPv6 access for anything larger than a single handset. Extending that /64 to something you can use is non-trivial. How many providers have actually done that? And how many end users cared? Bjørn
You're confusing things. The fact that cellular providers, actually cellular equipment vendors, do not implement DHCPv6-PD, doesn't mean that you can't use DHCPv6-PD for assigning IPv6 prefixes using 464XLAT in broadband. See RFC8585 and RFC8683. El 6/9/21 14:56, "NANOG en nombre de Bjørn Mork" <nanog-bounces+jordi.palet=consulintel.es@nanog.org en nombre de bjorn@mork.no> escribió: JORDI PALET MARTINEZ via NANOG <nanog@nanog.org> writes: > All this is resolved using IPv6-only and IPv4aaS, the same way as > cellular providers are doing with 464XLAT. Sure, there are a gazillion ways to provde edge access to both IPv4 and IPv6. You can pick anyone you like. But the extra layers still do not come for free. And cellular providers give you a single /64. Not even useful as IPv6 access for anything larger than a single handset. Extending that /64 to something you can use is non-trivial. How many providers have actually done that? And how many end users cared? Bjørn ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On Mon, Sep 6, 2021 at 2:55 PM Bjørn Mork <bjorn@mork.no> wrote:
And cellular providers give you a single /64. Not even useful as IPv6 access for anything larger than a single handset. Extending that /64 to something you can use is non-trivial. How many providers have actually done that?
I am sitting here on a 4G broadband connection provided by the cellular provider "3". I am using the Huawei B535-232 CPE provided to me by "3" as part of the contract. My IPv6 configuration, which I received completely automatic without having to do anything or even know about it: Router IPv6: 2a02:aa7:4620:e76b:5a02:3ff:fe04:506 My computer connected through a LAN cable to the router: 2a02:aa7:4620:e76b:1870:3bef:4272:5 My android cell phone connected via wifi: 2a02:aa7:4620:e76b:d199:f9b2:7103:3a05 As should be obvious the /64 provided extends to something larger than a single handset here in a completely trivial way. The CPE is simply bridging the /64 provided. Yes I would be more happy with a prefix delegation of some size but this works too. It is still better than the IPv4 which has to go through NAT. Regards, Baldur
On Sep 6, 2021, at 12:27 AM, Saku Ytti <saku@ytti.fi> wrote:
On Mon, 6 Sept 2021 at 10:20, Bjørn Mork <bjorn@mork.no> wrote:
Adding new access infrastructure of any sort (Fixed Wireless is the hype...)? Why would you want to continue being stupid even if you implemented dual-stack for all your fibre, hfc and dsl customers? You can save a lot by dropping dual-stack complexities in PGWs and FWA CPEs, even if we assume most of the fibre/hfc/dsl value chain is reused.
Can you? You need to offer IPv4 anyhow and all the complexities related to that, i.e. some stateful box. Why would I offer in addition to that IPv6, which is not being requested by anyone. And by anyone I mean anyone I want as customer, as those who request it, are probably going to be expensive to support and I need to subsidise those with my regular customers, so I'd rather not cater to those.
You don’t necessarily have to carry IPv4 across your network with all the complexities involved in that. You can do IPv4 at the edges with all IPv6 in the middle through a variety of techniques which are relatively trivial to implement these days. Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon. Unfortunately, nobody wants to lead because it comes with certain negative commercial implications. Perverse incentives remain a problem. The race is on: Will we get IPv6 deployed before our similar failures with regard to climate change (for amusingly similar perverse incentive reasons) render the planet uninhabitable? Owen
On Tue, 7 Sept 2021 at 19:51, Owen DeLong <owen@delong.com> wrote:
Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.
Fully agreed, I just don't see the driver. But I can imagine a different timeline where in 2000 several tier1 signed mutual binding contracts to drop IPv4 at the edge in 2020. And no one opposed, because 20 years before was 1980, and 20 years in the future IPv4 wont' anymore be a thing, it's clear due to exponential growth. And we'd all be enjoying a much simplified stack and lower costs all around (vendor, us, customers). Why is this not possible now? Why would we not sign this mutual agreement for 2040? Otherwise we'll be having this same discussion in 2040. -- ++ytti
On 9/8/21 08:50, Saku Ytti wrote:
Fully agreed, I just don't see the driver. But I can imagine a different timeline where in 2000 several tier1 signed mutual binding contracts to drop IPv4 at the edge in 2020. And no one opposed, because 20 years before was 1980, and 20 years in the future IPv4 wont' anymore be a thing, it's clear due to exponential growth.
And we'd all be enjoying a much simplified stack and lower costs all around (vendor, us, customers).
Why is this not possible now? Why would we not sign this mutual agreement for 2040? Otherwise we'll be having this same discussion in 2040.
I do not see why this is not possible now. In fact, I'd go as far as saying that the proposal should be shortened from 20 years to 10 years from today. 10 years is not unreasonable. I'm not sure if there needs to be a separate "cabal" amongst the major network operators that cover every corner of the world to agree to this, as I expect more talking here on NANOG than action around this issue. But I'd be happy to join and support such a cabal, with the backing of my own management toward making this commitment, at least from an African standpoint. I know at least 3 or 4 other operators in Africa that would be willing to commit to the same, either directly or by proxy with us. Do we drive this through the IETF, or just have private, multi-lateral agreements, as major operators? I'm now just thinking of how we get this idea off the ground, and stop talking too much. Mark.
On Wed, 8 Sept 2021 at 10:25, Mark Tinka <mark@tinka.africa> wrote:
Do we drive this through the IETF, or just have private, multi-lateral agreements, as major operators?
I have no idea, I'll ask our VP if we'd entertain such a contract and if so what type of terms. I imagine some website documenting who has undersigned. I also anticipate we'd need an escape clause, like a company could go 'our commitment will expire if these of our competitors do not commit'. So we'd have a list of companies customers can pressure to commit in order to put the contracts in-force. This may be a naive suggestion, this is not an area I have experience in. But I'll ask nonetheless. -- ++ytti
On 9/8/21 09:30, Saku Ytti wrote:
I have no idea, I'll ask our VP if we'd entertain such a contract and if so what type of terms.
That would be great! Consider our side in full support, already, as I usually have positive outcomes with my management on these sorts of things. SEACOM would be happy to sign and promote such an accord.
I imagine some website documenting who has undersigned. I also anticipate we'd need an escape clause, like a company could go 'our commitment will expire if these of our competitors do not commit'. So we'd have a list of companies customers can pressure to commit in order to put the contracts in-force.
Yes, agreed. Makes it easier if the world knows where to go to understand how much support the idea has, and if their provider (or provider's provider) is part of it or not.
This may be a naive suggestion, this is not an area I have experience in. But I'll ask nonetheless.
So both Workonline and SEACOM made a similar agreement to enable ROV and drop Invalids on 1st April, 2019, and we made this commitment to the public via multiple fora. There was a 3rd major African operator that was originally part of the accord, but they pulled out at the last minute. That did not prevent us from going ahead. So while not as critical as the basic IP protocol that governs our Internet, not to mention the small sample size, myself and Ben (Workonline) have a little experience in this area :-). And I can bet almost all the wine in my house that Ben would support an accord to drop egde-IPv4 by 2031. Mark.
I'm not sure if there needs to be a separate "cabal" amongst the major network operators that cover every corner of the world to agree to this, as I expect more talking here on NANOG than action around this issue. But I'd be happy to join and support such a cabal, with the backing of my own management toward making this commitment, at least from an African standpoint.
If the Telecom Infra Project <https://telecominfraproject.com/participants/> is a good indicator of what operators can achieve by uniting, then you're on a good trajectory. Cheers, Etienne On Wed, Sep 8, 2021 at 9:25 AM Mark Tinka <mark@tinka.africa> wrote:
On 9/8/21 08:50, Saku Ytti wrote:
Fully agreed, I just don't see the driver. But I can imagine a different timeline where in 2000 several tier1 signed mutual binding contracts to drop IPv4 at the edge in 2020. And no one opposed, because 20 years before was 1980, and 20 years in the future IPv4 wont' anymore be a thing, it's clear due to exponential growth.
And we'd all be enjoying a much simplified stack and lower costs all around (vendor, us, customers).
Why is this not possible now? Why would we not sign this mutual agreement for 2040? Otherwise we'll be having this same discussion in 2040.
I do not see why this is not possible now.
In fact, I'd go as far as saying that the proposal should be shortened from 20 years to 10 years from today. 10 years is not unreasonable.
I'm not sure if there needs to be a separate "cabal" amongst the major network operators that cover every corner of the world to agree to this, as I expect more talking here on NANOG than action around this issue. But I'd be happy to join and support such a cabal, with the backing of my own management toward making this commitment, at least from an African standpoint.
I know at least 3 or 4 other operators in Africa that would be willing to commit to the same, either directly or by proxy with us.
Do we drive this through the IETF, or just have private, multi-lateral agreements, as major operators?
I'm now just thinking of how we get this idea off the ground, and stop talking too much.
Mark.
-- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
On 9/8/21 09:35, Etienne-Victor Depasquale wrote:
If the Telecom Infra Project <https://telecominfraproject.com/participants/> is a good indicator of what operators can achieve by uniting, then you're on a good trajectory.
Without the membership fees, of course :-). Mark.
Without the membership fees, of course :-).
Membership fees can be painful, that's for sure. They do have positive aspects, though :) Cheers, Etienne On Wed, Sep 8, 2021 at 9:38 AM Mark Tinka <mark@tinka.africa> wrote:
On 9/8/21 09:35, Etienne-Victor Depasquale wrote:
If the Telecom Infra Project <https://telecominfraproject.com/participants/> is a good indicator of what operators can achieve by uniting, then you're on a good trajectory.
Without the membership fees, of course :-).
Mark.
-- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale
On 9/8/21 09:40, Etienne-Victor Depasquale wrote:
Membership fees can be painful, that's for sure. They do have positive aspects, though :)
I encourage other operators (especially the "major" ones - but really, everyone) to seriously consider supporting this idea, and begin to circulate, within your organizations, whether you can receive purchase for this initiative internally, so we put this discussion about IPv6 to bed, in the next 10 years. Just a simple piece of feedback about basic support back to this list would help kick things off, I feel. Mark.
On Wed Sep 08, 2021 at 09:49:15AM +0200, Mark Tinka wrote:
On 9/8/21 09:40, Etienne-Victor Depasquale wrote:
I encourage other operators (especially the "major" ones - but really, everyone) to seriously consider supporting this idea, and begin to circulate, within your organizations, whether you can receive purchase for this initiative internally, so we put this discussion about IPv6 to bed, in the next 10 years.
Just a simple piece of feedback about basic support back to this list would help kick things off, I feel.
This was discussed as a follow up to World IPv6 day. We'd be 10 years closer by now if we had done it then. The sooner we start the sooner we can finish, I was in favour of it then and remain so. brandon
On Sep 8, 2021, at 00:49 , Mark Tinka <mark@tinka.africa> wrote:
On 9/8/21 09:40, Etienne-Victor Depasquale wrote:
Membership fees can be painful, that's for sure. They do have positive aspects, though :)
I encourage other operators (especially the "major" ones - but really, everyone) to seriously consider supporting this idea, and begin to circulate, within your organizations, whether you can receive purchase for this initiative internally, so we put this discussion about IPv6 to bed, in the next 10 years.
Just a simple piece of feedback about basic support back to this list would help kick things off, I feel.
Mark.
I think the tipping point would be to get the major eyeball providers on board. If you can get them to agree (even if they just agree to surcharge IPv4 support by that time or even in 5 years), that will serve as a really strong forcing function for the content providers. Comcast is well positioned to be able to do this, many of their customers have no viable alternative anyway, so not like they lose business almost no matter what they do. (They’ve proven this repeatedly). They’ve also already got full or nearly full IPv6 enablement for all of their customers (albeit it with ridiculously small prefixes for most of them). The reality is that if we get content dual-stacked and stop requiring IPv4 for new eyeball installations, that’s the biggest initial win. Owen
On Wed, 08 Sep 2021 11:39:50 -0700, Owen DeLong via NANOG said:
The reality is that if we get content dual-stacked and stop requiring IPv4 for new eyeball installations, that’s the biggest initial win.
The problem is "get content dual-stacked". Somebody made this handy page of the IPv6 status for the Alexa Top 500. http://www.delong.com/ipv6_alexa500.html Awful lot of red spots even in the top 100. Hell, even amazon.com isn't IPv6 yet. And the long tail is going to be the death of a thousand cuts for the call center unless you have a way to deal with those sites. And the devil is in the details. cnn.com itself has a quad-A. But looking at Chrome loading it with the IPvFoo extension, I see that of the 145 addresses it hits, only 38 are IPv6, the rest are IPv4. On the other hand, looking at *who* are the IPv4, they seem to be overwhelmingly ad servers and analytics sites - so maybe hitting cnn.com as IPv6-only is a win for the consumer. I rather suspect that the CFO of CNN would see it differently though.... (Eerily reminiscent of the factoid that 60% of the cost of a long distance phone call before the AT&T breakup was keeping the accounting records so they could bill the customer)
On Sep 8, 2021, at 18:55 , Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Wed, 08 Sep 2021 11:39:50 -0700, Owen DeLong via NANOG said:
The reality is that if we get content dual-stacked and stop requiring IPv4 for new eyeball installations, that’s the biggest initial win.
The problem is "get content dual-stacked".
Somebody made this handy page of the IPv6 status for the Alexa Top 500.
http://www.delong.com/ipv6_alexa500.html
Awful lot of red spots even in the top 100. Hell, even amazon.com isn't IPv6 yet. And the long tail is going to be the death of a thousand cuts for the call center unless you have a way to deal with those sites.
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards. Think about it… Amazon doesn’t want to lose access to Comcast, T-Mobile, Verizon Wireless, and/or AT&T eyeballs any more than those ISPs want to deal with the call center consequences if they turn off IPv4 before those content providers are ready. If they put that date, say, 5 years out, perhaps January 15, 2027 for example, so that it doesn’t happen during the retail cash cow season, I suspect it would drive that long tail to shorten. Right now, it’s costing Amazon (amazon.com, not AWS) nothing to ignore IPv6 and continue lagging, they’re able to externalize all of those costs onto the eyeball ISPs.
And the devil is in the details. cnn.com itself has a quad-A. But looking at Chrome loading it with the IPvFoo extension, I see that of the 145 addresses it hits, only 38 are IPv6, the rest are IPv4.
You don’t think they’d be motivated by a drop-dead date agreed upon by the eyeball ISPs? I think they would.
On the other hand, looking at *who* are the IPv4, they seem to be overwhelmingly ad servers and analytics sites - so maybe hitting cnn.com as IPv6-only is a win for the consumer. I rather suspect that the CFO of CNN would see it differently though....
I rather suspect that an announcement of a drop-dead date 5 years out by a select group of major eyeball providers would get the situation corrected likely well short of 5 years.
(Eerily reminiscent of the factoid that 60% of the cost of a long distance phone call before the AT&T breakup was keeping the accounting records so they could bill the customer)
Yes… IIRC, After the breakup, that jumped to more like 80% until things finally got to the point that everyone recognized that eliminating the billing records for such things saved tons of money. Owen
Owen DeLong via NANOG wrote:
The reality is that if we get content dual-stacked and stop requiring IPv4 for new eyeball installations, that’s the biggest initial win.
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards.
Aren't you calling your desire "the reality"? Masataka Ohta
Owen DeLong via NANOG <nanog@nanog.org> writes:
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards.
Think about it… Amazon doesn’t want to lose access to Comcast, T-Mobile, Verizon Wireless, and/or AT&T eyeballs any more than those ISPs want to deal with the call center consequences if they turn off IPv4 before those content providers are ready.
By all means, let's just escalate the peering wars between eyeball networks and content providers. That will solve all our problems. Bjørn
On 20210909, at 21:55, Owen DeLong via NANOG <nanog@nanog.org> wrote:
[..] Awful lot of red spots even in the top 100. Hell, even amazon.com isn't IPv6 yet. And the long tail is going to be the death of a thousand cuts for the call center unless you have a way to deal with those sites.
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards.
You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ? yes, a /24 was 0 setup, now now close to 5000 of currency.... and the monthly fee also doubled. Noting that 20 for an IPv4 IP is effectively quite cheap with current prices going towards 50+... There are thus already a few places that are doing the squish.... Greets, Jeroen
On Sep 10, 2021, at 01:39 , Jeroen Massar <jeroen@massar.ch> wrote:
On 20210909, at 21:55, Owen DeLong via NANOG <nanog@nanog.org> wrote:
[..] Awful lot of red spots even in the top 100. Hell, even amazon.com isn't IPv6 yet. And the long tail is going to be the death of a thousand cuts for the call center unless you have a way to deal with those sites.
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards.
You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
yes, a /24 was 0 setup, now now close to 5000 of currency.... and the monthly fee also doubled. Noting that 20 for an IPv4 IP is effectively quite cheap with current prices going towards 50+...
There are thus already a few places that are doing the squish....
Greets, Jeroen
Yes, but it needs to come from a major eyeball ISP to be the motivating factor that we need here. A minor virtual server host isn’t going to do it. Owen
On 2021-09-10 18:27, Owen DeLong wrote:
On Sep 10, 2021, at 01:39 , Jeroen Massar <jeroen@massar.ch> wrote:
On 20210909, at 21:55, Owen DeLong via NANOG <nanog@nanog.org> wrote:
[..] Awful lot of red spots even in the top 100. Hell, even amazon.com isn't IPv6 yet. And the long tail is going to be the death of a thousand cuts for the call center unless you have a way to deal with those sites.
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards.
You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
yes, a /24 was 0 setup, now now close to 5000 of currency.... and the monthly fee also doubled. Noting that 20 for an IPv4 IP is effectively quite cheap with current prices going towards 50+...
There are thus already a few places that are doing the squish....
Greets, Jeroen
Yes, but it needs to come from a major eyeball ISP to be the motivating factor that we need here. A minor virtual server host isn’t going to do it.
"minor virtual server host". I think you are underestimating things... https://bgp.he.net/AS24940 + AS213230 That is not a toy network... but hey, I guess 'everything is bigger' on the other side of the big old lake eh. I am sure, considering the news and rumors, that that pricing change made, that it made an impact at a lot of companies, that things are changing, and that is a win for IPv6... But hey, YMMV. Greets, Jeroen
On Sep 10, 2021, at 14:17 , Jeroen Massar <jeroen@massar.ch> wrote:
On 2021-09-10 18:27, Owen DeLong wrote:
On Sep 10, 2021, at 01:39 , Jeroen Massar <jeroen@massar.ch> wrote:
On 20210909, at 21:55, Owen DeLong via NANOG <nanog@nanog.org> wrote:
[..] Awful lot of red spots even in the top 100. Hell, even amazon.com isn't IPv6 yet. And the long tail is going to be the death of a thousand cuts for the call center unless you have a way to deal with those sites.
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards.
You mean like: https://docs.hetzner.com/general/others/ipv4-pricing/ ?
yes, a /24 was 0 setup, now now close to 5000 of currency.... and the monthly fee also doubled. Noting that 20 for an IPv4 IP is effectively quite cheap with current prices going towards 50+...
There are thus already a few places that are doing the squish....
Greets, Jeroen
Yes, but it needs to come from a major eyeball ISP to be the motivating factor that we need here. A minor virtual server host isn’t going to do it.
"minor virtual server host". I think you are underestimating things...
https://bgp.he.net/AS24940 + AS213230
That is not a toy network... but hey, I guess 'everything is bigger' on the other side of the big old lake eh.
Not everything, but compare to (e.g. 15169, 16509). Also, the key here is more that we need large eyeballs, such as 7922, 21928, 6167, 6298, etc.). I wasn’t meaning to disparage Hetzner in any way, but they’re a cloud host, not an eyeball provider. While they’re not a toy network, I also wouldn’t call them a major cloud provider in the same league with (e.g. AWS, Azure, Google Cloud).
I am sure, considering the news and rumors, that that pricing change made, that it made an impact at a lot of companies, that things are changing, and that is a win for IPv6...
Agreed… I’m glad to see what they’ve done, but I’m advocating for someone like Comcast to follow suit in hopes that it will drive other large content providers to make the move. Owen
It appears that Owen DeLong via NANOG <owen@delong.com> said:
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards.
Indeed. They would send postcards to all their customers saying "Comcast has said they will cut off your access to Netflix on April 1, Call their president's office at 1-800-xxx-xxxx and tell them what you think." Great move. R's, John
On Sep 10, 2021, at 13:22 , John Levine <johnl@iecc.com> wrote:
It appears that Owen DeLong via NANOG <owen@delong.com> said:
This is my point… That is why I think an announcement of “On X date, we will begin charging extra for IPv4 services and define Internet Access to be IPv6” by a couple of the larger eyeball ISPs would light a pretty big fire under those laggards.
Indeed. They would send postcards to all their customers saying "Comcast has said they will cut off your access to Netflix on April 1, Call their president's office at 1-800-xxx-xxxx and tell them what you think."
Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs doing this. Now Amazon might send post cards saying “Comcast has said that they will cut off your access to our store…”, but I suspect that the cost of such a campaign and the collateral damage would be well in excess of the cost of just adding IPv6 to their service. Owen
Indeed. They would send postcards to all their customers saying "Comcast has said they will cut off your access to Netflix on April 1, Call their president's office at 1-800-xxx-xxxx and tell them what you think."
Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs doing this.
OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't even need postcards, just stick the flyer in with the bill.
Now Amazon might send post cards saying “Comcast has said that they will cut off your access to our store…”, but I suspect that the cost of such a campaign and the collateral damage would be well in excess of the cost of just adding IPv6 to their service.
AWS has perfectly good support for IPv6 so they must have business reasons to stick with v4. But I expect the cost of putting up banners on the homepage saying to call your ISP, for people coming through the relevant ISP, would be pretty cheap, and Amazon's customers appear to like their accounts and their Prime quite a lot. Again, peering wars never end well. This ignores the question of what the advantage to the ISP would be other than bloody-mindedness. The world is not going to abandon IPv4 any time soon and the last time I looked, the cost of routing packets is the same regardless of which header they have. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On Sep 11, 2021, at 13:17 , John R. Levine <johnl@iecc.com> wrote:
Indeed. They would send postcards to all their customers saying "Comcast has said they will cut off your access to Netflix on April 1, Call their president's office at 1-800-xxx-xxxx and tell them what you think."
Nope… Netflix is fully available on IPv6 and actually looks forward to ISPs doing this.
OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't even need postcards, just stick the flyer in with the bill.
Is that really cheaper and easier than deploying IPv6? Really?
Now Amazon might send post cards saying “Comcast has said that they will cut off your access to our store…”, but I suspect that the cost of such a campaign and the collateral damage would be well in excess of the cost of just adding IPv6 to their service.
AWS has perfectly good support for IPv6 so they must have business reasons to stick with v4. But I expect the cost of putting up banners on the homepage saying to call your ISP, for people coming through the relevant ISP, would be pretty cheap, and Amazon's customers appear to like their accounts and their Prime quite a lot. Again, peering wars never end well.
This isn’t really the same as a peering war, however. They can’t really claim Comcast is going to cut you off. They’d have to admit that Comcast is going to start charging more for… Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that Comcast start passing along some of the added expense of maintaining IPv4 connectivity to the customers that want it.
This ignores the question of what the advantage to the ISP would be other than bloody-mindedness. The world is not going to abandon IPv4 any time soon and the last time I looked, the cost of routing packets is the same regardless of which header they have.
You haven’t looked in depth, then. The cost of routing packets is the same. The cost of dealing with address shortages and supporting/maintaining the various hacks and workarounds intended to help mitigate that issue continues to increase. As I have repeatedly stated, the perverse incentive here that drives things is that those who lag aren’t bearing most of the costs. Instead, like toxic polluters, they are able to externalize those costs to developers, eyeball ISPs, CDNs, and others while continuing the status quo. The flyer in the bill thing works both ways. Comcast could just as easily put in a flyer that points out the facts of the situation: 1. There is a flaw in the addressing scheme currently in use in that it doesn’t have enough addresses for everyone. 2. There is a new-iso addressing scheme that has been in use for more than 20 years now. 3. Many services are available through either addressing scheme today. 4. The cost of preserving connectivity to the old addressing scheme is continuing to increase. 5. As a result, starting on <X date in the future>, we will be passing some of those costs on to customers who still want to use the old addressing scheme in the form of an “IPv4 Surcharge”. 6. For more details and to see a list of popular services that do and don’t currently work with the new addressing scheme, check <link>here</link>. If the surcharge starts out at something silly like $2/month or even $5/month, I bet most customers just pay it. Large chunks of the world (those that have IPv6 deployed) would love to abandon or mostly abandon IPv4 as soon as possible. That possibility isn’t defined as “when everybody has IPv6”. It’s defined (for at least eyeball ISPs) as “When enough of the content providers our customers care about are on IPv6 that the business we lose by turning off IPv4 costs less than maintaining IPv4 for all of our customers.” That day may not be today, but it is coming and I don’t think it’s as far off as you imagine. The soft way for eyeball ISPs to approach that is to start passing along some of those costs to their customers by making IPv4 an opt-in add-on to their Internet Service with a nominal charge. Sort of like the fee I used to pay when I had cable TV service where they charged me ~$5 every month for “access to local sports” which I didn’t want and repeatedly asked them to stop. Owen
OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't even need postcards, just stick the flyer in with the bill.
Is that really cheaper and easier than deploying IPv6? Really?
The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or not at all, but you know about accountants and depreciation.
Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that Comcast start passing along some of the added expense of maintaining IPv4 connectivity to the customers that want it.
Ah, so they should start adding a gratuitous charge for a feature they have always provided as part of the basic service. How many milliseconds do you think it'll take for the Congress to haul their CEO in front of a committee?
That day may not be today, but it is coming and I don’t think it’s as far off as you imagine.
Nothing personal, but people have been saying exactly that for about 25 years now. Please forgive me if I continue not to hold my breath. R's, John
On Sep 17, 2021, at 21:03 , John R. Levine <johnl@iecc.com> wrote:
OK, then Disney+ or Hulu or whoever. Peering wars never end well. Don't even need postcards, just stick the flyer in with the bill.
Is that really cheaper and easier than deploying IPv6? Really?
The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or not at all, but you know about accountants and depreciation.
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
Remember, I didn’t suggest that Comcast turn off IPv4… I suggested that Comcast start passing along some of the added expense of maintaining IPv4 connectivity to the customers that want it.
Ah, so they should start adding a gratuitous charge for a feature they have always provided as part of the basic service. How many milliseconds do you think it'll take for the Congress to haul their CEO in front of a committee?
I doubt that their CEO would get hauled in at all. Even if he did, I would think this would be one of the easiest hearings ever for them as literally, they could easily show the increased costs of continuing to provide IPv4 services and note that they didn’t want to jack up everyone’s bills to support the customers that need IPv4, so they’ve made IPv4 an opt-in value added service instead of punishing customers that don’t patronize laggards. (I’m sure their lawyers would say it better, I’m blunt).
That day may not be today, but it is coming and I don’t think it’s as far off as you imagine.
Nothing personal, but people have been saying exactly that for about 25 years now. Please forgive me if I continue not to hold my breath.
Nope… People have been saying that IPv4 would stop being the lingua franca of the internet for 25+ years. There’s still hope for that, but I agree it’s been disappointingly and tragically slow. OTOH, the idea of doing cost-recovery on the additional nuisance that is IPv4 is relatively novel and hasn’t been floated that I’m aware of more than 3 or 4 years ago. Bottom line is that IPv4 continues to increase costs for eyeball providers. They’ll need to recover that cost. At some point, the cost will be enough of a differentiator that customers willing to accept v6-only service will get a break. If they don’t do it as an IPv4 surcharge, they could do it as an IPv6-only discount… That might even be better. Either way, the net effect is the same… Suddenly, customers have a monetary advantage to push their content providers toward providing v6. Owen
It appears that Owen DeLong via NANOG <owen@delong.com> said:
The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or not at all, but you know about accountants and depreciation.
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
I wasn't talking about switches and routers. I was talking about every single piece of software and equipment that they use for support and marketing and customer service and all the other stuff that big companies do. As I may have said once or twice, eventuallly it'll all be replaced so it works on IPv6 but we're not holding our breath. R's, John
On Sat, Sep 18, 2021 at 2:39 PM John Levine <johnl@iecc.com> wrote:
The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or not at all, but you know about accountants and depreciation.
Unless their infrastructure runs significantly on hardware and software
It appears that Owen DeLong via NANOG <owen@delong.com> said: pre-2004 (unlikely), so does the cost of
adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
I wasn't talking about switches and routers. I was talking about every single piece of software and equipment that they use for support and marketing and customer service and all the other stuff that big companies do.
As I may have said once or twice, eventuallly it'll all be replaced so it works on IPv6 but we're not holding our breath.
Glad you noted this. Thinking this was/is purely a hardware cycle problem related to normal/forced upgrade strategies. On that point, most hardware I know of from 2004 in larger networks is long fully depreciated and sweating assets 15+ years can happen, but I don't personally think this is the biggest issue. As you noted John, its the plethora of software, support systems, tooling, and most important in many environments - legacy customer management and provisioning systems that can be the limiting factor. I recall looking back when leading IPv6 turn-up, those were the biger problems to solve for. Often such systems are extremely expensive to touch and working on them required prioritization against direct revenue generating projects (opportunity cost) . Replacing routers was just a money problem. I am by far not saying I agree with choices made by hold-outs, but I also understand this is for many, not just an engineering problem to solve. regards, Victor K
R's, John
As you noted John, its the plethora of software, support systems, tooling, and most important in many environments - legacy customer management and provisioning systems that can be the limiting factor. ...
Just looking around my office, I have a Cisco SPA112 two-port ATA. It's been discontinued but Cisco says they will support it through 2025 and they shipped a firmware update in 2019. It works fine on IPv4 behind a NAT. It has no v6 support at all and never will. Multiply that by a zillion and you can see that IPv4 isn't going away any time soon. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
I mostly agree with this. Even new hardware like eero doesn't do v6 by default. It's just off. So many things are like this. It's nice that LTE and other deployments have v6 by default. Last time I knew providers like t mobile are great but their MVNOs like Ultra Mobile do not do v6. All this and we will get there. I'm expecting another decade or two though. Sent from my TI-99/4a
On Sep 18, 2021, at 4:29 PM, John R. Levine <johnl@iecc.com> wrote:
IPv4 isn't going away any time soon.
On Sep 18, 2021, at 13:25 , John R. Levine <johnl@iecc.com> wrote:
As you noted John, its the plethora of software, support systems, tooling, and most important in many environments - legacy customer management and provisioning systems that can be the limiting factor. ...
Just looking around my office, I have a Cisco SPA112 two-port ATA. It's been discontinued but Cisco says they will support it through 2025 and they shipped a firmware update in 2019. It works fine on IPv4 behind a NAT. It has no v6 support at all and never will. Multiply that by a zillion and you can see that IPv4 isn't going away any time soon.
This isn’t about removing IPv4 from every last corner of the internet. It’s about adding IPv6 to the content providers that are blocking the ability to build new eyeball networks v6 only. Owen
On Sep 18, 2021, at 12:34 , Victor Kuarsingh <victor@jvknet.com> wrote:
On Sat, Sep 18, 2021 at 2:39 PM John Levine <johnl@iecc.com <mailto:johnl@iecc.com>> wrote: It appears that Owen DeLong via NANOG <owen@delong.com <mailto:owen@delong.com>> said:
The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or not at all, but you know about accountants and depreciation.
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
I wasn't talking about switches and routers. I was talking about every single piece of software and equipment that they use for support and marketing and customer service and all the other stuff that big companies do.
As I may have said once or twice, eventuallly it'll all be replaced so it works on IPv6 but we're not holding our breath.
Glad you noted this. Thinking this was/is purely a hardware cycle problem related to normal/forced upgrade strategies. On that point, most hardware I know of from 2004 in larger networks is long fully depreciated and sweating assets 15+ years can happen, but I don't personally think this is the biggest issue.
It’s certainly not purely hardware, but it also doesn’t require solving the entire problem across the entire backend. What is urgently needed is to fix the customer-facing front end so that it speaks both protocols (or at least speaks IPv6).
As you noted John, its the plethora of software, support systems, tooling, and most important in many environments - legacy customer management and provisioning systems that can be the limiting factor. I recall looking back when leading IPv6 turn-up, those were the biger problems to solve for. Often such systems are extremely expensive to touch and working on them required prioritization against direct revenue generating projects (opportunity cost) . Replacing routers was just a money problem.
Why do those systems have to be updated in order to deliver the service to the customer in both protocols? I mean sure, you’ll probably need to fix some logging databases that think that a customers address can be logged as a uint32_t, but that’s a relatively small number of systems that need to be updated in that case and it’s not like expanding the field to uint128_t in the database is incompatible with the old software during the upgrade process.
I am by far not saying I agree with choices made by hold-outs, but I also understand this is for many, not just an engineering problem to solve.
I agree there are some systems that may make this more complex in some environments, but I don’t agree that it’s impossible (or even particularly difficult) for a content provider to deliver their content on both protocols today even if they don’t upgrade their back-end systems. Owen
Owen, On Sat, Sep 18, 2021 at 23:51 Owen DeLong <owen@delong.com> wrote:
On Sep 18, 2021, at 12:34 , Victor Kuarsingh <victor@jvknet.com> wrote:
On Sat, Sep 18, 2021 at 2:39 PM John Levine <johnl@iecc.com> wrote:
It appears that Owen DeLong via NANOG <owen@delong.com> said:
Glad you noted this. Thinking this was/is purely a hardware cycle problem related to normal/forced upgrade strategies. On that point, most hardware I know of from 2004 in larger networks is long fully depreciated and sweating assets 15+ years can happen, but I don't personally think this is the biggest issue.
It’s certainly not purely hardware, but it also doesn’t require solving the entire problem across the entire backend.
What is urgently needed is to fix the customer-facing front end so that it speaks both protocols (or at least speaks IPv6).
This is a great question. So when we approached this (going back a while now) this is what I thought too. But I was responsible to solve this end to end. So just updating front end (CPEs, network routers, DHCP, provisioning, IP address planning, security, peering/transit, staff training, test harnesses/plans, etc) was not sufficient to turn on IPv6. The high cost and time challenge issues were not upgrading backend servers to IPv6, but backend provisioning systems, tools, customer support tools, their training, and related items. These systems were far more complex and costly to address (especially when considering opportunity cost). Without all of this in place, we could not actually deploy IPv6 for production use (it’s not just Turing it on, its our ability to operate it down to the person answer the phone, the technician that installs and/or fixes/replaces items in home). Also at that time vendor CPE hardware was not as far along on IPv6 readiness (approx mid-decade 2000s). Getting reliable code at that time was hard with a lot of brokenness (which also could not go into production until it was reliable). Perhaps this a non-issue today, but it certainly was not a something that was “ready to go” even 10-15 years. This (IPv6 readiness in CPE code) was also competing with other priorities often blowing up timelines which meant it had to wait as not releasing code into production on a strict timeline was not an option for business reasons. All said and done, we got it completed, but it far most costly than we first thought, and IPv4 costs did not go away after we were completed. Sure it’s possible to reduce those costs with an aggressive program, but it is not as simple as many think.
As you noted John, its the plethora of software, support systems, tooling, and most important in many environments - legacy customer management and provisioning systems that can be the limiting factor. I recall looking back when leading IPv6 turn-up, those were the biger problems to solve for. Often such systems are extremely expensive to touch and working on them required prioritization against direct revenue generating projects (opportunity cost) . Replacing routers was just a money problem.
Why do those systems have to be updated in order to deliver the service to the customer in both protocols?
Addressed in above comment. When it comes to turning on IPv6 and reducing your dependency on IPv4, your mileage may vary (in terms of real costs, complexities and deployment). Regards, Victor K
I mean sure, you’ll probably need to fix some logging databases that think that a customers address can be logged as a uint32_t, but that’s a relatively small number of systems that need to be updated in that case and it’s not like expanding the field to uint128_t in the database is incompatible with the old software during the upgrade process.
I am by far not saying I agree with choices made by hold-outs, but I also understand this is for many, not just an engineering problem to solve.
I agree there are some systems that may make this more complex in some environments, but I don’t agree that it’s impossible (or even particularly difficult) for a content provider to deliver their content on both protocols today even if they don’t upgrade their back-end systems.
Owen
On Sep 19, 2021, at 16:17 , Victor Kuarsingh <victor@jvknet.com> wrote:
Owen,
On Sat, Sep 18, 2021 at 23:51 Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
On Sep 18, 2021, at 12:34 , Victor Kuarsingh <victor@jvknet.com <mailto:victor@jvknet.com>> wrote:
On Sat, Sep 18, 2021 at 2:39 PM John Levine <johnl@iecc.com <mailto:johnl@iecc.com>> wrote: It appears that Owen DeLong via NANOG <owen@delong.com <mailto:owen@delong.com>> said:
Glad you noted this. Thinking this was/is purely a hardware cycle problem related to normal/forced upgrade strategies. On that point, most hardware I know of from 2004 in larger networks is long fully depreciated and sweating assets 15+ years can happen, but I don't personally think this is the biggest issue.
It’s certainly not purely hardware, but it also doesn’t require solving the entire problem across the entire backend.
What is urgently needed is to fix the customer-facing front end so that it speaks both protocols (or at least speaks IPv6).
This is a great question. So when we approached this (going back a while now) this is what I thought too. But I was responsible to solve this end to end. So just updating front end (CPEs, network routers, DHCP, provisioning, IP address planning, security, peering/transit, staff training, test harnesses/plans, etc) was not sufficient to turn on IPv6.
The high cost and time challenge issues were not upgrading backend servers to IPv6, but backend provisioning systems, tools, customer support tools, their training, and related items. These systems were far more complex and costly to address (especially when considering opportunity cost). Without all of this in place, we could not actually deploy IPv6 for production use (it’s not just Turing it on, its our ability to operate it down to the person answer the phone, the technician that installs and/or fixes/replaces items in home).
This sounds like an eyeball environment… Note that my question was in the context of the laggard content providers. Eyeball providers are going to have to do something eventually whether they like it or not and I’m a whole lot less worried about a forcing function for them. The major eyeball providers have basically completed this. Hopefully that means that the vendors you’re using have been forced to upgrade their code and such to accommodate by now.
Also at that time vendor CPE hardware was not as far along on IPv6 readiness (approx mid-decade 2000s). Getting reliable code at that time was hard with a lot of brokenness (which also could not go into production until it was reliable). Perhaps this a non-issue today, but it certainly was not a something that was “ready to go” even 10-15 years. This (IPv6 readiness in CPE code) was also competing with other priorities often blowing up timelines which meant it had to wait as not releasing code into production on a strict timeline was not an option for business reasons.
Sure, but a lot of that has gotten better in the recent years, largely driven by some of the major eyeball ISPs.
All said and done, we got it completed, but it far most costly than we first thought, and IPv4 costs did not go away after we were completed. Sure it’s possible to reduce those costs with an aggressive program, but it is not as simple as many think.
Agreed… IPv4 costs for you, as an eyeball provider, can’t really go away until you can start doing one or more of the following: 1. Raising your overall rates and providing a discount to IPv6-only customers 2. Adding a surcharge to your billing for customers still requiring IPv4 services 3. Turning off or reducing availability of IPv4 native services and moving more towards IPv4AAS 4. Turning off IPv4 services outright All of those basically depend on moving a few key laggard content providers forward.
As you noted John, its the plethora of software, support systems, tooling, and most important in many environments - legacy customer management and provisioning systems that can be the limiting factor. I recall looking back when leading IPv6 turn-up, those were the biger problems to solve for. Often such systems are extremely expensive to touch and working on them required prioritization against direct revenue generating projects (opportunity cost) . Replacing routers was just a money problem.
Why do those systems have to be updated in order to deliver the service to the customer in both protocols?
Addressed in above comment.
Eyeball… Now think about it in the context of a content provider… Especially one that is behind a CDN where it’s literally simply flipping the switch on the CDN that says front end our stuff with both protocols.
When it comes to turning on IPv6 and reducing your dependency on IPv4, your mileage may vary (in terms of real costs, complexities and deployment).
Agreed… Much more variable for eyeballs, but still some variability for content providers, too. Nonetheless, I think it is generally quite simple for content providers today while there are still some issues that remain unsolved on the eyeball side of things. The good news is that once a few laggard content providers add IPv6 capabilities, eyeball providers can start treating IPv4 as (mostly) optional in a lot of areas, so that those which have deployed IPv6 to their customers in a meaningful way can start to shrink their IPv4 costs. Owen
On Sep 18, 2021, at 11:37 , John Levine <johnl@iecc.com> wrote:
It appears that Owen DeLong via NANOG <owen@delong.com> said:
The cost of putting flyers in the bills rounds to zero, so yes, really. I expect these companies all have plans to support v6 eventually, someday, once they're retired and replaced all of the old junk that handles v6 poorly or not at all, but you know about accountants and depreciation.
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
I wasn't talking about switches and routers. I was talking about every single piece of software and equipment that they use for support and marketing and customer service and all the other stuff that big companies do.
That doesn’t all have to change in order to make their services available on IPv6 also. IPv6 is not an all-or-nothing thing. If your backend is all IPv4 all the time and you want to keep it that way, more power to you. I encourage my competitors to try that. However, if your customer-facing services are IPv4-only, that’s not hard to fix in most cases and it’s really obnoxious not to do so.
As I may have said once or twice, eventuallly it'll all be replaced so it works on IPv6 but we're not holding our breath.
I’m not holding my breath, but I’m also trying to argue reasonable approaches and realistic solutions here. You seem to be looking for excuses to claim the problem that needs to be solved is harder than it is to justify not solving it. Owen
John Levine wrote:
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
I wasn't talking about switches and routers.
But, on routers, IPv6 costs four times more than IPv4 to look up routing table with TCAM or Patricia tree. It is not a problem yet, merely because full routing table of IPv6 is a lot smaller than that of IPv4, which means most small ISPs and multihomed sites do not support IPv6. Mark Andrews wrote:
There is nothing at the protocol level stopping AT&T offering a similar level of service.
Setting up reverse DNS lookup for 16B address is annoying, which may stop AT&T offering it.
Don’t equate poor implementation with the protocol being broken.
IPv6 is broken in several ways. One of the worst thing is its address length. Masataka Ohta
People who keep thinking this is a technical problem that can be engineered away are confused. People who think the relative cost of doing lookup for IPV4/IPV6 is visible to TCO are confused. Just because you can observe technical differences doesn't mean they are important, it may mean you're being affected by availability heuristics bias, you think that the things you understand must contain the solution to the problem. IPv6 problem is, very few companies in developed markets need it to do business, as customers are just bouncing between established players, no new organic growth. Those companies choosing to do it increase their cost for no utility, so it is an objectively bad decision for many to do IPv6. People who have sentimental attachment to versions of IP protocols are a minority, most just want that customers continue paying their invoices and keep accepting the product. It is almost guaranteed we are married to IPv4 past our life cycles, because there will be a lot of drivers to keep it. Even though dual-stack increases cost for our vendors and us, each of us can transfer the cost to our customers with margins, fixing it would mean less revenue. Like infosec, it'll want things to remain relatively broken, as everyone in position to change it are capitalising on keeping it. -- ++ytti
Saku Ytti wrote:
It is almost guaranteed we are married to IPv4 past our life cycles, because there will be a lot of drivers to keep it.
So, the war was between "IPv4 with NAT" and "IPv4 dual stacked with IPv6". If IPv6 were simple, quickly standardized and easily deployable, which are technical points, it could have won. Masataka Ohta
On 9/18/21 11:20 PM, Masataka Ohta wrote:
Mark Andrews wrote:
There is nothing at the protocol level stopping AT&T offering a similar level of service.
Setting up reverse DNS lookup for 16B address is annoying, which may stop AT&T offering it.
How many mail servers are on the Internet today? I don't know. How many business customers (large and small) does AT&T have? I don't know, and don't expect ever to know. I assume by "16B" you mean "16 billion"; if so, why did you select that value? Based on the routing tables on my edge router for my existing connection-based allocation, I have a IPv6 address block with a /60 prefix. The AT&T SBCIS allocation for IPv6 is 2600:1700::/28 (4.294.967.296 /60 prefixes), and the parent range is /12. (In a prior message, someone mentioned that their customer was able to obtain a static /56 IPv6 address block. Don't know how they did that, unless they are tunneling to a different provider like HE.) AT&T does offer PTR records for IPv4 static addresses -- I have a set of static IPv4 addresses (which I pay for monthly) and one associated IN-ADDR.ARPA PTR record. (I used to have *two* sets of static IP IPv4 addresses -- both paid for monthly -- and two associated IN-ADDR.ARPA PTR records, but I released one of those sets when I discontinued my long-time DSL service with AT&T.) From the AT&T community forum, from two years ago, a moderator says this: "IPv6 Its [sic] are assigned to your connection; IPv4 static IP blocks are assigned to you. This is why they still don't offer reverse PTR delegation." What's missing? A static prefix of IPv6, and one IP6.ARPA PTR record. I'm willing to pay for IPv6 static addresses, as long as I can get the one IP6.ARPA PTR record for my mail server. Connection-based prefix would be fine, but I still need the PTR record to satisfy the Best Practices requirements for mail servers. (Why do I run my own mail server? When I started out with DSL many years ago, I used Pacific Bell's mail servers. The IP reputation was to the point that mail from my systems was blocked by so many mail servers around the 'Net. So, Postfix locally. Never looked back.)
On Sep 18, 2021, at 23:20 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
John Levine wrote:
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai. I wasn't talking about switches and routers.
But, on routers, IPv6 costs four times more than IPv4 to look up routing table with TCAM or Patricia tree.
It is not a problem yet, merely because full routing table of IPv6 is a lot smaller than that of IPv4, which means most small ISPs and multihomed sites do not support IPv6.
Well, it’s a combination. Even with full v6 adoption, the routing table in v6 should be substantially smaller. Compare AS6939 v4 vs. v6: + 6939 is probably the most v6 fully implemented ASN on the planet. + 6939 announces 4 of their own prefixes in v6 (They do originate 19 prefixes on behalf of customers) + 6939 announces at least 41 of their own prefixes in v4 and originates myriad customer prefixes in v4. That’s more than 10x the prefixes in v4 for the same network fully dual-stacked vs. what is announced in v6. v4 is so thoroughly fragmented and v6 is a lot less likely to become so.
Mark Andrews wrote:
There is nothing at the protocol level stopping AT&T offering a similar level of service.
Setting up reverse DNS lookup for 16B address is annoying, which may stop AT&T offering it.
Why would one need to do that? For customers with a static prefix that want reverse DNS capabilities, offer to point the NS records for their prefix wherever they want and let them run their own DNS servers.
Don’t equate poor implementation with the protocol being broken.
IPv6 is broken in several ways. One of the worst thing is its address length.
Why do you think 128 bits isn’t enough? Owen
Owen DeLong wrote:
But, on routers, IPv6 costs four times more than IPv4 to look up routing table with TCAM or Patricia tree.
It is not a problem yet, merely because full routing table of IPv6 is a lot smaller than that of IPv4, which means most small ISPs and multihomed sites do not support IPv6.
Well, it’s a combination. Even with full v6 adoption, the routing table in v6 should be substantially smaller.
Not at all.
Compare AS6939 v4 vs. v6:
That is not a meaningful comparison. As mergers of ASes increases the number of announcements and IPv4 addresses were allocated a lot earlier than those of IPv6, comparing the current numbers of announcements is not meaningful. As a result, size of global routing table will keep increasing unless there are other factors to limit it. An important factor is that, for IPv4 with globally routable /24, the absolute upper limit is merely 16M, to be looked up by a single memory access of conventional SRAM without needing TCAM. OTOH, IPv6 is hopeless. Another favorite factor for IPv4 is that, though most of routing table entries are generated from small entities having a /24 assuming NAT, if such entities are merged, renumbering is not so much a pain and they are motivated to rely on a single /24 and sell others. OTOH, there is no such motivation for IPv6.
v4 is so thoroughly fragmented and v6 is a lot less likely to become so.
It is true that fragmentation is a problem. However, it merely means that IPv6 address space will also be fragmented and that IPv4 can but IPv6 can't be deployed at full scale, Masataka Ohta
Hi,
v4 is so thoroughly fragmented and v6 is a lot less likely to become so.
It is true that fragmentation is a problem. However, it merely means that IPv6 address space will also be fragmented and that IPv4 can but IPv6 can't be deployed at full scale,
Just this week We had our first customer asking if we can setup BGP to route the /48 they received from the headquarters in the states. They are asking us to provide a few v4 addresses , but to use their own v6 block. Yes they are a large conglomerate with their own AS and a large v6 allocation, so not a common customer, but they have hundreds of offices everywhere in the world where they are doing this... I can just see the Cxx presenting their solution at some event and it becoming the new thing to do What you are still using your providers addresses? You must be crazy... We assign our own it's much better... A couple hundred corporations like this and the v6 table would surpass v4... Brian
On Sep 20, 2021, at 06:48 , Brian Turnbow via NANOG <nanog@nanog.org> wrote:
Hi,
v4 is so thoroughly fragmented and v6 is a lot less likely to become so.
It is true that fragmentation is a problem. However, it merely means that IPv6 address space will also be fragmented and that IPv4 can but IPv6 can't be deployed at full scale,
Just this week We had our first customer asking if we can setup BGP to route the /48 they received from the headquarters in the states. They are asking us to provide a few v4 addresses , but to use their own v6 block. Yes they are a large conglomerate with their own AS and a large v6 allocation, so not a common customer, but they have hundreds of offices everywhere in the world where they are doing this... I can just see the Cxx presenting their solution at some event and it becoming the new thing to do What you are still using your providers addresses? You must be crazy... We assign our own it's much better... A couple hundred corporations like this and the v6 table would surpass v4...
In such a case, I’m not convinced that’s a bad thing. Owen
On Sep 20, 2021, at 05:15 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Owen DeLong wrote:
But, on routers, IPv6 costs four times more than IPv4 to look up routing table with TCAM or Patricia tree. It is not a problem yet, merely because full routing table of IPv6 is a lot smaller than that of IPv4, which means most small ISPs and multihomed sites do not support IPv6. Well, it’s a combination. Even with full v6 adoption, the routing table in v6 should be substantially smaller.
Not at all.
Compare AS6939 v4 vs. v6:
That is not a meaningful comparison.
As mergers of ASes increases the number of announcements and IPv4 addresses were allocated a lot earlier than those of IPv6, comparing the current numbers of announcements is not meaningful.
Mergers of ASes does not increase announcements in IPv4 nearly as much as slow-start and repeated expanding requests for additional IPv4 space have.
As a result, size of global routing table will keep increasing unless there are other factors to limit it.
Sure, but it’s very clear that the rate of increase for IPv6 appears to be roughly 1/8th that of IPv4, so even if IPv6 was 4x as expensive, the growth rate in cost would still be 1/2 that of IPv4.
An important factor is that, for IPv4 with globally routable /24, the absolute upper limit is merely 16M, to be looked up by a single memory access of conventional SRAM without needing TCAM. OTOH, IPv6 is hopeless.
The reality is that IPv4 will never be completely disaggregated into /24s and IPv6 will never be completely disaggregated into /48s, so this is actually meaningless and not predictive in any way.
Another favorite factor for IPv4 is that, though most of routing table entries are generated from small entities having a /24 assuming NAT, if such entities are merged, renumbering is not so much a pain and they are motivated to rely on a single /24 and sell others. OTOH, there is no such motivation for IPv6.
There is no need for such motivation in IPv6 and better yet, since the two organizations have fully globally unique addresses deployed throughout their network, there’s no risk of collisions in RFC-1918 space necessitating large renumbering projects to merge the networks. Indeed, all you need to do is turn on forwarding between the two networks and you’re basically done. As such, no, that’s an advantage that clearly goes to IPv6, not IPv4.
v4 is so thoroughly fragmented and v6 is a lot less likely to become so.
It is true that fragmentation is a problem. However, it merely means that IPv6 address space will also be fragmented and that IPv4 can but IPv6 can't be deployed at full scale,
Why would IPv6 become fragmented? When a provider the size of HE can easily get a /24 from ARIN, what need is there for fragmentation. Sure, they started with a /32 and they’re keeping that, but the equivalent growth in IPv4 would have resulted in a /20 + /19 + /18 + /17 + /16 + /15 + /14 + /13 and likely an additional /12 eventually. So you get 7-8 prefixes for the same factor of growth as 2 prefixes in IPv4. It simply doesn’t make sense to claim that fragmentation in v6 will be nearly as bad as it is in v4 because we don’t have the problems of slow start and we’re no longer trying to balance scarcity against aggregation. Owen
Owen DeLong wrote:
As mergers of ASes increases the number of announcements and IPv4 addresses were allocated a lot earlier than those of IPv6, comparing the current numbers of announcements is not meaningful.
Mergers of ASes does not increase announcements in IPv4 nearly as much as slow-start and repeated expanding requests for additional IPv4 space have.
That *was* a factor, when increased number of subscribers meant more free addresses. Today, as /24 can afford hundreds of thousands of subscribers by NAT, only very large retail ISPs need more than one announcement for IPv4.
As a result, size of global routing table will keep increasing unless there are other factors to limit it.
Sure, but it’s very clear that the rate of increase for IPv6 appears to be roughly 1/8th that of IPv4,
It merely means IPv6 is not deployed at all by small ISPs and multihomed sites.
The reality is that IPv4 will never be completely disaggregated into /24s
You are so optimistic.
and IPv6 will never be completely disaggregated into /48s, so this is actually meaningless and not predictive in any way.
That IPv6 will be disaggregated into /40 or even /32 is disastrous.
There is no need for such motivation in IPv6 and better yet,
Then, in a long run, IPv6 will be disaggregated into /32 or /40.
since the two organizations have fully globally unique addresses deployed throughout their network, there's no risk of collisions in RFC-1918 space necessitating large renumbering projects to merge the networks.
You fully misunderstand why NAT is so popular today defeating IPv6. Even if two organizations are merged, sites of the organizations are, in general, not merged. As private address space behind NAT is used by each site independently, there is no renumbering occur for the private addresses. Masataka Ohta
On Wed, 22 Sept 2021 at 16:48, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
Today, as /24 can afford hundreds of thousands of subscribers by NAT, only very large retail ISPs need more than one announcement for IPv4.
You can only have about 200-300 subscribers per IPv4 address on a CGN. If you try to go further than that, for example by using symmetric NAT, you will increase the number of customers that want to get a public IPv4 of their own. That will actually decrease the combined efficiency and cause you to need more, not less, IPv4 addresses. Without checking our numbers, I believe we have at least 10% of the customers that are paying for a public IPv4 to escape our CGN. This means a /24 will only be enough for about 2500 customers maximum. The "nat escapers" drown out the efficiency of the NAT pool. The optimization you need to do is to make the CGN as customer friendly as possible instead of trying to squeeze the maximum customers per CGN IPv4 address. Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If it helps just a little bit, that alone will make implementing IPv6 worth it for smaller emerging operators. Buying IPv4 has become very expensive. Yes you can profit from selling a public IPv4 address to the customer, but there is also the risk that the customer just goes to the incumbent, which has old large pools of IPv4 and provides it for free. Regards, Baldur
Where does this "You can only have about 200-300 subscribers per IPv4 address on a CGN." limit come from? I have seen several apartment complexes run on a single static IPv4 address using a Mikrotik with NAT. On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On Wed, 22 Sept 2021 at 16:48, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Today, as /24 can afford hundreds of thousands of subscribers by NAT, only very large retail ISPs need more than one announcement for IPv4.
You can only have about 200-300 subscribers per IPv4 address on a CGN. If you try to go further than that, for example by using symmetric NAT, you will increase the number of customers that want to get a public IPv4 of their own. That will actually decrease the combined efficiency and cause you to need more, not less, IPv4 addresses.
Without checking our numbers, I believe we have at least 10% of the customers that are paying for a public IPv4 to escape our CGN. This means a /24 will only be enough for about 2500 customers maximum. The "nat escapers" drown out the efficiency of the NAT pool.
The optimization you need to do is to make the CGN as customer friendly as possible instead of trying to squeeze the maximum customers per CGN IPv4 address.
Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If it helps just a little bit, that alone will make implementing IPv6 worth it for smaller emerging operators. Buying IPv4 has become very expensive. Yes you can profit from selling a public IPv4 address to the customer, but there is also the risk that the customer just goes to the incumbent, which has old large pools of IPv4 and provides it for free.
Regards,
Baldur
And how many apartments where covered by that single IP address? Was this where there is a restriction on other providers so the occupants had no choice of wireline ISP?
On 23 Sep 2021, at 09:38, Colton Conor <colton.conor@gmail.com> wrote:
Where does this "You can only have about 200-300 subscribers per IPv4 address on a CGN." limit come from? I have seen several apartment complexes run on a single static IPv4 address using a Mikrotik with NAT.
On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On Wed, 22 Sept 2021 at 16:48, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Today, as /24 can afford hundreds of thousands of subscribers by NAT, only very large retail ISPs need more than one announcement for IPv4.
You can only have about 200-300 subscribers per IPv4 address on a CGN. If you try to go further than that, for example by using symmetric NAT, you will increase the number of customers that want to get a public IPv4 of their own. That will actually decrease the combined efficiency and cause you to need more, not less, IPv4 addresses.
Without checking our numbers, I believe we have at least 10% of the customers that are paying for a public IPv4 to escape our CGN. This means a /24 will only be enough for about 2500 customers maximum. The "nat escapers" drown out the efficiency of the NAT pool.
The optimization you need to do is to make the CGN as customer friendly as possible instead of trying to squeeze the maximum customers per CGN IPv4 address.
Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If it helps just a little bit, that alone will make implementing IPv6 worth it for smaller emerging operators. Buying IPv4 has become very expensive. Yes you can profit from selling a public IPv4 address to the customer, but there is also the risk that the customer just goes to the incumbent, which has old large pools of IPv4 and provides it for free.
Regards,
Baldur
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
300 apartments Mark. No, it's bulk internet and wifi so a single provider. On Wed, Sep 22, 2021 at 8:01 PM Mark Andrews <marka@isc.org> wrote:
And how many apartments where covered by that single IP address? Was this where there is a restriction on other providers so the occupants had no choice of wireline ISP?
On 23 Sep 2021, at 09:38, Colton Conor <colton.conor@gmail.com> wrote:
Where does this "You can only have about 200-300 subscribers per IPv4 address on a CGN." limit come from? I have seen several apartment complexes run on a single static IPv4 address using a Mikrotik with NAT.
On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On Wed, 22 Sept 2021 at 16:48, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Today, as /24 can afford hundreds of thousands of subscribers by NAT, only very large retail ISPs need more than one announcement for IPv4.
You can only have about 200-300 subscribers per IPv4 address on a CGN. If you try to go further than that, for example by using symmetric NAT, you will increase the number of customers that want to get a public IPv4 of their own. That will actually decrease the combined efficiency and cause you to need more, not less, IPv4 addresses.
Without checking our numbers, I believe we have at least 10% of the customers that are paying for a public IPv4 to escape our CGN. This means a /24 will only be enough for about 2500 customers maximum. The "nat escapers" drown out the efficiency of the NAT pool.
The optimization you need to do is to make the CGN as customer friendly as possible instead of trying to squeeze the maximum customers per CGN IPv4 address.
Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If it helps just a little bit, that alone will make implementing IPv6 worth it for smaller emerging operators. Buying IPv4 has become very expensive. Yes you can profit from selling a public IPv4 address to the customer, but there is also the risk that the customer just goes to the incumbent, which has old large pools of IPv4 and provides it for free.
Regards,
Baldur
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
The DMCA notices for that single ipv4 /32 must be interesting. On Thu, Sep 23, 2021 at 11:35 AM Colton Conor <colton.conor@gmail.com> wrote:
300 apartments Mark. No, it's bulk internet and wifi so a single provider.
On Wed, Sep 22, 2021 at 8:01 PM Mark Andrews <marka@isc.org> wrote:
And how many apartments where covered by that single IP address? Was this where there is a restriction on other providers so the occupants had no choice of wireline ISP?
On 23 Sep 2021, at 09:38, Colton Conor <colton.conor@gmail.com> wrote:
Where does this "You can only have about 200-300 subscribers per IPv4 address on a CGN." limit come from? I have seen several apartment complexes run on a single static IPv4 address using a Mikrotik with NAT.
On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On Wed, 22 Sept 2021 at 16:48, Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp> wrote:
Today, as /24 can afford hundreds of thousands of subscribers by NAT, only very large retail ISPs need more than one announcement for IPv4.
You can only have about 200-300 subscribers per IPv4 address on a CGN. If you try to go further than that, for example by using symmetric NAT, you will increase the number of customers that want to get a public IPv4 of their own. That will actually decrease the combined efficiency and cause you to need more, not less, IPv4 addresses.
Without checking our numbers, I believe we have at least 10% of the customers that are paying for a public IPv4 to escape our CGN. This means a /24 will only be enough for about 2500 customers maximum. The "nat escapers" drown out the efficiency of the NAT pool.
The optimization you need to do is to make the CGN as customer friendly as possible instead of trying to squeeze the maximum customers per CGN IPv4 address.
Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If it helps just a little bit, that alone will make implementing IPv6 worth it for smaller emerging operators. Buying IPv4 has become very expensive. Yes you can profit from selling a public IPv4 address to the customer, but there is also the risk that the customer just goes to the incumbent, which has old large pools of IPv4 and provides it for free.
Regards,
Baldur
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
So a single level of NAT and a similar level of customers to that which was stated could be supported by a single IP. This is not quite a apples to apples comparison to the double NAT scenario being described below but close enough for the number of sessions. Mark
On 24 Sep 2021, at 01:34, Colton Conor <colton.conor@gmail.com> wrote:
300 apartments Mark. No, it's bulk internet and wifi so a single provider.
On Wed, Sep 22, 2021 at 8:01 PM Mark Andrews <marka@isc.org> wrote:
And how many apartments where covered by that single IP address? Was this where there is a restriction on other providers so the occupants had no choice of wireline ISP?
On 23 Sep 2021, at 09:38, Colton Conor <colton.conor@gmail.com> wrote:
Where does this "You can only have about 200-300 subscribers per IPv4 address on a CGN." limit come from? I have seen several apartment complexes run on a single static IPv4 address using a Mikrotik with NAT.
On Wed, Sep 22, 2021 at 2:49 PM Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On Wed, 22 Sept 2021 at 16:48, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Today, as /24 can afford hundreds of thousands of subscribers by NAT, only very large retail ISPs need more than one announcement for IPv4.
You can only have about 200-300 subscribers per IPv4 address on a CGN. If you try to go further than that, for example by using symmetric NAT, you will increase the number of customers that want to get a public IPv4 of their own. That will actually decrease the combined efficiency and cause you to need more, not less, IPv4 addresses.
Without checking our numbers, I believe we have at least 10% of the customers that are paying for a public IPv4 to escape our CGN. This means a /24 will only be enough for about 2500 customers maximum. The "nat escapers" drown out the efficiency of the NAT pool.
The optimization you need to do is to make the CGN as customer friendly as possible instead of trying to squeeze the maximum customers per CGN IPv4 address.
Perhaps IPv6 can lower the number of people that need to escape IPv4 nat. If it helps just a little bit, that alone will make implementing IPv6 worth it for smaller emerging operators. Buying IPv4 has become very expensive. Yes you can profit from selling a public IPv4 address to the customer, but there is also the risk that the customer just goes to the incumbent, which has old large pools of IPv4 and provides it for free.
Regards,
Baldur
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
tor. 23. sep. 2021 01.39 skrev Colton Conor <colton.conor@gmail.com>:
Where does this "You can only have about 200-300 subscribers per IPv4 address on a CGN." limit come from? I have seen several apartment complexes run on a single static IPv4 address using a Mikrotik with NAT.
It is our observation as the limit before you regularly run out of ports using Linux as a CGN server. It will still work if you have more users on an IP. The users will just experience session failures at peak. Low levels of that might show up as pictures that fail to load on a web page and be ok when the user reloads. This will increase the number of support calls and the number of customers that asks to escape the CGN. Or people will live with it and just think that the Internet connection is low quality. Regards Baldur
On Thu, Sep 23, 2021 at 3:42 AM Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
tor. 23. sep. 2021 01.39 skrev Colton Conor <colton.conor@gmail.com>:
Where does this "You can only have about 200-300 subscribers per IPv4 address on a CGN." limit come from? I have seen several apartment complexes run on a single static IPv4 address using a Mikrotik with NAT.
It is our observation as the limit before you regularly run out of ports using Linux as a CGN server.
It will still work if you have more users on an IP. The users will just experience session failures at peak. Low levels of that might show up as pictures that fail to load on a web page and be ok when the user reloads. This will increase the number of support calls and the number of customers that asks to escape the CGN. Or people will live with it and just think that the Internet connection is low quality.
This sounds like very naive nat state management behavior. Ideally, you'd be able to maintain state of: original-src/dst/ports/proto -> in-interface/external ip/port/proto unless some internal/original src is double using port/proto ... you should really have the ability to nat quite a large number of things to a single ipv4 address. Of course as layers of nat get deeper you may lose some useful state :( you may be able to use tcp seq numbers or other items in the state though to overcome.
On Thu, 23 Sept 2021 at 21:48, Christopher Morrow <morrowc.lists@gmail.com> wrote:
This sounds like very naive nat state management behavior. Ideally, you'd be able to maintain state of: original-src/dst/ports/proto -> in-interface/external ip/port/proto
What you describe is called symmetric NAT and is the kind which has the highest impact on customers. Many NAT traversal techniques fail to work with this type of NAT. STUN does not work with symmetric NAT. You purposely want a lesser NAT type which makes NAT traversal easy. This enables more applications to function despite the NAT. Almost every CPE avoids symmetric NAT for one of the lesser types for this reason.
unless some internal/original src is double using port/proto ... you should really have the ability to nat quite a large number of things to a single ipv4 address.
There is no point in optimizing your customer per public CGN IP address ratio and multiple reasons for not doing so. At some point you will experience attacks on the CGN address or blacklisting in online games and so on. Having less customers affected each time that happens is better. In our network approximately 10% of new customers signed up within the last year have asked to escape the CGN and get a public IP. This means I need 100 IPv4 addresses per 1000 new customers. Plus 4 IPv4 addresses for the CGN server. What difference would it make if we could optimize those 4 addresses to be just 2 or maybe 1? What if it caused just a couple more customers to request a public IP address because they got annoyed by a more restrictive NAT or by failed sessions? Regards, Baldur
On Thu, Sep 23, 2021 at 4:13 PM Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On Thu, 23 Sept 2021 at 21:48, Christopher Morrow <morrowc.lists@gmail.com> wrote:
This sounds like very naive nat state management behavior. Ideally, you'd be able to maintain state of: original-src/dst/ports/proto -> in-interface/external ip/port/proto
What you describe is called symmetric NAT and is the kind which has the highest impact on customers. Many NAT traversal techniques fail to work with this type of NAT. STUN does not work with symmetric NAT.
why. (does stun/etc not work, I mean) Is the answer: "Because to do it right you need an ALG and that's more costly/problematic." or is the answer some other thing?
You purposely want a lesser NAT type which makes NAT traversal easy. This enables more applications to function despite the NAT. Almost every CPE avoids symmetric NAT for one of the lesser types for this reason.
unless some internal/original src is double using port/proto ... you should really have the ability to nat quite a large number of things to a single ipv4 address.
There is no point in optimizing your customer per public CGN IP address ratio and multiple reasons for not doing so. At some point you will experience attacks on the CGN address or blacklisting in online games and so on. Having less customers affected each time that happens is better.
Sorry, my point wasn't: "Oh you should just 1 address!" For many reasons that's crazy sauce. I was just pointing out that you'd be ABLE TO, if you wanted, sure more ips is better though. mostly the '100 ports per backend address' isn't really correct, if you are smarter in the nat state management. In our network approximately 10% of new customers signed up within the last
year have asked to escape the CGN and get a public IP. This means I need 100 IPv4 addresses per 1000 new customers. Plus 4 IPv4 addresses for the CGN server. What difference would it make if we could optimize those 4 addresses to be just 2 or maybe 1? What if it caused just a couple more customers to request a public IP address because they got annoyed by a more restrictive NAT or by failed sessions?
Regards,
Baldur
On Sep 22, 2021, at 07:47 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Owen DeLong wrote:
As mergers of ASes increases the number of announcements and IPv4 addresses were allocated a lot earlier than those of IPv6, comparing the current numbers of announcements is not meaningful. Mergers of ASes does not increase announcements in IPv4 nearly as much as slow-start and repeated expanding requests for additional IPv4 space have.
That *was* a factor, when increased number of subscribers meant more free addresses.
It’s still a factor as many providers are purchasing addresses rather than deploy CGN because they don’t want the expensive phone calls CGN causes.
Today, as /24 can afford hundreds of thousands of subscribers by NAT, only very large retail ISPs need more than one announcement for IPv4.
I fail to grasp this desire to move the majority of users from second class citizens of the network to third class all in the interests of forestalling the inevitable.
As a result, size of global routing table will keep increasing unless there are other factors to limit it. Sure, but it’s very clear that the rate of increase for IPv6 appears to be roughly 1/8th that of IPv4,
It merely means IPv6 is not deployed at all by small ISPs and multihomed sites.
Not true. Judging by the number of /48s in the table, IPv6 is relatively widely deployed by multi homed end sites and judging by the number of /32 to /40 prefixes, also widely deployed by small-iso ISPs.
The reality is that IPv4 will never be completely disaggregated into /24s
You are so optimistic.
Yes, I’ll be surprised if (e.g. Apple, HP) part out their /8s in to /24s. I’ll be surprised if a bunch of large organizations fully part out their /16s and such. I doubt any major eyeball ISPs will be significantly disbursing or disaggregating any of their large blocks any time soon. I suppose you can call that optimism. I call it realism. Frankly, the faster IPv4 fully fragments, the better because that only serves to make continuing to carry it all the more expensive, further making the case for IPv6.
and IPv6 will never be completely disaggregated into /48s, so this is actually meaningless and not predictive in any way.
That IPv6 will be disaggregated into /40 or even /32 is disastrous.
Which it won’t. It’s unlikely we will fully deploy 2000::/3 in the lifetime of anyone on this list today.
There is no need for such motivation in IPv6 and better yet,
Then, in a long run, IPv6 will be disaggregated into /32 or /40.
Not likely… Too many providers and large organizations getting /20s and /24s for that to happen.
since the two organizations have fully globally unique addresses deployed throughout their network, there's no risk of collisions in RFC-1918 space necessitating large renumbering projects to merge the networks.
You fully misunderstand why NAT is so popular today defeating IPv6.
Maybe… I certainly don’t understand why it is popular. It’s simply awful.
Even if two organizations are merged, sites of the organizations are, in general, not merged.
Seems rather pointless and counterproductive.
As private address space behind NAT is used by each site independently, there is no renumbering occur for the private addresses.
Well, as GUA would be globally unique to each site, there would be a full ability to merge the sites _AND_ no renumbering cost. Can you explain any way in which NAT is somehow better? Owen
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> writes:
That IPv6 will be disaggregated into /40 or even /32 is disastrous.
It won't. No ISPs will deaggregate anything. Some multi-site enterprises might assign a /48 per remote site from their single prefix, and want those /48s routed via some transit peers. But this does not imply that their prefix is split into the maximum number of /48s. The number of routes is limited to the number of separate network sites. There is no need to worry about this number ever exceeding the number of IPv4 prefixes. And those /48s will most likely be filtered out of the global table forever. Enterprises wanting such a configuration will depend on special transit agreements to carry and aggregate them for the rest of the world. This is not a problem. There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell. Bjørn
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell.
I don’t disagree, but a reversion to IPv4-only certainly won’t do it. I think the only way out is through. Unfortunately, the IPv6 resistant forces are making that hard for everyone else. Owen
Side question on this thread… Is it everyones current expectation that if a provider were to switch to IPv6 and drop IPv4 that the customers would all be just fine with that? I believe that there are several applications used by some of the the loudest customers (typically gamers and network gurus), not to mention some business applications that would break or be sub-optimal at best. I see CGN as the band aid to this issue, not the cure to the problem. Discuss…? - Brian
On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG <nanog@nanog.org> wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell.
I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
I think the only way out is through. Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
On Sep 23, 2021, at 12:50 , Brian Johnson <brian.johnson@netgeek.us> wrote:
Side question on this thread…
Is it everyones current expectation that if a provider were to switch to IPv6 and drop IPv4 that the customers would all be just fine with that? I believe that there are several applications used by some of the the loudest customers (typically gamers and network gurus), not to mention some business applications that would break or be sub-optimal at best. I see CGN as the band aid to this issue, not the cure to the problem.
Today? no. At some point when a relatively small number of remaining laggards among major content providers move forward? Yes. Do you really think that those applications/vendors wouldn’t move quickly if a couple of major eyeball providers announced “Effective X date”, we’re going to start offering a $X/month discount to any customer(s) who are willing to stop using IPv4. You an only cover an arterial bleed with a band-aid for so long before it becomes silly, septic even. If you’re wondering how quick that point is coming up, I suggest you check your mirrors. Owen
Discuss…?
- Brian
On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG <nanog@nanog.org> wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell.
I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
I think the only way out is through. Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
On Sep 23, 2021, at 6:49 PM, Owen DeLong <owen@delong.com> wrote:
On Sep 23, 2021, at 12:50 , Brian Johnson <brian.johnson@netgeek.us> wrote:
Side question on this thread…
Is it everyones current expectation that if a provider were to switch to IPv6 and drop IPv4 that the customers would all be just fine with that? I believe that there are several applications used by some of the the loudest customers (typically gamers and network gurus), not to mention some business applications that would break or be sub-optimal at best. I see CGN as the band aid to this issue, not the cure to the problem.
Today? no.
At some point when a relatively small number of remaining laggards among major content providers move forward? Yes.
So do we just bleed out in the mean time?
Do you really think that those applications/vendors wouldn’t move quickly if a couple of major eyeball providers announced “Effective X date”, we’re going to start offering a $X/month discount to any customer(s) who are willing to stop using IPv4.
I’d be happy to suggest this to my clients, but it’s not a real thing yet. Plus, the average human (even the average CSR at a small regional provider network) has no idea what this means.
You an only cover an arterial bleed with a band-aid for so long before it becomes silly, septic even. If you’re wondering how quick that point is coming up, I suggest you check your mirrors.
Triage suggests that you assist in succession of the current bleeding before being concerned about the next time you are cut. I have BGN deployments that have been in place for 4+ years with little customer knowledge. It has allowed clients to avoid the IPv4 market issues, and in some instances, become a source for others to help compensate for the initial CGN expense. I totally agree with you in spirit, but I am working on the problem of now, not the problem of some point in the future. The cost of CGN is becoming less expensive than IPv4 space acquisition. I wish this weren’t true.
Owen
Discuss…?
- Brian
On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG <nanog@nanog.org> wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell.
I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
I think the only way out is through. Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
On Sep 23, 2021, at 18:48 , Brian Johnson <brian.johnson@netgeek.us> wrote:
On Sep 23, 2021, at 6:49 PM, Owen DeLong <owen@delong.com> wrote:
On Sep 23, 2021, at 12:50 , Brian Johnson <brian.johnson@netgeek.us> wrote:
Side question on this thread…
Is it everyones current expectation that if a provider were to switch to IPv6 and drop IPv4 that the customers would all be just fine with that? I believe that there are several applications used by some of the the loudest customers (typically gamers and network gurus), not to mention some business applications that would break or be sub-optimal at best. I see CGN as the band aid to this issue, not the cure to the problem.
Today? no.
At some point when a relatively small number of remaining laggards among major content providers move forward? Yes.
So do we just bleed out in the mean time?
Well, you can turn off IPv4 on your network whenever you choose to do so. Unfortunately, I suspect you’re in the same boat I am there, yes, continuing to bleed until the laggards on the content side get their acts together.
Do you really think that those applications/vendors wouldn’t move quickly if a couple of major eyeball providers announced “Effective X date”, we’re going to start offering a $X/month discount to any customer(s) who are willing to stop using IPv4.
I’d be happy to suggest this to my clients, but it’s not a real thing yet. Plus, the average human (even the average CSR at a small regional provider network) has no idea what this means.
Yeah, it doesn’t mean anything there. For it to mean something, it would have to be somebody like Comcast, Cox, etc. and they’d have to put it like 2 years out, but make a big point of it with the content providers. Another thing they could do if so inclined (the really big eyeball providers) is they could start doing settlement free IPv6-only PNIs for content providers.
You an only cover an arterial bleed with a band-aid for so long before it becomes silly, septic even. If you’re wondering how quick that point is coming up, I suggest you check your mirrors.
Triage suggests that you assist in succession of the current bleeding before being concerned about the next time you are cut. I have BGN deployments that have been in place for 4+ years with little customer knowledge. It has allowed clients to avoid the IPv4 market issues, and in some instances, become a source for others to help compensate for the initial CGN expense.
I hear you. I’m not sure there’s a viable alternative, but in my experience, CGN pisses off online gamers something fierce and if you’re an eyeball ISP, I don’t envy you the phone calls that’s going to create, especially as games get more and more network-oriented. Sony already categorizes NAT into various categories and basically when it detects CGN it can’t easily penetrate or circumvent, it tells you to call your ISP and complain.
I totally agree with you in spirit, but I am working on the problem of now, not the problem of some point in the future. The cost of CGN is becoming less expensive than IPv4 space acquisition. I wish this weren’t true.
Yeah, but it’s far from zero and that’s more because IPv4 is getting more expensive than because CGN is getting cheaper. There’s only so far you can go with CGN before the user experience turns universally bad. It turns bad for a lot of customers well before that point. I don’t envy you. Owen
Owen
Discuss…?
- Brian
On Sep 23, 2021, at 10:46 AM, Owen DeLong via NANOG <nanog@nanog.org> wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell.
I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
I think the only way out is through. Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
It appears that Brian Johnson <brian.johnson@netgeek.us> said:
Side question on this thread…
Is it everyones current expectation that if a provider were to switch to IPv6 and drop IPv4 that the customers would all be just fine with that?
Try sending e-mail to AOL/Yahoo or Hotmail/Outlook over IPv6. R's, John
Owen DeLong via NANOG wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell. I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
For everyone who does have enough IPv4 addresses, it does. This is the problem in a nutshell. If that starts trending, IPv6 is done.
I think the only way out is through.
I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough. And as the trip winds on, the landscape is changing, not necessarily for the better. One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date.
Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all. Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster. Joe
On Sep 23, 2021, at 13:26 , Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong via NANOG wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell. I don’t disagree, but a reversion to IPv4-only certainly won’t do it.
For everyone who does have enough IPv4 addresses, it does. This is the problem in a nutshell. If that starts trending, IPv6 is done
This is virtually no-one with any growth. That’s why Azure, AWS, and Google have been snapping up every large prefix that comes on the market as fast as they can. I don’t see how this can possibly trend long enough to matter before it hits that brick wall. .
I think the only way out is through.
I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough.
By “the only way out is through” I meant that the only way we can get back to anything resembling mono-stack is, in fact, to complete the transition to IPv6.
And as the trip winds on, the landscape is changing, not necessarily for the better.
The IPv4 landscape will continue to get worse and worse. It cannot possibly get better, there just aren’t enough addresses for that.
One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date.
If that’s what it takes to move forward with a protocol that has enough addresses, then so be it. I’m not attached to IPv6 particularly, but I recognize that IPv4 can’t keep up. As such, IPv6 is just the best current candidate. If someone offers a better choice, I’m all for it.
Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all.
It’s not a surprise, but it is a tragedy. There are things that can be done about it, but nobody currently wants to do them.
Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster.
IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among us remain in denial about that. At some point, we are going to have to make a choice about how much longer we want to keep letting them hold us back. It will not be an easy choice, it will not be convenient, and it will not be simple. The question is how much more pain an dhow much longer will it take before the choice becomes less difficult than the wait? Owen
Owen DeLong wrote:
On Sep 23, 2021, at 13:26 , Joe Maimon <jmaimon@jmaimon.com> wrote:
I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough. By “the only way out is through” I meant that the only way we can get back to anything resembling mono-stack is, in fact, to complete the transition to IPv6.
The question is how? Waiting for everyone or nearly everyone to dual stack, the current strategy, is awful. Like pulling gum off a shoe.
And as the trip winds on, the landscape is changing, not necessarily for the better. The IPv4 landscape will continue to get worse and worse. It cannot possibly get better, there just aren’t enough addresses for that.
I was referring to the more general network landscape, the governance system, the end of p2p, balkanization, etc, all trends and shifts that become more likely and entrenched the longer IPv6 lags and the scarcer IPv4 becomes.
One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date. If that’s what it takes to move forward with a protocol that has enough addresses, then so be it. I’m not attached to IPv6 particularly, but I recognize that IPv4 can’t keep up. As such, IPv6 is just the best current candidate. If someone offers a better choice, I’m all for it.
Whose to say it would be a proper p2p system? I know you believe strongly in that and want it fully restored, at least on the protocol level.
Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all. It’s not a surprise, but it is a tragedy.
There are things that can be done about it, but nobody currently wants to do them.
So lets make the conversation revolve around what can be done to actually advance IPv6, and what we should know by now is that convincing or coercing deployment with the current state of affairs does not have enough horsepower to get IPv6 anywhere far anytime soon.
Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster. IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among us remain in denial about that.
Who is this "us"? Anybody even discussing IPv6 in a public forum is well ahead of the curve. Unfortunately. All early adopters. Real Early.
At some point, we are going to have to make a choice about how much longer we want to keep letting them hold us back. It will not be an easy choice, it will not be convenient, and it will not be simple.
The question is how much more pain an dhow much longer will it take before the choice becomes less difficult than the wait?
Owen
Exactly what does this choice look like? Turn off IPv4 when its fully functional? Only the have-nots may make the choice not to deploy IPv4 sometime in the future, and for them, its not going to be a real choice. Joe
On Sep 24, 2021, at 9:56 AM, Joe Maimon <jmaimon@jmaimon.com> wrote:
Owen DeLong wrote:
On Sep 23, 2021, at 13:26 , Joe Maimon <jmaimon@jmaimon.com> wrote:
I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough. By “the only way out is through” I meant that the only way we can get back to anything resembling mono-stack is, in fact, to complete the transition to IPv6.
The question is how? Waiting for everyone or nearly everyone to dual stack, the current strategy, is awful. Like pulling gum off a shoe.
Agreed, so the question boils down to what can be done to motivate the laggard content providers to get off the dime.
And as the trip winds on, the landscape is changing, not necessarily for the better. The IPv4 landscape will continue to get worse and worse. It cannot possibly get better, there just aren’t enough addresses for that.
I was referring to the more general network landscape, the governance system, the end of p2p, balkanization, etc, all trends and shifts that become more likely and entrenched the longer IPv6 lags and the scarcer IPv4 becomes.
One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date. If that’s what it takes to move forward with a protocol that has enough addresses, then so be it. I’m not attached to IPv6 particularly, but I recognize that IPv4 can’t keep up. As such, IPv6 is just the best current candidate. If someone offers a better choice, I’m all for it.
Whose to say it would be a proper p2p system? I know you believe strongly in that and want it fully restored, at least on the protocol level.
There are so many potential useful things we could do with a restored e2e system that are simply not proactical today that yes, I consider that vital. For one thing, I’m really tired of vendor cloud locking just because products need rendezvous hosts with public addresses.
Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all. It’s not a surprise, but it is a tragedy.
There are things that can be done about it, but nobody currently wants to do them.
So lets make the conversation revolve around what can be done to actually advance IPv6, and what we should know by now is that convincing or coercing deployment with the current state of affairs does not have enough horsepower to get IPv6 anywhere far anytime soon.
I’m open to alternatives if you have any to offer.
Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster. IPv4 is an ongoing failure slouching to disaster, but the IPv6-resistant among us remain in denial about that.
Who is this "us"? Anybody even discussing IPv6 in a public forum is well ahead of the curve. Unfortunately. All early adopters. Real Early.
Everybody using the internet, but more importantly, the content providers that are resisting IPv6 deployment on their content are probably the biggest problem at this time.
At some point, we are going to have to make a choice about how much longer we want to keep letting them hold us back. It will not be an easy choice, it will not be convenient, and it will not be simple.
The question is how much more pain an dhow much longer will it take before the choice becomes less difficult than the wait?
Owen
Exactly what does this choice look like? Turn off IPv4 when its fully functional? Only the have-nots may make the choice not to deploy IPv4 sometime in the future, and for them, its not going to be a real choice.
IPv4 hasn’t been fully functional for more than a decade. At some point, the pain of continuing to wait for the laggards will become sufficient that those who have been running dual-stack will simply turn off IPv4 and leave the laggards behind. It might tragically not happen in my lifetime, but it has to happen at some point. Owen
Oh yeah, it would be very funny if this will really happen (new protocol). Im not happy with IPv6, and it seems many others too. This is short list how my ideal IPv6 proto looks like: - 64bit address space more is not always better - loopback 0:0:0:1/48 - soft LL 0:0:1-ffff:0/32 (Link Local) - RFC1918 address space 0:1-ffff:0:0/16 - keep ARPs, ND wasnt great idea after all? - NAT support (because its everywhere these days) - IPv6 -> IPv4 interop (oneway) we can put customers on IPv6, while keeping services dualstack - correct DHCP support (SLAAC wasnt great idea after all?) I think its already in IPv6, but was an issue at the begining If there are some weird requirements from others, put them into layer up. L3 needs to be simple (KISS concept), so its easy to implement and less prone to bugs. And that IPv6 I would love to see and addapt right away :) ---------- Original message ---------- From: Joe Maimon <jmaimon@jmaimon.com> To: Owen DeLong <owen@delong.com>, Bjrn Mork <bjorn@mork.no> Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Thu, 23 Sep 2021 16:26:17 -0400 Owen DeLong via NANOG wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell. I dont disagree, but a reversion to IPv4-only certainly wont do it.
For everyone who does have enough IPv4 addresses, it does. This is the problem in a nutshell. If that starts trending, IPv6 is done.
I think the only way out is through.
I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough. And as the trip winds on, the landscape is changing, not necessarily for the better. One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date.
Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all. Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster. Joe
On 9/24/21 3:01 AM, borg@uu3.net wrote:
Oh yeah, it would be very funny if this will really happen (new protocol). Im not happy with IPv6, and it seems many others too.
Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction with the deployment / adoption of the IPv6 protocol? I think that it's a very critical distinction. Much like DoH as a protocol vs how some companies have chosen to utilize it. Similar to IBM's computers vs what they were used for in the 1940's.
This is short list how my ideal IPv6 proto looks like: - 64bit address space more is not always better - loopback 0:0:0:1/48 - soft LL 0:0:1-ffff:0/32 (Link Local) - RFC1918 address space 0:1-ffff:0:0/16 - keep ARPs, ND wasnt great idea after all? - NAT support (because its everywhere these days) - IPv6 -> IPv4 interop (oneway) we can put customers on IPv6, while keeping services dualstack - correct DHCP support (SLAAC wasnt great idea after all?) I think its already in IPv6, but was an issue at the begining
I'm probably showing my ignorance, but I believe that the IPv6 that we have today effectively does all of those things. At least functionality, perhaps with different values.
If there are some weird requirements from others, put them into layer up. L3 needs to be simple (KISS concept), so its easy to implement and less prone to bugs.
How many of the hurtles to IPv6's deployment have been bugs in layer 3? It seems to me that most of the problems with IPv6 that I'm aware of are at other layers, significantly higher in, or on top of, the stack.
And that IPv6 I would love to see and addapt right away :)
I'm of the opinion that IPv6 has worked quite well dual stack from about 2005-2015. It's only been in the last 5 or so years that I'm starting to see more problems with IPv6. And all of the problems that I'm seeing are companies making business level decisions, way above layer 7, that negatively impact IPv6. Reluctance to run an MX on IPv6 for business level decisions is definitely not a protocol, much less L3, problem. -- Grant. . . . unix || die
Well, I see IPv6 as double failure really. First, IPv6 itself is too different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine. It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had. The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;) As for details, that list is just my dream IPv6 protocol ;) But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems - IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah) - ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses. - Neighbor Discovery protocol... quite a bit problems it created. What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc - NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes And biggest problem, interop w/ IPv4 was completly failure. Currently we have best Internet to migrate to new protocol. Why? Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS. And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4. If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. The fact is, IPv6 failed. There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now. ---------- Original message ---------- From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 10:17:42 -0600 On 9/24/21 3:01 AM, borg@uu3.net wrote:
Oh yeah, it would be very funny if this will really happen (new protocol). Im not happy with IPv6, and it seems many others too.
Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction with the deployment / adoption of the IPv6 protocol? I think that it's a very critical distinction. Much like DoH as a protocol vs how some companies have chosen to utilize it. Similar to IBM's computers vs what they were used for in the 1940's.
This is short list how my ideal IPv6 proto looks like: - 64bit address space more is not always better - loopback 0:0:0:1/48 - soft LL 0:0:1-ffff:0/32 (Link Local) - RFC1918 address space 0:1-ffff:0:0/16 - keep ARPs, ND wasnt great idea after all? - NAT support (because its everywhere these days) - IPv6 -> IPv4 interop (oneway) we can put customers on IPv6, while keeping services dualstack - correct DHCP support (SLAAC wasnt great idea after all?) I think its already in IPv6, but was an issue at the begining
I'm probably showing my ignorance, but I believe that the IPv6 that we have today effectively does all of those things. At least functionality, perhaps with different values.
If there are some weird requirements from others, put them into layer up. L3 needs to be simple (KISS concept), so its easy to implement and less prone to bugs.
How many of the hurtles to IPv6's deployment have been bugs in layer 3? It seems to me that most of the problems with IPv6 that I'm aware of are at other layers, significantly higher in, or on top of, the stack.
And that IPv6 I would love to see and addapt right away :)
I'm of the opinion that IPv6 has worked quite well dual stack from about 2005-2015. It's only been in the last 5 or so years that I'm starting to see more problems with IPv6. And all of the problems that I'm seeing are companies making business level decisions, way above layer 7, that negatively impact IPv6. Reluctance to run an MX on IPv6 for business level decisions is definitely not a protocol, much less L3, problem. -- Grant. . . . unix || die
On 9/24/21 10:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really. First, IPv6 itself is too different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine. It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
But that is what ipv6 delivers -- a 64 bit routing prefix. Am I to take it that a whopping 16 bytes of extra addressing information breaks the internet? And all of the second system syndrome stuff was always separable just like any other IETF protocol. you implement what is needed and ignore all of the rest -- there is no IETF police after all. I can understand the sound and fury when people were trying to make this work on 56kb modems, but with speeds well over 1G it seems sort of archaic. Mike
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX? If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall. More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6. IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols. From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity: 1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP. There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s? In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different. -- Grant. . . . unix || die
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks? Yeah, IPv6 is new, but its more like revolution instead of evolution. Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6.. IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case. IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again? IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6... IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;) As for IPv4 vs IPv6 complexity, again, why repeat history. Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game. (Another big mistake was class E reservation...) Internet was tiny at that time so everyone followed. Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility. Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion... ---------- Original message ---------- From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600 On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX? If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall. More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6. IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity: 1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP. There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s? In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different. -- Grant. . . . unix || die
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven’t found a particularly good use for this, but it is possible. It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren’t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn’t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6. Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I’m using IPv6 DHCP. I haven’t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about… It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can’t put 128 bits of data in a 32 bit field without loss. IPv6 really isn’t so alien, so I don’t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn’t have had addresses available to experiment with or develop multicast. There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can’t parse this into a meaningful comment. Can you clarify please? What is “forced network::endpoint” supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective. I’m not trying to bash your position or you. I’m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I’d like to attempt useful education to address those. Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house? And if they change ISP they will get new range? Doesnt sounds nice to me.. But I guess I its just me Yeah I am aware of putting additional aliases on loopback. No futher comment about ND and DHCP. Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;) Hah, multicast... Ill skip it. Followed change to support CIDR, Internet was still small and considered R&D field... Okey, I think its no need to futher pollute NANOG list with this. I said at the begining that this is just my subjective opinion. This will not help IPv6 case at all. At least from my (2) standpoint it would be really cool that IPv6 would be finally addopted. I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away. ---------- Original message ---------- From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible. It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6. Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss. IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast. There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective. I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those. Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
On 28 Sep 2021, at 19:19, borg@uu3.net wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
And if they change ISP they will get new range?
Yes! What do you think DHCPv6 Prefix Delegation is all about? It has only been specified for 18 years now. The IPv6 address ranges ISP get for RIRs are based on handing out multiple /64 to every customer.
Doesnt sounds nice to me.. But I guess I its just me
It sounds like you need to do some reading about IPv6, then actually use it. 100s of millions of home customers are get routable IPv6 prefixes today around the world. It's not scary. Things don’t blow up.
Yeah I am aware of putting additional aliases on loopback.
No futher comment about ND and DHCP.
Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;)
Hah, multicast... Ill skip it.
Followed change to support CIDR, Internet was still small and considered R&D field...
Okey, I think its no need to futher pollute NANOG list with this. I said at the begining that this is just my subjective opinion. This will not help IPv6 case at all.
At least from my (2) standpoint it would be really cool that IPv6 would be finally addopted.
I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away.
---------- Original message ----------
From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible.
It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6.
Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss.
IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast.
There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective.
I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those.
Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
Do you mean, because of hole punching, "not routable" does not mean that it is "not reachable from outside"?
And if they change ISP they will get new range?
Yes!
The problem is that IPv6 was promised to perform *AUTOMATIC* *RENUMBERING*, with which, even if address ranges change, all the configuration information, including those for DNS glues, can be automatically updated. With careful design by real experts, it is possible to design such a protocol even with IPv4 but IPv6 "committee" naturally abandoned to do so with IPv6. Masataka Ohta
On Sep 28, 2021, at 08:13 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Mark Andrews wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house? Yes! Remember routable does not mean that it is reachable from outside.
Do you mean, because of hole punching, "not routable" does not mean that it is "not reachable from outside"?
And if they change ISP they will get new range? Yes!
The problem is that IPv6 was promised to perform *AUTOMATIC* *RENUMBERING*, with which, even if address ranges change, all the configuration information, including those for DNS glues, can be automatically updated.
Sure it can… That’s just software.
With careful design by real experts, it is possible to design such a protocol even with IPv4 but IPv6 "committee" naturally abandoned to do so with IPv6.
What’s missing? We already have DDNS and DHCP is already capable of doing what’s needed to update the DNS server there. If you don’t like DDNS, then there are relatively simple ways to script DNS updates for prefix changes as well. Owen
Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming? Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy routing and NATing however I want.. ---------- Original message ---------- From: Mark Andrews <marka@isc.org> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Wed, 29 Sep 2021 00:28:40 +1000
On 28 Sep 2021, at 19:19, borg@uu3.net wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
And if they change ISP they will get new range?
Yes! What do you think DHCPv6 Prefix Delegation is all about? It has only been specified for 18 years now. The IPv6 address ranges ISP get for RIRs are based on handing out multiple /64 to every customer.
Doesnt sounds nice to me.. But I guess I its just me
It sounds like you need to do some reading about IPv6, then actually use it. 100s of millions of home customers are get routable IPv6 prefixes today around the world. It's not scary. Things don˙˙t blow up.
Yeah I am aware of putting additional aliases on loopback.
No futher comment about ND and DHCP.
Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;)
Hah, multicast... Ill skip it.
Followed change to support CIDR, Internet was still small and considered R&D field...
Okey, I think its no need to futher pollute NANOG list with this. I said at the begining that this is just my subjective opinion. This will not help IPv6 case at all.
At least from my (2) standpoint it would be really cool that IPv6 would be finally addopted.
I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away.
---------- Original message ----------
From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible.
It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6.
Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss.
IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast.
There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective.
I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those.
Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Sep 29, 2021 at 4:39 AM <borg@uu3.net> wrote:
Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy routing and NATing however I want..
why of COURSE you do source address selection! so simple!
---------- Original message ----------
From: Mark Andrews <marka@isc.org> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Wed, 29 Sep 2021 00:28:40 +1000
On 28 Sep 2021, at 19:19, borg@uu3.net wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
And if they change ISP they will get new range?
Yes! What do you think DHCPv6 Prefix Delegation is all about? It has only been specified for 18 years now. The IPv6 address ranges ISP get for RIRs are based on handing out multiple /64 to every customer.
Doesnt sounds nice to me.. But I guess I its just me
It sounds like you need to do some reading about IPv6, then actually use it. 100s of millions of home customers are get routable IPv6 prefixes today around the world. It's not scary. Things don˙˙t blow up.
Yeah I am aware of putting additional aliases on loopback.
No futher comment about ND and DHCP.
Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;)
Hah, multicast... Ill skip it.
Followed change to support CIDR, Internet was still small and considered R&D field...
Okey, I think its no need to futher pollute NANOG list with this. I said at the begining that this is just my subjective opinion. This will not help IPv6 case at all.
At least from my (2) standpoint it would be really cool that IPv6 would be finally addopted.
I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away.
---------- Original message ----------
From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible.
It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6.
Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss.
IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast.
There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective.
I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those.
Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues
generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than
between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate
serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space,
64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new
IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the
itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for
part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall
tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something
into one the delta protocols that likely protocol; protocol the better pole in the that many
have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs. Owen
On Sep 29, 2021, at 07:35, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Sep 29, 2021 at 4:39 AM <borg@uu3.net> wrote: Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy routing and NATing however I want..
why of COURSE you do source address selection! so simple!
---------- Original message ----------
From: Mark Andrews <marka@isc.org> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Wed, 29 Sep 2021 00:28:40 +1000
On 28 Sep 2021, at 19:19, borg@uu3.net wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
And if they change ISP they will get new range?
Yes! What do you think DHCPv6 Prefix Delegation is all about? It has only been specified for 18 years now. The IPv6 address ranges ISP get for RIRs are based on handing out multiple /64 to every customer.
Doesnt sounds nice to me.. But I guess I its just me
It sounds like you need to do some reading about IPv6, then actually use it. 100s of millions of home customers are get routable IPv6 prefixes today around the world. It's not scary. Things don˙˙t blow up.
Yeah I am aware of putting additional aliases on loopback.
No futher comment about ND and DHCP.
Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;)
Hah, multicast... Ill skip it.
Followed change to support CIDR, Internet was still small and considered R&D field...
Okey, I think its no need to futher pollute NANOG list with this. I said at the begining that this is just my subjective opinion. This will not help IPv6 case at all.
At least from my (2) standpoint it would be really cool that IPv6 would be finally addopted.
I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away.
---------- Original message ----------
From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible.
It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6.
Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss.
IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast.
There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective.
I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those.
Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP. I have had IPv6 in my home for a long time now using multiple providers, but it definitely works with high touch admin. I don't see this as a barrier to deploy IPv6 though (don't read that into my response). But IPv6 still has a few corner cases that require some TLC. regards, Victor K
On Sep 29, 2021, at 07:35, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Sep 29, 2021 at 4:39 AM <borg@uu3.net> wrote:
Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy routing and NATing however I want..
why of COURSE you do source address selection! so simple!
---------- Original message ----------
From: Mark Andrews <marka@isc.org> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Wed, 29 Sep 2021 00:28:40 +1000
On 28 Sep 2021, at 19:19, borg@uu3.net wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
And if they change ISP they will get new range?
Yes! What do you think DHCPv6 Prefix Delegation is all about? It has only been specified for 18 years now. The IPv6 address ranges ISP get for RIRs are based on handing out multiple /64 to every customer.
Doesnt sounds nice to me.. But I guess I its just me
It sounds like you need to do some reading about IPv6, then actually use it. 100s of millions of home customers are get routable IPv6 prefixes today around the world. It's not scary. Things don˙˙t blow up.
Yeah I am aware of putting additional aliases on loopback.
No futher comment about ND and DHCP.
Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;)
Hah, multicast... Ill skip it.
Followed change to support CIDR, Internet was still small and considered R&D field...
Okey, I think its no need to futher pollute NANOG list with this. I said at the begining that this is just my subjective opinion. This will not help IPv6 case at all.
At least from my (2) standpoint it would be really cool that IPv6 would be finally addopted.
I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away.
---------- Original message ----------
From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible.
It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6.
Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss.
IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast.
There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective.
I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those.
Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues
generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than
between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate
serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space,
64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new
IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the
itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for
part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall
tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/
Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something
into one the delta protocols that likely protocol; protocol the better pole in the the that many
have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Sep 29, 2021, at 09:25, Victor Kuarsingh <victor@jvknet.com> wrote:
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org> wrote: Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
I have had IPv6 in my home for a long time now using multiple providers, but it definitely works with high touch admin. I don't see this as a barrier to deploy IPv6 though (don't read that into my response). But IPv6 still has a few corner cases that require some TLC.
It’s not high touch in my environment, but my environment goes way beyond consumer and involves ARIN assigned GUA and BGP. Not every home is the same. Owen
regards,
Victor K
On Sep 29, 2021, at 07:35, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Sep 29, 2021 at 4:39 AM <borg@uu3.net> wrote: Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy routing and NATing however I want..
why of COURSE you do source address selection! so simple!
---------- Original message ----------
From: Mark Andrews <marka@isc.org> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Wed, 29 Sep 2021 00:28:40 +1000
On 28 Sep 2021, at 19:19, borg@uu3.net wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
And if they change ISP they will get new range?
Yes! What do you think DHCPv6 Prefix Delegation is all about? It has only been specified for 18 years now. The IPv6 address ranges ISP get for RIRs are based on handing out multiple /64 to every customer.
Doesnt sounds nice to me.. But I guess I its just me
It sounds like you need to do some reading about IPv6, then actually use it. 100s of millions of home customers are get routable IPv6 prefixes today around the world. It's not scary. Things don˙˙t blow up.
Yeah I am aware of putting additional aliases on loopback.
No futher comment about ND and DHCP.
Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;)
Hah, multicast... Ill skip it.
Followed change to support CIDR, Internet was still small and considered R&D field...
Okey, I think its no need to futher pollute NANOG list with this. I said at the begining that this is just my subjective opinion. This will not help IPv6 case at all.
At least from my (2) standpoint it would be really cool that IPv6 would be finally addopted.
I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away.
---------- Original message ----------
From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible.
It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6.
Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss.
IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast.
There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective.
I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those.
Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote: > Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
> First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
> What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely > 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
> It should just fix problem (do we have other problems I am not aware of with > IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of > usage we pretty much fixed all problems we had.
I disagree.
> The second failure is adoption. Even if my IPv6 hate is not rational, adoption > of IPv6 is crap. If adoption would be much better, more IPv4 could be used for > legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
> As for details, that list is just my dream IPv6 protocol ;) > > But lets talk about details: > - Loopback on IPv6 is ::1/128 > I have setups where I need more addresses there that are local only. > Yeah I know, we can put extra aliases on interfaces etc.. but its extra > work and not w/o problems
How does IPv6 differ from IPv4 in this context?
> - IPv6 Link Local is forced. > I mean, its always on interface, nevermind you assign static IP. > LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
> - ULA space, well.. its like RFC1918 but there are some issues with it > (or at least was? maybe its fixed) like source IP selection on with > multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
> - Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
> What was wrong w/ good old ARP? I tought we fixed all those problems > already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
> - NAT is there in IPv6 so no futher comments > - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
> And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
> From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
> Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
> Because how internet become centralized. Eyeball networks just want to reach > content. E2E communication is not that much needed. We have games and > enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
> And end comment. I do NOT want to start some kind of flame war here. Yeah I > know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
> If something new popups, I want it better than previous thingie (a lot) and > easier or at least same level of complications, but IPv6 just solves one thing > and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
> The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
> There are probably multiple reasons for it. Do we ever move to IPv6? I dont > know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 9/29/21 12:22 PM, Owen DeLong via NANOG wrote:
On Sep 29, 2021, at 09:25, Victor Kuarsingh <victor@jvknet.com> wrote:
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
I think the multiple router problem is one of the things that homenet was supposed to be solving for such that it is plug and play. But I share some of your skepticism. I wonder if anybody has run an experiment wider than one or two people where the home router implements a 6-4 NAT and the default numbering is v6 instead of v4. That is, run everything that can run on v6 and NAT it to v4 on the wan side (assuming there isn't v6 there). There are lots of v6 stacks out there for all of the common OS's and supposedly they prefer v6 in a happy eyeballs race. I mean, if we have to NAT why not v6 NAT the devices that support it and v4 NAT the ones that can't. I'm not sure if Cablelabs is active with v6 -- last I heard they were pushing v6, but that's been ages -- but that would really put their money where their mouth is if it really worked well at scale. It would also give some incentive to have v6 in the last mile so you don't even need the 6-4 NAT. Didn't somebody like Comcast go to a complete v6 network internally to simplify their network? That sounds like it would push the simplification even farther. Mike
On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong <owen@delong.com> wrote:
On Sep 29, 2021, at 09:25, Victor Kuarsingh <victor@jvknet.com> wrote:
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to). I am only considering one router (consumer level stuff). Here is my example: - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a local cable service and/or DSL service, and/or xPON service - Both providers have IPv6 (competing in the market so don't cooperate on how to address, manage customer homes) - Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything anything else technical (typical consumer); They only knows how to walk into a store and buy a random thing off the shelf and ask for "WiFi". - Both providers provide IPv6 and delegate a prefix to the router (let's pretend the retail staff knew enough to sell this person a consumer box with 2x WAN interfaces) - Lets also assume the cable boxes have a consumer actionable way to force R1483 mode, and assume the DSL device can do the same (I know many providers that don't allow this type of configuration) - So this dual WAN (retail) device now has one Public IPv4 address per WAN interface (assuming one or both of the services was not disallowing bridging mode, in which case its a Private address on one or both of the WAN interfaces) - this dual wan device also gets a PD from both upstream providers which delegates to the CPE I will ignore the dual router case as that normally looks very ugly in networks as customers typically don't hook that up correctly (normally hook one box in behind the first, not in parallel). Do we think this use case just works today? Can we say we are confident we know how this all pans out in real production? e.g. CPE only uses one PD? uses both? does all the right things to support SLAAC downstream? I hate to say it, but for the IPv4 case, as ugly as NAT is, I know what happens and normally the consumer has no clue what's going on and the router just deals with it. For the IPv6 side, I am not yet confident this is all just working yet. I would like to be wrong. I can say - in my consumer mode in the US - this example above is not working by default. (I won't out the providers of course). I want the answer to be different, but there is still more work to do (especially since dual provider has become much more common due to work from home). regards, Victor K
I have had IPv6 in my home for a long time now using multiple providers, but it definitely works with high touch admin. I don't see this as a barrier to deploy IPv6 though (don't read that into my response). But IPv6 still has a few corner cases that require some TLC.
It’s not high touch in my environment, but my environment goes way beyond consumer and involves ARIN assigned GUA and BGP.
Not every home is the same.
Owen
regards,
Victor K
On Sep 29, 2021, at 07:35, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Sep 29, 2021 at 4:39 AM <borg@uu3.net> wrote:
Oh well.. Then how you gonna solve the el-cheapo SOHO multihoming?
Im currently dual homed, having 2 uplinks, RFC1918 LAN, doing policy routing and NATing however I want..
why of COURSE you do source address selection! so simple!
---------- Original message ----------
From: Mark Andrews <marka@isc.org> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Wed, 29 Sep 2021 00:28:40 +1000
On 28 Sep 2021, at 19:19, borg@uu3.net wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
Yes! Remember routable does not mean that it is reachable from outside.
And if they change ISP they will get new range?
Yes! What do you think DHCPv6 Prefix Delegation is all about? It has only been specified for 18 years now. The IPv6 address ranges ISP get for RIRs are based on handing out multiple /64 to every customer.
Doesnt sounds nice to me.. But I guess I its just me
It sounds like you need to do some reading about IPv6, then actually use it. 100s of millions of home customers are get routable IPv6 prefixes today around the world. It's not scary. Things don˙˙t blow up.
Yeah I am aware of putting additional aliases on loopback.
No futher comment about ND and DHCP.
Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;)
Hah, multicast... Ill skip it.
Followed change to support CIDR, Internet was still small and considered R&D field...
Okey, I think its no need to futher pollute NANOG list with this. I said at the begining that this is just my subjective opinion. This will not help IPv6 case at all.
At least from my (2) standpoint it would be really cool that IPv6 would be finally addopted.
I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away.
---------- Original message ----------
From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible.
It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6.
Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss.
IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast.
There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective.
I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those.
Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues
generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater
between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate
serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space,
64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new
IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with
itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for
part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall
tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/
Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something
into one than the delta protocols that likely protocol; the protocol the better pole in the the that many
have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 9/29/21 1:09 PM, Victor Kuarsingh wrote:
On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
On Sep 29, 2021, at 09:25, Victor Kuarsingh <victor@jvknet.com <mailto:victor@jvknet.com>> wrote:
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example: - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a local cable service and/or DSL service, and/or xPON service
Isn't the easier (and cheaper) thing to do here is just use a VPN to get behind the corpro firewall? Or as is probably happening more and more there is no corpro network at all since everything is outsourced on the net for smaller companies like your law firm. The use cases that stuck in my mind for the justification for the need for routing was for things like Zigbee and other low power networks where you want them isolated from the chatter of the local lan. Not saying that I agree with the justification, but that was it iirc. Mike
On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas <mike@mtcc.com> wrote:
On 9/29/21 1:09 PM, Victor Kuarsingh wrote:
On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong <owen@delong.com> wrote:
On Sep 29, 2021, at 09:25, Victor Kuarsingh <victor@jvknet.com> wrote:
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org> wrote:
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example: - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a local cable service and/or DSL service, and/or xPON service
Isn't the easier (and cheaper) thing to do here is just use a VPN to get behind the corpro firewall? Or as is probably happening more and more there is no corpro network at all since everything is outsourced on the net for smaller companies like your law firm.
For shops with IT departments, sure that can make sense. For many mom/pop setups, maybe less likely. The challenge for us (in this industry) is that we need to address not just the top use cases, but the long tail as well (especially in this new climate of more WFH). regards, Victor K
The use cases that stuck in my mind for the justification for the need for routing was for things like Zigbee and other low power networks where you want them isolated from the chatter of the local lan. Not saying that I agree with the justification, but that was it iirc.
Mike
On 9/29/21 2:23 PM, Victor Kuarsingh wrote:
On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:
On 9/29/21 1:09 PM, Victor Kuarsingh wrote:
On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
On Sep 29, 2021, at 09:25, Victor Kuarsingh <victor@jvknet.com <mailto:victor@jvknet.com>> wrote:
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote:
Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example: - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a local cable service and/or DSL service, and/or xPON service
Isn't the easier (and cheaper) thing to do here is just use a VPN to get behind the corpro firewall? Or as is probably happening more and more there is no corpro network at all since everything is outsourced on the net for smaller companies like your law firm.
For shops with IT departments, sure that can make sense. For many mom/pop setups, maybe less likely. The challenge for us (in this industry) is that we need to address not just the top use cases, but the long tail as well (especially in this new climate of more WFH).
The last startup I worked for a customer wanted audit info on our corporate network. We didn't have one. We just used various cloud based services to get our jobs done and rented cloud based vm's for the customer facing services. I would imagine that a mom/pop setup would do the same thing these days. Having a corpro network in the small probably doesn't make much sense anymore let alone the fancy multihoming scenarios to access it. There are security implications with all of this, of course, but that's probably the path of least resistance. Mike
On Sep 29, 2021, at 14:23 , Victor Kuarsingh <victor@jvknet.com> wrote:
On Wed, Sep 29, 2021 at 4:51 PM Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:
On 9/29/21 1:09 PM, Victor Kuarsingh wrote:
On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
On Sep 29, 2021, at 09:25, Victor Kuarsingh <victor@jvknet.com <mailto:victor@jvknet.com>> wrote:
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote: Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example: - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a local cable service and/or DSL service, and/or xPON service
Isn't the easier (and cheaper) thing to do here is just use a VPN to get behind the corpro firewall? Or as is probably happening more and more there is no corpro network at all since everything is outsourced on the net for smaller companies like your law firm.
For shops with IT departments, sure that can make sense. For many mom/pop setups, maybe less likely. The challenge for us (in this industry) is that we need to address not just the top use cases, but the long tail as well (especially in this new climate of more WFH).
The mom/pop law firm without an IT department probably isn’t working from home any more, they’re probably back in the office. In any case, they probably have the office “resources” they want to use for WFH in the cloud somewhere so there’s no difference in access between home and office. Owen
On Wed, 29 Sept 2021 at 22:11, Victor Kuarsingh <victor@jvknet.com> wrote:
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example:
I am afraid you are tailor making your case. We could just as well have an even more clueless customer that simply buys a 4G/5G router and attaches it to the inside of his LAN in addition to the wifi router he got from his DSL/cable/xPON service. Guess what will happen? It wont work as far as IPv4 goes but it _will_ work with IPv6. As for the tailor made case where the customer buys a device actually made for this, said device would also implement IPv6 for dual WAN. Plenty of options for how the device could do that, including the possibility of doing 1:1 stateless IPv6 NAT or simply presenting both prefixes to the LAN and source route to the correct ISP. Regards, Baldur
On Wed, Sep 29, 2021 at 5:49 PM Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On Wed, 29 Sept 2021 at 22:11, Victor Kuarsingh <victor@jvknet.com> wrote:
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example:
I am afraid you are tailor making your case. We could just as well have an even more clueless customer that simply buys a 4G/5G router and attaches it to the inside of his LAN in addition to the wifi router he got from his DSL/cable/xPON service. Guess what will happen? It wont work as far as IPv4 goes but it _will_ work with IPv6.
As for the tailor made case where the customer buys a device actually made for this, said device would also implement IPv6 for dual WAN. Plenty of options for how the device could do that, including the possibility of doing 1:1 stateless IPv6 NAT or simply presenting both prefixes to the LAN and source route to the correct ISP.
You are correct - various cases will have different results (in fact my main concern is that with consumer gear - there is quite a bit of variability in what we can expect). As for my use case, you are right, it was very specific, but that was on purpose to have a fruitful discussion (versus hand waving things). I also wanted to discuss the dual prefix item as well (which was being discussed). However it is a very real example and shows up in networks (at least in NA). I am sure we can draw a very long table of use cases with different results. Don't get me wrong, I want IPv6 to work better, I spent a lot of time implementing IPv6 in multiple networks. That said, I also don't want to ignore real common uses cases which impact customers and need to be resolved. I would like to dig into your use case a bit just so I understand. I guess in this case - you assumed the customer would hook up the LTE/5G router using LAN side ports (no WAN side port). That makes sense. I bring this up because what I had found when looking at direct network data is that most consumers serialize connecting second routers to each other (but that's a single provider use case - so I digress). In this case, when we say "it won't work". Do we mean nothing works? or that the effective result of having a redundant connection to two providers wont work. I agree that only one side, for IPv4 could work as the host would only get an address from one or the other router. This is a great use case for IPv6 in terms of the benefits for dual router situations. All that said, I do personally (because of impact on call centers and costs) differentiate outcomes where something "does not have the full intended redundancy" (but still works and gets people to the Internet) versus "can supply brokenness driving calls and IT support" (the latter is more serious in my opinion). regards, Victor K
Regards,
Baldur
On Sep 29, 2021, at 13:09 , Victor Kuarsingh <victor@jvknet.com> wrote:
On Wed, Sep 29, 2021 at 3:22 PM Owen DeLong <owen@delong.com <mailto:owen@delong.com>> wrote:
On Sep 29, 2021, at 09:25, Victor Kuarsingh <victor@jvknet.com <mailto:victor@jvknet.com>> wrote:
On Wed, Sep 29, 2021 at 10:55 AM Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote: Use SLAAC, allocate prefixes from both providers. If you are using multiple routers, set the priority of the preferred router to high in the RAs. If you’re using one router, set the preferred prefix as desired in the RAs.
Owen
I agree this works, but I assume that we would not consider this a consumer level solution (requires an administrator to make it work). It also assumes the local network policy allows for auto-addressing vs. requirement for DHCP.
It shouldn’t require an administrator if there’s just one router. If there are two routers, I’d say we’re beyond the average consumer.
In the consumer world (Where a consumer has no idea who we are, what IP is and the Internet is a wireless thing they attach to).
I am only considering one router (consumer level stuff). Here is my example: - Mr/Ms/Ze. Smith is a consumer (lawyer) wants to work from home and buy a local cable service and/or DSL service, and/or xPON service
OK, so one router or two?
- Both providers have IPv6 (competing in the market so don't cooperate on how to address, manage customer homes)
This shouldn’t be necessary with appropriate CPE, especially if Mr/Ms/Ze Smith has a single router for both.
- Mr/Ms/Ze Smith has no idea what IPv4 is, what IPv6 is or anything anything else technical (typical consumer); They only knows how to walk into a store and buy a random thing off the shelf and ask for "WiFi".
Again, assuming a single router managing both providers with a sane implementation and rational defaults, this shouldn’t be a problem. Of course, today, that isn’t really available in v4 for the most part, either.
- Both providers provide IPv6 and delegate a prefix to the router (let's pretend the retail staff knew enough to sell this person a consumer box with 2x WAN interfaces)
Let’s further pretend that the software in the box is sane about its v6 implementation and has a “primary” and “backup” port allowing it to make rational default choices about priority/preference fields in the RAs that it generates and that it defaults to SLAAC only on the LAN ports.
- Lets also assume the cable boxes have a consumer actionable way to force R1483 mode, and assume the DSL device can do the same (I know many providers that don't allow this type of configuration)
R1483 is unfamiliar to me unless you mean the RFC covering Multiprotocol Encapsulation over ATM Adaptation Layer 5. Assuming this is what you mean, let me get this straight, we’ve got a consumer who doesn’t know what IPv4 or IPv6 are, and she just wants WiFi, but she’s supposed to understand what RFC-1483 is and/or the implications of ATM Adaptation layer 5 for multi protocol encapsulation? I could be wrong, but I think that’s asking a lot. The CPE should have rational defaults for supporting the two connections, period. She shouldn’t need “consumer actionable anything” an it should be possible to just plug it in and have it work.
- So this dual WAN (retail) device now has one Public IPv4 address per WAN interface (assuming one or both of the services was not disallowing bridging mode, in which case its a Private address on one or both of the WAN interfaces)
Sure, but we really don’t care about the IPv4 thing here, that’s going to involve tragic NAT hackery and whatever. Hopefully it’s a somewhat temporary problem.
- this dual wan device also gets a PD from both upstream providers which delegates to the CPE
That’s certainly what I would expect.
I will ignore the dual router case as that normally looks very ugly in networks as customers typically don't hook that up correctly (normally hook one box in behind the first, not in parallel). Do we think this use case just works today? Can we say we are confident we know how this all pans out in real production? e.g. CPE only uses one PD? uses both? does all the right things to support SLAAC downstream?
I think that if the CPE has rational defaults (which I admit is not a given today) and truly supports IPv6 on the dual WAN ports with proper support for PD and corresponding SLAAC on the LAN ports, then yes, this should work. CPE should use both. It should create RAs with a prefix from the primary port PD as preferred,valid,on-link and the secondary port PD as valid,on-link. CPE should have no problem doing SLAAC downstream. I do not know if there are currently any routers that get this right, nor do I know if there are not. It’s almost certain there are still CPE routers that get this wrong.
I hate to say it, but for the IPv4 case, as ugly as NAT is, I know what happens and normally the consumer has no clue what's going on and the router just deals with it. For the IPv6 side, I am not yet confident this is all just working yet. I would like to be wrong. I can say - in my consumer mode in the US - this example above is not working by default. (I won't out the providers of course). I want the answer to be different, but there is still more work to do (especially since dual provider has become much more common due to work from home).
It’s a valid concern and I’m not sure what testing has been done at this level yet. I will say that it’s a not particularly common configuration even in IPv4 and the switchover when the primary ISP fails isn’t as entirely smooth as you imply. You may know exactly what to expect, but I guarantee the consumer faces at least some confusion at best in most cases. I’ll also guarantee you that when they call their ISP it’s almost certain to be a very confusing conversion on both sides of the phone, especially if they are using any of the really big providers that have call centers full of people that can’t deal with anything beyond the script they barely know how to read (if that) and the 4 or 5 buttons they’re allowed to poke to (send a it to your modem, re-flash your modem’s firmware, “test” your modem’s reachability, produce a delay to make the customer think they did something, or escalate the call to someone that will never actually call the consumer). Owen
On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said:
- Both providers provide IPv6 and delegate a prefix to the router (let's pretend the retail staff knew enough to sell this person a consumer box with 2x WAN interfaces)
So... do such boxes exist in any great quantity? Do consumers who can't add a valid number after 'IPv' accidentally contract for Internet service from two different providers often? Do they intentionally do that often? It sounds like a sufficiently rare situation that "clueless lawyer/whatever hires somebody with clue for 2 hours work to configure it all" is a reasonable solution.
On Thu, Sep 30, 2021 at 10:01 PM Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said:
- Both providers provide IPv6 and delegate a prefix to the router (let's pretend the retail staff knew enough to sell this person a consumer box with 2x WAN interfaces)
Just to make it clear, I would love it all to work really well and by default. But I also look at the reality and don't over estimate how proficient consumers will be.
So... do such boxes exist in any great quantity?
Not in great quantity. But for the fun of it, I ran down to the local BestBuy recently and they offered me a dual WAN router (only one type) in stock. So, I guess sufficient supply?
Do consumers who can't add a valid number after 'IPv' accidentally contract for Internet service from two different providers often? Do they intentionally do that often?
Likely not accidentally, but the router they showed me (will not say what brand on this list) showed a "WAN" and "WAN/DMZ" port, so just as clear as any other port markings for consumer grade connections.
It sounds like a sufficiently rare situation that "clueless lawyer/whatever hires somebody with clue for 2 hours work to configure it all" is a reasonable solution.
Yes, I suspect that may happen. How many clueful IPv6 folks do we suspect service this market which are available at a cost most will be willing to pay? regards, Victor K
On Sep 30, 2021, at 19:35 , Victor Kuarsingh <victor@jvknet.com> wrote:
On Thu, Sep 30, 2021 at 10:01 PM Valdis Klētnieks <valdis.kletnieks@vt.edu <mailto:valdis.kletnieks@vt.edu>> wrote: On Wed, 29 Sep 2021 16:09:26 -0400, Victor Kuarsingh said:
- Both providers provide IPv6 and delegate a prefix to the router (let's pretend the retail staff knew enough to sell this person a consumer box with 2x WAN interfaces)
Just to make it clear, I would love it all to work really well and by default. But I also look at the reality and don't over estimate how proficient consumers will be.
No reason it can’t. The limitations on this are not in the protocol or the specifications at this point. CPE is another matter. It’s never been particularly good at IPv4, let alone IPv6.
So... do such boxes exist in any great quantity?
Not in great quantity. But for the fun of it, I ran down to the local BestBuy recently and they offered me a dual WAN router (only one type) in stock. So, I guess sufficient supply?
How well did it handle IPv6?
Do consumers who can't add a valid number after 'IPv' accidentally contract for Internet service from two different providers often? Do they intentionally do that often?
Likely not accidentally, but the router they showed me (will not say what brand on this list) showed a "WAN" and "WAN/DMZ" port, so just as clear as any other port markings for consumer grade connections.
I’m an expert and that’s not clear to me. Which one is primary, which one is secondary? Does that second notation mean WAN and DMZ, or does it mean WAN OR DMZ? WAN+DMZ on same port seems an odd combination. OTOH, “OR” would imply a need to configure it one way or the other and for the consumer to understand the concept of a DMZ network and…
It sounds like a sufficiently rare situation that "clueless lawyer/whatever hires somebody with clue for 2 hours work to configure it all" is a reasonable solution.
Yes, I suspect that may happen. How many clueful IPv6 folks do we suspect service this market which are available at a cost most will be willing to pay?
$LAWYER won’ t blink at paying $250/hour for 2 hours of work to configure a router. I’ve done so for several of them. They also don’t blink at billing their clients much more than that per hour. Owen
On Sep 28, 2021, at 02:19 , borg@uu3.net wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
NAT is absolutely that evil after all. The presence of NAT has basically prevented a number of products that I think would have been really cool from being developed because they just aren’t practical without end to end addressing. A routable GUA for every device…Yes, yes, please yes!!! Not necessarily reachable from outside (stateful inspection can still take care of that, you don’t have to mutilate the packet headers in the process).
And if they change ISP they will get new range?
Yes. It’s all dynamic addressed anyway, so who cares?
Doesnt sounds nice to me.. But I guess I its just me
What’s the difference between keeping the same NAT’d v4 with a new public translated address and a new public address other than easier event correlation, readable audit logs, and consistency?
Yeah I am aware of putting additional aliases on loopback.
No futher comment about ND and DHCP.
Well, at a time when TCP/IP was invented, 32bit address space looked pretty much big... I dont blame them than they didnt predicted future.. Unfortunately, cant say the same about IPv6 R&D taskforce ;)
Sure, but it wasn’t expected to be a global consumer network. It was intended to be an R&D network shared primarily among the military and universities and a few other research institutions.
Hah, multicast... Ill skip it.
Followed change to support CIDR, Internet was still small and considered R&D field...
CIDR was the precursor to NAT largely as a result of the progress of the same forces that got us where we are today… The internet becoming popular among audiences it was never originally intended to reach.
I just wanted to share my toughts about why im not big fan of IPv6. I also wanted to hear other opinions what they dislike about it, no list of how cool IPv6 is and how everyone should use it right away.
Well, if you just want an IPv6 complaint fest, then you should probably go find one of the various lists dedicated to doing that. On NANOG, you’re more likely to get a balanced practical set of opinions from operators discussing both the good and the bad with a healthy dose of the recognition that IPv4 is a dead end whether people want to admit it or not. Owen
---------- Original message ----------
From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Sat, 25 Sep 2021 12:01:22 -0700
On Sep 25, 2021, at 01:57 , borg@uu3.net wrote:
Well, I think we should not compare IPX to IPv4 because those protocols were made to handle completly different networks?
Yeah, IPv6 is new, but its more like revolution instead of evolution.
Well, Industry seems to addapt things quickly when they are good enough. Better things replace worse. Of course its not always the case, sometimes things are being forced here.. And thats how I feel about IPv6..
Sometimes worse things replace better. NAT, for example was definitely not an improvement to IPv4. It was a necessary evil intended to be a temporary fix.
IPv4 Lookback is 127.0.0.1/8 You can use bind IPs within range by applications. Handy In IPv6 its not the case.
You are free to assign any additional IPv6 addresses you like to the loopback interface and then bind them to applications. Personally, I haven˙˙t found a particularly good use for this, but it is possible.
It does mean that instead of wasting 1/256th of the entire address space in every context on loopbacks, you have to assign what you need there, but you can easily assign a /64 prefix to a loopback interface and have applications bind within range.
IPv6 ND brings new problems that has been (painfully?) fixed in IPv4. Tables overflows, attacks and DDoS.. Why to repeat history again?
Table overflows weren˙˙t fixed in IPv4 and have nothing to do with ND vs. ARP. Table overflows are (not really an issue in my experience) the result of a larger address space than the memory available for the L2 forwarding table on switches or the ND table on hosts. This isn˙˙t due to a difference in ND vs. ARP. It is due to the fact that there are no 64-bit networks in IPv4, but they are commonplace in IPv6.
Mostly this has been solved in software by managing table discards more effectively.
IPv6 DHCP: Im not using IPv6, but I heard ppl talking about some issues. If this is not the case, im sorry. Its been a while when I last time played with IPv6...
I am using IPv6 and I˙˙m using IPv6 DHCP. I haven˙˙t encountered any significant problems with it other than some minor inconveniences introduced by the ability to have different DUID types and vendors doing semi-obnoxious things along that line.
IPv6 interop: yeah, I agree here.. But people involved with IPv6 should think about some external IPv4 interop.. Internet was exploding at 1997.. Maybe they had hope that everyone upgrade like in CIDR case. And maybe it could happen if IPv6 wasnt so alien ;)
It was thought about˙˙ It was considered. It was long pondered. Problem was, nobody could come up with a way to overcome the fact that you can˙˙t put 128 bits of data in a 32 bit field without loss.
IPv6 really isn˙˙t so alien, so I don˙˙t buy that argument. The software changes necessary to implement IPv6 were significantly bigger than CIDR and IPv6 affected applications, not just network. There was no way around these two facts. The IPv6 network stack did get adopted and implemented nearly as fast as CIDR and virtually every OS, Switch, Router has had IPv6 support for quite some time now at the network stack level. It is applications and content providers that are lagging and they never did anything for CIDR.
As for IPv4 vs IPv6 complexity, again, why repeat history.
What complexity?
Biggest IPv4 mistake was IPv4 being classfull. It was fixed by bringing CIDR into game.
No, biggest IPv4 mistake was 32-bit addresses. A larger address would have been inconvenient in hardware at the time, but it would have made IPv4 much more scalable and would have allowed it to last significantly longer.
(Another big mistake was class E reservation...)
Not really. It was a decision that made sense at the time. Class D reservation made sense originally too. Without it, we wouldn˙˙t have had addresses available to experiment with or develop multicast.
There was no way to know at the time that decision was made that IPv4 would run out of addresses before it would find some new thing to experiment with.
Internet was tiny at that time so everyone followed.
Followed what, exactly?
Image something like this today? Same about IPv6.. it brings forced network::endpoint probably due to IoT, sacrificing flexibility.
I can˙˙t parse this into a meaningful comment. Can you clarify please? What is ˙˙forced network::endpoint˙˙ supposed to mean and what does it have to do with IoT? What flexibility has been sacrificed?
Again, I dont want to really defend my standpoint here. Its too late for that. I kinda regret now dropping into discussion...
OK, so you want to make random comments which are not even necessarily true and then walk away from the discussion? I have trouble understanding that perspective.
I˙˙m not trying to bash your position or you. I˙˙m trying to understand your objections, figure out which ones are legitimate criticism of IPv6, which ones are legitimate criticism, but not actually IPv6, and which ones are simply factually incorrect. For the last category, I presume that comes from your lack of actual IPv6 experience or some other form of ignorance and I˙˙d like to attempt useful education to address those.
Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 14:26:27 -0600
On 9/24/21 11:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really.
I still feel like you are combining / conflating two distinct issues into one generalization.
First, IPv6 itself is too different from IPv4.
Is it? Is it really? Is the delta between IPv4 and IPv6 greater than the delta between IPv4 and IPX?
If anything, I think the delta between IPv4 and IPv6 is too small. Small enough that both IPv4 and IPv6 get treated as one protocol and thus a lot of friction between the multiple personalities therein. I also think that the grouping of IPv4 and IPv6 as one protocol is part of the downfall.
More over if you think of IPv4 and IPv6 dual stack as analogous to the multi-protocol networks of the '90s, and treat them as disparate protocols that serve similar purposes in (completely) different ways, a lot of the friction seems to make sense and as such becomes less friction through understanding and having reasonable expectations for the disparate protocols.
What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine.
I don't think you truly mean that having a new protocol is fine. Because if you did, I think you would treat IPv6 as a completely different protocol from IPv4. E.g. AppleTalk vs DECnet. After all, we effectively do have a new protocol; IPv6.
IPv6 is as similar to IPv4 as Windows 2000 is similar to Windows 98. Or "different" in place of "similar".
It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
I disagree.
The second failure is adoption. Even if my IPv6 hate is not rational, adoption of IPv6 is crap. If adoption would be much better, more IPv4 could be used for legacy networks ;) So stuborn guys like me could be happy too ;)
I blame the industry, not the IPv6 protocol, for the lackluster adoption of IPv6.
As for details, that list is just my dream IPv6 protocol ;)
But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
How does IPv6 differ from IPv4 in this context?
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah)
I agree that IPv6 addresses seem to accumulate on interfaces like IoT devices do on a network. But I don't see a technical problem with this in and of itself. -- I can't speak to OSPFv3 issues.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
I consider this to be implementation issues and not a problem with the protocol itself.
- Neighbor Discovery protocol... quite a bit problems it created.
Please elaborate.
What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
The apparent need to ""fix / address / respond to a protocol problem at a lower layer seems like a problem to me.
- NAT is there in IPv6 so no futher comments - DHCP start to get working on IPv6.. but it still pain sometimes
What problems do you have with DHCP for IPv6? I've been using it for the better part of a decade without any known problems. What pain are you experiencing?
And biggest problem, interop w/ IPv4 was completly failure.
I agree that the interoperability between IPv4 and IPv6 is the tall pole in the tent. But I also believe that's to be expected when trying to interoperate disparate protocols.
From ground zero, I would expect that disparate protocols can't interoperate without external support, some of which requires explicit configuration.
Currently we have best Internet to migrate to new protocol. Why?
The primary motivation -- as I understand it -- is the lack of unique IP addresses.
Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Now you are talking about two classes of Internet connectivity:
1) First class participation where an endpoint /is/ /on/ the Internet with a globally routed IP. 2) Second class participation where an endpoint /has/ /access/ /to/ the Internet via a non-globally routed IP.
There may be some merit to multiple classes of Internet connectivity. But I think it should be dealt with openly and above board as such.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4.
I don't view honest and good spirited discussion of facts and understanding to be a flame war. In fact, I view such discussions as a good thing.
If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity. Please elaborate on the complexity that IPv6 brings that IPv4 didn't also bring with it in the '90s?
Would the things that you are referring to as IPv6 complexities have been any different if we had started with IPv6 instead of IPv4 in the '80s & '90s?
In some ways it seems to me that you are alluding to the legacy code / equipment / understanding / configuration / what have you. This is something that many have been dealing with for quite a while. The mainframe's ability to run code from near half a century ago comes to mind.
The fact is, IPv6 failed.
I concede that IPv6 has faltered. But I don't believe it's failed. I don't think it's fair to claim that it has.
There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
You are entitled to your own opinion as much as I'm entitled to mine. But the key thing to keep in mind is that it's /your/ opinion. The operative word being "your" as in "you". Your views / opinions / experiences are /yours/. What's more important is that other people's views / opinions / experiences may be different.
-- Grant. . . . unix || die
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
in ipv6 they can. and it can have consequences, see NATting Else Matters: Evaluating IPv6 Access Control Policies in Residential Networks; Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf the ietf did not give guidance to cpe vendors to protect toys inside your LAN randy
On Tue, Sep 28, 2021 at 3:02 PM Randy Bush <randy@psg.com> wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
in ipv6 they can. and it can have consequences, see
NATting Else Matters: Evaluating IPv6 Access Control Policies in Residential Networks; Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife
https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf
the ietf did not give guidance to cpe vendors to protect toys inside your LAN
guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is likely to impact all of our security 'requirements'. :( I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet) was supposed to have provided the guidance you seek here?
On 9/28/21 1:06 PM, Christopher Morrow wrote:
On Tue, Sep 28, 2021 at 3:02 PM Randy Bush <randy@psg.com <mailto:randy@psg.com>> wrote:
> Heh, NAT is not that evil after all. Do you expect that all the home > people will get routable public IPs for all they toys inside house?
in ipv6 they can. and it can have consequences, see
NATting Else Matters: Evaluating IPv6 Access Control Policies in Residential Networks; Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife
https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf <https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf>
the ietf did not give guidance to cpe vendors to protect toys inside your LAN
guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is likely to impact all of our security 'requirements'. :( I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet <https://datatracker.ietf.org/wg/homenet>) was supposed to have provided the guidance you seek here?
What I wonder is which string the IETF has to push on to get CPE vendors to... anything. Anecdotally, I've seen firewall controls on all of the CPE I've had and no IPv6 (at least commercially). Mike
the ietf did not give guidance to cpe vendors to protect toys inside your LAN guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is likely to impact all of our security 'requirements'. :(
that point was made in the paper i cited
I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet) was supposed to have provided the guidance you seek here?
got a cite for the guidance? randy
On Tue, Sep 28, 2021 at 4:18 PM Randy Bush <randy@psg.com> wrote:
the ietf did not give guidance to cpe vendors to protect toys inside your LAN guidance aside... 'Time To Market' (or "Minimum Viable Product - MVP!) is likely to impact all of our security 'requirements'. :(
that point was made in the paper i cited
"This is a preview of subscription content, log in <https://link.springer.com/signup-login?previousUrl=https%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%252F978-3-030-72582-2_22> to check access." <paywall complaint goes here> I can see a wierdo looking image with 'port scan data', which roughly seems to say: "Hey, turn on the firewall" on all of their tested devices... and what look like 'cablelabs affiliates' mostly did the right thing with that fw policy.
I also thought 'homenet' (https://datatracker.ietf.org/wg/homenet) was supposed to have provided the guidance you seek here?
got a cite for the guidance?
sure, that's in the referenced architecture document from your link (one of the other few things I can see is the references section): 3. Chown, T., Arkko, J., Brandt, A., Troan, O., Weil, J.: IPv6 home networking architecture principles. RFC 7368, Internet Engineering Task Force (October 2014) The points about NAT in v4 being 'helpful' are sort of right, but the attacks just move up the stack[0] :( so I don't think it's particularly germaine to worry/not about nat for 'security' purposes. -chris 0: https://us.norton.com/internetsecurity-malware-malvertising.html (NOTE: I'm not a fan of norton nor any AV really, but.. the article makes the 'up the stack' point)
On 29 Sep 2021, at 05:02, Randy Bush <randy@psg.com> wrote:
Heh, NAT is not that evil after all. Do you expect that all the home people will get routable public IPs for all they toys inside house?
in ipv6 they can. and it can have consequences, see
NATting Else Matters: Evaluating IPv6 Access Control Policies in Residential Networks; Karl Olson, Jack Wampler, Fan Shen, and Nolen Scaife
https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf
the ietf did not give guidance to cpe vendors to protect toys inside your LAN
Really? RFC6092 January 2011 Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service https://datatracker.ietf.org/doc/html/rfc6092 CableLabs has similar requirements. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, Sep 28, 2021 at 10:25 PM Randy Bush <randy@psg.com> wrote:
good stuff. thanks.
The memories are all coming back now. I thought this was old news. regards, Victor K
On Tue, 28 Sept 2021 at 22:05, Randy Bush <randy@psg.com> wrote:
https://link.springer.com/content/pdf/10.1007%2F978-3-030-72582-2_22.pdf
the ietf did not give guidance to cpe vendors to protect toys inside your LAN
Luckily Amazon, Google, Apple, et.al. want to sell us products, and they noticed lack of standardisation in home automation limits the total size of the market. So we're getting a nice network protocol; thread and nice application protocol; matter to enable vendors to sell more products to us. As a side effect, we also increase security quite a bit, due to the thread network not having public addresses and will communicate only to the gateway. Many of us already have thread gateway at home, via homepod mini or google nest and increasingly so will get one. Amazing what commercially motivated standards can do in a short time, when not ran through IETF. -- ++ytti
borg@uu3.net wrote:
Well, I see IPv6 as double failure really. First, IPv6 itself is too different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine. IPv4 was extendable, with header option as one concept that was shot down in favor of a new protocol.
If it was just an incremental IPv4 upgrade, than we would have been there already, and you could be using your extended IPv4 addresses to communicate with any gear over any network gear that had been upgraded in the past decade or two. Its just that the internet was supposed to be able deploy a new protocol in the same or less time. Which didnt happen. Joe
On Sep 24, 2021, at 10:53 AM, borg@uu3.net wrote:
Well, I see IPv6 as double failure really. First, IPv6 itself is too different from IPv4. What Internet wanted is IPv4+ (aka IPv4 with bigger address space, likely 64bit). Of course we could not extend IPv4, so having new protocol is fine. It should just fix problem (do we have other problems I am not aware of with IPv4?) of address space and thats it. Im happy with IPv4, after 30+ years of usage we pretty much fixed all problems we had.
Lack of address space is a key problem with IPv4 resolved by IPv6. Lack of address transparency is another one, but that’s largely a side-effect of the hacks applied to try and (temporarily cope with the first one). (also solved by IPv6) Inability to scale routing by using topology indicators separate from addresses is a problem inherent in both IPv4 and IPv6. No, I do not consider that the various hacks that have been applied on this, including LISP, are a solution. Zeroconf in IPv4 is quite a bit less functional than in IPv6. PMTU-D is a problem in both protocols, but in some ways, not quite as bad in IPv6.
As for details, that list is just my dream IPv6 protocol ;) But lets talk about details: - Loopback on IPv6 is ::1/128 I have setups where I need more addresses there that are local only. Yeah I know, we can put extra aliases on interfaces etc.. but its extra work and not w/o problems
I haven’t had a problem assigining additional lo addresses, but whatever. I think wasting an entire /8 on loopbacks was utterly stupid. Do you have any situation where you need more than 18 quintillion loopbacks? If not, then an IPv6 /64 would be fine worst case. (0:0:0:1::/64?)
- IPv6 Link Local is forced. I mean, its always on interface, nevermind you assign static IP. LL is still there and gets in the way (OSPFv3... hell yeah) How is it in the way? It’s quite useful and utilitarian. OSPFv3 uses LL because it doesn’t want to risk having its traffic forwarded off-link and this guarantees that it won’t.
- ULA space, well.. its like RFC1918 but there are some issues with it (or at least was? maybe its fixed) like source IP selection on with multiple addresses.
Isn’t that an issue in IPv4 if you assign a host a 1918 address and a GUA on the same interface, too? Bottom line, if you have GUA, ULA is mostly pointless in most scenarios. This isn’t a problem unique to IPv6, save for the fact that you don’t usually have the option of putting GUA where you put RFC-1918 because if you have GUA, you don’t usually want 1918. So I really don’t see any difference here other than the fact that IPv6 gives you an additional choice you don’t generally have in IPv4, but that choice does come with some additional tradeoffs.
- Neighbor Discovery protocol... quite a bit problems it created. What was wrong w/ good old ARP? I tought we fixed all those problems already like ARP poisoning via port security.. etc
What are the problems you’re seeing with ND? In my experience, it mostly just works.
- NAT is there in IPv6 so no futher comments
Sadly, this is true. The good news is that hardly anyone uses it and most people doing IPv6 seem to understand that it’s a really bad idea.
- DHCP start to get working on IPv6.. but it still pain sometimes
I haven’t seen anything in DHCPv6 that is significantly harder than in IPv4 other than the need to chase the DUID format that a particular host uses in order to set up a fixed address.
And biggest problem, interop w/ IPv4 was completly failure. Currently we have best Internet to migrate to new protocol. Why? Because how internet become centralized. Eyeball networks just want to reach content. E2E communication is not that much needed. We have games and enhusiast, but those can pay extra for public IPv4. Or get VPN/VPS.
Lots of possibilities were discussed, but it boiled down to the eventual realization that there is mathematically no way to put a 128 bit address into a 32 bit field without loss of information. I bet any solution you can theorize ends up dying due to a variant of the above issue.
And end comment. I do NOT want to start some kind of flame war here. Yeah I know, Im biased toward IPv4. If something new popups, I want it better than previous thingie (a lot) and easier or at least same level of complications, but IPv6 just solves one thing and brings a lot of complexity.
I have implemented IPv6 in a lot of environments and other than the complexities around vendors doing a poor job of implementation, I haven’t encountered any complexity that I couldn’t relate to the same problem in IPv4. Can you elaborate on these supposed complexities and how they have actually impacted you in real world scenarios? Perhaps the issues you’ve encountered can be addressed in a useful way.
The fact is, IPv6 failed. There are probably multiple reasons for it. Do we ever move to IPv6? I dont know.. Do I care for now? Nope, IPv4 works for me for now.
Many of us have moved to IPv6 and for eyeball sites that have deployed it, more than 50% of most traffic flows over IPv6. I think its telling that India is at roughly 97% IPv6 deployment. By the time internet was developing in India, APNIC was mostly out of addresses. This coupled with the previous regulatory environment for internet services in India severely crippled India’s access to iPv4 addresses. I know of multiple enterprises in the US that are now deploying IPv6 at least at their edge in order to work with developers in India. India is a microcosm of what is to come in the developing world. The US is at roughly 47% IPv6 eyeballs preferred today. There is going to come a time when we start having IPv6-only eyeballs in the US and other parts of the world. How painful or problematic that becomes will depend on a large extent to how content providers react to this situation over the next few years. Owen
---------- Original message ----------
From: Grant Taylor via NANOG <nanog@nanog.org> To: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 10:17:42 -0600
On 9/24/21 3:01 AM, borg@uu3.net wrote:
Oh yeah, it would be very funny if this will really happen (new protocol). Im not happy with IPv6, and it seems many others too.
Is your dissatisfaction with the IPv6 protocol itself or is your dissatisfaction with the deployment / adoption of the IPv6 protocol?
I think that it's a very critical distinction. Much like DoH as a protocol vs how some companies have chosen to utilize it. Similar to IBM's computers vs what they were used for in the 1940's.
This is short list how my ideal IPv6 proto looks like: - 64bit address space more is not always better - loopback 0:0:0:1/48 - soft LL 0:0:1-ffff:0/32 (Link Local) - RFC1918 address space 0:1-ffff:0:0/16 - keep ARPs, ND wasnt great idea after all? - NAT support (because its everywhere these days) - IPv6 -> IPv4 interop (oneway) we can put customers on IPv6, while keeping services dualstack - correct DHCP support (SLAAC wasnt great idea after all?) I think its already in IPv6, but was an issue at the begining
I'm probably showing my ignorance, but I believe that the IPv6 that we have today effectively does all of those things. At least functionality, perhaps with different values.
If there are some weird requirements from others, put them into layer up. L3 needs to be simple (KISS concept), so its easy to implement and less prone to bugs.
How many of the hurtles to IPv6's deployment have been bugs in layer 3? It seems to me that most of the problems with IPv6 that I'm aware of are at other layers, significantly higher in, or on top of, the stack.
And that IPv6 I would love to see and addapt right away :)
I'm of the opinion that IPv6 has worked quite well dual stack from about 2005-2015. It's only been in the last 5 or so years that I'm starting to see more problems with IPv6. And all of the problems that I'm seeing are companies making business level decisions, way above layer 7, that negatively impact IPv6. Reluctance to run an MX on IPv6 for business level decisions is definitely not a protocol, much less L3, problem.
-- Grant. . . . unix || die
On Sep 24, 2021, at 2:01 AM, borg@uu3.net wrote:
Oh yeah, it would be very funny if this will really happen (new protocol). Im not happy with IPv6, and it seems many others too.
This is short list how my ideal IPv6 proto looks like: - 64bit address space more is not always better
Perhaps, but the benefits of a 128 bit address space with a convenient near universal network/host boundary has benefits. What would be the perceived benefit of 64-bit addressing over 128?
- loopback 0:0:0:1/48
Why dedicate a /48 to loopback?
- soft LL 0:0:1-ffff:0/32 (Link Local)
Having trouble understanding that expression… Wouldn’t it overlap loopback, since 0:0::/32 and 0:0:0::/48 would be overlapping prefixes?
- RFC1918 address space 0:1-ffff:0:0/16
Why repeat this mistake?
- keep ARPs, ND wasnt great idea after all?
I don’t see a significant difference (pro or con) to ND vs. ARP.
- NAT support (because its everywhere these days)
That’s a tragedy of IPv4, I don’t see a benefit to inflicting it on a new protocol.
- IPv6 -> IPv4 interop (oneway) we can put customers on IPv6, while keeping services dualstack
That requires the services to be dual stack which is kind of the problem we have with IPv6 today… Enough services that matter aren’t dual stack.
- correct DHCP support (SLAAC wasnt great idea after all?) I think its already in IPv6, but was an issue at the begining
Depends on your definition of “correct”. I disagree about SLAAC not being a great idea. It might not fit every need, but it’s certainly a low-overhead highly useful mechanism in a lot of deployments.
If there are some weird requirements from others, put them into layer up. L3 needs to be simple (KISS concept), so its easy to implement and less prone to bugs.
And that IPv6 I would love to see and addapt right away :)
Well.. Present your working prototype on at least two different systems. ;-) Owen
---------- Original message ----------
From: Joe Maimon <jmaimon@jmaimon.com> To: Owen DeLong <owen@delong.com>, Bjrn Mork <bjorn@mork.no> Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Thu, 23 Sep 2021 16:26:17 -0400
Owen DeLong via NANOG wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell. I dont disagree, but a reversion to IPv4-only certainly wont do it.
For everyone who does have enough IPv4 addresses, it does. This is the problem in a nutshell. If that starts trending, IPv6 is done.
I think the only way out is through.
I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough.
And as the trip winds on, the landscape is changing, not necessarily for the better.
One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date.
Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all.
Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster.
Joe
Because IPv4 loopback is 127.0.0.1/8 and its usefull? 0:0:1-ffff:0/32 means you generate addreses from that range and not necessary using /32 prefix.. It just range thats reserved for LL. Same about RFC1918 aka space.. its a range reserved for local addreses. The whole rationale is: - shorter prefix wins (so no overlap?) - you can use nice short addreses like ::1234 for loopback or ::1:aaaa for LL or ::1:0:1234 for RFC1918 like Whole ::1 short format should be used only to cut leading zeros not "more zeroes whatnever they appear". ND is new thing and it requires new things to protect it from attacks? While all the hate towards NAT, after years of using it I see it as cool thing now. Yeah it breaks E2E, and thats why its place is only at CPE. The true tragedy is CGN. Yeah, services make money so they should addapt new protocol, so users can access those services. In my opinion, due to IPv4 exhaustion, this is right adoption scheme. You move users to IPv6 and free IPv4 addresses for more services. It means internet can still grow and noone is really cut off. Once IPv6 mass is big enough, you can start to fade IPv4 services. Prototype yeah... if only this would be 1997 again... ;) ---------- Original message ---------- From: Owen DeLong <owen@delong.com> To: borg@uu3.net Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Fri, 24 Sep 2021 17:24:29 -0700
On Sep 24, 2021, at 2:01 AM, borg@uu3.net wrote:
Oh yeah, it would be very funny if this will really happen (new protocol). Im not happy with IPv6, and it seems many others too.
This is short list how my ideal IPv6 proto looks like: - 64bit address space more is not always better
Perhaps, but the benefits of a 128 bit address space with a convenient near universal network/host boundary has benefits. What would be the perceived benefit of 64-bit addressing over 128?
- loopback 0:0:0:1/48
Why dedicate a /48 to loopback?
- soft LL 0:0:1-ffff:0/32 (Link Local)
Having trouble understanding that expression˙˙ Wouldn˙˙t it overlap loopback, since 0:0::/32 and 0:0:0::/48 would be overlapping prefixes?
- RFC1918 address space 0:1-ffff:0:0/16
Why repeat this mistake?
- keep ARPs, ND wasnt great idea after all?
I don˙˙t see a significant difference (pro or con) to ND vs. ARP.
- NAT support (because its everywhere these days)
That˙˙s a tragedy of IPv4, I don˙˙t see a benefit to inflicting it on a new protocol.
- IPv6 -> IPv4 interop (oneway) we can put customers on IPv6, while keeping services dualstack
That requires the services to be dual stack which is kind of the problem we have with IPv6 today˙˙ Enough services that matter aren˙˙t dual stack.
- correct DHCP support (SLAAC wasnt great idea after all?) I think its already in IPv6, but was an issue at the begining
Depends on your definition of ˙˙correct˙˙. I disagree about SLAAC not being a great idea. It might not fit every need, but it˙˙s certainly a low-overhead highly useful mechanism in a lot of deployments.
If there are some weird requirements from others, put them into layer up. L3 needs to be simple (KISS concept), so its easy to implement and less prone to bugs.
And that IPv6 I would love to see and addapt right away :)
Well.. Present your working prototype on at least two different systems. ;-) Owen
---------- Original message ----------
From: Joe Maimon <jmaimon@jmaimon.com> To: Owen DeLong <owen@delong.com>, Bjrn Mork <bjorn@mork.no> Cc: nanog@nanog.org Subject: Re: IPv6 woes - RFC Date: Thu, 23 Sep 2021 16:26:17 -0400
Owen DeLong via NANOG wrote:
There are real issues with dual-stack, as this thread started out with. I don't think there is a need neither to invent IPv6 problems, nor to promote IPv6 advantages. What we need is a way out of dual-stack-hell. I dont disagree, but a reversion to IPv4-only certainly wont do it.
For everyone who does have enough IPv4 addresses, it does. This is the problem in a nutshell. If that starts trending, IPv6 is done.
I think the only way out is through.
I hope not, both for IPv6 sake and for the network users. We dont know how much longer the goal will take, there is materializing a real possibility we will never quite reach it, and the potholes on the way are pretty rough.
And as the trip winds on, the landscape is changing, not necessarily for the better.
One more "any decade now" and another IPv4 replacement/extension might just happen on the scene and catch on, rendering IPv6 the most wasteful global technical debacle to date.
Unfortunately, the IPv6 resistant forces are making that hard for everyone else.
Owen
You say that as if it was a surprise, when it should not have been, and you say that as if something can be done about it, which we should know by now cannot be the primary focus, since it cannot be done in any timely fashion. If at all.
Its time to throw mud on the wall and see what sticks. Dual stack and wait is an ongoing failure slouching to disaster.
Joe
On Sat, 25 Sept 2021 at 11:10, <borg@uu3.net> wrote:
Because IPv4 loopback is 127.0.0.1/8 and its usefull?
I am not sure why it is useful but nothing stops you from adding more loopback addresses: root@jump2:~# ip addr add ::2/128 dev lo root@jump2:~# ping6 ::2 PING ::2(::2) 56 data bytes 64 bytes from ::2: icmp_seq=1 ttl=64 time=0.043 ms While I am not sure what use extra addresses from the 127.0.0.0/8 prefix are on the loopback, it is quite common for us to add extra global addresses and then use that with proxy arp. Of course that is only necessary on IPv4 since IPv6 isn't so restrained that we have to save every last address bit using tricks.
- you can use nice short addreses like ::1234 for loopback
root@jump2:~# ip addr add ::1234/128 dev lo root@jump2:~# ping6 ::1234 PING ::1234(::1234) 56 data bytes 64 bytes from ::1234: icmp_seq=1 ttl=64 time=0.046 ms :-)
or ::1:aaaa for LL or ::1:0:1234 for RFC1918 like
With IPv6 you can use fe80::1:aaaa for link local and fd00::1:0:1234 for your RFC1918 like setup. And then you can use 1:1 NAT to transform that to GUA on the router. Even NAT, if you insist on using it, is better with IPv6. The confusion here appears to be that auto generated link local prefixes are long with many hex digits. But compared to the new proposal, which could have no auto generated link local due to having too few bits, there is nothing that stops you from manually assigning link local addresses. It is just that nobody wants to bother with that and you wouldn't either. Example: root@jump2:~# ip addr add fe80::1:aaaa/64 dev eth0 root@jump2:~# ping6 fe80::1:aaaa%eth0 PING fe80::1:aaaa%eth0(fe80::1:aaaa) 56 data bytes 64 bytes from fe80::1:aaaa: icmp_seq=1 ttl=64 time=0.033 ms
ND is new thing and it requires new things to protect it from attacks?
I am not aware of any NDP attacks that would be any different if based on ARP. Those two protocols are practically the same. Regards, Baldur
On Sep 25, 2021, at 02:10 , borg@uu3.net wrote:
Because IPv4 loopback is 127.0.0.1/8 and its usefull?
How so? Where do you actually use 16.7 million loopback addresses, let alone 18 Quitillion+ * 65536 (/48)?
0:0:1-ffff:0/32 means you generate addreses from that range and not necessary using /32 prefix.. It just range thats reserved for LL.
So you want to reserve the range 0:0:1:0..0:0:ffff:0 with all zeros in the last 16 bits as loopback? Why the (effectively discontiguous net mask)? Why not include 0:0:0:0 in it? Sorry, not trying to rain on your parade, but trying to understand your thinking here.
Same about RFC1918 aka space.. its a range reserved for local addreses.
My point was why repeat the RFC-1918 mistake. There’s really no need for it unless you intend to recreate the NAT problems. Further, you specified: 0:0:0:1/48 as loopback, that’s the range 0:0:0:0..0:0:0:ffff in your proposed addressing structure. 0:0:1-ffff:0/16 as RFC-1918, that’s an odd way of notating 0:0:0:0..0:ffff:ffff:ffff in your proposed addressing structure. As such, your meaning is unclear. So it’s unclear how you intend to map ranges and netmxasks in your proposal.
The whole rationale is: - shorter prefix wins (so no overlap?)
Usually longest matching prefix wins, but when you’re talking about the distinction between RFC-1918 and loopback, I think overlap poses a human factors problem that you haven’t considered.
- you can use nice short addreses like ::1234 for loopback or ::1:aaaa for LL or ::1:0:1234 for RFC1918 like
Not to put too fine a point on it, but ::1 works in IPv6 today. If you want, you are free to assign anything else you want on the loopback interface, so for example, you could assign fd:0:0:1::/64 to the loopback interface and use any address you want from fd:0:0:1::0 through fd:0:0:1:ffff:ffff:ffff:ffff as loopback addresses. (I don’t see a point in using GUA for loopback as long as the ULA silliness exists. In fact, this might be the one and only legitimate use case I can see for ULA.) For RFC1918, you can make up anything you want within fd::/8 in IPv6 as it exists today. Ideally, you choose a randomized /48 from fd::/8 and subnet that along /64 boundaries, but I don’t see that as significantly more complex than what I think you are proposing.
Whole ::1 short format should be used only to cut leading zeros not "more zeroes whatnever they appear".
Why? The current format allows you to put the :: wherever you think it makes the most sense and as long as there’s only one :: in an address (which is a requirement), there’s no ambiguity about the number of 0s replaced. Yes, it makes textual comparison of addresses messy, but there’s really no need for that. Far better use textual representations only for user presentation anyway. Internally, they should always be stored/handled as a 128-bit unsigned integer value. So the fact that: 2001:db8:0:1::5 2001:db8::1:0:0:0:5 Are two different ways of representing the same address isn’t of any concern unless you’re making the mistake of trying to string wise compare them in their text-representation format. Both equate to the same uint128_t value.
ND is new thing and it requires new things to protect it from attacks?
Not so much. The defined ND attacks aren’t new for ND. They all exist in ARP as well. What is new is 64-bit wide network segments. If you put a /6 on a switch in IPv4 and then do an ARP scan, you’ll get the same table overflow problems as you are talking about with “ND attacks”. The difference is that in IPv4, /6 networks are extraordinarily rare (if any exist at all) while it is commonplace in IPv6 to have /64 network segments. Nonetheless, this isn’t actually inherent in the difference between ND ad ARP, it is inherent in the difference between network segments limited to 1024 possible host addresses or less and network segments that have more than 18 Quintillion possible host addresses. In fact, if you’re really super-worried about this (which isn’t really a thing in most environments, TBH), you can create your IPv6 networks as /120s or /118s or whatever and simply limit the total number of available host addresses. You have to give up some IPv6 features that don’t exist in IPv4 anyway, but ND will still work and you won’t have to worry about table overflows any more than you did in IPv4.
While all the hate towards NAT, after years of using it I see it as cool thing now. Yeah it breaks E2E, and thats why its place is only at CPE. The true tragedy is CGN.
So making the average household a second-class citizen on the network is “cool thing now”? Not in my opinion. There are lots of applications that should exist today and don’t because we chose to break the E2E model. Of the applications that do, there is a great deal of added complexity, fragility, and a loss of privacy due to the use of rendezvous hosts to overcome the difficulties posed by NAT. Even in CPE, NAT is still harmful. CGN just makes it clear how harmful it is at an even larger scale.
Yeah, services make money so they should addapt new protocol, so users can access those services. In my opinion, due to IPv4 exhaustion, this is right adoption scheme. You move users to IPv6 and free IPv4 addresses for more services. It means internet can still grow and noone is really cut off. Once IPv6 mass is big enough, you can start to fade IPv4 services.
Yeah, that’s not really effective. What really needs to happen is moving content to IPv6 so that new users that are IPv6-only aren’t faced with a less useful internet. Moving eyeballs to IPv6 while growing content in IPv4- only land helps no-one. The content providers lose users. The users lose access to content. Owen
On Sat, 25 Sept 2021 at 21:26, Owen DeLong via NANOG <nanog@nanog.org> wrote:
So the fact that:
2001:db8:0:1::5 2001:db8::1:0:0:0:5
Are two different ways of representing the same address isn’t of any concern unless you’re making the mistake of trying to string wise compare them in their text-representation format. Both equate to the same uint128_t value.
If you adhere to RFC 5952 only the former is to be used (2001:db8:0:1::5). Also strict RFC 5952 on any output will make a string compare ok because there is only one way to print any address. We should remember there are also multiple ways to print IPv4 addresses. You can zero extend the addresses and on some ancient systems you could also use the integer value. You can even encounter IPv4 printed as IPv6 which is not too uncommon. Many programs internally are IPv6 only and IPv4 is therefore mapped to IPv6. It appears some people are forgetting this fact when proposing to drop IPv6. Regards, Baldur
On Sep 25, 2021, at 14:20 , Baldur Norddahl <baldur.norddahl@gmail.com> wrote:
On Sat, 25 Sept 2021 at 21:26, Owen DeLong via NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> wrote: So the fact that:
2001:db8:0:1::5 2001:db8::1:0:0:0:5
Are two different ways of representing the same address isn’t of any concern unless you’re making the mistake of trying to string wise compare them in their text-representation format. Both equate to the same uint128_t value.
If you adhere to RFC 5952 only the former is to be used (2001:db8:0:1::5). Also strict RFC 5952 on any output will make a string compare ok because there is only one way to print any address.
IIRC 5952 only specifies display, it does not control (and even if it purports to, depending users to comply is silly) user input.
We should remember there are also multiple ways to print IPv4 addresses. You can zero extend the addresses and on some ancient systems you could also use the integer value.
Truth.
You can even encounter IPv4 printed as IPv6 which is not too uncommon. Many programs internally are IPv6 only and IPv4 is therefore mapped to IPv6. It appears some people are forgetting this fact when proposing to drop IPv6.
Fair point. I think that ::ffff:1.2.3.4 is fine and I doubt it confuses anyone in IPv4 land much. Owen
On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said:
We should remember there are also multiple ways to print IPv4 addresses. You can zero extend the addresses and on some ancient systems you could also use the integer value.
19:17:38 0 [~] ping 2130706433 PING 2130706433 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms ^C --- 2130706433 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 84ms rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9. That's a bit more than just 'some ancient systems' - depending whether it works on other Android releases, and what IoT systems do, we may have more systems today that support it than don't support it.
On Sep 25, 2021, at 8:44 PM, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said:
We should remember there are also multiple ways to print IPv4 addresses. You can zero extend the addresses and on some ancient systems you could also use the integer value.
19:17:38 0 [~] ping 2130706433 PING 2130706433 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms ^C --- 2130706433 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 84ms rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.
That's a bit more than just 'some ancient systems' - depending whether it works on other Android releases, and what IoT systems do, we may have more systems today that support it than don't support it.
It also works on this 'ancient' macOS Monterey system. Last login: Sat Sep 25 20:50:00 on ttys000 xz4gb8 ~ % ping 2130706433 PING 2130706433 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.047 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.111 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.103 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.109 ms ^C --- 2130706433 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.047/0.092/0.111/0.026 ms xz4gb8 ~ %
Once upon a time, Andy Smith <andy@strugglers.net> said:
On Sat, Sep 25, 2021 at 08:44:00PM -0400, Valdis Klētnieks wrote:
19:17:38 0 [~] ping 2130706433
"ping 017700000001" and "ping 0x7F000001" also fun ones :)
More than once, I've had to explain why zero-filling octets, like 127.000.000.001 (which still works) or 008.008.008.008 (which does not), is broken. -- Chris Adams <cma@cmadams.net>
On Saturday, September 25, 2021 21:55 Chris Adams <cma@cmadams.net> wrote:
More than once, I've had to explain why zero-filling octets, like 127.000.000.001 (which still works) or 008.008.008.008 (which does not), is broken.
Zero filling IPv4 is just evil. How about this party trick?
% ping -c 1 010.010.010.010 PING 010.010.010.010 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=27.496 ms
--- 010.010.010.010 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 27.496/27.496/27.496/0.000 ms %
Originally, textual IPv4 addresses were maintained centrally by ISI as a file format of HOSTS.TXT, when there was no DNS and users are required to download the current most HOSTS.TXT from ISI through ftp. At that time, there can be, because of consistent central management, just one way to represent them, which is described in rfc810 as: <address> ::= <octet> "." <octet> "." <octet> "." <octet> <octet> ::= <0 to 255 decimal> Obviously, syntax was extended, at least beyond decimal, by a BSD implementation with language C. Masataka Ohta
Valdis Klētnieks wrote on 26/09/2021 01:44:
19:17:38 0 [~] ping 2130706433 PING 2130706433 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms ^C --- 2130706433 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time84ms rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.
this is a good example of "might work but don't depend on it". The fact that it works at all is a historical curiosity which happened because the text format for ipv4 addresses was never formally specified, so when some of the tcp/ip code was originally written for bsd, it accepted unusual formats in some places, including: integers, octal, hex, binary and assuming zeros when the address is incompletely specified, among other things. The octal representation was a real problem because rfc790 specified decimal dotted quad notation with leading zeros, leading to a whole bag of pain for parsers because there is no way of knowing what a leading zero means in practice, and for 3-digit numbers where each digit is <= 7, there is no a-priori way of determining whether it's octal representation or decimal. Nick
On 2021-09-19 09:20, Masataka Ohta wrote:
John Levine wrote:
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
I wasn't talking about switches and routers.
But, on routers, IPv6 costs four times more than IPv4 to look up routing table with TCAM or Patricia tree.
It is not a problem yet, merely because full routing table of IPv6 is a lot smaller than that of IPv4, which means most small ISPs and multihomed sites do not support IPv6.
Mark Andrews wrote:
There is nothing at the protocol level stopping AT&T offering a similar level of service.
Setting up reverse DNS lookup for 16B address is annoying, which may stop AT&T offering it.
Don’t equate poor implementation with the protocol being broken.
IPv6 is broken in several ways. One of the worst thing is its address length.
Masataka Ohta +1 Different scope problem: on inexpensive software BRAS solutions (PPPoE/IPoE). Enabling ipv6 just jacked up neighbour table usage and lookups cost in benchmark profiling, because now it have to keep for all users IPv6 /64 + MAC entries. Another drop is neighbor discovery on device with 10k IPOE termination vlans and privacy extensions. Also, i wonder how this changed? https://blog.bimajority.org/2014/09/05/the-network-nightmare-that-ate-my-wee... Another problem is privacy extension and IoT, they are not supported in lwip stack shipped with most of IoT SoC. As far as i see in git it is not added yet too. And SLAAC vs DHCPv6, again, first lacking some critical features, and second is often not implemented properly.
As many say - this is tiny, a drops of mess and complexities, but the ocean is made up of tiny drops. All these little things lead to the fact that very few want to mess with v6.
On Fri, 17 Sep 2021 21:15:00 -0700 Owen DeLong via NANOG <nanog@nanog.org> wrote:
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
Owen, I have nothing but respect for you, but this is a fantasy... I provide FTTx services to business and residential. I had to fight, and grind, and test for over a year to get a mix of hardware and software that would provide anything resembling IPv6 equivalent services to most of our customers. The only devices in my network that worked with few problems are my Adtran gpon/xgs-pon cards (try to find DHCPv6 option-18 support on anything else)... EVERYTHING else I used from my Juniper routers to customer CPE had to go through more rounds of testing and bug fixes than I could name - for years. I've provided static v6 services to business customers for a long time (with no takers), but dynamic, scalable residential services was very hard. There are still holes in our infrastructure because most vendors I am dealing with are doing very little to no v6 testing and still think I am a weirdo for asking for it. Every ACS vendor is either just now working on it, or thinks they have it until I point out to them that they don't. There have been some vendors that were good to work with: Juniper fixed the bugs I reported once I was able to prove to them it really was on there end (DHCPv6 relay server). ZyXel has been good to work with; they care about and fix bugs that are reported. There are also big vendors I won't work with any more because they do not have full v6 support for features I need, and they have no plans to have it. I'm not a big enough customer for them to care about what I want. I have devices with 2 year old software and zero v6 support and none is coming ever; these are not no-name vendors; they are big. People who think modern equipment is ready to provide native dual-stack services at scale to their customers are either using stuff very similar to mine, or are simply not doing it yet or have a lot of compromises. --TimH
Also, I realise I'm kinda taking your comment out of context and jumping on it to harp on my favorite pet peeve, so, yeah, sorry about that. --TimH On Sat, 18 Sep 2021 13:28:02 -0700 Tim Howe <tim.h@bendtel.com> wrote:
On Fri, 17 Sep 2021 21:15:00 -0700 Owen DeLong via NANOG <nanog@nanog.org> wrote:
Unless their infrastructure runs significantly on hardware and software pre-2004 (unlikely), so does the cost of adding IPv6 to their content servers. Especially if they’re using a CDN such as Akamai.
Owen, I have nothing but respect for you, but this is a fantasy... I provide FTTx services to business and residential. I had to fight, and grind, and test for over a year to get a mix of hardware and software that would provide anything resembling IPv6 equivalent services to most of our customers. The only devices in my network that worked with few problems are my Adtran gpon/xgs-pon cards (try to find DHCPv6 option-18 support on anything else)... EVERYTHING else I used from my Juniper routers to customer CPE had to go through more rounds of testing and bug fixes than I could name - for years.
I've provided static v6 services to business customers for a long time (with no takers), but dynamic, scalable residential services was very hard. There are still holes in our infrastructure because most vendors I am dealing with are doing very little to no v6 testing and still think I am a weirdo for asking for it. Every ACS vendor is either just now working on it, or thinks they have it until I point out to them that they don't. There have been some vendors that were good to work with: Juniper fixed the bugs I reported once I was able to prove to them it really was on there end (DHCPv6 relay server). ZyXel has been good to work with; they care about and fix bugs that are reported.
There are also big vendors I won't work with any more because they do not have full v6 support for features I need, and they have no plans to have it. I'm not a big enough customer for them to care about what I want. I have devices with 2 year old software and zero v6 support and none is coming ever; these are not no-name vendors; they are big.
People who think modern equipment is ready to provide native dual-stack services at scale to their customers are either using stuff very similar to mine, or are simply not doing it yet or have a lot of compromises.
--TimH
Saku Ytti <saku@ytti.fi> writes:
On Tue, 7 Sept 2021 at 19:51, Owen DeLong <owen@delong.com> wrote:
Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.
Fully agreed, I just don't see the driver. But I can imagine a different timeline where in 2000 several tier1 signed mutual binding contracts to drop IPv4 at the edge in 2020. And no one opposed, because 20 years before was 1980, and 20 years in the future IPv4 wont' anymore be a thing, it's clear due to exponential growth.
And we'd all be enjoying a much simplified stack and lower costs all around (vendor, us, customers).
I started wondering if there are areas where we can disable IPv4 today. Ideas like Tore documented in RFC 7755 are certainly possible without any negative effects, and hopefully with reduced costs compared to a full dual-stack environment. But it is still based on the assumption that any interface facing the Internet must be dual-stack. The next thought was SMTP and authoritative DNS servers. Running IPv6 only in a real production environment should be possible as long as you keep IPv4 on at least one of the servers. But you don't have to look far before you hit snags like this: https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/ So although I techincally could run IPv6 only on all but one of the DNS servers, this would violate current policy. Oddly enough, running IPv4 only on all servers is allowed. Go figure.
Why is this not possible now? Why would we not sign this mutual agreement for 2040? Otherwise we'll be having this same discussion in 2040.
Signing such a contract would be pretty stupid from a commercial pov. The growth isn't exponential anymore. It's linear at best. You can probably run just fine with an IPv4 only network after 2040. Not so sure about the IPv6 only network. Bjørn
On Wed, 8 Sept 2021 at 11:24, Bjørn Mork <bjorn@mork.no> wrote:
Signing such a contract would be pretty stupid from a commercial pov. The growth isn't exponential anymore. It's linear at best. You can probably run just fine with an IPv4 only network after 2040. Not so sure about the IPv6 only network.
This is probably true for large segment of eyeballs. But stakeholders like tier1, cdn and cloudyshops have customer demand for ipv4+ipv6. So they'd all be able to capitalise on ipv4 going away. And if the small, mid size eyeballs knew ipv4 is going away in 10, 15, 20 years whichever it is, then they'd of course have to start moving too, because no upstream. -- ++ytti
Sent using a machine that autocorrects in interesting ways...
On Sep 8, 2021, at 1:31 AM, Saku Ytti <saku@ytti.fi> wrote:
If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years whichever it is, then they'd of course have to start moving too, because no upstream.
And they would fight it tooth and nail, just like they do now, and if they found an address they could NAT to, they would argue that that one address gave them the ability to avoid the transition -just like they do now.
On Sep 11, 2021, at 9:04 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
Sent using a machine that autocorrects in interesting ways...
On Sep 8, 2021, at 1:31 AM, Saku Ytti <saku@ytti.fi> wrote:
If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years whichever it is, then they'd of course have to start moving too, because no upstream.
And they would fight it tooth and nail, just like they do now, and if they found an address they could NAT to, they would argue that that one address gave them the ability to avoid the transition -just like they do now.
Speaking for the smaller providers, there is enough of the Internet that is only accessible via IPv4 out there that CGN solutions are a reasonable way to manage the situation. There is also enough legacy equipment out there that doesn’t accommodate IPv6 that this process will still take several decades. Edicts never work. More carrot, less stick.
On Sep 12, 2021, at 11:35 , Brian Johnson <brian.johnson@netgeek.us> wrote:
On Sep 11, 2021, at 9:04 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote:
Sent using a machine that autocorrects in interesting ways...
On Sep 8, 2021, at 1:31 AM, Saku Ytti <saku@ytti.fi> wrote:
If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years whichever it is, then they'd of course have to start moving too, because no upstream.
And they would fight it tooth and nail, just like they do now, and if they found an address they could NAT to, they would argue that that one address gave them the ability to avoid the transition -just like they do now.
Speaking for the smaller providers, there is enough of the Internet that is only accessible via IPv4 out there that CGN solutions are a reasonable way to manage the situation. There is also enough legacy equipment out there that doesn’t accommodate IPv6 that this process will still take several decades.
Edicts never work. More carrot, less stick.
They did with ATSC. Owen
If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years whichever it is, then they'd of course have to start moving too, because no upstream.
And they would fight it tooth and nail, just like they do now
you speak as if it was religion or they are bad people. neither is the case. it is what they see as their best business interest. being from the pacific northwest, i have learned not to try to push water uphill. so, until we can tilt the hill, it's probably bast for one's health if one gets over it. randy
On 9/12/21 1:08 PM, Randy Bush wrote:
If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years whichever it is, then they'd of course have to start moving too, because no upstream. And they would fight it tooth and nail, just like they do now you speak as if it was religion or they are bad people. neither is the case. it is what they see as their best business interest.
being from the pacific northwest, i have learned not to try to push water uphill. so, until we can tilt the hill, it's probably bast for one's health if one gets over it.
If vendors actually cared they could make the CGNAT's and other hacks ridiculously buggy and really expensive to deploy and maintain. I doubt many vendors were chomping at the bit to support CGNAT and are probably wondering what fresh hell is next to keep ipv4 limping along. Mike
On 9/12/21 4:59 PM, Randy Bush wrote:
I doubt many vendors were chomping at the bit to support CGNAT definitely. they hate to sell big expensive boxes.
Back in the early 2000's the first rumblings of what would eventually turn into CGN started popping up at Cablelabs. I went to the EVP of Service Provider and basically told him that he had a choice between that mess or developing ipv6. I doubt he was interested in doing anything at all, but he chose ipv6, at least in the abstract. Steve Deering and I then went around to all of the BU's trying to figure out what it would take for them to implement ipv6 in the routing plane. Cablelabs was also pretty ipv6-focused too making a similar calculation. So no, they weren't interested in it either. They were completely driven by what the providers wanted and what a large group of providers have since made pretty clear is that horrible hacks are fine by them if it gets them out of a short term bind. But it's hardly uniform across the industry. This is a classic reverse-tragedy of the commons. Mike
On 9/13/21 02:16, Michael Thomas wrote:
But it's hardly uniform across the industry. This is a classic reverse-tragedy of the commons.
The problem is it's uniform in the corners that contain scale and the money to make a difference at vendor-land. 7 million mom & pop ISP's vs. 10 large mobile operators... yeah, $vendor will struggle to make that decision :-). Mark.
< rant > ipv6 was designed at a time where the internet futurists/idealists had disdain for operators and vendors, and thought we were evil money grabbers who had to be brought under control. the specs as originally RFCed by the ietf is very telling. for your amusement, take a look at rfc 2450. it took five years of war to get rid of the tla/sla crap. and look at the /64 religion today[0]. real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space. we are left to make the mess work for the users, while being excoriated for not doing it quickly or well enough, and for trying to make ends meet financially. randy, trying to deal with the mess since the early '90s --- [0] https://datatracker.ietf.org/doc/html/draft-bourbaki-6man-classless-ipv6-05
Randy Bush wrote on 13/09/2021 19:22:
the specs as originally RFCed by the ietf is very telling. for your amusement, take a look at rfc 2450. it took five years of war to get rid of the tla/sla crap. and look at the /64 religion today[0].
architectural decisions were made because of a mixture of actual and perceived problems at the time, but several of the outcomes make little sense now or in some cases, actively cause problems. E.g. using mcast for address resolution because large flat l2 networks were the order of the day, that "privacy addresses" would give privacy, that client self-selected addresses should be the only game in town for auto-addressing (it took years to get any form of dhcp through), that extension headers were a great idea, that "transition mechanisms" would be viable for fundamentally incompatible protocols, etc. That said, it's easy to be critical of design decisions with 25y of hindsight, and even easier to understate how difficult it is to dislodge ipv4 which took 40 years of evolution to cement itself into its current position. Nick
Nick Hilliard wrote:
E.g. using mcast for address resolution because large flat l2 networks were the order of the day,
It was and still is trivially obvious that automatic address resolution over large flat l2 does not scale. Configuring virtual all-host-mcast in large flat l2 for automatic address resolution needs static address resolution information, which is not automatic.
that client self-selected addresses should be the only game in town for auto-addressing
Using lengthy MAC addresses for that purpose was tried in XNS. But as it was so annoying, it was totally abandoned at the time IPv4 was widely developed. Though AppleTalk was still using a single byte for that purpose in SOHO, DHCP was already performing better everywhere including SOHO.
that extension headers were a great idea,
IPv4 optional header was totally operationally denied a lot before that. Masataka Ohta
On Mon, Sep 13, 2021 at 8:22 PM Randy Bush <randy@psg.com> wrote:
real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space.
What I find most peculiar about this whole rant (not just yours but the whole thread) is that I may be the only one who found implementing IPv6 with dual stack completely trivial and a non issue? There is no scale issue nor any of the other rubbish. Some say what we have is not a true dual stack setup because we run MPLS and the IPv6 mostly lives inside L2VPN or L3VPN tunnels. Most of our network gear has no idea what an IPv6 address is. But neither does that equipment touch the public IPv4 internet. Nevertheless we configure our IPv4 and IPv6 both only on our few edge Juniper MX devices and that is it. I do not believe IPv6 has 100 config lines in my network total. For all I care we already have a perfect working system with IPv4+CGN+IPv6. The CGN part was the most troublesome, not the IPv6. Regards, Baldur
In resource challenged regions we have been using IPv4+CGN+IPv6 dual stack for the last ten or so years. For 20K subs you can use one /24 of ipv4 and a /40 or so of ipv6. There have been available RGW’s and sufficient vendor support throughout this time. The only issues I have ever really seen have been with Sony PSN doing random ipv4 /32 blocks. Apart from that it has been working just fine. Over 50% of traffic now flows on the V6 side and in general end customers have no clue, it just works.
For all I care we already have a perfect working system with IPv4+CGN+IPv6. The CGN part was the most troublesome, not the IPv6.
Baldur Norddahl wrote:
On Mon, Sep 13, 2021 at 8:22 PM Randy Bush <randy@psg.com <mailto:randy@psg.com>> wrote:
real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space.
What I find most peculiar about this whole rant (not just yours but the whole thread) is that I may be the only one who found implementing IPv6 with dual stack completely trivial and a non issue? There is no scale issue nor any of the other rubbish.
Baldur
The essential point is that your dual stack is barely relevant until every stack is dual. Which is impossible without CGNAT. It also turns out that is barely relevant how easy it may have been for you. Joe
On 9/13/21 2:52 PM, Baldur Norddahl wrote:
On Mon, Sep 13, 2021 at 8:22 PM Randy Bush <randy@psg.com <mailto:randy@psg.com>> wrote:
real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space.
What I find most peculiar about this whole rant (not just yours but the whole thread) is that I may be the only one who found implementing IPv6 with dual stack completely trivial and a non issue? There is no scale issue nor any of the other rubbish.
I agree on the host side. It didn't even occur to me at the time I was looking at it that it would be any sort of issue -- we had all kinds of other protocols on our boxes like SMB, Netware, DEC LAT, etc. We would have done it if customers told us they wanted it, just like we implemented ACL's not realizing why they were especially important. Back in the early days all routing was done in software so it wouldn't have been hard to squeeze v6 in. All of that changed when the forwarding plane got cast in silicon though which made it far, far more difficult to get anybody to stick their necks out vs a skunk works software project. But before that it would have been completely doable if somebody was willing to throw money at it. Mike
On 9/13/21 11:22 AM, Randy Bush wrote:
< rant >
ipv6 was designed at a time where the internet futurists/idealists had disdain for operators and vendors, and thought we were evil money grabbers who had to be brought under control.
the specs as originally RFCed by the ietf is very telling. for your amusement, take a look at rfc 2450. it took five years of war to get rid of the tla/sla crap. and look at the /64 religion today[0].
real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space.
we are left to make the mess work for the users, while being excoriated for not doing it quickly or well enough, and for trying to make ends meet financially.
This is really easy to say in hindsight. 30 years ago it wasn't even vaguely a given that the Internet would even win and the size of the IP universe was still tiny. The main problem is that the internet was a classic success disaster where you're going as fast as possible and falling farther and farther behind. All of the gripes about particulars strike me as utterly irrelevant in the global scheme of things. As I mentioned, if they did nothing more than bolted on two more address bytes it still would have been just as impossible to get vendors and providers to care because everybody was heads down trying to deal with the success disaster. It's really easy to say that ipv6 suffers from second system syndrome -- which it does -- but that doesn't provide any concrete strategy for what would have been "better" in both getting vendors and providers to care. None of them wanted to do anything other than crank out kit that could be sold in the here and now that providers were willing to buy. That was certainly my experience at Cisco. As I said, the exec I talked to didn't actually want to do anything at all but was willing to let a couple of engineers navel gaze if it gave him something to talk about were the subject to actually come up with customers and a bludgeon against 3COM (iirc) at the time. None of this is technical. It was which short term hack is going to keep the gravy train flowing? I was a developer at the time keeping an eye on the drafts as they were coming out. They didn't strike me was overly difficult to implement nor did they strike me as particularly overwrought. From a host standpoint, i didn't think it would take too much effort to get something up and running but I waited until somebody started asking for it. That never came. Nothing ever came. Then NAT's came and kicked the can down the roads some more. Now we have mega-yacht NAT's to kick it down the road even farther. Tell us what else would have prevented that? Mike
On 13.09.21 20:22, Randy Bush wrote:
< rant >
ipv6 was designed at a time where the internet futurists/idealists had disdain for operators and vendors, and thought we were evil money grabbers who had to be brought under control.
and...
<snip>
real compatibility with ipv4 was disdained.
I'm not claiming IPv6 is any sort of perfect, but let's not revise history. To quote Lee Hayes' adaptation of Will Rogers: “Things aren't what they used to be, what's more they never were.” There were four proposals for the IPng: * NIMROD, PIP, SIP, and TUBA SIP was the one that was chosen, supported by endpoint manufacturers such as Sun and SGI, and it was the MOST compatible. Operators and router manufacturers at the time pushed TUBA, which was considerably less compatible with the concepts used in v4 because of variable length addressing. If we endpoints had some notion that v6 would take as long as it has to diffuse, perhaps we all might have thought differently. I don't know. There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely. There are many reasons v6 has taken this long to deploy, but one prediction model (Elmore/Camp) dating back to 2008 have said it would take to the end of the century to get to 80%, barring a paradigm shift. We may have that paradigm shift with IoT, but the jury is still out. Eliot
and 8+8, variable length, ... just didn't happen, eh? the nice thing about revisionist history is that anybody can play. randy
8+8 came *MUCH* later than that, and really wasn't ready for prime time. The reason we know that is that work was the basis of LISP and ILNP. Yes, standing on the shoulders of giants. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh. On 14.09.21 14:10, Randy Bush wrote:
and 8+8, variable length, ... just didn't happen, eh?
the nice thing about revisionist history is that anybody can play.
randy
On 9/14/21 5:37 AM, Eliot Lear wrote:
8+8 came *MUCH* later than that, and really wasn't ready for prime time. The reason we know that is that work was the basis of LISP and ILNP. Yes, standing on the shoulders of giants. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh.
I wasn't there at actual meetings at the time but I find the notion that operators were ignored pretty preposterous too. There was a significant amount of bleed over between the two as I recall from going to Interop's. What incentive do vendors have to ignore their customers? Vendors have incentive to listen to customer requirements and abstract them to take into account things can't see on the outside, but to actually give the finger to them? And given how small the internet community was back while this was happening, I find it even more unlikely. But Randy still hasn't told us what would have worked and why it would have succeeded. Mike
On 14.09.21 14:10, Randy Bush wrote:
and 8+8, variable length, ... just didn't happen, eh?
the nice thing about revisionist history is that anybody can play.
randy
On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com> wrote:
On 9/14/21 5:37 AM, Eliot Lear wrote:
8+8 came MUCH later than that, and really wasn't ready for prime time. The reason we know that is that work was the basis of LISP and ILNP. Yes, standing on the shoulders of giants. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh.
I wasn't there at actual meetings at the time but I find the notion that operators were ignored pretty preposterous too. There was a significant amount of bleed over between the two as I recall from going to Interop's. What incentive do vendors have to ignore their customers? Vendors have incentive to listen to customer requirements and abstract them to take into account things can't see on the outside, but to actually give the finger to them? And given how small the internet community was back while this was happening, I find it even more unlikely.
You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn. Owen
On 9/14/21 1:06 PM, Owen DeLong wrote:
On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:
On 9/14/21 5:37 AM, Eliot Lear wrote:
8+8 came *MUCH* later than that, and really wasn't ready for prime time. The reason we know that is that work was the basis of LISP and ILNP. Yes, standing on the shoulders of giants. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh.
I wasn't there at actual meetings at the time but I find the notion that operators were ignored pretty preposterous too. There was a significant amount of bleed over between the two as I recall from going to Interop's. What incentive do vendors have to ignore their customers? Vendors have incentive to listen to customer requirements and abstract them to take into account things can't see on the outside, but to actually give the finger to them? And given how small the internet community was back while this was happening, I find it even more unlikely.
You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.
But we're talking almost 30 years ago when the internet was tiny. And it's not like operators were some fount of experience and wisdom back then: everybody was making it up along the way including operators which barely even existed back then. I mean, we're talking about the netcom days here. That's why this stinks of revisionist history to me. Mike
On Sep 14, 2021, at 13:51 , Michael Thomas <mike@mtcc.com> wrote:
On 9/14/21 1:06 PM, Owen DeLong wrote:
On Sep 14, 2021, at 12:58 , Michael Thomas <mike@mtcc.com <mailto:mike@mtcc.com>> wrote:
On 9/14/21 5:37 AM, Eliot Lear wrote:
8+8 came MUCH later than that, and really wasn't ready for prime time. The reason we know that is that work was the basis of LISP and ILNP. Yes, standing on the shoulders of giants. And there certainly were poor design decisions in IPv6, bundling IPsec being one. But the idea that operators were ignored? Feh.
I wasn't there at actual meetings at the time but I find the notion that operators were ignored pretty preposterous too. There was a significant amount of bleed over between the two as I recall from going to Interop's. What incentive do vendors have to ignore their customers? Vendors have incentive to listen to customer requirements and abstract them to take into account things can't see on the outside, but to actually give the finger to them? And given how small the internet community was back while this was happening, I find it even more unlikely.
You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.
But we're talking almost 30 years ago when the internet was tiny. And it's not like operators were some fount of experience and wisdom back then: everybody was making it up along the way including operators which barely even existed back then. I mean, we're talking about the netcom days here. That's why this stinks of revisionist history to me.
I was there for parts of it. Even then, the vendors were entrenched in their views and dominated many of the conversations. Owen
On 9/14/21 2:07 PM, Owen DeLong wrote:
You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.
But we're talking almost 30 years ago when the internet was tiny. And it's not like operators were some fount of experience and wisdom back then: everybody was making it up along the way including operators which barely even existed back then. I mean, we're talking about the netcom days here. That's why this stinks of revisionist history to me.
I was there for parts of it. Even then, the vendors were entrenched in their views and dominated many of the conversations.
Vendors have to be able to implement things so of course there is going to be push back when it's not technically feasible or far more expensive. Nobody expects customers putting out the actual $$$ to be up to speed on the intricacies of TCAM's and other such considerations so there is always going to be back and forth. And none of this alters that nobody has given a scenario where their $SOLUTION would have fared any better than ipv6. Mike
On Sep 14, 2021, at 14:20 , Michael Thomas <mike@mtcc.com> wrote:
On 9/14/21 2:07 PM, Owen DeLong wrote:
You’d be surprised… Vendors often get well down a path before exposing enough information to the community to get the negative feedback their solution so richly deserves. At that point, they have rather strong incentives to push for the IETF adopting their solution over customer objections because of entrenched code-base and a desire not to go back and explain to management that the idea they’ve been working on for the last 6 months is stillborn.
But we're talking almost 30 years ago when the internet was tiny. And it's not like operators were some fount of experience and wisdom back then: everybody was making it up along the way including operators which barely even existed back then. I mean, we're talking about the netcom days here. That's why this stinks of revisionist history to me.
I was there for parts of it. Even then, the vendors were entrenched in their views and dominated many of the conversations.
Vendors have to be able to implement things so of course there is going to be push back when it's not technically feasible or far more expensive. Nobody expects customers putting out the actual $$$ to be up to speed on the intricacies of TCAM's and other such considerations so there is always going to be back and forth.
Back and forth is one thing, but the reality is that they put a lot of development effort into things in a vacuum and then expected us to take what they built and standardize it. They often seemed utterly surprised when the practical realities of deploying it in an operational network didn’t agree with their idea of an “elegant” solution.
And none of this alters that nobody has given a scenario where their $SOLUTION would have fared any better than ipv6.
That’s probably fair criticism to some extent. Owen
Just because I didn't attend IETF meetings doesn't mean that I didn't read drafts, etc. Lurkers are a thing and lurkers are allowed opinions too.
i missed the rfc where the chair of the v6 wg said the ops did not understand the h ratio because we did not understand logarithms. <plonk> randy
On 9/14/21 2:17 PM, Randy Bush wrote:
Just because I didn't attend IETF meetings doesn't mean that I didn't read drafts, etc. Lurkers are a thing and lurkers are allowed opinions too. i missed the rfc where the chair of the v6 wg said the ops did not understand the h ratio because we did not understand logarithms.
So in order to have an opinion, I have to know all of the politics along with the documents produced. Got it. Thank goodness we didn't know that when we were implementing IPv4 in the mid 80's. Frankly I had always regretted not going to an IETF meeting at ISI around 88 or so, but given the silliness of IETF politics maybe that was a blessing. Mike
The 600 ton elephant in the room is anyone could right now sit down and design and deploy some alternative to IPv4/IPv6 and from there begin writing down how they did it as a series of standards documents and encourage others to give it a try hoping for some snowball effect. You just float it on top of the current probably IP layer tho there are other possibilities, not too many (pick a layer.) What much of the muttering is about is people (who never do things like this) tend to be risk-averse and want someone or something on high to bless and nurture their efforts. That's what much of this discussion about some alternative to IPv6 comes down to, risk aversion, how do you know if you sat down and began working out an alternative you'd be rewarded for your efforts. You Don't! Imagine if Linus Torvalds sat waiting for the POSIX committees et al to take up his ideas for an alternative to Unix (TM). He'd still be waiting. Probably one of the worst problems with IPv6 is precisely the fact that groups of people managed to ride directly on the then rapid growth of IPv4 and turn out whatever a dozen or so strangers in windowless hotel rooms and some email lists could agree on, including all sorts of vested interests (e.g., router vendors and the big tech of the day.) Clearly it wasn't completely insidious, it all kind of works, it's just that there's been a lot of resistance to adoption hence a sense that something's wrong. The world is your oyster (TheWorld is mine :-)). P.S. One might want to keep in mind a quote often attributed to Bill Joy (one of the founders of Sun Microsystems, and a lot of other stuff), roughly: In order for a new technology to succeed it has to be ten times better than what it seeks to replace (i.e., to overcome incumbency and inertia.) -- -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 Sep 15, 2021, at 2:20 PM, bzs@theworld.com wrote: Hi,
The 600 ton elephant in the room is anyone could right now sit down and design and deploy some alternative to IPv4/IPv6 and from there begin writing down how they did it as a series of standards documents and encourage others to give it a try hoping for some snowball effect.
Isn't that how 6RD (RFC5969) was created? Thanks, Sabri
On September 15, 2021 at 15:40 sabri@cluecentral.net (Sabri Berisha) wrote:
----- On Sep 15, 2021, at 2:20 PM, bzs@theworld.com wrote:
Hi,
The 600 ton elephant in the room is anyone could right now sit down and design and deploy some alternative to IPv4/IPv6 and from there begin writing down how they did it as a series of standards documents and encourage others to give it a try hoping for some snowball effect.
Isn't that how 6RD (RFC5969) was created?
Thanks,
Sabri
One could use a similar approach tho probably an entire routing infrastructure would also need to be simulated. It wouldn't just be sneaking a packet from here to there, it would be the emulation of an entire network most likely. Hard to say w/o a design spec :-) But at the end of the day it's just bits. -- -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*
Eliot Lear wrote:
Operators and router manufacturers at the time pushed TUBA, which was considerably less compatible with the concepts used in v4 because of variable length addressing.
That address length is variable is not a problem at all. Byte-wise barrel shifters by hardware for CLNP are trivially easy and light weight to implement. The real problem is on the number of prefix bits which must be looked up by backbone routers, which means IPv6 abandoning TLA is hopeless. NSAP addresses, which essentially are telephone numbers, assume geographically aggregated addresses at country level (so called, country code), which is why they don't need large global routing tables. 8+8 has nothing to do with the problem and LISP came a lot later as a broken solution for the problem. Masataka Ohta
On Tue, Sep 14, 2021 at 10:03 AM Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
NSAP addresses, which essentially are telephone numbers, assume geographically aggregated addresses at country level (so called, country code), which is why they don't need large global routing tables.
The phone network doesn't really operate or 'route' in the same way as the Internet does. I don't think using it in a comparison here works, at all... I really wish folk would stop trying to make this equivalency. (I think LNP actually means the phone carriers are creating a 'must know about 6+b address/path mappings in a possible future... or even just in the US ~350m endpoints/mappings, but anyways...)
Christopher Morrow wrote:
NSAP addresses, which essentially are telephone numbers, assume geographically aggregated addresses at country level (so called, country code), which is why they don't need large global routing tables.
The phone network doesn't really operate or 'route' in the same way as the Internet does.
The context here is TUBA where NSAP addresses are used for best effort CLNP, which is not circuit switched and resource reserving phone network.
I don't think using it in a comparison here works, at all... I really wish folk would stop trying to make this equivalency.
That you don't properly understand the similarities and the differences between telephone network and the Internet is not a problem for rest of us. Masataka Ohta
But in fact with local number portability, you cannot rely on the county code to tell you where to route a telephone call anymore. Which is many calls result in a data dip to provide you the routing information from a central repository. Shane On Tue, Sep 14, 2021 at 10:07 AM Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
Eliot Lear wrote:
Operators and router manufacturers at the time pushed TUBA, which was considerably less compatible with the concepts used in v4 because of variable length addressing.
That address length is variable is not a problem at all. Byte-wise barrel shifters by hardware for CLNP are trivially easy and light weight to implement.
The real problem is on the number of prefix bits which must be looked up by backbone routers, which means IPv6 abandoning TLA is hopeless.
NSAP addresses, which essentially are telephone numbers, assume geographically aggregated addresses at country level (so called, country code), which is why they don't need large global routing tables.
8+8 has nothing to do with the problem and LISP came a lot later as a broken solution for the problem.
Masataka Ohta
Shane Ronan wrote:
But in fact with local number portability, you cannot rely on the county code to tell you where to route a telephone call anymore.
Not. With geographical aggregation, you may route a call *anywhere* in the destination country. Geographical aggregation means carriers in a country is required to have rich and robust connectivity between them within the country as if the country is served by a single carrier, which actually was the case with ATT/PTT/NTT monopoly. Then, whichever international carrier is chosen by the caller, the international carrier looks up country-wise routing table to reach the country. When the call reaches some point in the destination country, the callee can be reached relying on rich connectivity in the country. Number portability database is looked up after the call reaches the destination country, which will be used for further intra-national routing, which do not affect country-wise aggregation of international routing table. But, as ISPs do not want to be regulated to have such rich intra-national connectivity in all the countries, geographically aggregated addressing is considered not acceptable by operator community of the Internet. Masataka Ohta
On Wed, 15 Sep 2021 13:38:21 +0900, Masataka Ohta said:
Not. With geographical aggregation, you may route a call *anywhere* in the destination country.
The *real* fun starts when my provider is able to connect calls to my +1 540 etcetc phone number to my phone even if I'm in +371 or +81 or similar....
Valdis Klētnieks wrote:
Not. With geographical aggregation, you may route a call *anywhere* in the destination country.
The *real* fun starts when my provider is able to connect calls to my +1 540 etcetc phone number to my phone even if I'm in +371 or +81 or similar....
No problem. The caller will be charged for call to +1 and you will be charged for international transfer from +1 to +371 or +81. Masataka Ohta
On Wed, 15 Sept 2021 at 06:38, Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
Shane Ronan wrote:
But in fact with local number portability, you cannot rely on the county code to tell you where to route a telephone call anymore.
Not. With geographical aggregation, you may route a call *anywhere* in the destination country.
You mean anywhere in the world. Calls to my number reach my cell phone no matter where I go.
Number portability database is looked up after the call reaches the destination country, which will be used for further intra-national routing, which do not affect country-wise aggregation of international routing table.
Actually the GSM system will query the HLR to find out where to really route the call. Much like LISP actually. Regards, Baldur
Baldur Norddahl wrote:
But in fact with local number portability, you cannot rely on the county ^^^^^^^^^^^^^^^^^^^^^^^^ code to tell you where to route a telephone call anymore.
Not. With geographical aggregation, you may route a call *anywhere* in the destination country.
You mean anywhere in the world. Calls to my number reach my cell phone no matter where I go.
You are confusing number portability and call forwarding. Masataka Ohta
On 9/15/21 09:31, Masataka Ohta wrote:
Baldur Norddahl wrote:
But in fact with local number portability, you cannot rely on the county ^^^^^^^^^^^^^^^^^^^^^^^^ code to tell you where to route a telephone call anymore.
Not. With geographical aggregation, you may route a call *anywhere* in the destination country.
You mean anywhere in the world. Calls to my number reach my cell phone no matter where I go.
You are confusing number portability and call forwarding.
You're confusing call forwarding with international roaming. Obligatory back story. In the early days of international roaming I had cellular service in the US with AT&T. I traveled to Bulgaria for a week and took my phone with me. International rates were on the order of $3.95 per minute. I deliberately left my phone turned off so as to avoid expensive incoming calls. On arrival I turned my phone on and made two calls to let people at home know I'd arrived. During the trip I would turn it on and make a call occasionally, total under ten calls, all outbound. When I got home I would up with a bill totaling several hundred dollars. Every time someone called my number the call got routed to Bulgaria. The call then went back to the USA and hit my voicemail, so I got charged $3.95 twice for each of these calls. I eventually got the bill resolved, but it took a very long time and multiple escalations. Suffice it to say that AT&T customer service reps are located nowhere near the "A" in "AT&T". A year later I made another international trip. Ahead of time I called AT&T to ask them to disable voicemail so I wouldn't have to deal with that again. I finally was able to do so but that, too, took multiple calls to people very obviously not in "A". -- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV
On Sep 15, 2021, at 09:31 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Baldur Norddahl wrote:
But in fact with local number portability, you cannot rely on the county ^^^^^^^^^^^^^^^^^^^^^^^^ code to tell you where to route a telephone call anymore.
Not. With geographical aggregation, you may route a call *anywhere* in the destination country.
You mean anywhere in the world. Calls to my number reach my cell phone no matter where I go.
You are confusing number portability and call forwarding.
Masataka Ohta
Not exactly… He is confusing number portability and roaming. Owen
ons. 15. sep. 2021 19.37 skrev Owen DeLong via NANOG <nanog@nanog.org>:
On Sep 15, 2021, at 09:31 , Masataka Ohta < mohta@necom830.hpcl.titech.ac.jp> wrote:
Baldur Norddahl wrote:
But in fact with local number portability, you cannot rely on the county ^^^^^^^^^^^^^^^^^^^^^^^^ code to tell you where to route a telephone call anymore.
Not. With geographical aggregation, you may route a call *anywhere* in the destination country.
You mean anywhere in the world. Calls to my number reach my cell phone no matter where I go.
You are confusing number portability and call forwarding.
Masataka Ohta
Not exactly… He is confusing number portability and roaming.
I am not confusing anything. Nobody said anything about number portability in the above quote. Just pointing out that some assumptions about how voice call works is not true. Nor would it be smart to send traffic to another part of the world unnecessarily. Local calls stay local even when roaming. Please remember that signaling and voice is separate in the telco world which is why it compares poorly with IP. Except for the LISP protocol which does something similar. Regards Baldur
Baldur Norddahl wrote:
But in fact with local number portability, you cannot rely ^^^^^^^^^^^^^^^^^^^^^^^^
You are confusing number portability and call forwarding
I am not confusing anything. Nobody said anything about number portability in the above quote.
But, Shane Ronan wrote:
But in fact with local number portability, you cannot rely on the county code to tell you where to route a telephone call anymore. Which is many calls result in a data dip to provide you the routing information from a central repository.
OK?
Just pointing out that some assumptions about how voice call works is not true. Nor would it be smart to send traffic to another part of the world unnecessarily. Local calls stay local even when roaming. Please remember that signaling and voice is separate in the telco world which is why it compares poorly with IP. Except for the LISP protocol which does something similar.
I'm afraid you have too much complicated view on phone networks and the Internet. Masataka Ohta
Owen DeLong wrote:
You mean anywhere in the world. Calls to my number reach my cell phone no matter where I go.
You are confusing number portability and call forwarding.
Not exactly… He is confusing number portability and roaming.
Wrong. Mobility including, but not limited to, roaming (international roaming of mobile phones is assumed) needs 1) access foreign environment 2) route packets to foreign network Roaming today perform 1) by foreign network (often through a chain of AAA) and 2) by home carrier as call forwarding, which is very similar to IP mobility. As we are talking about "Calls to my number reach my cell phone", "call forwarding" is the most properly scoped explanation. It should be noted that many on this thread misunderstand that 2) destroys route aggregation. However, call forwarding from home carrier for roaming and mobility tunnel from home agent for IP mobility is performed by end system without burdening routing system of intermediate network and just scale. Instead, many have wrongly assumed a poor alternative to have a separate routing table entry for each mobile host in global routing table, which does not scale. Masataka Ohta
It appears that Baldur Norddahl <baldur.norddahl@gmail.com> said: According to Baldur Norddahl <baldur.norddahl@gmail.com>:
Number portability database is looked up after the call reaches the destination country, which will be used for further intra-national routing, which do not affect country-wise aggregation of international routing table.
Actually the GSM system will query the HLR to find out where to really route the call. Much like LISP actually.
With a century and a half of history, the phone system has a lot of different numbering hacks. In the US, the country is divided into several hundred regions within which you can port phone numbers. They do this with an overlay database; on each call the number is looked up to get a routing number which is used to route the call. If the number hasn't been ported the routing number is the number itself, otherwise it's a number assigned to the switch that handles the call. The routing numbers are assigned in the familar hierarchical way and the first seven digits of the number (three digit area code, three digit prefix, one digit subprefix) to route the call. Mobile carriers have their own system underneath that so if you, say, get an AT&T number in New York, port it to Verizon, and then move to California, calls to your number get routed to New York, looked up in the porting database, delivered to a Verizon switch in NY, then routed within the Verizon network to your phone in California. Dunno whether Verizon uses the same HLR to do international roaming or separate for domestic and international. There is a proposal to provide national number portability in the US which would in effect merge all of the regions together and get rid of all long distance charges within the US that has a reasonably good chance of happening. This has nothing to do with IPv6, of course, other than that modern phones use VoLTE so within a mobile carrier's network your voice call is probably handled using IPv6 transport.
This has nothing to do with IPv6, of course, other than that modern phones use VoLTE so within a mobile carrier's network your voice call is probably handled using IPv6 transport.
Good point John.
A lot of folks missed that ipv6 absorbed the scale growth in mobile, and mobile is what most eyeballs and be big content consider the internet to be. And, yes, mobile voice is called VoLTE and is most commonly deployed in the usa with ipv6. And most internet is called youtube / fb, and that is ipv6 too. This is where i live and work , 87% of mobiles on v6, voice and data https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/Comb... This is where nanog seems to be (old man yells at cloud meme) https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/rev... I don’t see the failure of ipv6 in 2021. It is globally deployed, providing global address, to billions of things and PB/s of content There are laggards in adopting v6, but they have not stopped the frontier of internet to reaching billions of people and things.
On Sep 16, 2021, at 9:23 AM, Ca By <cb.list6@gmail.com> wrote:
This has nothing to do with IPv6, of course, other than that modern phones use VoLTE so within a mobile carrier's network your voice call is probably handled using IPv6 transport.
Good point John.
A lot of folks missed that ipv6 absorbed the scale growth in mobile, and mobile is what most eyeballs and be big content consider the internet to be. And, yes, mobile voice is called VoLTE and is most commonly deployed in the usa with ipv6.
And most internet is called youtube / fb, and that is ipv6 too.
This is where i live and work , 87% of mobiles on v6, voice and data
https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/Comb...
This is where nanog seems to be (old man yells at cloud meme)
https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/rev...
I don’t see the failure of ipv6 in 2021. It is globally deployed, providing global address, to billions of things and PB/s of content
There are laggards in adopting v6, but they have not stopped the frontier of internet to reaching billions of people and things.
Yeah, I think this is the thing that I see people most often missing. Yes your provider may not be doing IPv6, but many applications and providers may yet be IPv6 internally or IPv6 to the popular content. I also say the number of people who store an IP as integer in a mysql(mariadb) backend is not to be underestimated. I still see some people doing the split up the IPv6 to store it in multiple columns thing even in 2021 which is disappointing as it shows this backwards/legacy thinking. If you’re seeing majority IPv4 bits, you likely have some choke point (CGN/FW) or similar gateway on the content side that needs a major update. I saw a post yesterday that someone used a unicode char to add an account nickname at their bank and it caused the entire bank to pause and them to get a phone call. Not sure if it’s true, but it rings true. Be the one enabling the next-generation access and you’ll similarly see graphs like the mobile carriers see. - Jared
On Sep 16, 2021, at 06:35 , Jared Mauch <jared@puck.nether.net> wrote:
On Sep 16, 2021, at 9:23 AM, Ca By <cb.list6@gmail.com> wrote:
This has nothing to do with IPv6, of course, other than that modern phones use VoLTE so within a mobile carrier's network your voice call is probably handled using IPv6 transport.
Good point John.
A lot of folks missed that ipv6 absorbed the scale growth in mobile, and mobile is what most eyeballs and be big content consider the internet to be. And, yes, mobile voice is called VoLTE and is most commonly deployed in the usa with ipv6.
And most internet is called youtube / fb, and that is ipv6 too.
This is where i live and work , 87% of mobiles on v6, voice and data
https://www.worldipv6launch.org/apps/ipv6week/measurement/images/graphs/Comb...
This is where nanog seems to be (old man yells at cloud meme)
https://static.wikia.nocookie.net/memepediadankmemes/images/0/01/297.jpg/rev...
I don’t see the failure of ipv6 in 2021. It is globally deployed, providing global address, to billions of things and PB/s of content
There are laggards in adopting v6, but they have not stopped the frontier of internet to reaching billions of people and things.
Yeah, I think this is the thing that I see people most often missing. Yes your provider may not be doing IPv6, but many applications and providers may yet be IPv6 internally or IPv6 to the popular content.
I also say the number of people who store an IP as integer in a mysql(mariadb) backend is not to be underestimated.
Nothing wrong with this as long as it’s a 128 bit integer. ;-)
I still see some people doing the split up the IPv6 to store it in multiple columns thing even in 2021 which is disappointing as it shows this backwards/legacy thinking.
UGH… I haven’t seen that in a while, sad to hear it’s still going on. Owen
On 15.09.21 06:38, Masataka Ohta wrote:
Geographical aggregation means carriers in a country is required to have rich and robust connectivity between them within the country...
or region. And this is indeed why such an addressing concept was dropped from IPv6. It just didn't fly economically. Eliot
On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
…. There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely.
Elliot - If by “design choices” you mean the criteria that we set forth for the new protocol (IPng), then that’s potentially true - it’s fairly challenging to hypothecate what impact different technical criteria would have had on the outcome. If by “design choices” you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring victory, then I’d strongly disagree. I believe that we had the appropriate technical criteria for IPng (very nicely compiled and edited by Craig Patridge and Frank Kastenholz in RFC1726) and then made conscious decisions to disregard those very criteria in order to “make a decision” & “move forward.” All of the IPng proposals where completely deficient with respect to transition capabilities. In the rush to make a IPng decision, the actual IPng Transition Criteria [1] that mandated a straightforward transition plan from IPv4 was simply acknowledged and then declared as “resolved" because we would also simultaneously form some working groups to study all of the transition requirements and made good on the transition criteria via future deliverables...(deliverables that were subsequently not delivered on) The right answer would have been to formally and critically evaluate each of the candidate protocols against the requirements and not make any selection until candidate presented itself that actually met the required technical criteria. Instead, IPv6 transition was left as an afterthought for the operator community to solve, and thus the battles with the IETF on NAT-based transition for nearly two decades to get this basic technical requirement met. FYI, /John Disclaimer: my views alone - made from 100% recycled electrons. === [1] The actual IPng Transition criteria (per RFC 1726) are as follows - " 5.5 Transition CRITERION The protocol must have a straightforward transition plan from the current IPv4. DISCUSSION A smooth, orderly, transition from IPv4 to IPng is needed. If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it. We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible. Rather, IPng will need to co-exist with IPv4 for some period of time. There are a number of ways to achieve this co-existence such as requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4. Each scheme has its strengths and weaknesses, which have to be weighed. Furthermore, we note that, in all probability, there will be IPv4 hosts on the Internet effectively forever. IPng must provide mechanisms to allow these hosts to communicate, even after IPng has become the dominant network layer protocol in the Internet. The absence of a rational and well-defined transition plan is not acceptable. Indeed, the difficulty of running a network that is transitioning from IPv4 to IPng must be minimized. (A good target is that running a mixed IPv4-IPng network should be no more and preferably less difficult than running IPv4 in parallel with existing non-IP protocols). " In short: 1) The protocol must have a straightforward transition plan 2) A number of ways to achieve this which are to be explored 3) IPng must provide backward-compatibility to IPv4-only hosts 4) The absence of a well-defined transition plan is not acceptable ===
On 20210916, at 11:15, John Curran <jcurran@istaff.org> wrote:
On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
…. There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely.
Elliot -
If by “design choices” you mean the criteria that we set forth for the new protocol (IPng), then that’s potentially true - it’s fairly challenging to hypothecate what impact different technical criteria would have had on the outcome.
If by “design choices” you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring victory, then I’d strongly disagree. I believe that we had the appropriate technical criteria for IPng (very nicely compiled and edited by Craig Patridge and Frank Kastenholz in RFC1726) and then made conscious decisions to disregard those very criteria in order to “make a decision” & “move forward.”
All of the IPng proposals where completely deficient with respect to transition capabilities.
Would not have mattered: one has to upgrade a large portion of the code/hardware present in the network anyway. And ~1995 was a completely different time from 1998, or 2001 let alone 2021 in number of devices and deployment; thus anything one would have guessed would have been off. The only thing that might have worked is a flag day, but unless some large org sets that in the near future, we'll just have the very very slow death thing that is happening and I bet that IPv4 will nicely outlive us all on this list and the ones that where there when IPng started. Greets, Jeroen
It's hard to argue that there was no transition plan. There were in fact at least three transition plans for the selected approach (dual stack, 6to4, and tunneling) some of which have been discarded along the way; while others came to be based on operational experience. Moreover, the only way to really know that a transition mechanism is really going to work is to let it out of the lab. And ALL of the proposals would have suffered the very same transition pains, because just as Jeroen has pointed out, the pain stretched all the way to the application. I don't think it's reasonable to argue that we should have waited for some other mythical better proposal to come along. I don't recall anyone arguing for that at the time, and there's no reason to believe that such a mythical proposal would have ever come to be in any foreseeable time frame. In fact Erik Fair, Dave Crocker, Tom Kessler and I argued the very opposite, that we were digging ourselves a hole with NAT. Your argument at the time (Interop '95, Vegas) was that the IETF didn't have the right to dictate address usage to deployments. True enough, but then people shouldn't hang their woes on the IETF. As I mentioned earlier, the fundamental issue was that there were no ng proposals that were in fact substitutable resources for v4, and NAT was. From there, economics has ruled, arguments be damned. Eliot * I *did* in fact posit an approach in 1992 that would have allowed for orderly transition such that IPv4 could continue, and that was to define class E addresses as extension blocks that were in fact name space prefixes for another IPv4 header. It wasn't taken seriously, and perhaps rightly so. This actually borrowed a page from the PSTN - most people communicate locally and so you would rarely use those extended name spaces. This was before Paul (Tsuchiya) Francis offered PIP, which had a notion of Landmark Routing that also went nowhere. On 16.09.21 11:15, John Curran wrote:
On 14 Sep 2021, at 3:46 AM, Eliot Lear <lear@ofcourseimright.com <mailto:lear@ofcourseimright.com>> wrote:
…. There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely.
Elliot -
If by “design choices” you mean the criteria that we set forth for the new protocol (IPng), then that’s potentially true - it’s fairly challenging to hypothecate what impact different technical criteria would have had on the outcome.
If by “design choices” you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring victory, then I’d strongly disagree. I believe that we had the appropriate technical criteria for IPng (very nicely compiled and edited by Craig Patridge and Frank Kastenholz in RFC1726) and then made conscious decisions to disregard those very criteria in order to “make a decision” & “move forward.”
All of the IPng proposals where completely deficient with respect to transition capabilities. In the rush to make a IPng decision,the actual IPng Transition Criteria [1] that mandated a straightforward transition plan fromIPv4 was simply acknowledged and then declared as “resolved" becausewe would also simultaneously form some working groups to study all of the transition requirements and made good on the transition criteria via future deliverables...(deliverables that were subsequently not delivered on)
The right answer would have been to formally and critically evaluate each of the candidate protocols against the requirements and not make any selection until candidate presented itself that actually met the required technical criteria. Instead, IPv6 transition was left as an afterthought for the operator community to solve, and thus the battles with the IETF on NAT-based transition for nearly two decades to get this basic technical requirement met.
FYI, /John
Disclaimer: my views alone - made from 100% recycled electrons.
=== [1] The actual IPng Transition criteria (per RFC 1726) are as follows -
" 5.5 Transition
CRITERION The protocol must have a straightforward transition plan from the current IPv4.
DISCUSSION A smooth, orderly, transition from IPv4 to IPng is needed. If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it.
We believe that it is not possible to have a "flag-day" form of transition in which all hosts and routers must change over at once. The size, complexity, and distributed administration of the Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of time. There are a number of ways to achieve this co-existence such as requiring hosts to support two stacks, converting between protocols, or using backward compatible extensions to IPv4. Each scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4 hosts on the Internet effectively forever. IPng must provide mechanisms to allow these hosts to communicate, even after IPng has become the dominant network layer protocol in the Internet.
The absence of a rational and well-defined transition plan is not acceptable. Indeed, the difficulty of running a network that is transitioning from IPv4 to IPng must be minimized. (A good target is that running a mixed IPv4-IPng network should be no more and preferably less difficult than running IPv4 in parallel with existing non-IP protocols). "
In short:
1) The protocol must have a straightforward transition plan 2) A number of ways to achieve this which are to be explored 3) IPng must provide backward-compatibility to IPv4-only hosts 4) The absence of a well-defined transition plan is not acceptable
===
On 16 Sep 2021, at 5:46 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
It's hard to argue that there was no transition plan. There were in fact at least three transition plans for the selected approach (dual stack, 6to4, and tunneling) some of which have been discarded along the way; while others came to be based on operational experience. Moreover, the only way to really know that a transition mechanism is really going to work is to let it out of the lab. And ALL of the proposals would have suffered the very same transition pains, because just as Jeroen has pointed out, the pain stretched all the way to the application.
Eliot - The requirement was not for the assertion of multiple “transition plans”, but rather "The protocol must have a straightforward transition plan from the current IPv4.” "A straightforward plan” – singular. If you have a link to that plan, please provide it, but until such time I’ll stay with my understanding of events (that being that we completely dropped the ball with regard to providing the operator community with a meaningful transition plan.)
I don't think it's reasonable to argue that we should have waited for some other mythical better proposal to come along. I don't recall anyone arguing for that at the time, and there's no reason to believe that such a mythical proposal would have ever come to be in any foreseeable time frame. In fact Erik Fair, Dave Crocker, Tom Kessler and I argued the very opposite, that we were digging ourselves a hole with NAT. Your argument at the time (Interop '95, Vegas) was that the IETF didn't have the right to dictate address usage to deployments. True enough, but then people shouldn't hang their woes on the IETF.
Sorry, I was on the IPng Directorate, and there were indeed arguments that we lacked meaningful transition strategy, and that the fig leaf of shipping the responsibility off to “to-be-defined” working groups was irresponsible.
As I mentioned earlier, the fundamental issue was that there were no ng proposals that were in fact substitutable resources for v4, and NAT was. From there, economics has ruled, arguments be damned.
As predicted - "As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices. In order to meet the requirement for “viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred.” Sorry, but as the sole “network operator” on the IPng Directorate who lived through thru convenient papering over of the transition requirement firsthand, I’ll have to concur with Randy Bush’s take on this one -
"real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space."
we are left to make the mess work for the users, while being excoriated for not doing it quickly or well enough, and for trying to make ends meet financially.”
Anyone who wants to argue that IPng had a viable transition plan best put a hard link to the documented plan in their reply - trying to argue the point without actually citing the alleged “straightforward plan" is just embarrassing. Thanks, /John p.s. Disclaimer: my views alone (although likely shared by many operators upon hearing silence in response to the question: “Okay, how is this transition really supposed to work?”)
John you were not the "sole network operator" on the directorate.[1] And I'm not saying that there weren't arguments, but I am saying that nobody said, “wait for something better.” Rather, everyone was arguing for their preferred approach out of the ones I mentioned. Eliot [1] https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94 On 16.09.21 14:10, John Curran wrote:
On 16 Sep 2021, at 5:46 AM, Eliot Lear <lear@ofcourseimright.com <mailto:lear@ofcourseimright.com>> wrote:
It's hard to argue that there was no transition plan. There were in fact at least three transition plans for the selected approach (dual stack, 6to4, and tunneling) some of which have been discarded along the way; while others came to be based on operational experience. Moreover, the only way to really know that a transition mechanism is really going to work is to let it out of the lab. And ALL of the proposals would have suffered the very same transition pains, because just as Jeroen has pointed out, the pain stretched all the way to the application.
Eliot -
The requirement was not for the assertion of multiple “transition plans”, but rather "The protocol must have a straightforward transition plan from the current IPv4.”
"A straightforward plan” – singular. If you have a link to that plan, please provide it, but until such time I’ll stay with my understanding of events (that being that we completely dropped the ball with regard to providing the operator community with a meaningful transition plan.)
I don't think it's reasonable to argue that we should have waited for some other mythical better proposal to come along. I don't recall anyone arguing for that at the time, and there's no reason to believe that such a mythical proposal would have ever come to be in any foreseeable time frame. In fact Erik Fair, Dave Crocker, Tom Kessler and I argued the very opposite, that we were digging ourselves a hole with NAT. Your argument at the time (Interop '95, Vegas) was that the IETF didn't have the right to dictate address usage to deployments. True enough, but then people shouldn't hang their woes on the IETF.
Sorry, I was on the IPng Directorate, and there were indeed arguments that we lacked meaningful transition strategy, and that the fig leaf of shipping the responsibility off to “to-be-defined” working groups was irresponsible.
As I mentioned earlier, the fundamental issue was that there were no ng proposals that were in fact substitutable resources for v4, and NAT was. From there, economics has ruled, arguments be damned.
As predicted - "As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices. In order to meet the requirement for “viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred.”
Sorry, but as the sole “network operator” on the IPng Directorate who lived through thru convenient papering over of the transition requirement firsthand, I’ll have to concur with Randy Bush’s take on this one -
"real compatibility with ipv4 was disdained. the transition plan was dual stack and v4 would go away in a handful of years. the 93 transition mechanisms were desperate add-ons when v4 did not go away. and dual stack does not scale, as it requires v4 space proportional to deployed v6 space."
we are left to make the mess work for the users, while being excoriated for not doing it quickly or well enough, and for trying to make ends meet financially.”
Anyone who wants to argue that IPng had a viable transition plan best put a hard link to the documented plan in their reply - trying to argue the point without actually citing the alleged “straightforward plan" is just embarrassing.
Thanks, /John
p.s. Disclaimer: my views alone (although likely shared by many operators upon hearing silence in response to the question: “Okay, how is this transition really supposed to work?”)
On 16 Sep 2021, at 8:58 AM, Eliot Lear <lear@ofcourseimright.com> wrote:
John you were not the "sole network operator" on the directorate.[1] https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94 <https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94>
Eliot - You are referencing the minutes of a rather large workshop (the Big10 confab) that had far more attendees that the IPng Directorate itself. The list of directorate members is contained in RFC 1752 "The Recommendation for the IP Next Generation Protocol” in Appendix B, and is listed below for reference – Appendix B - IPng Area Directorate J. Allard - Microsoft <jallard@microsoft.com> Steve Bellovin - AT&T <smb@research.att.com> Jim Bound - Digital <bound@zk3.dec.com> Ross Callon - Wellfleet <rcallon@wellfleet.com> Brian Carpenter - CERN <brian.carpenter@cern.ch> Dave Clark - MIT <ddc@lcs.mit.edu > John Curran - NEARNET <curran@nic.near.net> Steve Deering - Xerox <deering@parc.xerox.com> Dino Farinacci - Cisco <dino@cisco.com> Paul Francis - NTT <francis@slab.ntt.jp> Eric Fleischmann - Boeing <ericf@atc.boeing.com> Mark Knopper - Ameritech <mak@aads.com> Greg Minshall - Novell <minshall@wc.novell.com> Rob Ullmann - Lotus <ariel@world.std.com> Lixia Zhang - Xerox <lixia@parc.xerox.com>
And I'm not saying that there weren't arguments, but I am saying that nobody said, “wait for something better.” Rather, everyone was arguing for their preferred approach out of the ones I mentioned.
Also incorrect. The preferred transition approached of the recommended IPng candidate (SIPP) was IPAE, and that was actually dead-on-arrival. Per the same recommendation RFC - The biggest problem the reviewers had with SIPP was with IPAE, SIPP's transition plan. The overwhelming feeling was that IPAE is fatally flawed and could not be made to work reliably in an operational Internet. This is what lead to the conception of the infamous Simple SIPP Transition (SST) approach as a stand-in Transition plan in order to allow for a decision to be made – and creation of IETF working groups to develop the respective transition mechanisms. At the time of the IPng decision there was actually _no_ “transition plan” – as the very mechanisms that were to be used (and that were eventually discarded as unworkable) were just placeholders for future IETF work. Thanks, /John p.s. My views alone. Warning: contents may be hot / burn hazard
your memory of the procedural details is better than mine. you have my sympathies. i was focused on the technical disater that has cost us decades. but folk who i still consider friends were willing to throw dren at the wall hoping it would stick so the ietf/iana was not taking crap in the press for the looming disaster of running out of address space. and here we are, decades later, still having to listen to hysteria about running out of address space; just not in the new york times. problem solved, eh? we had to invent dnssec to find something that would deploy more slowly, and with more gl!tches, than ipv6. and have you seen what's going on in the 6man wg?!?! randy
John Curran wrote:
If by "design choices" you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring victory, then I’d strongly disagree.
What actually happened is that SIP was chosen but modified by IPng directorates to pretend, for political purposes, IPng were a merger of all the proposals only to make the result totally unusable, during which address length was extended from 8B to 16B to accommodate so infamous XNS style auto configuration. Masataka Ohta
On 16 Sep 2021, at 11:33 AM, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
John Curran wrote:
If by "design choices" you mean the tradeoffs accepted in selecting a particular candidate protocol and declaring victory, then I’d strongly disagree.
What actually happened is that SIP was chosen but modified by IPng directorates to pretend, for political purposes, IPng were a merger of all the proposals only to make the result totally unusable, during which address length was extended from 8B to 16B to accommodate so infamous XNS style auto configuration.
Masataka - You are correct, in that the design choices made for the final “IPng" weren’t actually any of the proposals as submitted, but rather an interesting compromise creation. (My negative answer to Eliot’s "There is no evidence that any other design choices on the table at the time would have gotten us transitioned any faster, and a lot of evidence and analysis that the exact opposite is more likely” was simply noting that the design choices made about the “straightforward transition plan" was effectively to punt – i.e. despite lacking one, choosing declare victory anyway and leave it as an exercise for the reader. It’s fairly obvious that different choices here could have made a very significant difference in IPng deployment trajectory.) Thanks, /John Disclaimer: my views alone - (no one else would wanted them…)
Randy Bush wrote:
it took five years of war to get rid of the tla/sla crap.
As backbone operators do not want to have large routing tables, TLA is a good idea. As you can see, TLA of IPv4 is /24, though there is no NLA.
and look at the /64 religion today[0].
It was /80, until I pointed out that IEEE1394 MAC address is 64bit long. Masataka Ohta
On 9/13/21 01:00, Michael Thomas wrote:
If vendors actually cared they could make the CGNAT's and other hacks ridiculously buggy and really expensive to deploy and maintain. I doubt many vendors were chomping at the bit to support CGNAT and are probably wondering what fresh hell is next to keep ipv4 limping along.
10's of millions of dollars being spent by African mobile operators, every year, in CG-NAT hardware and licenses, with the vendors. They will make sure that code is bug-free :-). Mark.
On Sep 13, 2021, at 05:17 , Mark Tinka <mark@tinka.africa> wrote:
On 9/13/21 01:00, Michael Thomas wrote:
If vendors actually cared they could make the CGNAT's and other hacks ridiculously buggy and really expensive to deploy and maintain. I doubt many vendors were chomping at the bit to support CGNAT and are probably wondering what fresh hell is next to keep ipv4 limping along.
10's of millions of dollars being spent by African mobile operators, every year, in CG-NAT hardware and licenses, with the vendors.
They will make sure that code is bug-free :-).
ROFLMAO 100s of millions of dollars are spent every year on major backbone router kit. That code has never been bug free. Your assertion is provably false. Owen
On Sep 8, 2021, at 10:24 AM, Bjørn Mork <bjorn@mork.no> wrote: The next thought was SMTP
I assume someone’s tried using MX record precedence to do this? AAAA record references with lower values than A record references, and see what happens? Anyone have any results to share there?
and authoritative DNS servers.
If all currently-listed NS are dual-stack, I don’t know how much more would be gained by pruning them back to IPv6 only, from an actual-change-in-the-world perspective. Obviously it’s got to happen in the long run, will happen in the long run, and is the right thing to do, but I’m not sure that’s where our short-term tactical effort is going to have the most effect. If there are currently IPv4-only nameservers, deprecating those, dual-stacking them, or replacing them with IPv6-only is a good move.
Running IPv6 only in a real production environment should be possible as long as you keep IPv4 on at least one of the servers.
Agreed, and in your internal environment you can go IPv6 only with NAT/gateway at the edge to reach legacy stuff on the outside. That helps get your people used to IPv6-only, and demonstrates the benefits of less configuration, less worrying about IP address availability, etc. If people don’t have a taste of how much easier it is, they don’t have a strong incentive to keep moving forward.
But you don't have to look far before you hit snags like this: https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/
Ugh. Policy from 2018. Has anyone reached out to them to get this fixed? .NO is one of the few ccTLDs we don’t have a relationship with. Looks like they’re using NetNod and Neustar. -Bill
It appears that Bill Woodcock <woody@pch.net> said:
The next thought was SMTP
I assume someone’s tried using MX record precedence to do this? AAAA record references with lower values than A record references, and see what happens? Anyone have any results to share there?
I used to publish two MX records at the same precedence, one with an A record and one with an AAAA record. It didn't work very well because some v4 only systems decided that an MX without an A record meant my mail system was broken. Now I have one MX with both which works OK. Postfix has some parameters to say whether to prefer v4 or v6 at the same priority. Wietse says don't prefer v6, you'll lose mail. R's, John
But you don't have to look far before you hit snags like this: https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/
I just sent the following to them: I’m writing about your name server requirements page: https://www.norid.no/en/om-domenenavn/regelverk-for-no/vedlegg-f/ I think that requirement 4: Accessible name servers Name servers must be permanently connected to the Internet, and must have a permanently assigned (fixed) IPv4 address. The name servers may also have an IPv6 address, and this too must be permanently assigned as required for the IPv4 address. The name servers must be connected to a stable and reliable infrastructure. is somewhat out of date relevant to current best internet practices… At the very least, IPv6 should no longer be options. Ideally, IPv4 should be optional. Suggest you send something similar. Owen
On Sep 7, 2021, at 23:50 , Saku Ytti <saku@ytti.fi> wrote:
On Tue, 7 Sept 2021 at 19:51, Owen DeLong <owen@delong.com> wrote:
Hopefully this idea that “you need to do IPv4 anyhow” will die some day soon.
Fully agreed, I just don't see the driver. But I can imagine a
$$$$$$ IPv4 continues to increase in cost. Surely, there is a point where organizations start to cry uncle. Surely there is a point where we move from but you have to do IPv4 anyhow to but you have to do IPv6 to support most new things because newcomers don’t want to pay $150/address to get on the legacy network. (Yeah, I know it’s only $50 today, but it was $10 a few years ago and $30 last year).
different timeline where in 2000 several tier1 signed mutual binding contracts to drop IPv4 at the edge in 2020. And no one opposed,
That would have been nice, but that opportunity was missed. I’m thinking that the most hope for this to happen realistically is for eyeball providers to start charging extra to provide IPv4AAS to their customers that need it. I think an announcement from one or two of the major ones would serve as an extreme motivation for the lagging content providers (Are you listening here Amazon? Skype? Google Cloud? AWS? (global load balancing)) to get their shit together. Once they do, there’s really not much “you have to support IPv4 anyway” left, then the eyeballs can shut it off for customers that don’t pay extra and voila… Little incentive remains to continue maintaining IPv4 infrastructure.
because 20 years before was 1980, and 20 years in the future IPv4 wont' anymore be a thing, it's clear due to exponential growth.
And we'd all be enjoying a much simplified stack and lower costs all around (vendor, us, customers).
Yep.
Why is this not possible now? Why would we not sign this mutual agreement for 2040? Otherwise we'll be having this same discussion in 2040.
Because markets (and people) are bad at transition and we live in a world of markets and perverse incentives. It’s part of the reason climate change is so hard to address also. Owen
* Owen DeLong via NANOG [Wed 08 Sep 2021, 20:35 CEST]:
IPv4 continues to increase in cost. Surely, there is a point where organizations start to cry uncle.
In most western countries there isn't much growth in the total number of connections. It's mostly churn between providers. IPv4 addresses aren't wasted once a customer leaves (unlike for mobile numbers there is no mandated number portability for IP addresses), they can be reused for the next customer, they don't deteriorate when kept in stock, and they can likely be sold for more, later, eventually. (As long as you buy, not rent, that is, and LIR fees don't significantly increase.) -- Niels.
On Sep 8, 2021, at 11:57 , Niels Bakker <niels=nanog@bakker.net> wrote:
* Owen DeLong via NANOG [Wed 08 Sep 2021, 20:35 CEST]:
IPv4 continues to increase in cost. Surely, there is a point where organizations start to cry uncle.
In most western countries there isn't much growth in the total number of connections. It's mostly churn between providers. IPv4 addresses aren't wasted once a customer leaves (unlike for mobile numbers there is no mandated number portability for IP addresses), they can be reused for the next customer, they don't deteriorate when kept in stock, and they can likely be sold for more, later, eventually.
(As long as you buy, not rent, that is, and LIR fees don't significantly increase.)
-- Niels.
The addresses aren’t the major cost of providing IPv4 services. CGN boxes, support calls, increasing size of routing table = buying new routers, etc. Increased cost of developers having to work around NAT and NAT becoming ever more complex with multiple layers, etc. All of these are the things driving the ever increasing cost of IPv4 services, not just the cost of the addresses. Owen
Owen DeLong via NANOG <nanog@nanog.org> writes:
The addresses aren’t the major cost of providing IPv4 services.
CGN boxes, support calls, increasing size of routing table = buying new routers, etc.
You're counting dual-stack costs as if IPv4 was the optional protocol. That's a fantasy world. Time to get out of la-la land now. Your edge routers can do CGN for all connected users just fine. Yes, there is still a cost both in resources and management, but you'll have to weigh that against the cost of doing dual-stack on the same box. I'm not convinced dual-stack wins. Don't know what you're thinking of wrt support calls, but dual-stack has some failure modes which are difficult to understand for both end users and support. NAT is pretty well understood in comparison. Your routing tables won't grow with IPv4 or CGN. They grow when you add IPv6.
Increased cost of developers having to work around NAT and NAT becoming ever more complex with multiple layers, etc.
And this can be avoided by reconfiguring the local network somehow? Or are we talking about an Internet without IPv4? This is even more fantastic than the idea that IPv4 is optional in the local network.
All of these are the things driving the ever increasing cost of IPv4 services, not just the cost of the addresses.
Yes, the cost of addresses is not prohibitive, and there is no indication it will be. The consolidation of hosting services have reduced the need for globally routable addresses. You don't host your own mail server and web server anymore, even if you're a large organisation. Most ISPs haven't yet taken advantage of this. They are still giving globally routable IPv4 addresses to customers which have no need for that. These addresses can be re-allocated for CGN if there is a need. This is obviously still not free, but it does limit the price of fresh IPv4 addresses. The other costs you list will not affect an IPv4 only shop at all. Bjørn
On 10 Sep 2021, at 17:21, Bjørn Mork <bjorn@mork.no> wrote:
Owen DeLong via NANOG <nanog@nanog.org> writes:
The addresses aren’t the major cost of providing IPv4 services.
CGN boxes, support calls, increasing size of routing table = buying new routers, etc.
You're counting dual-stack costs as if IPv4 was the optional protocol. That's a fantasy world. Time to get out of la-la land now.
Your edge routers can do CGN for all connected users just fine. Yes, there is still a cost both in resources and management, but you'll have to weigh that against the cost of doing dual-stack on the same box. I'm not convinced dual-stack wins.
Don't know what you're thinking of wrt support calls, but dual-stack has some failure modes which are difficult to understand for both end users and support. NAT is pretty well understood in comparison.
Your routing tables won't grow with IPv4 or CGN. They grow when you add IPv6.
Increased cost of developers having to work around NAT and NAT becoming ever more complex with multiple layers, etc.
And this can be avoided by reconfiguring the local network somehow? Or are we talking about an Internet without IPv4? This is even more fantastic than the idea that IPv4 is optional in the local network.
All of these are the things driving the ever increasing cost of IPv4 services, not just the cost of the addresses.
Yes, the cost of addresses is not prohibitive, and there is no indication it will be.
The consolidation of hosting services have reduced the need for globally routable addresses. You don't host your own mail server and web server anymore, even if you're a large organisation. Most ISPs haven't yet taken advantage of this. They are still giving globally routable IPv4 addresses to customers which have no need for that. These addresses can be re-allocated for CGN if there is a need. This is obviously still not free, but it does limit the price of fresh IPv4 addresses.
The other costs you list will not affect an IPv4 only shop at all.
Bjørn
Or you could deliver IPv6-only to your customers and used to CGN boxes to deliver IPv4AAS using less than 1/2 the IPv4 address space you need for a NAT444 solution as +60% of your traffic doesn’t need CGN processing. 464XLAT example { Internet IPv4(40% of traffic) + IPv6(60% of traffic) } - [Router w/ NAT64] - { IPv6-only (IPv4 traffic has been translated to IPv6) } - [CPE w/ CLAT] { home network IPv4 + IPv6 } DS-Lite { Internet IPv4(40% of traffic) + IPv6(60% of traffic) } - [Router w/ AFTR] - { IPv6-only (IPv4 traffic has been encapsulated in IPv6) } - [CPE w/ B4] { home network IPv4 + IPv6 } MAP-T and MAP-E are similar to 464XLAT and DS-Lite respectively. Yes, you have to learn something new but it costs less that a “pure" IPv4 service. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Sep 10, 2021, at 00:21 , Bjørn Mork <bjorn@mork.no> wrote:
Owen DeLong via NANOG <nanog@nanog.org> writes:
The addresses aren’t the major cost of providing IPv4 services.
CGN boxes, support calls, increasing size of routing table = buying new routers, etc.
You're counting dual-stack costs as if IPv4 was the optional protocol. That's a fantasy world. Time to get out of la-la land now.
No, I’m counting them as if they are the increasing cost of continuing to support IPv4.
Your edge routers can do CGN for all connected users just fine. Yes, there is still a cost both in resources and management, but you'll have to weigh that against the cost of doing dual-stack on the same box. I'm not convinced dual-stack wins.
It does. At least in my environments.
Don't know what you're thinking of wrt support calls, but dual-stack has some failure modes which are difficult to understand for both end users and support. NAT is pretty well understood in comparison.
Single layer NAT, sure. But double-layer NAT has some oddities that you might not have encountered yet… 1. Products which are built on really strange assumptions about everyone having the same NAT environment. For example, Philips Hue makes an assumption that if you are in the same household, your Hue Gateway and your phones and laptops will all have the same public IP address. This has two unexpected ramifications: 1. You cannot actually complete their registration process for their cloud services if you don’t NAT everything to the same address or proxy it all through a common proxy address. 2. If you are behind CGN, you and your neighbors are going to be considered a single household (at least everyone behind the same CGN address). Of course, this assumes that you get a consistent single public CGN address for everything in your house. If you don’t, then you get a combination of this problem with problem 1 above and life gets very interesting. 2. NAT Traversal technologies that don’t cope well with an added layer. 3. Added and inconsistent latency through CGN boxes degrading several online experiences, including voice, interactive video, and most of all several types of gaming. There are many more and each of them generates additional support calls to the ISP about “The internet is broken”.
Your routing tables won't grow with IPv4 or CGN. They grow when you add IPv6.
Um, please review the IPv4 routing table report over the past few years and tell me that again. For your convenience: https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp%2dactive%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step
Increased cost of developers having to work around NAT and NAT becoming ever more complex with multiple layers, etc.
And this can be avoided by reconfiguring the local network somehow? Or are we talking about an Internet without IPv4? This is even more fantastic than the idea that IPv4 is optional in the local network.
We are talking about internet where IPv4 prevalence continues to drop. Whether it can be avoided or not, however, it is a factor in the ever increasing cost of IPv4.
All of these are the things driving the ever increasing cost of IPv4 services, not just the cost of the addresses.
Yes, the cost of addresses is not prohibitive, and there is no indication it will be.
Agreed… But the other costs are also continuing to increase. None of these costs exist in IPv6 save a one-time deployment cost.
The consolidation of hosting services have reduced the need for globally routable addresses. You don't host your own mail server and web server anymore, even if you're a large organisation.
Lots do, actually.
Most ISPs haven't yet taken advantage of this. They are still giving globally routable IPv4 addresses to customers which have no need for that. These addresses can be re-allocated for CGN if there is a need. This is obviously still not free, but it does limit the price of fresh IPv4 addresses.
Lots of things you don’t expect break when you stop giving at least one IPv4 GUA to your customers.
The other costs you list will not affect an IPv4 only shop at all.
This simply isn’t true. Owen
Regulatory enforcement by whom? Last I knew there wasn’t a world wide Internet regulatory body.
On Sep 6, 2021, at 2:33 AM, Saku Ytti <saku@ytti.fi> wrote:
On Sun, 5 Sept 2021 at 19:22, Bjørn Mork <bjorn@mork.no> wrote:
So where does that put us in a decade or two? Which protocol is optional?
If we don't get regulatory enforcement or voluntary commitments to sunset IPv4, we are doomed for dual-stack for the foreseeable future (decades). I absolutely HATE testing, developing and supporting IPv4+IPv6, more than doubling my time, adding 3rd stack would actually not increase cost that much, it's the 1=>2 which is fantastically expensive. And costs are transferred to customers. Those who have not done _anything_ with IPv6, have done the right thing from business POV, they've had lowest cost, least issues and have had other people pay for the improvements of the stack. And even today, I see no business sense deploying IPv6.
Now if we'd know, all of our CDN, cloudyshops and tier1 will start dropping IPV4 at edge in 2040, this would create good business reason to start developing to IPv6, you'd know you need to have it, and you'd know you have finite window when you need to support both. And this is something we should commit to do, and everyone would benefit from the comment.
-- ++ytti
On 9/4/21 10:43 PM, Saku Ytti wrote:
I view IPv6 as the biggest mistake of my career and feel responsible for this horrible outcome and I do apologise to Internet users for it. This dual-stack is the worst possible outcome, and we've been here over two decades, increasing cost and reducing service quality. We should have performed better, we should have been IPv6 only years ago.
I wish 20 years ago big SPs would have signed a contract to drop IPv4 at the edge 20 years from now, so that we'd given everyone a 20 year deadline to migrate away. 20 years ago was the best time to do it, the 2nd best time is today. If we don't do it, 20 years from now, we are in the same position, inflating costs and reducing quality and transferring those costs to our end users who have to suffer from our incompetence.
I can't see how an "end of the tunnel" clause would be helpful. As with everything, nothing would be done until the very and then they'd just extend the tunnel again which is functionally no different than running out of IP address. I looked up CGN's this morning and the thing that struck me the most was losing port forwarding. It's probably a small thing to most people but losing it means to get an incoming session it always has to be mediated by something on the outside. Yuck. So I hope that is not what the future hold, though it probably does. So is there anything we could have done different? Was this ever really a technical issue? Even if we bolted two more bytes onto an IPv4 address and nothing more, would that have been adopted either? Mike
On 9/5/21 3:28 PM, Michael Thomas wrote:
I looked up CGN's this morning and the thing that struck me the most was losing port forwarding. It's probably a small thing to most people but losing it means to get an incoming session it always has to be mediated
by something on the outside. Yuck. So I hope that is not what the future hold, though it probably does.
I think we are heading into a world where Internet is going to be bifurcated with "/on/ the Internet" (with globally routed IP address(es)) or "/access/ /to/ the Internet" (with one or more layers of CGN). I think that the vast majority of consumers would be content with the latter while a small minority will demand the former. Content hosting will almost definitely require the former. (Wiggle room is for other arrangements that can be made.) -- Grant. . . . unix || die
The vast majority of LTE based last mile users in developing nation environments (where maybe less than 5% of people have residential wireline broadband to their residence) are already behind a cgnat. In many places it's actually an anomaly and weird for a person to desire, or be able to afford, both a broadband internet connection at home with wired router/801.11 AP, and also the (per GB) data service for their cellphone. They choose to go with only the latter. On Sun, Sep 5, 2021 at 6:00 PM Grant Taylor via NANOG <nanog@nanog.org> wrote:
On 9/5/21 3:28 PM, Michael Thomas wrote:
I looked up CGN's this morning and the thing that struck me the most was losing port forwarding. It's probably a small thing to most people but losing it means to get an incoming session it always has to be mediated
by something on the outside. Yuck. So I hope that is not what the future hold, though it probably does.
I think we are heading into a world where Internet is going to be bifurcated with "/on/ the Internet" (with globally routed IP address(es)) or "/access/ /to/ the Internet" (with one or more layers of CGN).
I think that the vast majority of consumers would be content with the latter while a small minority will demand the former.
Content hosting will almost definitely require the former. (Wiggle room is for other arrangements that can be made.)
-- Grant. . . . unix || die
On 9/7/21 17:25, Eric Kuhnke wrote:
The vast majority of LTE based last mile users in developing nation environments (where maybe less than 5% of people have residential wireline broadband to their residence) are already behind a cgnat.
Our mobile carriers in Africa, for example, will happily give the vendors 10's of millions of coin every year, to maintain CG-NAT. It's truly amazing, how much money they are swimming in. The bad news is that infrastructure is no longer a play, and by the time they realize this, they'll have wished they at least used that cash to buy their staff cookies.
In many places it's actually an anomaly and weird for a person to desire, or be able to afford, both a broadband internet connection at home with wired router/801.11 AP, and also the (per GB) data service for their cellphone. They choose to go with only the latter.
Well, in many cases, it comes down to what is available (even before it's affordable). We all NEED phones, but we don't all NEED fibre at the house (I'm generalizing, but you know what I mean). The phone is probably the most basic requirement, and is what operators are most likely to accommodate for before they add wire for data. So chances are folk have started off with a phone. If the fibre follows, is it affordable, to the point that it can co-exist (not replace) my phone? Mark.
Michael Thomas wrote:
I looked up CGN's this morning and the thing that struck me the most was losing port forwarding. It's probably a small thing to most people but losing it means to get an incoming session it always has to be mediated by something on the outside.
So, to receive mails at home, we need forwarding of well known SMTP port (25) or an external SMTP server.
So is there anything we could have done different?
As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful. Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today.
Even if we bolted two more bytes onto an IPv4 address and nothing more, would that have been adopted either?
Nothing more? We may even develop transport protocols with 32 bit port numbers, which is a lot easier to deploy than IPv6. Masataka Ohta
* mohta@necom830.hpcl.titech.ac.jp (Masataka Ohta) [Tue 07 Sep 2021, 18:36 CEST]:
As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful.
This absolutely doesn't work. And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email).
Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today.
Oh and we need to work around the whole IP reputation system that governs email today. Is there even any IETF work being done on getting port forwards on a device behind your immediate LAN at home?
We may even develop transport protocols with 32 bit port numbers, which is a lot easier to deploy than IPv6.
Do you have any more practical proposals, or..? -- Niels.
Niels Bakker wrote:
As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful.
This absolutely doesn't work.
Thank you very much for your emotional and unfounded comment.
And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email).
I know SRV and other similar proposals so far are not very compatible with URL syntax and should better be simplified.
Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today.
Oh and we need to work around the whole IP reputation system that governs email today. IP reputation system must evolve to be IP+port reputation system, which is not my problem.
Is there even any IETF work being done on getting port forwards on a device behind your immediate LAN at home?
That's overkill, because servers should have stable addresses and ports. So, we only need statically configured port forwarding. But if you insist, UPnP by Microsoft has been implemented on almost all NAT boxes. There even exists PCP.
Do you have any more practical proposals, or..?
What are missing are practical comments. Masataka Ohta
On 8 Sep 2021, at 12:51, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Niels Bakker wrote:
As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful. This absolutely doesn't work.
Thank you very much for your emotional and unfounded comment.
And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email).
Which is why there is HTTPS and SVCB. If you look at your recursive server logs you are likely to see queries for HTTPS being made as browsers are starting to make queries for HTTPS (a.k.a. TYPE65).
I know SRV and other similar proposals so far are not very compatible with URL syntax and should better be simplified.
The only thing difficult to map was non-default ports and that could easily have been addressed. Remember SRV required a seperate RFC to specify how to map existing services on to it. HTTPS just prefixed the label "_<port>”. That could have easily been done with SRV. HTTPS and SVBC are just SRV on steroids.
Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today.
Oh and we need to work around the whole IP reputation system that governs email today. IP reputation system must evolve to be IP+port reputation system, which is not my problem.
Is there even any IETF work being done on getting port forwards on a device behind your immediate LAN at home?
That's overkill, because servers should have stable addresses and ports. So, we only need statically configured port forwarding.
But if you insist, UPnP by Microsoft has been implemented on almost all NAT boxes. There even exists PCP.
But how much has been implemented in CGNs and how many ISP’s enable it if it is implemented? Getting IPv4 continue to work just add layer upon layer of hacks which we are all continuing to pay for. While we debate more and more services are enabling IPv6 and the traffic is shifting to IPv6.
Do you have any more practical proposals, or..?
What are missing are practical comments.
Masataka Ohta
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews wrote:
I know SRV and other similar proposals so far are not very compatible with URL syntax and should better be simplified.
The only thing difficult to map was non-default ports and that could easily have been addressed.
That's why simplification is desired. See below.
Remember SRV required a seperate RFC to specify how to map existing services on to it. HTTPS just prefixed the label "_<port>”. That could have easily been done with SRV.
HTTPS and SVBC are just SRV on steroids.
Nothing should be HTTPS specific. What is essentially necessary is to map: <scheme>:[<userinfo>"@"]<host> and <scheme>:[<userinfo>"@"]<host>":"<port> to <scheme>:[<userinfo>"@"]<realhost>":"<realdefaultport> and <scheme>:[<userinfo>"@"]<realhost>":"<port> for which RRs like: _<scheme>.<host> MAP <realhost> <realdafaultport> should be just enough.
But if you insist, UPnP by Microsoft has been implemented on almost all NAT boxes. There even exists PCP.
But how much has been implemented in CGNs and how many ISP’s enable it if it is implemented?
As most users are satisfied without port forwarding and even those who aren't merely need static configuration on CGNs, why do you bother?
Getting IPv4 continue to work just add layer upon layer of hacks which we are all continuing to pay for.
We don't need any new mechanism to keep using IPv4 if users can accept external servers, which is the usual case for SMTP and DNS. On the other hand, people still insisting on IPv6 are, as you can see here, still arguing for hacks, most of which are well known and already abandoned but, worse, some of which are new. Masataka Ohta
On Sep 7, 2021, at 19:51 , Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Niels Bakker wrote:
As for well known port, we can specify non-default port numbers in URLs (I'm not sure whether it works for mailto: or not) or. in the future, things like DNS SRV RRs should be helpful. This absolutely doesn't work.
Thank you very much for your emotional and unfounded comment.
It’s neither. There’s no support for SRV RRs in virtually any of the software that would need it in order for this to be a viable solution and it does not appear to be coming any time soon. That’s a fact. Not unfounded and not emotional. You, yourself admit that mailto: URLs don’t have space for a port number (though you express uncertainty, I assure you that they don’t).
And DNS SRV RRs have roughly zero uptake for stuff that matters (web, email).
I know SRV and other similar proposals so far are not very compatible with URL syntax and should better be simplified.
I think the bigger problem is that SRV just hasn’t really caught on and I suspect isn’t likely to. In reality, the effort to modify all the code to support SRV wouldn’t be significantly less than what is required to do IPv6 which would (mostly) obviate the need for SRV as service-specific IP addresses would be easy to assign. The significant problem here, no matter how many different ways we attempt to hack around it is address shortage. The solution to that is more addresses (i.e. IPv6).
Then, to run servers at home, we only need some not-well-known ports forwarded, which can be default or value added service of your local ISP, just like fixed IP addresses today.
Oh and we need to work around the whole IP reputation system that governs email today. IP reputation system must evolve to be IP+port reputation system, which is not my problem.
ROFLMAO — as if that’s at all likely to happen. Further, you have the problem that the port side where this matters is ephemeral meaning that multiple systems (which need different reputations) share the same source address+port combination, so it doesn’t really help. No, IP reputation system must evolve to support 128 bit addresses and some level of heuristic determination of how many of those 128 bits should be applied to a given reputation (probably defaulting to 64 and working left from there). Owen
In fact, I am going to continue with said H.E. IPv6 tunnel, just without advertising it to the network (RA / DHCPv6). I will have to statically configure IPv6 on things that I want to use it on.
There we get to the heart of things. The problem is not with IPv6 or your ISP (*), but with the Netflix software. Doing happy eyeballs and selecting an IP address out of the ones available that they *then* reject because they don’t like it: beyond broken, just plain stupid. Netflix should be using only those IP addresses that it likes (**). Grüße, Carsten (*) Well, an ISP that does not offer 128-bit IP *is* a problem, but not the one that led to this thread. (**) if it needs to deal in address liking at all, which is also fundamentally broken, but seems to be an addiction of their specific industry.
On 9/5/21 12:48 AM, Carsten Bormann wrote:
There we get to the heart of things.
The problem is not with IPv6 or your ISP (*), but with the Netflix software.
Hum....
Doing happy eyeballs and selecting an IP address out of the ones available that they *then* reject because they don’t like it: beyond broken, just plain stupid.
I feel like that might be conflating a couple of things; the selection of $SERVICE's destination IP address, and the $CLIENT's inherent source is coming from. The $SERVICE can choose any number of destination IP addresses. The $CLIENT only has minimal control over which protocol is used; IPv4 or IPv6. I do feel like the $SERVICE could rely on something a bit more intelligent than DNS such that they make a more informed decision based on the $CLIENT's inherent source address(es).
Netflix should be using only those IP addresses that it likes (**).
I don't know if it's the case or not, but I believe that simple DNS based name resolution tends to be largely ignorant of knowledge of the $CLIENT's IP address. -- Yes, there are some options, but those tend to take us way off into the weeds.
(*) Well, an ISP that does not offer 128-bit IP *is* a problem, but not the one that led to this thread.
Agreed.
(**) if it needs to deal in address liking at all, which is also fundamentally broken, but seems to be an addiction of their specific industry.
First: I like the "seems to be an addition of their specific industry". Second: I think that there are technological solutions that would present a better end user experience. E.g. serve a page / redirect that sends the client to an IPv4 only destination. Or at the very least provide a more graceful UX that briefly describes the problem instead of the service falling over leaving the end user -> consumer -> paying customer holding the ball and wondering what's wrong. In many cases, the end user -> consumer -> paying customer is quite likely the party least equipped / ill-equipped to deal with the ""problem. Especially when the so called problem is really something that the $SERVICE provider dislikes and is not a real technological problem preventing communications. -- Grant. . . . unix || die
Grant Taylor via NANOG <nanog@nanog.org> writes:
Hi,
Does anyone have any recommendation for a viable IPv6 tunnel broker / provider in the U.S.A. /other/ /than/ Hurricane Electric?
I reluctantly just disabled IPv6 on my home network, provided by Hurricane Electric, because multiple services my wife uses are objecting to H.E.'s IPv6 address space as so called VPN or proxy provider. Netflix, HBO Max, Pandora, and other services that I can't remember at the moment have all objected to H.E.
Disabling IPv6 feels *SO* *WRONG*! But fighting things; hacking DNS, null routing prefixes, firewalling, etc., seems even more wrong.
Well, that's what I used to do back when I didn't have native v6 and ran into this issue: block v6 at the DNS level. I.e., simply filter out all AAAA records for offending service providers. Pretty simple to setup on your home router (it's usually one or a few TLDs per service provider). It does fail if your clients do DNSSEC validation, but if you do that at the router (or not at all) it should just work :) And yeah, it's an ugly hack that really shouldn't be necessary, but I found it worked quite well back when I used it (a handful of years ago or so), and it keeps IPv6 active and working for everything else... Another solution that I've used on occasion is to do your own tunnelling: find a hosting provider that can provide you a VPS with a v6 prefix and do your own tunnelling to that. This works by virtue of being "under the radar" of the service providers that do this kind of broken filtering, providing you can find a VPS provider whose prefixes are not blacklisted for some other reason (like being non-residential or something). Works equally well by tunnelling to a friend (or other trusted third party) who does have native v6 and a prefix that's large enough to sub-delegate some IP space to you. -Toke
Hi Toke, On 9/5/21 3:07 PM, Toke Høiland-Jørgensen via NANOG wrote:
Well, that's what I used to do back when I didn't have native v6 and ran into this issue: block v6 at the DNS level. I.e., simply filter out all AAAA records for offending service providers. Pretty simple to setup on your home router (it's usually one or a few TLDs per service provider).
I agree that it's not hard to disable AAAA resolution for ... obstinate domains. However, as you say, doing so means breaking DNSSEC more and more often. Of course it's possible to do that, but it's now a second thing that's being done per obstinate domain. :-( I've considered null routing / rejecting IPv6 traffic to prefixes associated with the obstinate domains, but that's not really a set it and forget it thing. Especially if ~> when the obstinate domains use shared hosting thus bring collateral damage into the mix. And yet another (3rd) hack ~> workaround. :-(
It does fail if your clients do DNSSEC validation, but if you do that at the router (or not at all) it should just work :)
Ya. I've been doing the DNSSEC validation on the LAN local recursive DNS server for this reason.
And yeah, it's an ugly hack that really shouldn't be necessary,
Yep. How many ugly hacks does it take before one starts questioning if said ugly hack(s) is (are) the proper thing to do?
but I found it worked quite well back when I used it (a handful of years ago or so), and it keeps IPv6 active and working for everything else...
If you're willing to (break) deal with DNSSEC, yes it does work.
Another solution that I've used on occasion is to do your own tunnelling: find a hosting provider that can provide you a VPS with a v6 prefix and do your own tunnelling to that. This works by virtue of being "under the radar" of the service providers that do this kind of broken filtering, providing you can find a VPS provider whose prefixes are not blacklisted for some other reason (like being non-residential or something).
The operative phrase being "find a VPS provider whose prefixes are not blacklisted". :-/ The workaround ~> hack is becoming more and more problematic year after year.
Works equally well by tunnelling to a friend (or other trusted third party) who does have native v6 and a prefix that's large enough to sub-delegate some IP space to you.
I conceptually agree. However, finding a friend with comparable bandwidth (~1 Gbps) /with/ native IPv6 is ... problematic. It sort of means that you're into the VPS territory. And now you're back to the whack-a-mole game of /which/ VPS provider. :-/ -- Grant. . . . unix || die
Grant Taylor via NANOG <nanog@nanog.org> writes:
Hi Toke,
On 9/5/21 3:07 PM, Toke Høiland-Jørgensen via NANOG wrote:
Well, that's what I used to do back when I didn't have native v6 and ran into this issue: block v6 at the DNS level. I.e., simply filter out all AAAA records for offending service providers. Pretty simple to setup on your home router (it's usually one or a few TLDs per service provider).
I agree that it's not hard to disable AAAA resolution for ... obstinate domains. However, as you say, doing so means breaking DNSSEC more and more often. Of course it's possible to do that, but it's now a second thing that's being done per obstinate domain. :-(
I've considered null routing / rejecting IPv6 traffic to prefixes associated with the obstinate domains, but that's not really a set it and forget it thing. Especially if ~> when the obstinate domains use shared hosting thus bring collateral damage into the mix. And yet another (3rd) hack ~> workaround. :-(
It does fail if your clients do DNSSEC validation, but if you do that at the router (or not at all) it should just work :)
Ya. I've been doing the DNSSEC validation on the LAN local recursive DNS server for this reason.
Yup, me too :)
And yeah, it's an ugly hack that really shouldn't be necessary,
Yep. How many ugly hacks does it take before one starts questioning if said ugly hack(s) is (are) the proper thing to do?
Well, I come from a software background, so in my world the whole thing is held together by duct tape and string anyway ;) And while I can agree in principle, the nice thing about hacks is that you can actually get those to *work*, whereas tilting at windmills to get providers to do the right thing is much harder. So ideally you could do both: deploy the hack(s) while waiting to get the proper fix deployed a decade or two from now...
but I found it worked quite well back when I used it (a handful of years ago or so), and it keeps IPv6 active and working for everything else...
If you're willing to (break) deal with DNSSEC, yes it does work.
Another solution that I've used on occasion is to do your own tunnelling: find a hosting provider that can provide you a VPS with a v6 prefix and do your own tunnelling to that. This works by virtue of being "under the radar" of the service providers that do this kind of broken filtering, providing you can find a VPS provider whose prefixes are not blacklisted for some other reason (like being non-residential or something).
The operative phrase being "find a VPS provider whose prefixes are not blacklisted". :-/
The workaround ~> hack is becoming more and more problematic year after year.
Yeah, I do realise that that particular workaround probably has (had?) an expiry date :( -Toke
Given that, with NAT, IPv4 address space will last forever and that people still insisting on IPv6 requires NAT, there is no point to deploy IPv6. Even for architectural purity, NAT44 can, but NAT46 and NAT64 can't, be improved to have the end to end transparency. Masataka Ohta
On 9/6/21 5:04 AM, Toke Høiland-Jørgensen via NANOG wrote:
Well, I come from a software background, so in my world the whole thing is held together by duct tape and string anyway ;)
Don't forget bailing wire.
And while I can agree in principle, the nice thing about hacks is that you can actually get those to *work*, whereas tilting at windmills to get providers to do the right thing is much harder. So ideally you could do both: deploy the hack(s) while waiting to get the proper fix deployed a decade or two from now...
Yes, it's usually possible to get one or more hacks to work well enough to achieve the desired immediate goal -- $NextStreamingService to work on $SignificantOthersDevice. But, how much time and effort ins required for each $NextStreamingService that comes down the pipe and the associated ill-will of $SignificantOther?
Yeah, I do realise that that particular workaround probably has (had?) an expiry date :(
When is the proper time to give up on hacks and take one, relatively simple, step backwards to avoid all subsequent time / effort / ill-will? -- Grant. . . . unix || die
Grant Taylor via NANOG <nanog@nanog.org> writes:
On 9/6/21 5:04 AM, Toke Høiland-Jørgensen via NANOG wrote:
Well, I come from a software background, so in my world the whole thing is held together by duct tape and string anyway ;)
Don't forget bailing wire.
Heh, true, although I think the baling wire-to-string ratio tends to be a bit higher in the US than over here in Europe :)
And while I can agree in principle, the nice thing about hacks is that you can actually get those to *work*, whereas tilting at windmills to get providers to do the right thing is much harder. So ideally you could do both: deploy the hack(s) while waiting to get the proper fix deployed a decade or two from now...
Yes, it's usually possible to get one or more hacks to work well enough to achieve the desired immediate goal -- $NextStreamingService to work on $SignificantOthersDevice.
But, how much time and effort ins required for each $NextStreamingService that comes down the pipe and the associated ill-will of $SignificantOther?
Yeah, I do realise that that particular workaround probably has (had?) an expiry date :(
When is the proper time to give up on hacks and take one, relatively simple, step backwards to avoid all subsequent time / effort / ill-will?
Well, this is more a question for the philosophy department I'd say... :) -Toke
On Sun, Sep 05, 2021 at 11:07:22PM +0200, Toke Høiland-Jørgensen via NANOG wrote:
Another solution that I've used on occasion is to do your own tunnelling: find a hosting provider that can provide you a VPS with a v6 prefix and do your own tunnelling to that. This works by virtue of being "under the radar" of the service providers...
The content providers are also _currently_ classifying IPv4 and IPv6 blocks as cloud hosting, business access, residential access, etc. You'll have to find a VPS cloud provider that is too low under the content provider's radar to have been already classified as well.
participants (55)
-
Aaron C. de Bruyn
-
Andy Smith
-
Baldur Norddahl
-
Bill Woodcock
-
Bjørn Mork
-
borg@uu3.net
-
Brandon Butterworth
-
Brian Johnson
-
Brian Knight
-
Brian Turnbow
-
bzs@theworld.com
-
Ca By
-
Carsten Bormann
-
Chris Adams
-
Christopher Morrow
-
Colton Conor
-
Denys Fedoryshchenko
-
Doug McIntyre
-
Eliot Lear
-
Eric Kuhnke
-
Etienne-Victor Depasquale
-
Fred Baker
-
Grant Taylor
-
James R Cutler
-
Jared Mauch
-
Jay Hennigan
-
Jeroen Massar
-
Jim Young
-
Joe Maimon
-
John Curran
-
John Levine
-
John R. Levine
-
JORDI PALET MARTINEZ
-
Justin Streiner
-
Mark Andrews
-
Mark Tinka
-
Masataka Ohta
-
Matt Palmer
-
Michael Thomas
-
Nick Hilliard
-
Niels Bakker
-
Owen DeLong
-
Randy Bush
-
Ryan Hamel
-
Sabri Berisha
-
Saku Ytti
-
Shane Ronan
-
sronan@ronan-online.com
-
Stephen Satchell
-
Tim Howe
-
Toke Høiland-Jørgensen
-
Tony Wicks
-
Valdis Klētnieks
-
Victor Kuarsingh
-
Xavier Beaudouin