Musings on career progression

Well woo hoo...2 months since the ccie....its been fun. We're now done with hey congrats and pats on the back to silenced whispers that go 'why the heck are you still here'?....seriously! Im shocked at the number of people that expected me to leave my current role/job. I hope its not a vibe I put out because from a technical point of view, It's one of the best jobs. I command the respect of everyone that I care for, and as far as networking and my line of work is concerned, I really am well on my way to the top of the pack.

Last week I helped a 'friend' deliver an IP/ethernet backhaul class' that went really well. Next week I'll be speaking at afnog, one more long life dream to be accomplished and definately the beginning of something great.

So what next....?ehh i'll do a separate post for that.......

3G and IPv6 More considerations:

Please note this are pretty much notes I made while going through some literature, I also assume a lot of people reading this have probably worked for ISP's and understand a typical ISP network:

Architecture:
A 'generic' ISP network has functional roles very much like a 3G network. They have an access network, Distribution/aggregation and a core network. 3G is a just a 'little bit' more complex but think along those lines and you'll get it.

The 3G/UMTS network is divided into two main domains:
the packet switched (PS) domain - Where I predominantly work/worked
and the circuit switched (CS) domain - where I know enough theory to run circles around most but I'm by no means an expert.

The core network elements comprise of the GGSN, the SGSN and the IMS (Think of the IMS as a mix of many many systems/applications).The GGSN is really just a customized router between the GPRS network and other networks - the first GGSN I ever run was a cisco CMX based on the 7613 chassis and a bunch of MWAM modules interfacing networks such as the general Internet and customer networks.

The SGSN is again an intermediate router between the GGSN and radio network. It's main responsibity is administrative functions other than routing: AAA, mobility management, and billing, among others - please note you can bill from either SGSN or GGSN's, If you have a DPI/PCRF, the billing function is moved further out of the actual 3G network.

The IMS as mentioned earlier is essentially the server farm, is where content and IP infrastructure servers live. So your DPI, WAP, DNS etc etc

The radio network abbreviated as UTRAN has Radio Access Network Controllers (RNC's) and base stations (BTS), which connect the handsets (UE or User Equipment) to the core network. The radio network is capable of transmitting data at various increments from 64 kbps to 2 Mbps or more - it all depends on issues like the next line describes and the technologies used - google for direct tunnel-.

The actual data rate depends on propagation, velocity of the handset, bandwidth available, and so on. This is important to note especially if you're the kind of guy that escalates issues to me:-) or if you live in South C....:-) thats a joke...laugh

IPv6 view of a 3G network:
As far as IPv6 is concerned the biggest point of concern is the pdp context. This forms the connection between the (UE) - user terminal and the GGSN. It is over this link that we transfer packets. If you're thinking - oh so like PPP - I'll say yes, just like PPP, only we use a protocol called GTP .

PDP contexts are created and torn down every time you attach/detach/re-attach. So IPv6 runs over this PDP context and that is what is referred to as an IPv6 link for a handset.

Resource usage on Handsets:
Now imagine if you are dual stacked, imagine how much power you'll be using or attach reattach for two sets of contexts and you begin to see why I still insist that all mobile handsets should be made to only support IPv6 then use 6to4 mechanisms to transition.

Also imagine a chinese manufacturer and your standard user who will buy a Nokla phone that some 'manufacturer' only enabled IPv6 and you suddenly start having very interesting support calls. I am so sure the black market for IPv6 handsets will show up and one of the key issues will be IPv6/IPv4 misconfiguration. Some intentional, some laziness, some just pure sillines.

You will definately also need slightly more memory to hold the lenghthier IP addresses. This looks trivial but again I expect some issues there.

IPv6 address assignment:
GPRS systems have always supported static and dynamic addresses. This can be stateless or stateful. The key issue with IPv6 here is the simple fact that autoconfiguration requires a mac-address, your handset doesn't have this, to counter this, we'll use rfc 2472's procedures.

There are other issues here with addressing that Im not entirely sure I get, like since we now have so many addresses, doesn't it make sense to assign static addresses? plug each msisdn with an IP on the HLR and call it a day? apparently not

Aa /64 to each handset is a huge number of addresses, however you can very well expect guys to share connections behind mobile devices in which case it actually makes sense. It also makes sense because 'most books' say so, and if you do the binary math carefully, you start seeing why /64's to each endhost is good for the transition. Heck some might even require /48's - think of tethering. Plan how to do addressing carefully.

Whether or not you'll run out of addresses depends on many variables, including size of allocation, customer takeup, and so on. Your planning is also key here. If you were an idiot subnetter in IPv4, I suggest you try cross the idiot barrier fast. IPv6 is a whole 'nother ball game. In reality even with the ratio adjusted to /64 per PDP context, and only addresses from 2xxx:: used, there are still well over 300 trillion addresses available. This should be plenty of room for the next few years. Just plan accordingly, read widely, you should be okay.

Mobility:
The movement of cellular hosts within 3GPP networks is handled by link layer mechanisms. So as far as IPv6 goes, it's handled just as it would be in IPv4.

Following the case above, it means the PDP context would be moved from one location to another without tearing down the pdp context. Now most movements are within base stations - micro mobility? This doesn't change your point of attachment for IP so there's no 'handover from a ggsn to another. You can also have movements that churn your point of attachment between GGSNs - macro mobility. In the initial releases of 3G, macro mobility is taken care of below IP layer by using tunnels to create an apparently flat IP network. ie a tunnel between ggsnA and B ensuring your PDP context remains BUT the more this happens the more delay and other bad things can happen to your connection.

Roaming:
Arghhhh.......throw in another arghhh for the fact that telco's still insist on using simcards for identifying users....the sim card should be killed...swiftly...another rant, another day

Are there motivations to move IPv6:
Where I work, IPv6 is still pretty much driven by technical enthusiasts. Management is still quiet and can be quite unsupportive and a morale drain. However it might be us techies failing to inform them. Am I motivated enough to do that? probably not, for some reason there is always someone higher up, an invisible hand out to discredit or tear them down, or generally just not ready to make things happen fast enough, so unless i can safely do it without asking eg paying for my own ccie or travel to afnog,or test IPv6 I stopped bothering; they can read my blog though:-) to get a grasp of my views.

