Slashdot Mirror

As I posted in another sub-thread: http://packetlife.net/blog/201...

Nope. Microsoft fucked that a long time ago.

http://packetlife.net/blog/201...

The class E space has 268 million addresses and would give us in the order of 18 months worth of IPv4 address use. However, many TCP/IP stacks, such as the one in Windows, do not accept addresses from class E space and will not even communicate with correspondents holding those addresses. It is probably too late now to change this behavior on the installed base before the address space would be needed.

And you forgot to mention class D space, which is pretty sparsely defined. I seem to recall it uses about 5 out of 16 /8 size blocks, not to mention that IPv4 multicast is basically a failure anyhow, so really all 16 /8 blocks are wasted.

That joke was funny April 1st of last year. http://packetlife.net/blog/2011/apr/1/alternative-ipv6-works/

My octets go to 257.

That's not how IPv4.1 works. Check the facts.

Version number 5 was taken already, so you cannot use that. Apart from that, everything you suggest is something that IPv6 was already designed to do. For the compatibility there are ipv4 compatible ipv6 addresses, ipv4 mapped ipv6 addresses, and 6to4. But none of that made IPv6 happen as fast as it should have.

The main difference in your suggestion from the actual IPv6 protocol is that you suggested smaller addresses than IPv6, so your suggested 48 bit addresses would be running out. If you like short addresses you should take a look at IPv4.1. But you shouldn't expect to effectively use more than 80% of the bits in the address. In other words you need to find out how many bits you need for the number of devices you expect and then add at least 25% more bits to compensate for bits lost due to administrative overhead.

The current IPv6 address allocation strategy does look like a waste, but so what, it is most likely going to last anyway. Besides initially the address space was split into 8 equal sized parts of which two can be used for RFCs and one was given to IANA to hand out from. That means if the allocation strategy turns out to be broken also for IPv6, there will be another 5 chances to get it right. My guess is, if it another attempt turns out to be needed, the local portion of the address will be reduced from 64 to 56 or 52 bits, and the network portion of the address is increased from 61 to 69 or 73 bits.

As far as packet sizes goes, IPv6 did increase the sizes that must be supported significantly compared to IPv4. In IPv4 the packet size implementations were required to support was 576, and the MTU must not be less than 68 bytes on any link. In IPv6 the numbers were increased to 1500 and 1280 respectively.

OSPFv3 is most certainly IPv6.

http://packetlife.net/blog/2008/sep/1/ipv6-and-ospfv3/

There's some reasons this won't work.

EG-- Think of what would happen if you used ComCast's various local networks (the neighborhood branch networks that the cable modems are attached to), and all the VoIP connections that are being shuttled through them, and subtly alter their delivery routes a few hops at a time using the distributed arp poisoning approach above. By the time you get it over comcast's backbone connection, you would be directing a huge bitstream of "Legitimate", "high priority" packets. At the same time, you would be doing the same thing with ATT, TimeWarner Cable, etc... The end goal is to get all of those rivers of traffic to flood into the final network segment via its many backbone connections, fully saturating the segment, and overloading the routers at the destination.

1) It's highly unlikely you're going to have drones on continuous subnets, at least continuous enough to hit a target somewhere across a few networks. Outside of the network edge, where are you going to have an infected node? Once you're outside of the cable modem/VoIP access switches it'll be network aggregation. Good luck having an infected device connected on these switch-router or router-to-router network segments, which are probably all subnetted to allow only a few IP hosts anyways (which are other switches/routers).

2) I would assume ISPs are using static ARP entries in that aggregation layer. But, you never know.

3) At the access layer, many switches are configured to only allow 1 or 2 MAC addresses in a time period. If you suddenly change and dump a new MAC out, your port can be auto-disabled. (see port security)

4) Switches can be configured to monitor the DHCP leases granted by the network's trusted DHCP servers. If your port has an ARP packet come in with a source IP that was not leased out in its ARP messages, the packet is dropped. (see DHCP snooping)

Here is a good blog post on why this wouldn't work: http://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/

Stretch, over at Packet Life has a great lab set up that anyone who needs to test Cisco configurations on can sign up for and use.

Stretch, over at Packet Life has a great lab set up that anyone who needs to test Cisco configurations on can sign up for and use.