* Posts by Nanashi

312 posts • joined 19 Sep 2016

Page:

IPv6 is built to be better, but that's not the route to success

Nanashi

Re: Won't happen in my lifetime

v6 isn't forcing you; it's allowing you (compared to v4, which generally forces NAT). You can still do everything you do on v4. v6 also has privacy extensions to mask your IPs without causing the problems NAT causes. They use a different method (masking the IP with a different, random IP+port instead of a different, fixed IP+random port) but it achieves the same general goal.

I think you're worried about something totally unimportant here. Your browser is a far bigger risk to everything than people seeing your IPs (without even being able to connect to them!) is. But v6 has your back anyway.

Nanashi

Re: "I don't always need to look up the address of a bit of kit I need to contact"

It doesn't toss that knowledge out. Most aspects of v6 function exactly the same as v4, just with longer addresses.

The extensive retraining for security shouldn't be that extensive -- if you know how to secure a v4 network, then you already know how to secure a v6 one, so just do that. No retraining needed. Not having to put NAT on top is a simplification that makes everything easier.

As for using 48-bit addresses... it wouldn't be enough. We don't want to be spending all this effort deploying a new protocol that's still so small that we need to continue being stingy. It would also require doing all of the same things that we've needed to do to deploy v6, and would have the same compatibility properties as v6 does, so it wouldn't help on those fronts.

Nanashi

Re: Won't happen in my lifetime

Well... it's worth noting that they don't really have sufficient address space. It's almost impossible to get more than one v4 IP from most ISPs, yet almost everybody has an entire network of devices that they want to attach to the internet, not just one single device.

I imagine larger and larger ISPs are going to end up moving to CGNAT too, since AWS and friends are always in the market for more v4 space, so even getting one single v4 address is going to get harder and harder. This is already happening frequently in Germany and some nearby countries, and I don't see any reason for it to only happen there.

Nanashi

Re: Won't happen in my lifetime

It sounds like you want to use a proxy server to reach the internet, not routing. v6 won't stop you doing that. Even if you route, it has privacy extensions, which masks the number of devices you have.

You can easily set up a private network which a random stranger on the internet can't access. Routers will typically do that by default, so it's no harder than just plugging them in and using them.

You'll be replacing your hardware at some point or another. Just make sure that the replacements support v6 when you do, and you'll get v6 support along with the upgrade that you were paying for anyway.

It seems like most of your issues aren't really an issue.

It's interesting that you think v6 is actively hostile to NAT. The only thing v6 does against NAT is to give you enough address space to not need to use it. Apparently you won't use NAT unless forced into doing so...? But that's inconsistent with the rest of your post.

Nanashi

Re: NAT isn't your first line of defense, the stateful firewall is.

No, it doesn't. All it does to incoming packets is rewrite their dest address header, and only if they match a connection that's being NATed (or a static port forwarding rule); it doesn't decide whether or not to drop incoming packets.

Nanashi

Re: Won't happen in my lifetime

It's not against RFC1918. You're allowed to send packets with RFC1918 destinations through routers.

It would be a bad thing to do, but if you could rely on "nobody ever does bad things" to keep you safe then the world would be a much nicer place.

Nanashi

Re: "I don't always need to look up the address of a bit of kit I need to contact"

It's not really niche when it has almost two billion users. v6 is just hard to scan because it's so huge. Exhaustively scanning one /64 requires something like a million terabytes of traffic. If you're on a regular, slow 10 Gbit/s link that'll max it out for thousands of years.

(Obviously there are methods of finding hosts that aren't exhaustive scans... and people do use them on v6. You just won't see a constant stream of opportunistic scan attempts on every single address for every minute of every day.)

IPv4 addresses aren't exhausted, just their allocation is. a good 90% of them just aren't seen on the internet.

When we say exhausted, we mean that people have to take measures to conserve addresses due to not being able to get enough of them. The beginning stages of exhaustion happen when people start needing to do that. We're deep, deep into it for v4.

