Tell HN: Hacker News now supports IPv6
My browser just started connecting to Hacker News over IPv6 today:
$ host news.ycombinator.com
news.ycombinator.com has address 209.216.230.207
news.ycombinator.com has IPv6 address 2606:7100:1:67::26
The raw IP address correctly redirects to HN: http://[2606:7100:1:67::26]
Good job so far! Please don't pull a Reddit and turn it off again.
395 comments
[ 3.1 ms ] story [ 310 ms ] threadI recently enabled IPv6 on my home network, and roughly 30-40% of all internet traffic goes through IPv6. Things are noticeably faster, especially connection times to online games on Xbox Live.
My only complaint is that my ISP keeps changing the prefix every quarter or so, so my static addresses need to be updated in the firewall and other places. I am looking into link local addresses but the cocktail of tech is tricky.
Everything about v6 is over engineered with sharp edges.
https://www.prefixbroker.com/news/is-ipv6-faster-than-ipv4-a....
See https://community.cisco.com/kxiwq67737/attachments/kxiwq6773...
The overwelming majority of IPv4 packets have the DF bit set. A large number of services drop inbound fragments anyway (if you get more than a couple a minute, it's almost certainly abuse).
I believe all three large US mobile carriers use NAT64 at this point exclusively, and CG-NAT is quite common in DOCSIS cable networks.
Link-local can sometimes mean needing to append the interface name to your address and a bunch of other weirdness. If you pick a ULA prefix and announce it (or assign some statically) everything pretty much just works.
I’ve been using them internally for over a year and it’s been great, they basically feel like RFC 1918 addresses.
All of this is made much harder by ISPs actively fighting IPv6 adoption. They have the usual moat babble that users do not request it. But in my case they even blocked /protocol/ 40. This was not documented anywhere. Imagine the layers of support I had to work through. Imagine working with new technology and be sure enough that you have exhausted all other possibilities. So learning practical IPv6 has been an uphill struggle for me. Years ago I had a SixXS tunnel going before major adoption took off. Now I am living in another place and wanted to look at it seriously. SixXS was no more so I went with HE. To my dismay dark corners of the Internet have abused these offerings so I have my tunnel disabled most of the time as it gives too much grief. And I have even worked in operations at a large ISP in the 90s. Adoption is not easy even for the willing.
But the reason? No one here seems to mention it: Money. There are no technical excuses left. But it is surely a nice moat.
Sorry for the rant! A good up to date book recommendation would be appreciated :-)
SLAAC is still the way to go downstream, or upstream when you don’t have an ISP doing prefix delegation with DHCPv6. ISPs just want more downward control probably for money and maybe a tiny bit for legal/abuse/security reasons, so they use dhcpv6. secure neighbor discovery would probably be the non-dhcpv6 solution to having link-layer identity, would be cool if isps gave you slaac+send as an alternative to dhcpv6, but that would require average consumers to understand certificates and pki, so fat chance.
edit:
so there’s address assignment and addresses themselves. slaac and dhcpv6 are assignment mechanisms. global, ula, link-local are types of addresses. so the story isn’t really that people hopped from slaac to dhcpv6 to link-local to ula. it’s that slaac is how you configure ipv6 addresses in high trust environments and dhcpv6 came later when isps needed more control rolling things out. I actually don’t understand what problem dhcpv6 solves other than isps presumably wanting to spend less effort to work v6 into their existing systems than to write new utility that monitors their last mile segments for router solicitations and maps to customers that way. slaac is still the preferred mechanism.
then there’s the link-local to ULA transition . really it’s the site-local to ula transition. site local was the indended way to have a private network but had problems. so ot was deptecated. i think maybe before there was a ULA alternative, for link-local made sense in the scene for a hot minute, but now ULAs are here amd they are designed specifically for private site-wide addressing. so thats what is preferred for that.
slaac+ula for private home stuff
nat and dhcp are bad relics
whatever your isp supports/required to get a global prefix delegation. fun fact, you’re supposed to be handed a /48 by your isp so you can have the freedom of 65k subnets but few are so generous.
I never got IPv6 working well until I switched from pfSense to OpenWRT, due to my residential ISP switching prefixes very frequently.
For example, there was no way to get pfSense to not publish the public address of the router as the internal DNS, so every time the prefix changed internet effectively broke.
It was what I did when I had a router that announced only public IPv6 prefixes to the LAN.
For me, IPv4 doesn't break the privacy barrier, IPv6 blasts a huge hole straight into each and every household, office and IoT device on the planet. No, privacy fixes put into IPv6 do not work.
What exactly is the problem with the privacy fixes that were put into IPv6? Why don't they work?
You are correct that this isn't a big issue. SLAAC addresses are generally changed fairly frequently by the OS. As for stateful DHCPv6, well I turn it off for both this reason and the fact that Android doesn't support it.
You can change that, of course, and switch addresses every minute if you want to, but I do find the default a little high.
Identification to the level of IPv4 can still be done with IPv6 by using the /64 where you would previously take the /32, but with IPv6 you also get identifiers from within the network as well.
With how much IPv6 space is available, I'm not sure why SLAAC-based networks don't just assign different IP addresses to different use cases. I can see this becoming a problem on large company networks, but in home networks you could generate a random IPv6 address every hour for every website you visit and still never run out of address space.
Operating systems aren't exactly geared up for per-application outgoing IP addresses, and perhaps handling tens of thousands of IP addresses will bog down the kernel somehow, but in terms of privacy protection we could be doing a lot more than what IPv6 Privacy Extensions are doing right now.
Until browser fingerprinting is addressed, there will be no real privacy.
Problem number two is that the fiber provider doesn't support native v6; it's actually a 6rd tunnel. Latency isn't great compared to v4.
I need to go figure out the ULA situation and do NPTv6. But last I checked, my firewall wasn't able to do NPTv6 with delegated ranges. That may have changed, but I've not found any substantial reason to actually put in the effort to figure out it when my v4 network works fine.
I run a very small site for a local club from an AWS Nano instance. Minimum cost is important. When AWS announced that they would begin charging for public IPv4 addresses, I enabled IPv6 on the subnet (which was tricky), updates the DNS record, and removed the IPv4 address.
In my case, no one notices or cares because they almost always access the site through their cell phones.
I'm turning 40.
The next few months will be fine.
The simple reason people have to start paying AWS for them is that it isn't easy or cheap for AWS to buy large ranges anymore. If it was just "fill out a form telling someone I need 4 million more IPs" then AWS would have some cheap junior technician doing that, but now they need to rake in money to cover the expenses to get IPs and customers that need v4 needs to pay for it.
You can check the rate of handing out v4 ips in 2012* and see that it was never going to be sustainable. The solution to the known-in-advance problem of ipv4 running out was not to .. not hand them out and just leave internet as it looked in Jan-2011 when IANA ran out of networks to hand out. So while it may be fun to state "I heard this long long ago", it just means others had better vision than you.
*) https://en.wikipedia.org/wiki/IPv4_address_exhaustion#/media...
But nowadays the effect is more than visible (especially in my region, Asia-Pacific), with more and more ISPs putting their customers behind a CGNAT. Let me write a parody of one of the classics:
First, they put cellular users behind CGNAT, which is fine because mobile phones don't host services.
Then, they came for residential users on cheaper plans, which is fine because they are not powerusers and so are unlikely to host services.
After that, they put all residential users behind a CGNAT.
...
It is actually what I experienced throughout the last decade in Southeast Asia. Are the ISPs here doing this because they are being cheapskates? No. It's because we are genuinely running out of IPv4 resources forcing people to share them. We did not have the luxury of Western ISPs who were assigned millions of addresses, and buying the addresses is a costly endeavor nowadays with /16 IPv4 block literally costing millions today.
And if you think CGNAT is good, think again: (quoting one of my previous comments)
[...] you can't really build a truly-P2P network nor self-host a service on Internet when everyone is behind CGNAT. At some point, as IPv4 resources get scarcer, only corporates will have the ability to host services on the Internet, and I don't think it is in their interests to host Tor nodes, for example...
The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=37116487 - Aug 2023 (306 comments)
The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=25568766 - Dec 2020 (131 comments)
The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=20167686 - June 2019 (238 comments)
v6 is designed the way it is precisely because it needs to run on the same networks that v4 does, and v6 is a better design than v4 in our world because our world has completely outgrown v4.
> Eschew flamebait. Omit internet tropes.
[0] https://news.ycombinator.com/item?id=38939559
# openssl s_client -connect news.ycombinator .com:443 -tls1_3 CONNECTED(00000003) 4160736388:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1562:SSL alert number 70 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 244 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported No ALPN negotiated Early data was not sent Verify return code: 0 (ok)
For anybody that's curious, the IP-Foo [0] browser extension puts a little 4/6 icon in the address bar to make it clear at a glance which dialect you're speaking for $currentWebPage
[0]: https://github.com/pmarks-net/ipvfoo
In theory, browser vendors could define a narrowly-scoped permission that only reports (hostname, ip), or roll this functionality into the browser UI, but neither seems likely to happen.
I made IPvFoo to promote IPv6 adoption, and wouldn't consider selling it for less than $10M USD. It probably won't ever be worth that much because it's an easily-cloned utility without a "moat", but it's more rational to set a price than refuse to sell under any circumstances.
Miners need the least amount of permissions anyway.
i have no reason to think you'd sell out to scammers, but stranger things have happened and for a product whose whole utility to me is "huh, that's cool" it's not worth it. and i thought that was worth highlighting to others. some chrome extension hygeine is always good.
IPv4: 123.123.123.123
IPv6: 2001:db8::8a2e:370:7334
https://developer.chrome.com/docs/extensions/reference/api/w...
It makes sense that you would notice the change then :D
Was this a situation where you had to do a double-take? Like, you opened HN today and saw that your extension said IPv6 and for a split second you wondered if your extension had made a mistake? Before seeing that indeed HN has IPv6 now.
Hah. You take a strong starting position in the negotiations ;)
Is it hard to get patches into firefox? I never tried, just curious.
But these things auto update. If a government (or even just a moderately big org) really wants to spy on someone, and they determine that said someone uses IPvFoo, $10M isn't a very large price to pay to just get complete access to the target's web browser.
This isn't specific to your add-on in any way, but, well... that seems ripe for takeover by someone nefarious.
I get fun questions from people when I screenshare and they notice the green "6" or the red "4" and ask about it. Sure it doesn't do anything fancy behind the scenes but that's also what makes it perfect.
Also, Chrome (Google) has a habit of randomly disabling or removing side loaded extensions. I even had a side loaded extension that Google forced removal of because Google deemed it contained malware (which it didn't, I know because I wrote it).
You can download the current version and install it manually to get around that. If you do that and read the code you're probably safe.
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Read the code, don't update 'till you read the code, don't use the browser which knows better what is good for you.
I see:
When I put that into the url bar: I also see Hacker News.So that vast address space might not last as long as it would seem...
A reasonable sized /32 allocation would have allowed for giving every ATM they operate worldwide its own globally routable /48.
Those fanboys going "we'll never run out of 2^128 IPs" are being disingenuous when about 2^59 of them have been burnt straight away (I'd guess most subnets have less than 30 devices)
2^64 subnets is a reasonable number, but when they are handed out like candy that number dwindles quickly. ARIN is allocating the equivalent of a /15 every year. That's fine if it's a constant allocation, there's 100,000 years worth, but if that rate grows, the space will be eaten in a matter of a few decades.
* Sparse networks. 64 bits is too big to feasibly do a brute force scan on, which reduces how often servers get exploited by random network attacks. * SEND secures NDP by using those 64 bits for a public key
Reducing network sizes to 12 bits would destroy both advantages.
Snark aside, very much agreed, and I don't like that they got away with it. It's precisely with the mindset of "we'll have enough" that companies like ford have a /8 or the DoD has more /8s that we can count. And with this mindset we'll run out of IPv6 the same we ran out of IPv4.
You're not ment to utilize every address assigned to you. Trying to do so will always lead you to situations where you messed up and need to renumerate.
The more one digs, the more egregious it seems. If the NETIFY webpage is accurate, it shows that Capital One already had "/32" and "/36" blocks, and yet they also got "/16" : https://www.netify.ai/resources/networks/capital-one
And if I'm reading the ARIN fees correctly, it only costs $4000 annually for a "/16" allocation: https://www.arin.net/resources/fees/fee_schedule/
There doesn't seem to be any public transparency of the approval process to explain how a non-ISP company could justify a "/16" block so it just leaves everybody guessing.
John Sweeting from ARIN only confirmed that the "/16" was allocated to Capital One according to policy but he didn't elaborate on the rationale: https://www.mail-archive.com/arin-tech-discuss@arin.net/msg0...
Example reddit discussion : https://old.reddit.com/r/ipv6/comments/17yuqvp/til_capital_o...
For better or worse, you're not; that's for IPv4 /16. For IPv6 /16, it'd be the X-Large service category, so $16,000/year.
Yeah, that's not okay. Either the price needs to go up a lot or they need to include factors other than money in the allocation criteria.
They already do, and simply being able to pay the fee does nothing to qualify you for an allocation: https://www.arin.net/participate/policy/nrpm/#6-ipv6
At least, in theory. I'm not going to attempt to defend the Capital One allocation.
That's an interesting idea for how they justified it. There might be something like 4 billion active credit/debit cards in the US (but they probably weren't all issued by Capital One).
That subnet is large enough to then assign an IP address to every individual atom in that grain of sand.
For comparison, if we wanted to assign every living person on Earth a grain of sand, we would only need a few cubic feet of it (less than 1 cubic meter).
Of course we'd all be paperclips long before they need to worry about networking
As parent said, I'm sure people made the exact same argument about IPv4 back in the day, but comparing it to something else.
And when IPv16 finally appears in the future, people will yet again make exactly the same argument.
You're ignoring the sheer scale of this question. We don't have enough raw materials on this planet, or likely in the observable universe, to produce enough devices that would consume that many IPs.
We could colonize 1 billion planets.
Each of those planets could have 100 billion people.
Each of those 100 billion people could own 1 billion "things" that could be considered "networked devices".
Each of those "things" could consume 1 billion IPs.
We could have all that, and we would still have 70% of the IPv6 space left.
> The decision to put a 32-bit address space on there was the result of a year’s battle among a bunch of engineers who couldn’t make up their minds about 32, 128 or variable length. And after a year of fighting I said — I’m now at ARPA, I’m running the program, I’m paying for this stuff and using American tax dollars — and I wanted some progress because we didn’t know if this is going to work. So I said 32 bits, it is enough for an experiment, it is 4.3 billion terminations — even the defense department doesn’t need 4.3 billion of anything and it couldn’t afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing a experiment to prove the technology and that if it worked we’d have an opportunity to do a production version of it. Well — [laughter] — it just escaped! — it got out and people started to use it and then it became a commercial thing.
- https://www.youtube.com/watch?v=mZo69JQoLb8&t=816s
They were contemplating 128 bits addresses all the way back then, but settled on 32 bits as a mere proof of concept that got out of hand.
The original numbering plan for IP was that each network number became a /8. Which is how we miraculously ended up with 10/8, because network 10 was ARPANET itself, so 'flag day' left 10/8 vacant.
But back to the point at hand. IP itself is RFC 791, September 1981, nice and famous. The addition of classful networking because 255 network numbers wasn't going to last long, was RFC 790.
The first workaround for IP exhaustion was published before IP. It's been a Known Issue since day negative-one.
However, that only works with a /64 prefix and given that larger sites might want to have multiple subnets, that’s why most assignments are /56 or /48.
But still. If all assignments were /48s, that would still leave room for 281 trillion networks which even I believe is enough for the foreseeable future.
If the number space is so big, it makes sense to take advantage of it if that allows for other additional features (like SLAAC)
Well it should be redesigned so it works all the way down to individual addresses.
DHCPv6 also does not work without RA. DHCPv6 just assigns an address, a routable prefix, dns servers etc, it does not assign a subnet or any routes, you need route advertisements for that.
Why? What's wrong with how it works at the moment?
Collisions are very unlikely, and a quick ARP packet should detect them if they do happen.
You can do that, sure. But it's more complex and slower.
Using a mac address in the IP is terrible anyway from a privacy point of view, use a random IP in the subnet, send out a check to see if it's already used, if it is choose a new one. That check is already a feature of ipv6.
Oh and I ended up disabling IPv6 altogether as their router would crap itself with a modest amount of IPv6 traffic. Pulling ~10Mbps of IPv6 would completely DoS the router, as it would not even go as far as answering to ARP. Some quality hardware for sure.
Same goes for ipv6. If you get one single net (and a 'small' one at that), you once again have to resort to trickery to subnet at your end.
Preferably in both cases, you would get a small (/31 for v4, /127 for v6) transport net that goes to the ISP router or your first fw device, then the ISP routes the real net /24 (or whatever size you can get from it on v6) behind your IP on the /31,/127 so that your first device can split this in any way you prefer.
At least with the current state of affairs, you have the option to use ND Proxy instead of NAT66.
As it is, all my interfaces just have these random IPv6 addresses configured which don't work most of the time. I don't get it.
So, if you have knowledge of your mac address (which is what you say you are using for DHCP) then you will know the fe80::<> IPv6 IP too, which, while not globally routable is probably what you want based on this comment.
SLAAC is the replacement for DHCP, it provides a local prefix address (fe80::) and optionally (and, crucially: additionally) provides a publicly routable IP if there's a public prefix available.
You can think of the subject being split into two components:
As a base: You will get a local IP
On top: you get DNS/Public routing.
Here's a bit more about how it works: https://www.networkacademy.io/ccna/ipv6/stateless-address-au...
It is not the host-component of IPv6 that determines routability, it is the prefix.
If you have a link-local prefix (fe80::/10) then it is not global, if it is a private prefix (fc00::/7) then it also may not be global; if it is part of IANA's unicast allocation (2000::/3) it is global (firewall permitting).
It's less infrastructure to run, especially with embedded networks.
> DHCP provides a nice central place where you can map MAC addresses to IP addresses instead of configuring it ad-hoc on every device which needs a static IP address (if you're lucky and the device even supports static IP!).
You are limiting your thinking to macro-scale 'user-managed' devices, as opposed to things like embedded things:
* https://en.wikipedia.org/wiki/Matter_(standard)
(Maybe you meant billions of /64 blocks? ISPs could be providing a /32 ≈ 4 billion /64 blocks, though there still are 2 billion of those in the entire IPv6 space)
Weren't they supposed to allocate a /48? Or did that change while I wasn't looking?
Yes: https://datatracker.ietf.org/doc/html/rfc6177
Have you done the math?
* math property: x^y = x^(a+b) = (x^a )x(x^b )
* IPv4 addresses are 32 bits (2^32 )
* 2^32 ~ 4.3 billion
* So the IPv4 Internet has ~4.3B devices on it
* IPv6 subnets are 64 bits, /64 (2^64 )
So, a IPv6 2^64 subnet is the same as (2^32 )x(2^32 ), which means (4.3B)x(IPv4 Internet). I.e., a single IPv6 subnet can hold the equivalent of four billion (IPv4) Internets.
A second way of thinking about it:
* Stars in the Milky Way: 400 Billion
* Galaxies in the universe: 2 Trillion
So (4x10^11 )x(2x10^12 )=8x10^23 stars in the universe.
* Size of IPv6 address space: 3.4x10^38
Find the ratio between addresses and stars:
* 3.4x10^38 / 8x10^23
IPv6 offers about 430 trillion times more addresses than estimated stars in the universe.
A third way: On the surface of the Earth (land+water), there are 8.4 IPv4 addresses per km2. Not counting the oceans, that would be 28 IPv4 addresses per km2 of land.
IPv6 gives 10^17 addresses per mm2 (yes, square millimeter).
In terms of volume, 10^8 IPv6 addresses per mm3 throughout the Earth.
Imagine a scenario where we have nano-bots to perform "repairs" in our bodies or whatever, and obviously each individual nano-bot use TCP over IPv6 because future software developers are also as lazy as us.
Instead of taking paracetamol, people take nano-bot-shots which include (presumably) millions (or even billions?) of nano-bots that we inject into our bodies. However, they disappear after a week (or some other more realistic timeline).
Now, how many people can use these on a monthly basis before we run out of IPv6 addresses?
- Total number of /64 subnets available: 2^64
- Total number of humans in this future: Let's say 16 billion (roughly twice what we're at now)
To get the total number of months before we'd run out of /64 subnets, assuming each human is absorbing one every month, we divide the number of /64 subnets by the number of humans:
2^64 / 16 billion =~ 1,152,921,505
Divide by 12 to get the total number of years:
1,152,921,505 / 12 =~ 96,076,792
So by my math, assuming the human population stayed steady at 16 billion (which seems just as absurd as the initial premise) we'd have about 100 million years to figure out how to start reusing some of those old subnets before we started running into trouble.
No, I meant it as "You can reuse the subnet after 1 week + N" basically.
> it's just an intellectual exercise and take a stab!
Indeed it was, and thanks for conjuring a gratifying answer :)
These do not have to be globally unique, just unique on the local network.
* https://www.iana.org/assignments/ipv6-address-space/ipv6-add...
Currently all public addresses are being assigned out of 2000::/3. The following are reserved for future (public?) use: 4000::/3, 6000::/3, 8000::/3, a000::/3, c000::/3.
Everything that starts with "f" is a special case, so the vast (vast) majority of address space is cleaved off.
So you want "even billions(!!1!)" of nanobots per allocation. Well I'm lazy, and dynamically allocating a /64 is built right into the protocol. So lets let my medication dynamically allocate out of a /64. How many billions? Billions of billions. So lazy, so sorted.
But of course, I don't want my medication talking to my wife's medication. So lets de-conflict that. In fact, let's de-conflict everyone's medication.
We all know that 32bits is a bit over 4 billion. So 33 bits is going to be a bit over 8 billion. That's enough for now, but it's iffy, so let's go for 34bits, a bit over 16 billion. But in ipv6 world, it's polite to land on a nibble-boundary, so we'll go for 36 to be polite.
I'm going to steal the old allocation for ULA as an example. It was /7, but I'm going to call it /8 because I like round numbers.
So lets have an 8-bit prefix ala ULA. Then an 8bit planet number. Then an 8bit country/healthservice/issuingbody number. Then a 40bit human number, because I ran out of reasons to waste 8's There's our 64bit network number. With 64 bits left for billions of billions of nanobots to dynamically allocate.
The best bit about ipv6 isn't billions, it's that we get to actually structure our networks instead of cramming them into every nook and cranny we can buy.
The numbers are frankly mind-bending. Even if we we make a complete pigs ear of assigning billions of IPs to billions of networks in the current /3, we have space for more than one do-over.
But I do believe there's a higher chance the next /3 will be assigned to Mars.
And the IPv8 would be 0.0.0.0.1.2.3.4 whenever we need it, but probably not for a long time
When I saw all the double-colons and slashes and monstrosities like f00f:00f:::ea//dead::beef/3 I just kept using IPv4.
I can't even remember Google's IPv6 DNS ffs. 8.8.8.8 was easy to remember. Now it's got some hex bullshit in it and a double colon thrown in somewhere.
IPv4 isn't a text based protocol where IP addresses are parsed like DNS. It's a binary protocol where addresses are recorded in binary and adding more address space WOULD BE A BREAKING CHANGE.
Nothing would stop us from formatting IPv6 the IPv4 way except the monstrous length of the resulting address.
Or a strange number with two decimal parts: http://209.216.59087/
Of course IPv4 devices wouldn't be able to use IPv6 addresses, that would be impossible. But it is possible to "keep" IPv4 addresses, just make a.b.c.d to correspond 0.0.a.b.c.d.
Second, IPv6 is not just about addressing, it's a new protocol. Many things are different in IPv6, lots make much more sense. The header structure is different. Etc etc. The address space and notation are just the most visible aspects. But it's like comparing IRC and Signal. It's not just about user names, it's a different protocol.
Third, there are embeddings of the IPv4 address space into the IPv6 address space. For example ::ffff:192.0.2.128. Note the mix in notation. This is a valid IPv6 address! Perhaps a bit more cumbersome to write than your suggestion, but for technical reasons it was preferred to keep things syntactically unambiguous (that it's an IPv6 address).
Source: I work at a large router vendor, in the routing team.
Also, none of this is secret. Just read the Wikipedia page. I'm slightly shocked how a tech forum supposedly full of hackers is posting so much half truths and plain wrong information. It's all easily available and understandable, and it's not like we're discussing neurosurgery or epidemiology where we're all amateurs.
> I grew up with IPv4 (1.2.3.4) and I was expecting IPv6 to just be 1.2.3.4.5.6 with backward compatibility so that 1.2.3.4 would just be 0.0.1.2.3.4 and the 1.2.3.4 dude wouldn't need to change their address.
As you can see, dheera did not state that IPv4 or IPv6 work with strings. They just said that they wished/expected the trivial extension of the IPv4 protocol, with the same notation, and preserving the existing IPv4 addresses. (These are 2 distinct wishes.) Acknowledging that this did not happen.
Nor dheera nor me posted any half truth or plain wrong information.
It wouldn't be trivial in practice. You'd still end up needing to replace everything in between. And if you're going to replace everything in between, you might as well upgrade it to something much larger instead of taking little half steps that will need to be repeated again and again.
> preserving the existing IPv4 addresses
But it wouldn't really in the end. 0.0.1.2.3.4 is still a different address than 1.2.3.4. You'd still end up needing to translate 0.0.1.2.3.4 to 1.2.3.4, aka a 6to4 tunnel. So, you're in the same place in the end as where we are with the current IPv6, just with only a baby step in changes that will probably need to be upgraded again in the future.
Now your border router can announce your assigned transitional prefix, i.e. 53.32.122.91/32, and is responsible for routing packets to a NAT gateway that knows both v4 and v6 and rewrites packets seamlessly each way.
What we are left with is a scheme that allows v6 to exist on top of v4 and continue working across the existing internet, and the only people who need to worry about it or upgrade anything are the ones who need more address space.
But instead they followed the model of baking in every stakeholders random pet project into v6 to get consensus in the hopes of forcing adoption. They put letters in the middle of numbers, and expected us to not hate it like algebra.
If you prefer, you could write an IPv6 address in dotted-decimal notation just like an IPv4 address, or an IPv4 in hexadecimal notation like an IPv6 address. It's just 128 (IPv6) or 32 (IPv4) bits of data after all, the representation is completely independent of the protocol.
For example, you can also reach HN through its IPv4 address by writing http://3520653007/ or http://0xD1D8E6CF/.
Your proposal, as usual for these kinds of proposals, fails to consider how would an "old world" endpoint talk to a "new world" endpoint. An "old world" endpoint wouldn't know about these "additional 5 bytes", and would both send packets without them to "new world" endpoints (confusing them) and treat them as data bytes when receiving from "new world" endpoints. The only solution would be to upgrade all the computers on the "old world" first, but once you have to do that you could move them all to the "new world" instead.
If what you want is just the addressing (for instance, you already have 192.0.2.1, and want to use it for IPv6 without needing to obtain an IPv6 address first), there's already 6to4, which has most of the properties you want: it exists on top of IPv4, your router announces the IPv4 prefix, and IPv6 packets sent to it are transparently routed to a relay router which encapsulates them inside IPv4 packets destined to that IPv4 address (in the other direction, your encapsulated packets are sent to a relay router which extracts the IPv6 packet and forwards it). I've used this in the past to give full IPv6 connectivity to a site which had only a single IPv4 address, and it worked well.
Think of it like the mail service. For the majority of the journey your letter is only routed based on the first 3 digits of the zip code. When it reaches the last mile sorting facilities is when the full address becomes relevant.
You haven't managed to suggest anything that v6 doesn't already do, or anything that would solve any of the problems v6 has when doing it. I'm not sure you even noticed the problems, yet you think you can throw stones at the v6 people, who not only noticed the problems but had to solve them too?
We are now 26 years in and v6 has only gotten serious adoption because mobile carriers came along too late in the game to get enough number resources.
See also the text representation section: https://www.rfc-editor.org/rfc/rfc4291.html#section-2.2
So in addition to having the addresses embedded on binary level, you even have that text notation that uses traditional ipv4 dot-notation!You might ask why they are not more prevalent, but then you will find the practical issues that various transition mechanisms are attempting to solve.
If your issue is with the use of colons at all, they were a deliberate choice so that computers doing string processing could never confuse the two types of addresses.
Wait until you try to write an IPv6 address with a port number in standard notation.
How many people managing networks who knew their ip addresses by heart and typed it regularly for all kind of tasks were put off by the new format and decided, consciously or not, to wait until "I really have to deal with it"?
Some people get really angry when you point that out ;)
Good thing for IPv6 it didn't really have any competitor (except IPv4).
I'm not recommending those DNS servers, just highlighting that "vanity" IPv6 addresses exist now. It's possible that 2222:: or 3333:: could be allocated someday.
https://www.sami-lehtinen.net/blog/ipv4es-the-perfect-soluti...
No, it’s not possible without running into the exact same problems that we had with IPv6 (which actually has various compatibility mechanisms, to the point where now some mobile networks are IPv6 only but still work to let people access IPv4).
The problem with your proposal is the same issue we have now - something that only talks the old protocol can’t possibly talk to something in the new protocol (without the same kind of hacks we use with IPv6 like NAT64/464XLAT), since IP addresses in headers are fixed sized. Which also means that any router in the middle can’t possibly route packets to networks with the expanded addresses. So we have the exact same issue - everything needs to be upgraded to deal with your new scheme, but unless that all happens on the one same day, you need to be able to deal with the old addresses. So you need dual stack, just like with IPv6 until everything is transitioned.
So basically all you’d have with this kind of proposal is exactly the same problems, but it would be more confusing why older devices can’t talk to the newer devices since the addresses would look very similar!
I have an internal DNS server and it would be annoying if it could randomly break and require me to update all the IPs.
Isn't that a pain in the butt?
The most common setup for this is that you have a static link-local address, and a static global address. And listening processes should listen to these static addresses.
Then you have a temporary global address, and outbound connections should use the youngest temporary global address (because temporary addresses don't disappear when they age out, they disappear when they age out AND no existing connection is still using them).
The net effect is that the address you leave in example.com's httpd logs is a temporary address that has no listening processes. And the address you use in dns, mdns, when connecting intentionally, etc is a static address.
I stopped maintaining local DNS and use mDNS instead which updates automatically.
If you don't mind me asking, how did you notice that?
Eg: Sometimes IPv6 is faster due to routing differences.
However, this will depend on each specific game, if they are using all the available space or not. If they're sending 200 byte datagrams, they shouldn't see any difference.
On the flipside, IPv6 has a larger minimum MTU than IPv4, so it could happen that your maximum UDP payload actually goes up when switching to IPv6. So, if the game previously had to send 5 packets to do an update, it might be able to send only 3 when it can rely on IPv6, so maybe latency actually significantly improves.
Not sure if the same goes for game UDP packets, but the optional header stuff in v6 IP packets means more of it goes to the useful parts of the payload and less to "the sum of all protocol bits and flags that is not used by all traffic".
Anecdotally, my ping to HN is consistently 166ms with either protocol. I doubt an extra 20 bytes is going to make any meaningful difference to latency, but I'll leave that for the game devs to find out.
So, we have added 24 bytes to the header because of the address difference, and removed 4 bytes from other places.
Now again, there are many differences between IPv4 and v6 that are much more relevant to latency than this extra header overhead. But it is a real overhead, there is no extra scope for payload. Your observation with ping is just wrong (most likely both versions are just padding the packets up to 64 bytes by default).
https://www.youtube.com/watch?v=An7s25FSK0U
This is an area you want to measure carefully because some of the older reports about IPv6 being slower were artifacts of old hardware limitations or under-optimized software which are no longer relevant.
???
On the internet, most links are faster than 1 Gbps and most paths are shorter than 100 hops, so that's a conservative estimate.
If you're sending lots of 10-byte payloads, then IPv6 requires (40+10)/(20+10)=166% as much network capacity, but are you really filling up an expensive link with VoIP traffic?
In practice IPv6 is newer, which has good and bad sides; IPv6 routing paths are more likely to be using newer (and therefore faster) equipment, but there's also a bigger risk of someone making a mistake that messes up your routing/latency, particularly if your ISP hasn't been doing IPv6 for very long.
Google's IPv6 stats also measure latency compared to IPv4 and in most countries IPv6 has lower latency (e.g. in the US on average you get 10ms lower latency with IPv6). When this chart was new it was mostly the other way around, with early IPv6 implementations being poor https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
If your v4 goes through NAT and v6 doesn't, that's a big thing.
If you have different peering and transit providers in v4 and v6, that's a big thing.
If overhead from address sizes was really a big deal, we'd see work to push larger MTUs and working MTU discovery, but that kind of stalled a while ago. 1500 works for a lot of people, and many major sites drop effective MTU by 20 or so and that makes more things work, and then it gets swept under the rug. (OTOH, I think Android may have finally gotten MTU probing enabled after many years of shipping it disabled; Apple has had very effective probing, at least on iOS for a long time)
You can't see any benefits? Ok. So what does that have to do with HN being available over IPv6?
My, the luxury of not being put under a CGNAT.
If you configure NAT+firewall you're going to be somewhat resistant to configuration mistakes, but you can do the same thing on IPv6 if you really want to. However, for most consumer devices, all you get is "NAT instead if a firewall WITH NAT bypass methods so you can still use SIP and FTP".
Actually, there is! People normally don't notice because NAT is usually co-located with a stateful firewall (since both need connection tracking to work, unless it's the rarer 1:1 NAT). But you can run NAT with firewall disabled, and in that case, it's possible in some cases for a device on the outside to access a device on the inside.
For instance, suppose a NAT router with 192.168.0.x/24 on the inside, and 192.0.2.1/24 on the outside. A malicious device at 192.0.2.2, on the same level 2 network as the router, wants to attack a host inside the NAT. The malicious device can send a packet with IPv4 destination address 192.168.0.x and the Ethernet destination address of the 192.0.2.1 router; if that router has its stateful firewall disabled, it will accept the packet and route it to the target device.
That is: what "protects" devices on a NAT without a firewall is not the NAT, but the use of non-globally-routeable addresses within the NAT, since a packet from the outside won't find a route to your NAT router; but if someone manages to route the packet to your NAT router anyway, it'll be accepted unless a firewall rule blocks it.
(If you want non-globally-routeable IPv6 addresses, you can use ULA addresses, which have similar properties to the IPv4 private addresses.)
So, if I send traffic from 192.168.0.78:19990 to 1.1.1.1:443, the NAT may allocate TCP/29099 for this connection and forward traffic from its public IP, 3.56.54.90.
Then, if an attacker sends a SYN packet to 3.56.78.90:29099, the router will forward that packet to 192.168.0.78:19990. The machine may or may not accept that connection, but the attacker has reached it.
Now, many NAT implementions also do firewall-style tracking, and would not accept this packet unless it came from 1.1.1.1:443. But that is not required for NAT to work, and it requires extra memory per connection (storing the destination IP/port as well as the local IP/port), so I'd bet real devices exist that do this.
[1] https://www.google.com/intl/en/ipv6/statistics.html
[2] https://www.statista.com/statistics/216573/worldwide-market-...
IPv4 is useless.
Also, running dual-stacked servers I can confirm, all scans come via IPv4, so not only it is useless, it’s actually less secure to use it.
so I wish it was even more popular than you state. :D
I have been deploying IPv6 for more than ten years and it really improve many situations (beside larger addresses).
I have to admit, there is a learning curve. But I want to encourage everybody involved in configuring computers to learn.
Also I want to rent about Cisco not using /64 for link local by default, thus being incompatible with BSD systems. Link local must be /64.
I find that HN views IPv6 noticeably more harshly than many other communities I have been a part of (e.g. networking subreddits and gaming communities). I am curious of the reason behind this.
The use of hex is very helpful when you're calculating subnets. You want a /48 prefix? Just take the first 3 hextets. /56? First 3 and a half hextets. /64? First 4 hextets.
The new Godwin's Law, any discussion about IPv6 will inevitably lead to someone suggesting IPv4 with extra octets.
DNS exists to solve the problem of people not having to remember or type IP addresses. This is true regardless of whether you are talking about IPv4 or IPv6.
Background and current options, as I'm aware of them:
"IPv6 addresses are too difficult" objectors don't seem to want a solution to the ease-of-use problem that leverages aliases, because DNS is that. They want the ease of typing in IPv4 addresses without any overhead of setting up alias mappings or trusting local hosts' ideas of their own names. That's not possible, in general, with an addressing scheme that's 4x as big. The standard representation has tried to improve things with hex instead of decimal and collapsing the longest run of 0-fields. It could have used a higher base than 16 [1], but that would slow visual spot-recognition of an address. It could have dispensed with all the ':' chars, but that would prevent collapsing addresses and make chunking more difficult.
DNS as an aliasing scheme has many administrative forms. It can be configured per-machine with /etc/hosts (copied around manually, or with scripted or configuration management tools); on a trusted local network with mdns and ip autoassignment, if the network is trustworthy enough; or manually with a full-fledged DNS server, either private or public. More complex network environments leverage tooling to make DNS as painless as possible. The mappings still have to be configured and managed somewhere, even if that's separately per host via what hostname they each think they have.
It's also possible to assign stable, short local addresses that can be remembered and typed easily roughly on par with v4 addresses (10.0.x.1 vs fc00::x:1, which becomes shorter than IPv4 for x==0).
[1] See RFC 1924. Who wouldn't love to use addresses in the form of "4)+k&C#VzJ4br>0wv%Yp" ?
Under IPv6, you run into problems long before DNS - trying to assign static addresses as DHCPv6 is an afterthought, also whole setup has to be robust somehow when the whole network prefix changes.
Seriously, I have yet to see a good tutorial how to herd IPv6 LAN with reliable local DNS, as is usual with IPv4. Everything is just handwaved away "nah, zero configuration". The reluctance to adopt it could stem from that.
Macs and iPhones have relied on mDNS for years. Windows supports it. Android supports it since 2022. Linux has avahi.
If people could look a little further than the tip of their nose, they’d realize how much easier it’ll be to explain to people to just type in alices-iphone.local instead of trying to find the IPv4 address first.
At some point -- maybe when 60%, 70%, or 80%, or 90% of the Internet is running on IPv6 -- Internet services at a large scale will begin to deem IPv4 as a liability, and drop IPv4 support along with the addresses they are holding.
I am not talking about a distant future either. We already have IPv6-only servers up and running, mine included, and we haven't even reached the 50% milestone. In a way, the existence of IPv6-only servers meant that IPv6 is _already_ preventing IPv4 address depletion, because those servers would otherwise have to compete for IPv4 addresses with the other servers too.
Furthermore, I find "I hate IPv6 because it hasn't eliminated IPv4" a really weird opinion (it's not exactly what you said, but it is how I interpret your first few comments combined) because it's sort of recursive: hate IPv6 -> continues to use IPv4 -> IPv6 is unable to eliminate IPv4 -> hate IPv6??? Perhaps you can elaborate on it further, but I don't think it will be agreeable either way.
What do I mean by making IPv6 first class? Basically a transition plan/mechanism where IPv6 is interoperable with IPv4. This was one of the primary considerations at the time when IPng were still deciding, where other contenders at the time had a better transition plan story. Instead the IPng group chose the technology that didn't have any transition plan because they liked the shiny new features that were irrelevant to averting the address exhaustion situation. Their failure to address the transition back then is why we're in this IPv6 adoption bottleneck.
I don't get your claim that it's a separate island at all. It's not. This machine is v6-only and isn't on an island, it has full access to the entire Internet.
For IPv6 transition mechanism you can look into the ngtrans mailing list regarding AutoIPv6 which is basically an extension of 6to4 but instead of connecting IPv6 networks over IPv4 it would extend to IPv4 hosts. There's also an archive link in my post history which you can lookup (on phone).
As for current v6 being interoperable with v4, that is patently false.
[1] https://datatracker.ietf.org/doc/html/draft-ietf-tuba-transi...
> As for current v6 being interoperable with v4, that is patently false.
This machine is v6-only and can reach the entire Internet, including v4-only hosts. It clearly has more interoperability than you're claiming or this wouldn't be possible.
As for TUBA, the transition plan incorporated tunneling, with a bit more thought put into this we could've had something similar to AutoIPv6. That document was just a starting point and outlined some important aspects of the criteria such as low administrative overhead for transitioning IPv4 networks to IPng, something which IPv6 falls completely flat on.
> As for TUBA, the transition plan incorporated tunneling
The transition plan for v6 also incorporates tunneling (6in4 is the same thing as the EON tunneling described in the draft you linked), so again I ask why TUBA counts as having a sane transition plan when doing the same things in v6 doesn't.
There's not much administrative overhead involving in transitioning a network to v6. For most people it involves doing exactly no extra work beyond what they already do to deploy v4. Of course, you do need to reconfigure anything that's been configured such that it can only work with v4 (and this might be quite a lot of stuff), but that was always going to be necessary no matter what you're transitioning to.
By the late 2000s it was clear as day that 6to4 wasn't working out (the design rationales of contemporary IPv4<->IPv6 transition technologies will tell you why [0]). By extension, AutoIPv6 which was building on 6to4 was also unlikely to work out. Even worse, AutoIPv6 relies at least partially on anycast 6to4 which was later deprecated due to operational problems [1].
The only surviving 6to4 derivative is 6rd and even that is mostly phased out.
>As for current v6 being interoperable with v4, that is patently false.
You need to define your scope. Are you talking about programming? Or ability for IPv6 clients to talk to IPv4 servers? Or...?
IPv6 is interoperable with IPv4 from a programmer's perspective, once you upgrade your sockets from accepting sockaddr_in to accepting sockaddr_in6, your program automatically receives both IPv4 and IPv6 packets with IPv4 addresses represented as ::ffff:x.y.z.w.
And from a client's perspective, IPv6 clients absolutely can connect to IPv4 servers through a border relay of some sort, typically NAT64. But you can do SIIT as well if you are feeling fancy. Note that this is not much different from 6to4 and its derivatives.
As for the perspective of a server, indeed this is unsolved but again AutoIPv6 doesn't solve the issue as well since the server still needs a public IPv4 address.
[0]: https://en.wikipedia.org/wiki/IPv6_rapid_deployment#Comparis...
[1]: https://datatracker.ietf.org/doc/html/rfc6343#section-3
Not sure what you mean you can't use the Internet without IPv4. Yes some sites won't work but some sites don't work with https but that doesn't mean you can't use https on the internet
At $DAYJOB we are already running some services on IPv6 only to save costs, and if our IPv6 connectivity drops people notice it immediately. Is IPv6 still considered a second class citizen when this is the case?
Here's a reminder that "the Internet" is not just Google, Facebook, and Amazon.
Gamers understand the consequences of not having it when they want to play with their friend but both are behind CGNAT and they can only play games with a server run by someone else and not any that use P2P multiplayer.
HN users can afford the $2/month/server that AWS or whoever charges today and besides your standard SPA + REST API doesn't really care how many layers of NAT and proxies it's behind.
IPv6 will, finally, enabled the real internet: all p2p protocols will start to work seamlessly. I am thinking a super simple no-dns IP (audio|video) phone protocol listening only on tcp 1 port, new bittorrent like protocol for live streaming, etc.
Since IPv6 has been almost everywhere in my country for years: enjoying ssh session everywhere (ipv6 mobile internet), without any domestic NAT to configure.
But, still... steam... github... and some "rogue" (:P) smtp servers.
That said for HN, where is the champagne?
I get an ipv6 for my phone through Wireguard that way.
Yes. You also have to get an ASN though, and an ISP which which will advertise both over BGP.
(If you qualify for one, there's little downside to requesting it at the same time as your IPs, though)
If we want that, global orgs in charge of the global phone number mapping must coordinate around some slice of the IPv6 address space (what they already do with international roaming of phone numbers). This will be very hard to operate safely, very probably.
I don't know if it's actually being used. IIRC since then everything has moved to a higher layer.
A good idea? No.
IP addresses are used for routing. Every provider-independent block of addresses needs its own entry in the global routing tables, which are stored on basically every BGP router in the world. There's a limit to the size of these tables, as they need to be stored in special TCAM memory.
Note that IPv4 currently has many more routes than IPv6 not only due to higher adoption, but also due to higher fragmentation: some providers are obtaining many small non-consecutive blocks from different sources (buying addresses wherever they are cheapest), which results in a large number of routing entries. The increase in the overall table size means all other ISPs have to buy new hardware sooner than they would have without the increase caused by fragmentation. Everyone having their own personal address block would cause even worse fragmentation issues.
The processes involved wouldn't really scale if normal people were going to do it either, but if it's something you care deeply about and are willing to spend the time on, it is possible.
As another poster said, you can get a tunnel from Hurricane Electric, or some other tunnel brokers, and that works too, although it's not as flexible --- HE tunnels are not geographically flexible, you pick where your tunnel is assigned, and those addresses will always be routed through that location. If you move far away, you'll likely want to setup a new tunnel in a new location for performance reasons.
But won't that also have disadvantages? NAT obscures which natural person is responsible for any given household traffic, which makes user tracking and surveillance harder.
IPv6 has roughly the same level of privacy; your client device's IPv6 address changes every few hours. Yes there's a minor loss since an association can be made during those hours, but arguably with the generally low number of people sharing a household internet connection I don't think it's a huge difference.
Actually, this should be a base service of mobile internet. The various carrier peerings will define how "efficiently" your traffic is routed (realtime audio/video...).
The blocker is the billing scheme I guess (as usual...).
I have… concerns about removing NAT from everyone’s house now that IOT is a thing. Could it be done safely? Yes. Will it? Signs point to no.
Even without a firewall, a /64 is an extremely large amount of space. It's nearly impossible to find active hosts by port scanning, compared to v4 where it's trivial to scan the entire address space. We won't end up in the same situation we were in on v4 back when nobody used firewalls, and that's not just because our networks mostly have firewalls these days.
This is probably most of it.
My gripe is that there is essentially no realistic end to ipv4 in sight. So we as an industry carry the debt of securing, managing and troubleshooting parallel v4 and v6 networks for decades.
If ipv4 had an EOL it'd make the transition so much better
IPv4 will never go away, but will be smaller part of the Internet.
It will absolutely hang around in small private networks for 50 years (there's still some token ring networks out there)
I run my desktop with no v4, so it's clearly possible to push handling for v4 out of your network. You could outsource it to somebody else even, for example by using one of the DNS servers listed on https://nat64.net/.
The migration strategy for ipv4->ipv6 was just so horribly conceived that we'll be running both in parallel for decades.
TBH I think it would have been better if ipv6 was named something else entirely. Running TCP and UDP in parallel doesn't raise any flags, but running two versions of the same protocol in parallel is strange.
I don't think it was horribly conceived. I think it's close to the best we can do given the constraints we're working under. These constraints include the fact that there are millions of networks being run by millions of people and nobody is in a position to force all of these people to stop using v4.
That will drop the quality of the v4 internet, things will break and be slow to be fixed because who cares about the <10% v4 only traffic?
for most people, it is transparent and doesn't improve anything... ipv6 could be disabled on their router and everything would be the same (I actually used to disable ipv6 at router level to avoid inadvertently leaking data on ipv6)
Don't twist that effort into a reason to not deploy v6.
My T-Mobile connection issues an IPv6 address but fails online “is my IPv6 working?” tests.
I enjoy it on my private networks but simply can’t rely on it on the Internet yet.
There's nothing I do that IPv6 makes better, and switching to it is a very large and painful task, so delaying that switch until it's required doesn't seem unreasonable.
In any case, considerations like that are part of why I'm putting off any serious effort or decisions until it's required.
You've spent longer talking about not deploying v6 than you would have done deploying it. I said this before, but I suggest you sit down and turn v6 on for your network -- and *just* that, don't start gaming out how to disable v4 or deal with devices that don't support v6 or anything else, *just* do the basic enabling v6 on the network part. That way you'll see that you're seriously overthinking it.
But you won't listen to me, because http://habitatchronicles.com/2004/04/you-cant-tell-people-an...
I guarantee that I haven't.
> I suggest you sit down and turn v6 on for your network
I did this a long while ago. I apologize for giving the impression that I haven't. But actually using IPv6 in any serious way takes more than just turning it on. It requires reconfiguring a nontrivial number of machines/devices, figuring out how to accommodate the many machines/devices that aren't able to use IPv6, and so forth.
Now, I will admit that I'm still learning IPv6 stuff and as a result there are likely things that I'm overthinking. But responses like yours don't move that ball forward any. You're just scolding people for not being experts.
It's about like a back end geek not knowing how to do loopbacks with their router....sheesh!
Either way though, the inherent value in the technology is what has to drive the adoption and the value is already there it's just a matter of IPv4's value still holding well enough for now. As such I don't inherently mind 0/8 being available on Linux these days and wouldn't inherently mind 240/4 either but a completely separate set of "yes, you can configure that address but the problem is with getting between there and here not accepting it" is a bit disappointing for just another short term response to the problem.
Unrelated but kickass work on packet scheduling btw.