Actually this is effectively a broadcast/multicast MAC address.
The first byte of your MAC address should always be an even number. The value of the second bit is supposed to indicate if the MAC is "burned-in" and basically doesn't matter. The LSB of the first byte, however, should always be zero.
An iterator is a class. It can contain any private data you desire and mutate in any wonderful and/or stupid ways you desire.
How it decides to compare equal to the .end() instance is also your call. Your example is not a compliant iterator (as in, wouldn't work in a range-based for loop) - yet the same behaviour would be achievable through your own operator++() and operator bool(),
Given a peering with Y GBit of throughput to someone like say, Twitch or Facebook; with multicast, I now only end up with a single load of data for each livestream coming over the pipe.
However, this does require direct peerings. Multicast over the Internet is just not a thing. This could technically be built out with IPv6, but nobody's realistically going to arrange for globally-unique multicast space allocations and convince every AS in the world to start peering multicast over BGP for general public use.
Except in practice this is useless because you're now transmitting what is basically a corrupted packet.
For this to work, L4 protocols would need to be completely redone to consider and work with this concept.
Also, what is actually meant to happen is that an ICMP(v6) packet too big message is supposed to be sent back to inform the sender that they need to reduce the packet size.
Unfortunately, with the pervasiveness of idiotic firewall configurations that blanket block ICMP, this falls apart which is why we have to deal with ugly hacks like TCP MSS mangling.
By any combination of assigning static IPv6 addresses, organising devices into separate L2 links (VLANs) and firewalling by IP prefix, rather than the entire /128.
This makes no sense at all. The notation can basically be anything you want - you could, if you wanted, invent a new notation for IPv4 or IPv6 right now.
What actually matters is the packet format.
You cannot make it backwards compatible because it is impossible to expand the IP header's address space without it becoming unparseable to existing network equipment.
"Ah" you say, "but we could put the extra bits after the end of what is basically an IPv4 packet"
Well no, you can't do that either because it would require executing a global seizure of existing IPv4 space and reorganising the entirety of the IPv4 internet into a hierarchical manner where your "IPv7" extra bits can be processed prior to the final destination.
IPv6 works fine and is well-designed. Hardware and software implementations have been in-production for decades now; Google alone see 30% of their total traffic over v6.
Fundamentally, support of any network protocol is subject to Internet participants having compatible kit; x86-64 wasn't immune to this; if you didn't buy the chips, you couldn't use the software. The reason it actually won is that the Itanium architecture was completely different and resorted to translating x86 instructions which, unsurprisingly, ran like treacle and never made it to the consumer market either.
The idea of inventing yet another internet protocol is patently absurd when you consider it would require yet more upgrades across the globe to hardware and software in order to support it.
I implemented a variety of GitFlow, but with an emphasis on automation. Normally you branch off of develop; hotfixes will be a branch off of master.
Feature branches are combined with develop before being built and tested. If it passes, it becomes mergeable in GitLab.
all builds of develop that pass are taggable; you go into the CI interface and specify a tag. Once deployed, master is updated by the CI to point to that tag.
The most valuable part of this is the CI pipeline and having a solid body of tests to ensure that changes which don't necessarily conflict in Git will most likely be caught during test, prior to it being allowed for merge.
If you want maximum efficiency, your hosts all have RFC1918 IPs and you route the public IP addresses to them. zero wastage, everything usable.