Also, due to the way hierarchical aggregation and routing works, most individual IP addresses don't end up assigned to actual end devices, so "I haven't seen any internet traffic from 90% of addresses" doesn't mean that v4 is only 10% used.

I'm also going to point out that there are more individual devices than there are v4 addresses, so there's not going to be enough no matter how you slice them.

TBF if the internet core was run on v6 with BGP and everyone used NAT and RFC1918 addresses internally, there is no need for the added complexity of v6 inside an organisation

You mean the reduced complexity... and you would in fact need it, since v4 doesn't handle more than 32 address bits.

the NHS internally uses the RFC 1918 class A space and it hasn't exhausted it yet.

But the fact that they're using it at all is an indication that v4 is insufficient. Why go to all the added complication otherwise?

IMHO when they designed v6 they went overboard on the address space

Absolutely! Overboard is good. We want to have more address space than we can use, because the alternative is that we'll end up using it and will need to deploy another extension. As you might have noticed, that's a very difficult, expensive, long and drawn-out process that we really only want to do once.

Nanashi

Re: Won't happen in my lifetime

To be more accurate, your ISP can't route anything to that network because they're not connected directly to that network. To get a packet to your network, the ISP has to send it to your router first, and then your router passes it on.

You should realize, however, that your ISP can do that. They can send whatever packets they like to your router, and they can put 10.0.3.19 in the dest header of those packets if they want, and your router will happily route it onto your network. NATing your outbound connections won't stop these inbound connections either, although a firewall configured to block inbound connections will.

Also, this behavior is exactly the same regardless of what network range you're on. It would work the same even if only one machine had 10.0.0.1. It would work in any network range, v4 or v6, not just the RFC1918 ones.

Nanashi

Re: People do not want it

I wasn't overlooking that question. I was asked it multiple times, and answered it each time. It's just not relevant to my point of "your security isn't being provided by NAT".

Nanashi

Re: Won't happen in my lifetime

v6 networks aren't automatically routable. It's the router that does the routing, and the router can choose not to route or to drop whatever traffic it likes.

To be clear, that means you don't need NAT to set up a non-routable network. (And, er, you generally don't want a non-routable network anyway; most people want their network to be connected to the Iinternet. Otherwise you won't be able to reach any websites, services etc that are on it.)

If you want internet connectivity but don't want random people connecting to your machines, a default-deny inbound firewall is the way to go, and has been since forever, including in v4.

I didn't dodge the question in my previous post. Nobody asked about routability, and I did answer the question about "locks" (which I took to mean access control).

Nanashi

Re: Won't happen in my lifetime

The same way you do it in v4? You put a firewall on the router that rejects inbound connections by default. It's the exact same firewall you already need on v4 to be secure, so you already know how to do it.

If you're using iptables, it looks something like this:

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

-A FORWARD -m state --state INVALID -j DROP

-A FORWARD -i lo -j ACCEPT

-A FORWARD -i lan0 -j ACCEPT

-A FORWARD -j DROP

Nanashi

Re: Won't happen in my lifetime

Perhaps you should first explain why you think you'd need to set locks on every single device for v6.

That's not necessary. You just set the locks on the router like you do in v4.

Nanashi

Re: NAT won't block it.

Wrong. What NAT does is make your entire LAN appear to be a single host to the WAN.

No, it's right. Your description is more of a high level "here's a rough idea of what it does", not a low-level description of how it actually goes about doing it. Those low-level details matter.

* Private IP address - Dropped immediately. Least-wise I doubt anyone has ever implemented a NAT system that did anything other than immediately drop the packet since by definition it is invalid.

You should test! Linux accepts the packet. So does every other NAT that I'm aware of the behavior of (I haven't tested everything).

* Public IP address - if it doesn't match the router's, drop it.

That's not accurate. It'll go through the router's routing tables like normal.

* Public IP address - if it matches the router's then look in the connection mapping table for a match. If found change the destination address to be the private address of the initiating host and send the packet onto the LAN. If no match found in the table, give up and drop the packet.

Also not accurate. If there's no match in the table, it doesn't drop the packet, it just... doesn't change the address. The packet then gets delivered to whatever IP it was already addressed to.