The move to general IP is however very well taken up. we have come from far, we've done an NGN, we have a unified core so IPv6 will be an easy one to cross once we get widespread acceptance, or its forced on us. Either way it will happen.


I also saw a nice term describing a challenge we can expect. IPv6 brain drain. Since the most senior enough managers to make retention decisions do not know much about IPv6, expect to lose some people to the ones that get it faster than you.

In the US, IPv6 is actually being driven by government. i find it weird that organizations that stand to benefit the most are the ones lagging behind the most.

Probably the clearest motivation for 3G from the telco point of view is that the integration of IP actually helps to reduce the cost of running the network.Ultimately, the goal is to carry voice traffic over packets, enabling statistical multiplexing to kick in. This should save costs on traditional support infrastructure, such as circuit-switched E1-minimum increment backhaul. Furthermore, the mass market economics of IP, when brought to bear upon the production of telecomms equipment, should result in further savings.

- read IPv6 Network Administration By: Niall Richard Murphy; David Malone

References:
http://tools.ietf.org/html/rfc3316
http://tools.ietf.org/html/rfc2472
installation-and-configuration/ipv6na-chp-5-sect-7

IPv6 Addressing - Mobile network considerations

Now I have of late been looking into alot of things IPv6. So much that I'll actually be throwing in a discussion around it at Afnog in Tanzania - look me up on the 7th June 11 am. After that we can grab some beers at Kempiski.

While alot of the stuff we'll discuss are not implemented. They show our (the technical guys) thinking and plans for the mobile network part. The enterprise business and IT generally have plans just like everyone else has.


So what is different with IPv6 addressing:
First of all, IPv6 is technically incompatible with IPv4 addresses. With that in mind, here are some areas we expect some 'issues'...

There are three considerations to focus on here; the network,the mobile nodes and the applications.

1. - First of all Roaming. I don't see this happening without some automated tunneling like ISATAP. There have been commercial tests for this by Ericsson and a european telco. A native IPv6 roaming agreement will probably take a while. (I still dont get this whole roaming thing - I personally think its a 'silly business model'. also note that if some providers do not go IPv6 at around the same time you do, it ironically forces you to support IPv4 addressing when your own  (outbound) subscribers roam to networks which do not offer IPv6.
2. Per subscriber IP addressing: We'll seemingly be using several addresses per subscriber. If you did any IPv4 planning, conservation was very key. It might seem like a huge waste assigning /64's per subscriber GGSN/PGW- thats huge unless GGSN's start supporting 12Million subscribers or more.....
3. If you choose a dual stack scenario, Your handset will need more memory to hold IP's. At afnog we'll be discussing why the best strategy really is to have IPv6 end to end or at least at the network and handset level then leave the applications to slowly transition. This interestingly has us using NAT 'for good' ie we'll be natting IPv6 to V4.
4. The transport network need not be IPv6 ready, an operational IPv6 network can be deployed with configured tunneling between the network nodes with IPv4-only transport. for instane betwen nodeb's and rnc's.

http://tools.ietf.org/html/rfc4866
http://tools.ietf.org/html/draft-koodli-ipv6-in-mobile-networks-02 
A flexible method for IPv6 address assignment

What is NAT44

If you go through IPv6 training material or blogs or whatever your source is, if you have run an ISP *on a constrained budget or dodn't have AFRINIC  [1]as an RIR to get routable addresses for all your users,then the NAT technology is something you might have had to deal with.

