- what the fuck? over.
- why must I buy a new box to get something to work which is supposedly is there already
- immediate cessation in software updates upon release of incremental hardware update
- if you changed the chipset then how hard can it be to make a conditional instead of drop all future upgrades
- fail to communicate what's going to work and what's not
One of the great promises of IPv6 has been to get rid of NAT, no more will IT do RFC1918 and NAPT to single public IP. But how is IPv6 going to accomplish this, what is the magical toggle for it? Let's get disappointed.
Some devices, like Cisco IOS allow you to configure IPv6 prefix as 'macro', so you could tell that macro 'ME' is 2001:db8::/32 and everywhere where you write IPv6 address, you use macro 'ME'instead. So in theory, when your prefix changes, you simply change the macro. So the great renumbering benefit is ability to always get same size network. But of course this was true for IPv4 too, you got the network size you needed. Why isn't this utilized? Because enterprises don't have one Cisco IOS devices, they have plethora of devices from different vendors, firewalls, slb, ips, ids, servers, OSS systems and so forth, you'd still need to go in all of these to change the 'macro', not all devices even have the concept and quite frankly no enterprise of non-trivial size will even know without months of work _where_ and _what_ will need to be changed for renumbering to be successful. I know industry professionals who've done renumbering costing MEURs in single company. So in practice IPv6 gives you no benefit in renumbering, renumbering always was easy for trivial network and always hard for non-trivial network and will continue to be so.
So how will enterprises run IPv6? Getting PI/ASN is actually bit harder, as you MUST be dual-homed, while many enterprises just want PI/ASN to have ability to change operator. There has also been visibility problems with /48's, but these will be remedied in due time, when even rest of the people realize there will not be magical new protocol in IPv6 for address mobility. I'm quite certain that IPv6 will be deployed exactly like IPv4, instead of RFC1918 you will use RFC4193, but with the twist that most companies will find that PRNG always returns '0', so that they will get beautiful short fd::/48 block, and lot of cursing in M&A, as with RFC1918.
Companies will NAT this RFC4193 to external provider provided IP block, no renumbering needed, you can still change operator without complex and expensive renumbering. But there is something we will win, we can easily do 1:1 NAT, instead of NAPT, which has great many benefits, no more will you need session logging to comply with legal requirements, you will also get mostly working end-to-end connectivity, apart from protocols which carry address in payload.
For those few who have been bitten by RFC1918 in M&A and who view that IPv6 address memorability and beauty is less valuable than the many hours of pain RFC1918 in M&A causes, here is one-liner to generate random RFC4193:
I've recently noticed that it is becoming more and more common to see 'weird' MAC addresses, i.e. MAC addresses which do not start with numbers 00. Previously it was very easy to spot automatically mentally software defects which would cause strange MAC addresses to appear, it has helped me to diagnose several issues in the past. We've now beginning to lose that advantage, as IEEE has started to allocate MAC addresses quite randomly across the address space.
I emailed to IEEE and asked what was the motivation and perceived advantage in doing this change and reply was quite simply 'We changed our allocation methods to prevent vendors using unregistered mac addresses.'. OUI costs 1650USD one time fee, but IEEE appears to be concerned that some vendors choose not to pay it, instead allocate themselves OUI somewhere far in the address space, effectively thinking they are getting free OUI with little to no possibility of overlap. It would be curious to know if this instance who wants to save 1650USD would care about this slightly changed climate, I personally doubt the change while good-willed is completely ineffective and the slight operational benefit serial assignment had is lost. (/me starts crying over spilled milk).
In slightly related note regional IXP here is using static manually assigned MAC addresses from 4000.0X, where X is the number of the IXP site which is then followed by base10 of ASN and then free 4bits for user. So in site 1 for AS4242 would be 4000.0104.2420. Unfortunately when these were assigned someone mad mistake with bit significancy order and this MAC address is not locally assigned as was intended but normal public MAC address. I'm recommending new scheme of xEzz.yyyy.yyyy. Where 'y' is the ASN in hex (supporting 4byte ASN), 'z' is customer assigned, 'E' is static and 'x' is IXP site number. E could be also 2, 6 or a, but 'E' for exchange is kind cute.
NET-SNMPFirst of all, you probably want to set system wide version and community, so you never need to type them on snmpbulkwalk
WIRESHARK/TSHARKTo me this is more useful than net-snmp, to lab what type of traps router would send and in what situation. For some weird reason wireshark/tshark doesn't honour net-snmp settings, but needs its own settings.
Most incumbents are offering residential VoIP, some kind of music-on-demand service, IP-TV and so forth. These services are marketed only to existing subscribers so potential market is from 100k's to million or two. I cannot see how they could compete against skype, itunes, spotify, tivo etc, who are targeting whole Internet and are doing it as their core business. Skype can produce the service much cheaper due to economics of scale, there simply is no way incumbent can have this market. Incumbent would be as likely to succeed in any new random enterprise, such as starting pizza chain as they would be in VAS. Not impossible, but it is much more likely that new startup can succeed it in, who don't have century of red tape around them and who are vastly more numerously attempting it.
Rather than VAS telcos should concentrate their efforts on being profitable at pushing bits around, attempt to become skypes preferred PSTN<->SIP provider, provision and manage residential DSL so that you are profitable without counting on VAS to fix your cashflow.
It would be competitive advantage for telco to realise that they are utility like electricity and water, most important thing they have is their physical infrastructure, which they can sell to end users and competitors, it is expensive long term investment to expand that infrastructure, maybe not fitting for trendy quarter economy, but putting your money on black and hoping to win house (skype et.all) is simply delusional and waste of time.
Be Profitable Bartering Bits, BPBB.