To be clear, it's extremely common to deploy a firewall that does do the various drops you're describing here. It's common precisely because NAT won't do it. The CPE you're running in your house almost certainly does drop this stuff, because it has both NAT (for v4) and a firewall.

I'm simply pointing out that it's not NAT that's doing the dropping.

Nanashi

Re: People do not want it

you now acknowledge that the router must check the nat table for a corresponding entry to know which internal host to forward the traffic to.

Not quite. The router has to check the NAT table to see if the dst header on an incoming packet needs rewriting. If it does, it's rewritten, otherwise it's not rewritten. Actually routing the packet is done separately, by the not NAT parts of the router.

Now, the final hurdle for you, how can the router forward the packet to an internal host if it has no corresponding nat entry that matches the src-ip, src-port, dst-ip, dst-port details in the packet......

Easy: it looks at the dst IP header of the packet. Same way any router does it.

to save on gears grinding, the answer is that it can't forward something it has corresponding entry for as it won't know which internal host to rewrite the dst-ip & dst-port details to.

It can, because rewriting isn't necessary to forward a packet.

If the dst IP header of an incoming packet contains an IP from the network range on your LAN after NAT has rewritten the header, your router will route it onto the LAN.

If the dst IP header of an incoming packet already contains an IP from the network range on your LAN when it arrives at the router... your router will still route it to the LAN. It doesn't care whether the NAT stage rewrote the header or not.

Nanashi

Re: People do not want it

Neither of those articles are relevant. They're talking about how packets go over the internet, whereas I'm talking about NAT. The question isn't "how do I get a packet to your router", it's "what does NAT on your router do to the packets that arrive at it".

The answer to that question is that the destination address (for a packet coming in from the WAN) is looked up in the NAT state tables, and if an entry exists then the address is rewritten per the state entry, and if no entry exists then it's not rewritten.

Notice that nowhere in the answer is "the packet is dropped". That's because NAT won't drop the packet. Again, this is something that I've tested on real networks, and it works like I'm saying it does, not like you're saying it does. And, again, you can test it yourself if you don't believe me.

The fact that we can get this deep into a reply chain and people still can't get their heads around "NAT doesn't drop packets" just goes to show how badly people understand its behavior.

Nanashi

Re: Scary!

It shouldn't be terrifying. All it means is that no other machine on the internet is using the same IP at the same time.

You'll still be the one to decide whether those devices are reachable or not.

Nanashi

Re: People do not want it

If I want to get to your 10.x address from my public 9.30.1.30 address how do I put that in the ipv4 packet?

You put the 10.x address in the dest field, like I said.

You put the dst-ip in the dst-ip header but how does my isp or any intermediary know to send my ipv4 packet to the public ip of your router and not to literally anyone of millions of other public IP’s of end point routers for onward routing?

They don't. Like I said! You'd need to be on the immediate upstream network to arrange for a packet with an RFC1918 address to arrive at your router's WAN interface.

NAT is exactly like that port forwarding but dynamic [...] and forwards to that machine.

Okay, so, here's the big question: what exactly happens when a packet arrives at the WAN interface and it doesn't match an active NAT state table entry?

I've tested this, multiple times. The answer is that the packet is routed based on whatever IP is already in the packet. If that IP is the router's IP, then the packet is delivered to the router itself. If the IP is from the LAN-side network, then the packet is routed to the LAN network.

To be clear, the packet is not dropped, not unless you also configure a firewall that rejects new inbound connections.

If you think I'm wrong about this, then please explain why I see it happen when I test.

NAT MUST be stateful, it keeps track of connections, removing closed, old, & dead ones.

Stateless forms of NAT do exist, but okay, the form of NAT that we're talking about here is indeed stateful. But...

If you nat then you have a stateful dynamic firewall.

As I've said multiple times, no, you don't. You don't automatically get a firewall along with NAT. It's usually very easy to get one, and they're commonly configured together, but they're still separate things.

You can test this yourself if you want. Just set a test network up in a few VMs and watch the behavior. You'll see it matches what I've been describing the whole time.

