Is ipv6 a botnet?

Is ipv6 a botnet?

Other urls found in this thread:

iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
ipv6friday.org/blog/2011/12/ipv6-nat/
twitter.com/AnonBabble

Is SPI a botnet? Is http? Is I2C? Is C botnet?
All great questions indeed!

you asked Sup Forums so yeah it definetly is, along with your cat and your dick

It's a protocol... your question makes no sense

>Your brain on Anime

is mayonnaise a botnet?

Is animu a (chinese) botnet?

No. IPv6 40-byte header (+ sometimes hop by hop options) is actually a godsend in terms of routing. Also they killed the bullshit with IMCP packets being needed to fragment, now if a datagram is larger than a route's MTU the routers do the fragmentation instead of the sender. Much, much cleaner.

Sometimes I realise how much of a fucking is a t no longer a fan of the house and the other side of the beer and the sun and was great iwbso body's in this category has which wh s.

Alright? Newfags everywhere.

>reeeeeeeeeeeeeeeeeeeeeeeeeeeee

>IMCP packets

I think you mean ICMP, smart guy.

IPv6 and dual stack edge devices is how anonymity was removed from the Internet without anybody noticing.

Having solved WHO, WHAT is being worked on aka breaking TLS.

Explain

What technical limitations actually spawned internet anonymity? What limitations preserve it now? Is it a bug or a feature?

And to be clear I'm not talking about "you don't know who was sitting at the computer" or "Sup Forums posters don't know who the other one is" either.

there are bigger issues with IPv6 than facilitating traffic analysis of your toaster oven and shake weights.

> bretty gud:
killing router fragmentation: A+++, great work guys
bigger & sparser address space: awesome, my router CAMs finally get some breathing room

> ... huh.
extension header for routing: DOS built right into the protocol. gg, retards.
16b payload length: pretty short-sighted, jumbo extension will seem annoying in the future
no tailing end-to-end checksum: ***really*** stupid. TCP/UDP checksums suck, L2 hop-to-hop CRCs often botched
poorly defined traffic class/flow label field usage: wasteful
no variable length coding of addresses: lost opportunity
source address before dest address: literally why. just makes cut-through routing slower

It's not anonymous right now, if you're referring to government or ISP intervention. Privacy doesn't exist if you're connected to the internet.

How does ipv6 differ from ipv4 in this regard? How does it make it worse or better?

It uses your network card MAC address to generate the IP address.

In what way and why does this matter?

Is it a one way calculation, like a hash? If so, this is a non issue. Can your MAC be derived from the IP? If so, you can simply change your MAC at any time right? Not seeing the issue.

Everything is a botnet here, user.

No it doesn't look into privacy extensions most OSs don't generatie from MAC anymore.

ipv6 is the end of being user

every device gets a unique ip adress and not just the router who then partitions this into lan ip's

iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

I just remember reading ipv6friday.org/blog/2011/12/ipv6-nat/

The "NAT doesn’t help with security. But…" section specifically.

Is botnet a botnet?

maybe

...

Yeah I mistyped it dude, chill out

>Is C botnet?

kek

Why would you want to add even more overhead and add another fucking checksum at layer 3.

>extension header for routing: DOS built right into the protocol. gg, retards.
Yeah, that could be an issue
>16b payload length: pretty short-sighted, jumbo extension will seem annoying in the future
You will never have to deal with that, also I don't see MTUs increasing at a rate such that we'll be needing jumbograms anytime in the forseeable future
>no tailing end-to-end checksum: ***really*** stupid. TCP/UDP checksums suck, L2 hop-to-hop CRCs often botched
There's still a checksum. The fact that some routers don't verify it is not the problem of the people designing the protocol
>poorly defined traffic class/flow label field usage: wasteful
Nobody I know uses this shit, but yeah, I guess it could be a problem
>no variable length coding of addresses: lost opportunity
No. One of the things that makes IPv6 so much better is the fact that the header is a fixed 40 bytes, unlike the "options" field that fucked with the header size of ipv4. Routing in hardware will be much, much faster. Also, if people start using the privacy featuers like randomly assigned IP addresses, something like that would probably save space less than 20% of the time. As it is, you'd only be saving 1-2 bytes at the most, and adding considerable CPU load to routers
>source address before dest address: literally why. just makes cut-through routing slower
Bullshit. Taking an address to the start of the 40 byte header, adding 8 and then reading 16 bytes is just as fast as adding 24 then reading 16 bytes. Just about no difference whatsoever.

Your decive's MAC address maps 1:1 with your ipv6 address, every interface gets one unique address. Ever.

not my dick... oh wait it's okay I don't have sex

An OS can be configured to use random addresses instead of a MAC address for determining what address to use with SLAAC.

while this is true, you're forgetting that the ethernet controller has its own mac adress that cant be over-writted because its essentially a microcontroller that runs individually from the cpu and its ROM

you're specifically talking about the software layer that is designed for mac-adress blacklisting on home routers

I think we've hit peak Sup Forums retardation.
We can't get any worse than this.

didn't read

Every time I think that Sup Forums finds new ways to prove me wrong so don't worry the worst is yet to come.

>>source address before dest address: literally why. just makes cut-through routing slower
>Bullshit. Taking an address to the start of the 40 byte header, adding 8 and then reading 16 bytes is just as fast as adding 24 then reading 16 bytes. Just about no difference whatsoever.

moving the destination address 128b further back in the header costs ~13ns on 10Gb ports, and fast switches have cut-through latencies in the ballpark of 200-300 ns. maybe you don't care, but tons of HPC/HFT/etc. people do. sane hardware-oriented protocols, from 802.3 Ethernet to Infiniband, put the destination field first, since it's utterly senseless to do things otherwise.