NAT has been very successful in delaying large scale IPv6 deployment. But the end is near.

NAT44 is on most slides I have come across as an IPv6 transition mechanism. I have to say for some slides I was preparing, I had to throw it in just so I can rant about it.

NAT44 also goes by the names:
CGN - Carrier Grade NAT
LSN - Large scale NAT and
NAT444 - which implies multiple two NAT44 layers

There's also a distinction between SP NAT44 and Residential NAT44. The key difference really is the implementation and NAT placement. the SP gets a large box to do NAT and calls it CGN/LSN.

Lets have a quick look at the differences:
Residential NAT44
would be deployed on a CPE,
SP NAT44
generally deployed on the SP side .
The end topology would look like the following:

CGN is NAT44 on the SP end, CPE's are also running NAT

So you'd have two RFC1918 addresses back to back. The idea is to extend the 1918 space as much as possible.  Prolong the pain if you may.

The deployment models are varied. There's a NAT on a stick model that eliminates NAT from the main data path and uses source-IP based routing - This has almost killed our network several times.

You also have an inline model that forces all traffic to use the NAT path. You get a single point of failure as bonus.

Reasons I agree with alot of people that this is not an ideal solution:

• The most easy to identify from the diagram above is conflicting address space between the customers and SP's. there's a draft proposal for shared address space that Im yet to read.
• A single level of NAT (NAT4?) was very prevalent, and it worked to a large extent. Applications won't be aware of the other tiers of NAT which will undoubtedly break a few things.
• Troubleshooting will be a mess. I mean how many NAT's are we to learn - NAT, NAT4, NAT44,NAT64 - dare I say I expect someone after using all v6 space to propose NAT666 
• Application developers will have a hard time predicting or trying to work in what technologies will be used to reach their content/run their apps.
• There will be contention for port pools. Remember some applications leverage multiple ports to speed things up, NAT will be doing the same which means some customers will definately notice 'slow internet'.
• Accountability and logging? forget it in NAT44.

A few reasons why it will most likely be adopted more for IPv6 transition:
- It is well understood - I think * I suspect the real culprit is the ease of deployment not a good understanding, Most network engineers have no idea how NAT affects applications and guys writing apps have no clue how the network affects their work. Some do, actually most do, they just dont seem to be running networks. They're made managers:-)
- Its easy to enforce policy
- cluelessness/laziness/low budget/misplaced priorities
- NAT44 devices on the client end wont require replacing.

Fact:
- This NAT44 thing will be installed, mostly the NAT on a stick model.
- Customers WILL be affected during  the IPv6 transition
- It is inevitable that someone somewhere will be forced to host their application on an IPv6 only site. I expect this to begin happening in the next 3 years.
- Worse, it is inevitable that some devices maybe for home automation, maybe some large scale rfid tags to track rhinos , whatever, some device somewhere will be deployed without an IPv4 option.
-Even worse or better, high chances are they wont be connecting to a typical enterprise network, most likely going to be a mobile network of sortes. 3g/edge/umts/lte/wimax.
- the last fact from me here is that not many people know what is happening. there are too many prevailing not necessarily agreeing views on IPv6/IPv4 depletion, transition mechanisms and the effects on the internet.  I get the feeling 'no one really knows'...I sure as hell don't, but read widely, listen, work with others...who knows what sort of enlightened state we'll be in later.

Funny
In this part of the world -kenya, most mobile operators especially at high management level still have 'heads in the sand' as far as IPv6 is concerned. Early adoption would probably benefit them the most.

1-AFRINIC is probably the only RIR today that still has V4 addresses to dish out to LIR's.
*I posit that this could create a false sense of security for african operators forgeting that most of their customers access content 'outside' Africa, if said content is switched to IPv6, we're done for and the sad thing is most network admins might not be ready to explain to 'the suits' higher up what the hell happened.

References:
*For any reference to an rfc, google for it or  head to the ietf site
•  “basic-nat44” (Reference [RFC 2663])
•  “napt44” (Reference [RFC 2663])
•  “stateful-nat64” (Reference [NAT64])
•  “stateless-nat64” (Reference [XLATE])
•  “basic-nat66” (same as basic-nat44 but for IPv6 family)
•  “basic-nat-pt” (Reference [NAPT])
•  “napt-pt” (Reference [NAPT])
•  “twice-nat44” (Reference [RFC2663])
•  “dynamic-nat44” (Dynamic SRC Address-only)
•  “stateless-nat66” (Reference [NAT66])
•  “napt66” (same as napt44 but for IPv6 family)

*A Juniper implementation guide
* a paper from nanog
* jeff doyles post over at network world

as the rooster crows:-)

http://www.jackrooster.com/

Well the site came out really well, and if you ever need to listen to great tunes with a twist...head over to Jack's site .

Yes yes yes he's a ccie and close friend so the content is valid here:-) go check it out...download a tune, or two...maybe all 3 volumes.....