Nanashi

Re: But it will happen

Okay, let's consider the SOHO market.

v6 is obviously overkill here, like it is everywhere. That's a good thing -- you don't want underkill, because that's just another way of saying "not sufficient". It doesn't create much network complication though; v6 networks are simple, unlike in v4 where the combination of RFC1918, NAT, split horizon DNS, VPNs and RFC1918 clashes makes a massive mess.

If your DNS is broken, you fix your DNS. Maintaining working DNS is just part of the basic responsibilities for anyone running a network, SOHO or not.

As for your printers, you probably don't need to access them from outside your network, so you could reasonably stick them on a ULA prefix, meaning they could have a static IP like "fd00::10". That's shorter than almost all v4 addresses. It's not like reading a full, unabbreviable v6 address is that difficult (about the length of four v4 addresses), but you don't even have to do that much.

Also! Having v6 doesn't mean you don't have v4, so what's stopping you from connecting to your printers over v4 if it's really such a big deal?

It feels like you're just listing excuses to justify failing to keep up with moving Internet tech.

Nanashi

Re: Won't happen in my lifetime

Ooh, I'm popular!

Nanashi

Re: NAT won't block it.

I'm talking about NAT. I think I've said it enough times to be clear on that.

Nanashi

Re: People do not want it

No, NAT won't block it. NAT doesn't route anything. All it does is rewrite the src or dest headers on packets; any firewalling or routing is handled by the rest of the networking stack. You don't need a state table entry for basic routing to work.

You can’t directly route to rfc1918 addresses across the internet.

Correct.

Of the billions of systems that have 10.x addresses behind nat how do you know which router to send your rfc1918 traffic too?

If I want to access a network behind your router, then I send the traffic to your router.

ISP’s drop traffic with rfc 1918 dst IP’s.

They should do, at least.

Also how do you send something to your router from the internet with an additional dst ip? TCP packets have just 1 dst ip.

You don't. The TCP packet's dst address would be set to 10.0.0.234.

Because that's RFC1918, the only way to get it to your router would be to have a machine on your immediate upstream network, configured with a route for 10.0.0.234 via your router.

When the packet arrives at your router, it won't match a NAT state table entry, so NAT won't touch the dest IP. Your router will then follow its routing table entries and route it to your local network.

Nanashi

Re: NAT won't block it.

No, it knows what to do with inbound packets: it delivers them to whatever IP is in the "dest" header, or perhaps forwards them on to another router to handle. If it's tracking the connection that the packet belongs to, then it'll rewrite the header first and then deliver it, but if it's not tracking the connection it'll just deliver it to whatever IP is already there.

There is simply no way you can launch an attack against my 192.168.1.106 from outside my LAN

Uh, yes there is. I just explained how to do it in a post up this thread.

NAT won't stop connections to 192.168.1.106 from outside your LAN, and if you think it does then that's because you've gotten confused about what NAT does and doesn't do.

NAT rewrites the apparent source address of outbound connections. An inbound connection is not an outbound connection, hence NAT does nothing to it. That means inbound connections will either be possible, or not, depending on the behavior of the parts of your network which aren't NAT.

Nanashi

Re: NAT isn't your first line of defense, the stateful firewall is.

NAT isn't a stateful firewall. Stateful NAT requires state tracking and so do stateful firewalls, so they're often implemented together (e.g. netfilter on Linux), but that doesn't mean that NAT is a firewall.

NAT rewrites the apparent source address of outbound connections. That's all it does; it doesn't decide which packets to drop or not drop.

Nanashi

Re: NAT won't block it.

I'd think a packet bearing a destination address in a private ip block would have trouble getting routed over the internet.

Of course, but we're talking about NAT here, not private IP blocks.

Moreover, any decent NAT implementation is likely to take a dim view on (drop) packets coming in from the WAN interface with a LAN destination address.

That would be a firewall, not NAT. NAT implementations don't drop packets, they just rewrite the src or dest headers.

Nanashi

I'd fire you too with answers like that!

It's measurably faster (https://www.youtube.com/watch?v=76XbdedSrww), it's cheaper (no NAT, no split horizon DNS, no RFC1918 clashes, easier-to-understand network...) and it can be deployed incrementally and without outages.

If you need to replace networking gear at this point, either you're running stuff from 2005 still (so it's due for replacement anyway) or you bought v4-only hardware recently, which is your fault.

It sounds like you just don't know what you're doing. That's not v6's fault.

Nanashi

Re: Won't happen in my lifetime

You don't think going from 0.4% of the Internet’s client base to 38% over those ten years means anything?

At that rate, we'll be at 50% in three years. Predicting 10 years for something that ends up taking 13 years is pretty good going for long-term time estimates like this.

Nanashi

Re: If IPv6 had just been a sensible addressing extension then it would have worked

v6 is 128 bits because 64 isn't enough. EUI-64 addresses are 64 bits, and IP provides hierarchical allocation and aggregation on top of that, so it needs to be bigger than 64 bits. The next power of two up is 128.

Also, you might have noticed that deploying a new IP protocol is an extremely disruptive and expensive operation. We really don't want to have to do it again.

> A sensible alternative would have been to just extend the addressing from 32 bits to 64 bits with a direct map from IPv4 address aaa.bbb.ccc.ddd to IPv6 address 0.0.0.0.aaa.bbb.ccc.ddd

Ah, yes, but... how would this help? Even if you have a direct map, v4 hosts still couldn't talk to v6. In fact v6 already has a block allocated to this -- it's ::/96, allowing for ::aaa.bbb.ccc.ddd, exactly as you suggested. It's just not useful.

> One obvious (to everyone except the IPv6 designers) result is that routing in IPv6 is a nightmare needing far bigger routing tables than IPv4.

How is it a nightmare? v6 routing tables are much smaller than v4, due to the sheer size of the address space, which allows for significant aggregation. It's not hard to find ISPs with 500 v4 announcements and one single v6 announcement, covering the same network.

I'm also not sure about this "kitchen sinks" bit.

I think we should be glad the design of v6 was left to people who understood what they were talking about, not the many people in these comments who have no idea what the technical requirements are or how to meet them.

Nanashi

Re: People do not want it

The actual reality is that NAT does nothing to inbound connections. NAT changes the apparent source address of outbound connections; it does nothing to inbound ones. You can't call that "pretty good protection". It's no protection.

For your printer, it's possible to connect to it from outside your network by creating a v4 packet with the destination address set to "10.0.0.234" and sending it to your router. NAT won't block it.

Nanashi

Re: A fully working DNS...

Sure, and it's not like v6 stops you from doing that.

Put your router at <prefix>::1, DNS at <prefix>::53... that's pretty memorable. You'll remember your prefix easily enough after a while, or you can just look at `ipconfig`/`ifconfig` and copy it from there if you need to.

Also, having v6 doesn't mean you don't have v4, so nothing stops you from connecting over v4 to fix your DNS server -- unless you break your v4 somehow, in which case having v6 as an alternative is handy.

Nanashi

Re: IPv6

> But the biggest problem is the lack of interoperability. If you can't build an IPv6 network and see the whole world of IPv4 content, this means you have to build an IPv4 network as well (i.e. dual stack)

It doesn't lack interoperability. I'm posting from a v6-only machine, to this v4-only site, and it's working fine.

If the biggest problem in v6 is one that doesn't exist, then doesn't that mean it's doing a pretty good job?

Nanashi

Re: in IT for 27 years

> We'll remake the entire address paradigm with colons and hex, because we're engineers!!

They didn't remake the entire address paradigm. The addresses are still a block of binary and they're allocated and routed in the exact same way as v4, they're just 128 bits instead of 32.

Writing them in hex is to make them easier (not harder) to deal with: without it, the addresses would look something like "32.1.13.184.133.163.0.0.0.0.138.46.3.112.115.52", which is even more unwieldy, and subnetting when your numbers are written in decimal is much more of a pain than when they're in hex.

Using colons is to disambiguate v6 addresses from hostnames. Otherwise, an address ending in e.g. ".be" would look like a hostname under Belgium's ccTLD.

> And, especially in today's world, who in their right mind wants their IoT device to be directly addressable on the internet with its own 'front door'? Not anyone in their right mind, thank you very much.

If you're going to use a door analogy, get it right: it's like having a front door inside a gated compound. You've got the front door keeping people out, but they can't even get onto the grounds without going through security at the outer gate.

Note that the security of your house depends on the front door and the gate, not on whether your house has a number on the door. Removing the number just makes it harder for you to use the post system, which is unhelpful (because what's the point in an IoT device that can't communicate anywhere?).

Nanashi

Re: CGNAT is a problem for home servers on IPv4, issues with security on IPv6

What security/privacy implications are you even talking about? The situation is no worse on v6 than it is on v4: prefixes are either dynamic or static (mostly dynamic, like v4) and host IDs are randomized and changed frequently (so you can't track individual hosts on a network, like on v4 behind NAT).

v6 doesn't let people "nail you easily"... or at least, any easier than v4 does, because tracking on the internet is already pervasive on v4, but let's just ignore that part.

Nanashi

Re: People do not want it

v6 is not actually at all complicated; v4 tends to be more complicated in practice since you're stuck with also using NAT with it.

The "home NATing router" might be great protection, but none of that protection comes from NAT -- if you don't understand that, then that's a good demonstration of how complicated it is.

Nanashi

Re: Can't disagree with anything there

That's basically what v6 already did.

Nanashi

That's easy to do with v6 too. All you're saying here is that you're either incompetent or have never used v6 for any length of time.

APNIC: Big Tech's use of carrier-grade NAT is holding back internet innovation

Nanashi

Re: I knew this would hapoen

Yes, and that's the approach v6 takes. The third bit is set to 1 to indicate that clients should look for a v6 address rather than a v4 one. It also has a second mode, used for routing over routers that don't understand the normal mode, where that bit is left at 0, and the "protocol" header is set to 41, which indicates that the v6 address can be found at the start of the payload section.

Your suggestion of squatting on someone's existing, in-use v4 range for this has no benefits over the two locations already being used. Existing v4 software and hosts will be unable to use it, a problem which you offered no means of working around.

Apparently it's not so trivial, huh?

Nanashi

Re: That old chestnut

> it’s like getting excited over smart motorways when actually what’s needed is more real lanes not repurposing an existing lane and adding technology that is continually exposed as flawed.

You've got your analogy backwards. NAT is the thing that's repurposing what we've got, and which is continually exposed as flawed. v6 is the thing that's giving us more real lanes.

Nanashi

NAT isn't a security layer. It's not necessary for security and gives you none; all it does is make your network more complicated, which makes its security properties harder to understand.

You'll still be behind a firewall, which will still be secure.

Nanashi

Re: The real problem with ipv6....

No, site local was dropped because it was awkward and pointless. There was no reasonable way to specify which site an address was in, and site local addresses gave no benefit over ULA, so they were just dropped.

Nothing to do with NAT, which is mostly pointless in v6 because of the vastly increased address space.

Nanashi

Re: I've said it before and I'll say it again

That doesn't help in the slightest. There are already multiple ways to indicate that a packet is a different type, two of which (the "IP version" header and the next protocol header) v6 already uses.

I said that you need to come up with something that v6 doesn't already do.

Nanashi

Re: The real problem with ipv6....

RFC7217 and privacy extensions fix the first problem. The second problem doesn't exist; I'm not sure where you got it from, but the top 16 bits are available for allocations. Link-local addresses are used by everybody as part of bootstrapping a global address.

A redesign to fix these problems that aren't problems wouldn't be a good use of anybody's time.

As for DHCP, v6 was developed before DHCP was common. The DHCP RFC only predates the v6 RFC by two years (1993 vs 1995), plus v6 was in development long before the 1995 RFC date and DHCP wasn't ubiquitous until the late 90s, long after the 1995 date. There were multiple other address autoconfig mechanisms in common use until then.

It's kinda unfair to blame them for being unable to predict the future, don't you think?

Nanashi

Re: I knew this would hapoen

> For a new addressing scheme to be adopted it HAD to be an extension of IPV4. This would have been trivial to do

Can you explain how?

The fundamental problem that needs to be solved is that v4 is limited to 32 bits. After all, if it wasn't, we wouldn't need a new protocol in the first place. Can you explain how to make a new protocol, with addresses longer than 32 bits, that extends v4 in the way you claim is trivial to do?

The reality is that this isn't possible, and all of the possible workarounds are supported by v6 (...meaning it's not 100% incompatible at all). I think it's a bit unfair to describe the people that designed v6 as "either too stupid or to full of hubris to even consider that" just because they couldn't do the impossible.

But perhaps all of them were wrong, and you're right, and it was actually trivially possible, in which case you'll be able to tell us how to do it.

Or was your own post the result of either stupidity or hubris?

Nanashi

Re: Addressing only the problem that v4 has?

This is basically what v6 did.

Nanashi

Re: Thanks, but no thanks

No it doesn't. It'll get an IP from the network's subnet, which is different for each network, so the left-hand half of the address will change when you move between networks. The right-hand half will be randomly generated and change regularly due to privacy extensions, so it'll change even if you don't move between networks.

(Of course your apps etc will still track you by IMEI, UUID or whatever, but that has nothing to do with v6...)

Nanashi

Re: I've said it before and I'll say it again

Those things are the backwards compatibility. How did you expect it to work? Magic?

v4 isn't forwards compatible to address spaces wider than 32 bits. That's not v6's fault; it's v4's fault. There's no way to make it "just work" without some form of backwards compatibility method, and that's what v6 implements -- because it's the only thing that's compatible with v4.

If you think I'm wrong about this, all you need to do is explain how they should've designed it to make it possible for a v4-only device to talk to a v6-only device. If you can describe a way to do it, you'll prove I'm wrong. Just remember that whatever you come up with needs to a) be something that v6 doesn't already do, and b) actually work.

I've asked a lot of "v6 should've been backwards compatible" people to do this, and not one has been able to. Perhaps you will finally be the one to share the secret...?

Nanashi

Re: I've said it before and I'll say it again

You don't need good drugs to see this. Between dual stack, Teredo, 6to4, 6rd, 6in4/4in6, NAT64/DNS64, 464xlat, DS-lite, MAP-T/E and more, v6 has plenty of backwards compatibility.

Why do you think it doesn't?

Nanashi

Re: That old chestnut

> When I'm running out of nails, I don't start thinking about buying a new hammer.

Sure you don't. But when the entire world is out of nails, and nobody can make any more of them, but you still need to nail stuff down, wouldn't you start thinking about using screws instead?

Nanashi

Re: I've said it before and I'll say it again

Why say it repeatedly when it's wrong? v6 is backwards compatible with v4.

Describe a method of backwards compatibility that would actually work with v4, and v6 most likely already has it or something functionally similar. There's at least a dozen different methods available, depending on what your use-case, limitations, goals etc are.

If there's anything v6 lacks, it's not backwards compatibility.

IPv6 still 5-10 years away from mainstream use, but K8s networking and multi-cloud are now real

Nanashi

Re: Is this the most sensible Gardner report ever?

The lack of what now? v6 is backwards compatible in many, many different ways. Describe a method of backwards compatibility that would actually work, and v6 most likely already has it or something functionally similar. There's at least a dozen different methods available, depending on what your use-case, limitations, goals etc are.

If there's anything v6 lacks, it's not backwards compatibility.

UK internet providers told to mind their MANRS and start following Border Gateway Protocol best practices

Nanashi

Re: though nobody noticed because they were IPv6

Actually no, it doesn't. They advertised 2400::/12, which is basically the entire of APNIC's space. Any legitimate users in APNIC are advertising routes that are more specific and thus have higher priority, so the announcement didn't affect them.

So no, the reason they didn't notice wasn't because it was v6.

Page:

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER

Biting the hand that feeds IT © 1998–2022