So I got an invite to participate in this years IGF.I heard of the IGF last year and going by the amount of heckling, noise and politics that goes with governance especially when Kenyans get in the mix, I was not really interested. After going through previous sessions just to know what I am getting into, I was wrong on that assesment. Completely wrong.
This year it will be held in Kenya, at the UN headquarters Gigiri, this year I might just get a chance to steer debate, a chance to actually make a mark and interact with policy makers from all over the world, a chance to speak again, this is a good year.
Since an IGF is attended by a very diverse group of stakeholders, from different countries, you can expect alot of learning to happen.
So what is internet governance:
According to the Tunis agenda: Internet governance is “the development and
application by governments, the private sector and civil society, in their respective
roles, of shared principles, norms, rules, decision-making procedures, and
programmes that shape the evolution and use of the Internet.”(Paragraph 34, Tunis Agenda).
This year will focus alot on mobile devices and there is an IPv6 agenda. Thats probably where you'll find me making the most noise. I however am lucky in a very random aspect: I work at Safaricom and have access to data and people that analyze it. I see first hand the effect of our product in the market.
Imagine raising more than 120Million shillings for the hunger striken from several Million subscribers selflesly giving (MPESA,shortcodes, tshirts), imagine how much the internet has penetrated society just by use of cheap mobile handsets, imagine mobilizing community/county development using these devices.
At the rate we're going, we as a community can for instance vote using the internet, using our handsets, using sms for what development we want to see, we can then partner with local councils and actually use the same medium to raise money (shortcodes, mpesa etc)....
on IPv6 I have ideas on how this is likely to change things, make it more effective to use the internet, break application barriers that IPv4 imposes on application writers. Since the management of critical Internet resources is at the core of these discussions, IP obviously comes top on the list of things to be discussed. Is electricity a critical internet resource?
The internet operates in a global space without a formal constitution and established procedures, changes in the governance arrangements or the introduction of new resources almost always require experiments. Today we have had successful experiments (arpanet), silicon valley. With this in mind each new task in the area of critical Internet resources turns out to be pioneering work with uncertain outcomes.
On IPv6, I believe the way forward is to just get on with it; all of us together. The teachers should teach it, networks should provide it to users, policy makers should ensure IPv6 is embeded in their decision making. We all need to jump together then deal with the issues as they come along. Thats how the internet grew, thats how we should move it forward.
So why is why is the uptake of IPv6 is so slow and what are the obstacles that prevent vendors and operators from offering IPv6? I work for an operator, I work with vendors. Apart from ignorance, the other obstacle as far as I can tell is fear.I think one of the things I hope to bring in is that:
- IPv6 works, the transition can be painless - I have some experience with this and don't mind working with whoever requires the know how.
Ref:
http://www.intgovforum.org/cms/images/2010/book/igf.sharm.book.final.pdf
Tunis agenda
Showing posts with label IPv6. Show all posts
Showing posts with label IPv6. Show all posts
Friday, August 5, 2011
Saturday, June 11, 2011
Third World Networkers musings on the future for IPv6
I like it love it when the chickens come home to roost.
I was looking over ripe (for those who don't know, RIPE used to be the African RIR before AFRINIC was formed, my first LIR training was with RIPE so I tend and like to follow their proceedings). Anyway so I was going through RIPE 62's IPv6 sessions (that is all they discussed it seems) and realized how some 'operators' might get a very interesting edge over other players just by showing a readiness and willingness to work with key stakeholders in their respective markets.
Remember if you have done nothing up to now about IPv6, you stand to lose out quite a bit. you miss out on getting cheap experience for your engineers, you miss out on working out the kinks in pricing, application modelling and a host of other issues. In my case I imagine DPI and billing will be a pain in a tender area. You will lose customers.
Also most of what is being done now is pure experimentation, which is fine. The entire internet model is an experiment, try this, do that, tweak here; it's constantly improving and morphing. I never expected, ever to deploy a site with 30Gbps of bandwidth in Kenya, ever. But it's been done.
The present value of IPv6 and associated technologies is very very discounted. It will cost you more in the future to train, to migrate, to work with IPv6. You'll also probably lose alot of staff if you don't give them an opportunity to participate, an outlet for the enthusiasm we feel when dealing with new technologies and toys.I we love toys.
So it was no wonder that transition mechanisms are at the top of the list of issues for content providers too. Will tunnels work? I doubt it, not for everything anyway. what about NAT? we all know what that does. Content providers obviously want end to end IPv6 (native IPv6). This clears a path for their content from the user to the content. It's perfect for them.
It was rightly pointed out to me at Afnog that waiting for user demand is really not a wise idea. Users don't care much how they get their content, why would they start now? because you have a new buzz word? for bragging rights? 'heyy duuuude, check out my IPv6!'...Ha!
Anyway, to break this loop; waiting for user demand by carriers/ISP's and waiting for ISP's/Telcos to deploy IPv6 by content providers before deploying IPv6 on their systems, we all need to jump together. We learn together. Content providers need to dual stack or at least start running audits. ISP's pretty much know they need to have IPv6 on their core network, they should be peering with IPv6. Most have done that. Most are working on the access side now.
If you are a content provider, you're probably right in fearing that ISP's and other carriers will hide their traffic, their users, your customers behind NAT's (NAT can break your billing for instance) and other content gateways when IPv4 is finally trully completely depleted. They'll create walls around their users.
It's a risky situation and ISP's can exploit it; If I introduce NAT and hide the users, you have to come to me and negotiate for some sort of 'cdr'/customer data to effectively bill, also forget any lawful intercepts or proper logging - hence the need for regulator intervention if IPv6 uptake is slow by all parties. I don't think this is a major risk in Kenya. We don't have that many content providers or neutral data centers - sad but true.
There is no excuse for an ISP to not have basic IPv6 set up. It on the same note is irresponsible for a content provider or datacenter owner to not start playing around with content provision over IPv6, and requesting for IPv6 connectivity upstream. Datacenter and other content owners need neutral networks to sell their services. To help things along, it is imperative that content owners turn on dual-stack at the content level.
Don't get me wrong, there will be issues. But isn't it better to deal with them with everyone? Isn't it better to train your noc now? you want a situation where if a customer calls in the future with IPv6 related issues, it's handled just like any other call because your staff are so 'with it'.
Note customers get connectivity from an ISP or ('insert favorite name for a guy offering connectivity services here'). Customers know them as 'internet providers'. They call them if they have a problem. No customer I know in Kenya calls facebook when that page is unreachable. Most call Safaricom, or whoever connects them. Nothing will necessarily change their thinking in a post IPv4 world.
Which means if content providers don't do their transition properly the service providers helpdesk gets congested with calls from angry consumers. That creates unnecessary tension. I hope you now begin to see why this effort has to be end to end.
It is a good time as disruptive times tend to be to try and exploit the opportunity and improve your relative position and control of the market. Kenya doesn't have many content providers, I hate that fact, looking at those statistics can be very disheartening and I hope in the future to get involved in content generation, or just fund or help build platforms.
There is a huge untapped potential. However if we move fast and show the world and ourselves that we can offer native IPv6 to a popular content provider and you are a network with many many users with native IPv6, then you stand a higher chance of nailing that business.
Look in the end customers want content. ISP's are unfortunately just pipes for now unless you are very creative. You can work now and partner with content providers or wait for your demise.
It's a good time for re-invention. As a guy that designs networks and sometimes applications to get by, and have done it for a while now. I know this will probably be one of the most interesting periods for me. I also know this transition can't be wished away. Soon there will be real market forces driving it.
Either way we have far bigger issues to deal with. Lets just get this IPv6 done. Its easy, its fun, life can get much much more complicated than a few extra bits.....
ps*
I am going back to more deployment like technical implementation scenarios and writing, the focus is on processes and documentation, IPv6, data center technologies and multicast.... so if you'd like something tested out - let me know.
I was looking over ripe (for those who don't know, RIPE used to be the African RIR before AFRINIC was formed, my first LIR training was with RIPE so I tend and like to follow their proceedings). Anyway so I was going through RIPE 62's IPv6 sessions (that is all they discussed it seems) and realized how some 'operators' might get a very interesting edge over other players just by showing a readiness and willingness to work with key stakeholders in their respective markets.
Remember if you have done nothing up to now about IPv6, you stand to lose out quite a bit. you miss out on getting cheap experience for your engineers, you miss out on working out the kinks in pricing, application modelling and a host of other issues. In my case I imagine DPI and billing will be a pain in a tender area. You will lose customers.
Also most of what is being done now is pure experimentation, which is fine. The entire internet model is an experiment, try this, do that, tweak here; it's constantly improving and morphing. I never expected, ever to deploy a site with 30Gbps of bandwidth in Kenya, ever. But it's been done.
The present value of IPv6 and associated technologies is very very discounted. It will cost you more in the future to train, to migrate, to work with IPv6. You'll also probably lose alot of staff if you don't give them an opportunity to participate, an outlet for the enthusiasm we feel when dealing with new technologies and toys.
So it was no wonder that transition mechanisms are at the top of the list of issues for content providers too. Will tunnels work? I doubt it, not for everything anyway. what about NAT? we all know what that does. Content providers obviously want end to end IPv6 (native IPv6). This clears a path for their content from the user to the content. It's perfect for them.
It was rightly pointed out to me at Afnog that waiting for user demand is really not a wise idea. Users don't care much how they get their content, why would they start now? because you have a new buzz word? for bragging rights? 'heyy duuuude, check out my IPv6!'...Ha!
Anyway, to break this loop; waiting for user demand by carriers/ISP's and waiting for ISP's/Telcos to deploy IPv6 by content providers before deploying IPv6 on their systems, we all need to jump together. We learn together. Content providers need to dual stack or at least start running audits. ISP's pretty much know they need to have IPv6 on their core network, they should be peering with IPv6. Most have done that. Most are working on the access side now.
If you are a content provider, you're probably right in fearing that ISP's and other carriers will hide their traffic, their users, your customers behind NAT's (NAT can break your billing for instance) and other content gateways when IPv4 is finally trully completely depleted. They'll create walls around their users.
It's a risky situation and ISP's can exploit it; If I introduce NAT and hide the users, you have to come to me and negotiate for some sort of 'cdr'/customer data to effectively bill, also forget any lawful intercepts or proper logging - hence the need for regulator intervention if IPv6 uptake is slow by all parties. I don't think this is a major risk in Kenya. We don't have that many content providers or neutral data centers - sad but true.
There is no excuse for an ISP to not have basic IPv6 set up. It on the same note is irresponsible for a content provider or datacenter owner to not start playing around with content provision over IPv6, and requesting for IPv6 connectivity upstream. Datacenter and other content owners need neutral networks to sell their services. To help things along, it is imperative that content owners turn on dual-stack at the content level.
Don't get me wrong, there will be issues. But isn't it better to deal with them with everyone? Isn't it better to train your noc now? you want a situation where if a customer calls in the future with IPv6 related issues, it's handled just like any other call because your staff are so 'with it'.
Note customers get connectivity from an ISP or ('insert favorite name for a guy offering connectivity services here'). Customers know them as 'internet providers'. They call them if they have a problem. No customer I know in Kenya calls facebook when that page is unreachable. Most call Safaricom, or whoever connects them. Nothing will necessarily change their thinking in a post IPv4 world.
Which means if content providers don't do their transition properly the service providers helpdesk gets congested with calls from angry consumers. That creates unnecessary tension. I hope you now begin to see why this effort has to be end to end.
It is a good time as disruptive times tend to be to try and exploit the opportunity and improve your relative position and control of the market. Kenya doesn't have many content providers, I hate that fact, looking at those statistics can be very disheartening and I hope in the future to get involved in content generation, or just fund or help build platforms.
There is a huge untapped potential. However if we move fast and show the world and ourselves that we can offer native IPv6 to a popular content provider and you are a network with many many users with native IPv6, then you stand a higher chance of nailing that business.
Look in the end customers want content. ISP's are unfortunately just pipes for now unless you are very creative. You can work now and partner with content providers or wait for your demise.
It's a good time for re-invention. As a guy that designs networks and sometimes applications to get by, and have done it for a while now. I know this will probably be one of the most interesting periods for me. I also know this transition can't be wished away. Soon there will be real market forces driving it.
Either way we have far bigger issues to deal with. Lets just get this IPv6 done. Its easy, its fun, life can get much much more complicated than a few extra bits.....
ps*
I am going back to more deployment like technical implementation scenarios and writing, the focus is on processes and documentation, IPv6, data center technologies and multicast.... so if you'd like something tested out - let me know.
Wednesday, June 8, 2011
Happy world IPv6 day
The desired effect after today for me is:
- Wider recognition that IPv4 whether we like it or not will not work for the next 'internet'. Can't scale, won't scale for the future.
- Massive large scale complaints from customers to jolt executives awake on IPv6. this is unlikely if you the network guy has done his job well. (see how you are your own bottleneck for progress)?
- Mobile network Operators need to realize that IPv6 affects them more than most. IPv6 will be heavilly used on mobile devices. (home automation devices, sensors, handsets, POS,atm's etc etc).
- if you are a cio/cto/ceo don't assume your guys have not been doing anything about IPv6. Just ask nicely. we hate it when you sound clueless. we're supposed to look up to you. Just ask something like; 'hey gitau, how far are along are we with ipv6? can we offer something to customers? maybe invite a few for trials?' can we put something together for the media? yes and yes and yes...probably not the answer you expected. Remember you probably heard about it the other day, gitau has been quietly working on this for +5 years.
- AFRINIC while holding a lot of addressing resources for us can't guarantee business continuity for your network should some killer apps be hosted and implemented only for IPv6.
- Laziness will get us nowhere. Ignorance is not an excuse either.
- IPv6 is a cliff we third world networkers should jump with the rest of the world. If we get left behind, we'll miss out on experience and the opportunity to be 'with it' as its happening. jump with the rest of the world.
- At lunch yesterday, someone suggested we (AFRINIC) just goes ahead and sells/auctions off all IPv4 addresses remaining to stop the illusion that we can survive with IPv4.
- IPv6 education needs to be taken seriously.
- Organizations can expect some IPv6 brain drain.
- Widespread collaboration has to be enforced. We need in organization, in country, in region forums discussing this issues. Policy has to embed futuristic thinking.
- Corporates need to embrace and promote IPv6. Sponsored events should be encouraged.
- Don't accept any design without IPv6 considerations. don't.
- Don't host with guys without IPv6. Even 'clouds' should be ipv6 aware.
- Install and run an IPv6 DMZ. start with DNS.
- Apply for your IPv6 addresses today. Make sure its provider independent. If you'd like to know how and why you need this, leave a comment. I can cover how to go about getting IPv6 space.
- Start peering with IPv6. Ask your service provider for IPv6. It should be free. I really hope no one charges to connect, peer or give customers IPv6 addresses. I know most have no policy on this. Just demand for it the same way you do for other services.
- Ensure your infrastructure is v6 ready. do an audit. maybe I can help. throw me a comment.
- Talk about IPv6 in your next meeting. just add it as an FYI.
- call safaricom, they have some really clueful guys when it comes to these things and i'm not just saying it.
In the end the fact is there will be change. plan for it and deal with it. Otherwise IPv6 will be the gift that keeps giving to consultants from your pocket.
- Wider recognition that IPv4 whether we like it or not will not work for the next 'internet'. Can't scale, won't scale for the future.
- Massive large scale complaints from customers to jolt executives awake on IPv6. this is unlikely if you the network guy has done his job well. (see how you are your own bottleneck for progress)?
- Mobile network Operators need to realize that IPv6 affects them more than most. IPv6 will be heavilly used on mobile devices. (home automation devices, sensors, handsets, POS,atm's etc etc).
- if you are a cio/cto/ceo don't assume your guys have not been doing anything about IPv6. Just ask nicely. we hate it when you sound clueless. we're supposed to look up to you. Just ask something like; 'hey gitau, how far are along are we with ipv6? can we offer something to customers? maybe invite a few for trials?' can we put something together for the media? yes and yes and yes...probably not the answer you expected. Remember you probably heard about it the other day, gitau has been quietly working on this for +5 years.
- AFRINIC while holding a lot of addressing resources for us can't guarantee business continuity for your network should some killer apps be hosted and implemented only for IPv6.
- Laziness will get us nowhere. Ignorance is not an excuse either.
- IPv6 is a cliff we third world networkers should jump with the rest of the world. If we get left behind, we'll miss out on experience and the opportunity to be 'with it' as its happening. jump with the rest of the world.
- At lunch yesterday, someone suggested we (AFRINIC) just goes ahead and sells/auctions off all IPv4 addresses remaining to stop the illusion that we can survive with IPv4.
- IPv6 education needs to be taken seriously.
- Organizations can expect some IPv6 brain drain.
- Widespread collaboration has to be enforced. We need in organization, in country, in region forums discussing this issues. Policy has to embed futuristic thinking.
- Corporates need to embrace and promote IPv6. Sponsored events should be encouraged.
- Don't accept any design without IPv6 considerations. don't.
- Don't host with guys without IPv6. Even 'clouds' should be ipv6 aware.
- Install and run an IPv6 DMZ. start with DNS.
- Apply for your IPv6 addresses today. Make sure its provider independent. If you'd like to know how and why you need this, leave a comment. I can cover how to go about getting IPv6 space.
- Start peering with IPv6. Ask your service provider for IPv6. It should be free. I really hope no one charges to connect, peer or give customers IPv6 addresses. I know most have no policy on this. Just demand for it the same way you do for other services.
- Ensure your infrastructure is v6 ready. do an audit. maybe I can help. throw me a comment.
- Talk about IPv6 in your next meeting. just add it as an FYI.
- call safaricom, they have some really clueful guys when it comes to these things and i'm not just saying it.
In the end the fact is there will be change. plan for it and deal with it. Otherwise IPv6 will be the gift that keeps giving to consultants from your pocket.
Monday, June 6, 2011
IPv6 - Third world networkers catching up
So for the last couple of months I've been thinking hard and working out what I think are major issues with IPv6 adoption within EA.
First of all the regulators in the industry are a major barrier to driving some technologies forward. This is especially so for 'new' stuff that doesn't seem to be making money directly. (*this happens everywhere, justifying network spend is not easy in an organization, but governments and policy makers are there not for profit so I expect more from them).
The competitive environment among the major players eg Safaricom and Airtel makes it quite difficult for collaboration. Without collaboration what might once have been an easy task suddenly becomes a major issue. I don't mind the politics, but a line has to be drawn somewhere.
If there's one thing I miss about working in a pure ISP environment, it was the easy time we had just being able to chat with our 'rivals' technical people about technology. In telco's, even localized within organization collaboration is really difficult.
What might help:
An open membership forum/working group along the likes of go6 in slovania, for a small country <3M, thay have done quite alot with IPv6.
The membership would be open to ISP's, telcoms, regulators, big corporations, an expert council - to steer things, universities and tertiary colleges and individuals within the region. I say region because the challenges are different and we need to learn from our own experiences while borrowing from others who have done this before.
The main goal would probably be to publicize IPv6, arrange for more training along different lines eg applications, networking, System administration etc. They would host local ipv6 deployment labs, an ipv6 academy etc.
They would ensure that people are talking about IPv6. Help with deployments, put together the information for everyone to access, bring the competitors together, bring government to the table, help universities update their offerings etc etc.
Why do East Africans need IPv6 - well because we are part of the world. Guys are doing alot in this area. I know we are doing quite a bit, but the 'alot' we are doing needs to start being deployed with executive blessings - not some enthusiastic techies working alone during their 'free' time.
I keep insisting that if you are an operator with more than 500K subscribers (Safaricom,Airtel,Zuku), offering multiplay services then you need IPv6. It's clean, ensures end to end connectivity for your services, and its cheaper in the long run , you definately need it more urgently than everyone else. How do you think you'll sell connectivity to all those sensors, set top boxes, home automation stuff,handsets,pos's, atm's etc etc that will mainly ride on wireless networks?
Thinking about it, one of them should come out and sponsor monthly IPv6 meetups.
If you are a network designer/sysadmin/programmer, make sure whatever you design is IPv6 ready. Do not for instance buy from a vendor with no support (not roadmap) for IPv6. Do not build a new data center without an IPv6 plan (believe me I saw one very recently).
Go to afnog, so far it offers the best forum for expression. Unfortunately it happens once a year hence the need for something a little bit different. See you there on Tuesday.
First of all the regulators in the industry are a major barrier to driving some technologies forward. This is especially so for 'new' stuff that doesn't seem to be making money directly. (*this happens everywhere, justifying network spend is not easy in an organization, but governments and policy makers are there not for profit so I expect more from them).
The competitive environment among the major players eg Safaricom and Airtel makes it quite difficult for collaboration. Without collaboration what might once have been an easy task suddenly becomes a major issue. I don't mind the politics, but a line has to be drawn somewhere.
If there's one thing I miss about working in a pure ISP environment, it was the easy time we had just being able to chat with our 'rivals' technical people about technology. In telco's, even localized within organization collaboration is really difficult.
What might help:
An open membership forum/working group along the likes of go6 in slovania, for a small country <3M, thay have done quite alot with IPv6.
The membership would be open to ISP's, telcoms, regulators, big corporations, an expert council - to steer things, universities and tertiary colleges and individuals within the region. I say region because the challenges are different and we need to learn from our own experiences while borrowing from others who have done this before.
The main goal would probably be to publicize IPv6, arrange for more training along different lines eg applications, networking, System administration etc. They would host local ipv6 deployment labs, an ipv6 academy etc.
They would ensure that people are talking about IPv6. Help with deployments, put together the information for everyone to access, bring the competitors together, bring government to the table, help universities update their offerings etc etc.
Why do East Africans need IPv6 - well because we are part of the world. Guys are doing alot in this area. I know we are doing quite a bit, but the 'alot' we are doing needs to start being deployed with executive blessings - not some enthusiastic techies working alone during their 'free' time.
I keep insisting that if you are an operator with more than 500K subscribers (Safaricom,Airtel,Zuku), offering multiplay services then you need IPv6. It's clean, ensures end to end connectivity for your services, and its cheaper in the long run , you definately need it more urgently than everyone else. How do you think you'll sell connectivity to all those sensors, set top boxes, home automation stuff,handsets,pos's, atm's etc etc that will mainly ride on wireless networks?
Thinking about it, one of them should come out and sponsor monthly IPv6 meetups.
If you are a network designer/sysadmin/programmer, make sure whatever you design is IPv6 ready. Do not for instance buy from a vendor with no support (not roadmap) for IPv6. Do not build a new data center without an IPv6 plan (believe me I saw one very recently).
Go to afnog, so far it offers the best forum for expression. Unfortunately it happens once a year hence the need for something a little bit different. See you there on Tuesday.
Tuesday, May 31, 2011
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
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
Monday, May 16, 2011
IPv6 deployment status
IPv6 deployment status
Kenya's ipv6 deployment sucks, heck we don't have AAAA records even for google.co.ke,safaricom.co.ke etc...which pretty much means June 6 th - IPv6 day will hopefully break something - I hope that happens if only to get the sleeping execs up....
Kenya's ipv6 deployment sucks, heck we don't have AAAA records even for google.co.ke,safaricom.co.ke etc...which pretty much means June 6 th - IPv6 day will hopefully break something - I hope that happens if only to get the sleeping execs up....
Monday, April 11, 2011
8 June, 2011 - World IPv6 Day
I hate that this blog hasn't focused a lot more on ipv6. I take solace in the fact that mobile networks are not going to ipv6 soon (mainly out of ignorance if you ask me), Infact I suspect they will have to be forced to use it since no one will be thinking about it if the decision is left to the guys I see making current decisions in the telco space (imagine if apple released an IPv6 only iphone).
Mobile operators stand to benefit the most from IPv6 mainly from M2M applications/communications. Incidentally People so afraid of change are unfortunately in charge of moving us forward (from the regulator to the operators). Focus on mobile number portability has wasted lots of time. a few people saw it as the dead end it seems to be.
Its a clear case of the blind leading the sighted:-) I see it in the whole industry, there's alot of talk in mailing lists about 'issues' but no action *Please read disclaimer below if you're about to rant*. Politics doesn't get work done.
It will be a consultants field day:-) when IPv6 gets forced on the networks. Closer to home, we have some internet peering but dont have a single service on IPv6 (2c0f:fe38::/32): from the cable and wireless looking glass you'll find us represented:-) I would really like to have some IPv6 pdp contexts activated, an IPv6 dmz, to test end to end mobile IPv6.
* so yes our network is IPv6 ready, we can definately provide IPv6 connectivity but we again haven't really tested any service - yet, and you wont have many places to 'go' to that areipv6 enabled. I however wish you'd begin testing. Believe me you'll save money in the near future.
we haven't progressed the IPv6 initiative as much as we should have in Kenya either, the network guys seem ready. The local exchange point has a bunch of us IPv6 peering, but we as yet have no applications running on it - apart from DNS and hmm I wonder if the google global cache reachable through KIXP is IPv6 enabled.
tracing to the ipv6.google.com uses our international link so I guess not, or I used the wrong fqdn.
So...scoot over to the isc . its important to note here that whether we like it or not, among others, Facebook, Google, Yahoo, Cisco, Akamai Technologies, Limelight Networks, W3C, Bing (Microsoft), Tom's Hardware, Rackspace, Verizon, and Juniper have committed to participating in the experiment (wikipedia).We will all participate if our users visit sites affiliated with the networks above. so we might as well do something about our infrastructure.
what are you doing about it?
I am not directly responsible for this infrastructure at work anymore but I'll definately make a concerted effort to ensure our customers don't get caught off guard. and now Im sleepy:-)
Mobile operators stand to benefit the most from IPv6 mainly from M2M applications/communications. Incidentally People so afraid of change are unfortunately in charge of moving us forward (from the regulator to the operators). Focus on mobile number portability has wasted lots of time. a few people saw it as the dead end it seems to be.
Its a clear case of the blind leading the sighted:-) I see it in the whole industry, there's alot of talk in mailing lists about 'issues' but no action *Please read disclaimer below if you're about to rant*. Politics doesn't get work done.
It will be a consultants field day:-) when IPv6 gets forced on the networks. Closer to home, we have some internet peering but dont have a single service on IPv6 (2c0f:fe38::/32): from the cable and wireless looking glass you'll find us represented:-) I would really like to have some IPv6 pdp contexts activated, an IPv6 dmz, to test end to end mobile IPv6.
inet6.0: 5546 destinations, 31745 routes (5535 active, 0 holddown, 14 hidden)
+ = Active Route, - = Last Active, * = Both
2c0f:fe38::/32 *[BGP/170] 2w3d 09:10:07, MED 0, localpref 80
AS path: 6453 33771 I
> to 2001:5002:100:4::2 via ae0.1404* so yes our network is IPv6 ready, we can definately provide IPv6 connectivity but we again haven't really tested any service - yet, and you wont have many places to 'go' to that areipv6 enabled. I however wish you'd begin testing. Believe me you'll save money in the near future.
we haven't progressed the IPv6 initiative as much as we should have in Kenya either, the network guys seem ready. The local exchange point has a bunch of us IPv6 peering, but we as yet have no applications running on it - apart from DNS and hmm I wonder if the google global cache reachable through KIXP is IPv6 enabled.
tracing to the ipv6.google.com uses our international link so I guess not, or I used the wrong fqdn.
Primary#traceroute ipv6 ipv6.google.com
Type escape sequence to abort. Tracing the route to 2A00:1450:8002::93 1 2001:5A0:C00:100::35 [AS 6453] 292 msec 2001:5A0:C00:100::15 224 msec 2001:5A0:C00:100::35 248 msec 2 2001:5A0:2A00:100::1 [AS 6453] 180 msec 180 msec 180 msec 3 2001:5A0:2000:400::2 [AS 6453] 188 msec 188 msec 184 msec 4 2A01:3E0:FFF0:400::D [AS 6453] 188 msec 188 msec 188 msec 5 2A01:3E0:FF80:100::9 [AS 6453] 200 msec 196 msec 196 msec 6 2A01:3E0:FF20::3A [AS 6453] 196 msec 220 msec 196 msec 7 2001:7F8::3B41:0:1 [AS 6453] 200 msec 228 msec 200 msec 8 2001:4860::1:0:10 [AS 6453] 228 msec 200 msec 200 msec 9 2001:4860::1:0:8 [AS 6453] 208 msec 208 msec 204 msec 10 2001:4860::8:0:2AC3 [AS 6453] 212 msec 212 msec 212 msec 11 2001:4860::2:0:87D [AS 6453] 212 msec 208 msec 220 msec 12 2001:4860:0:1::25 [AS 6453] 216 msec 2001:4860:0:1::23 212 msec 2001:4860:0:1::25 220 msec 13 2A00:1450:8002::93 [AS 6453] 208 msec 212 msec 208 msecI hope and wish to have a full IPv6 DMZ (dns,smtp,ntp,pop,www,wap,looking glass etc) by the IPV6 day.
So...scoot over to the isc . its important to note here that whether we like it or not, among others, Facebook, Google, Yahoo, Cisco, Akamai Technologies, Limelight Networks, W3C, Bing (Microsoft), Tom's Hardware, Rackspace, Verizon, and Juniper have committed to participating in the experiment (wikipedia).We will all participate if our users visit sites affiliated with the networks above. so we might as well do something about our infrastructure.
what are you doing about it?
I am not directly responsible for this infrastructure at work anymore but I'll definately make a concerted effort to ensure our customers don't get caught off guard. and now Im sleepy:-)
Monday, March 16, 2009
IPv6 From the Ground Up : Part - II
ICMPv6
ICMP for IPv6 is identified by a header value of 58 in the IPv6 next header field. ICMPv6 is used to report errors and perform internet layer functions eg ping for diagnostics. It's the base protocol for IPv6 and has to be fully implemented and understood by aspiring engineers.
Diagram used for this article is:
IPv6 Neighbor discovery and unicast routing.
Unicast routing is off by default, remember to enable it to allow ICMpv6 neighbor discovery that replaces ARP.
note the expanded 0's (zeroes below), they mean the same thing.
note similar commands have to be run on router 1.
Now lets take some debug to observe this process of enabling th elink local address, but first cover a few basics:
Here - above- R0 sends then sends out an RA - router advertisement
other commands that show output for different IP versions:
ICMP for IPv6 is identified by a header value of 58 in the IPv6 next header field. ICMPv6 is used to report errors and perform internet layer functions eg ping for diagnostics. It's the base protocol for IPv6 and has to be fully implemented and understood by aspiring engineers.
Diagram used for this article is:
IPv6 Neighbor discovery and unicast routing.
Unicast routing is off by default, remember to enable it to allow ICMpv6 neighbor discovery that replaces ARP.
Router0(config)#ipv6 unicast-routing
Router0(config)#int f0/0
Router0(config-if)#ipv6 enable
Router0(config-if)#no shutdown
Router0#sh int f0/0
FastEthernet0/0 is up, line protocol is up
Hardware is AmdFE, address is cc00.1368.0000 (bia cc00.1368.0000)
Router0#sh ipv6 interface fastEthernet 0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::CE00:13FF:FE68:0
No global unicast address is configured
Joined group address(es):
FF02::1
FF02::1:FF68:0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
Router0#ping FE80::CE01:13FF:FE68:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:13FF:FE68:0, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/40/164 ms
note the expanded 0's (zeroes below), they mean the same thing.
Router0#ping FE80:0000:0000:0000:CE01:13FF:FE68:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:13FF:FE68:0, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/32/96 ms
note similar commands have to be run on router 1.
Now lets take some debug to observe this process of enabling th elink local address, but first cover a few basics:
- IPv6 host adresses are generated from interface mac addresses. from the previouse post (partI), mac addresses are 48 bits and need conversion to 64bit to make a EUI-64 address.
- ICMPv6 Neighbor discovery is used to resolve layer 3 address to Layer 2 address. in case of ethernet, that would be a mac address to an IP address, or frame relay dlci to an address, or pvc to an ip address etc etc...
- This is not necessary for point to point links. the router knows that any traffic resolving/recursing to the interface based on the routing table will use whatever layer 2 circuit is assigned to the circuit.
- no inverse neighbor discovery yet. so all routes should be mapped incase of frame relay (frame relay map ipv6).
- Solicitations - asking other neighbors for info.
- Neighbor Solicitations - By any general hosts eg desktops and other hosts.
- Router Solicitations - Devices routing IPV6 eg a default gateway. eg router to router segments.
- Used to decide what the remote L2 address is of hosts and routers. The two types are there because there is additional info apart from the L2 address. eg routers can tell hosts the network prefix - this way a host just needs to enable IPV6, start sending neighbor solicitations to find out the neighbor, and router solicitation to find out the routers. The router sends back the network bit and the host - stateless autoconfiguration is built into ipv6 protocol stack.
- Advertisements - sending informations.
- Neighbor advertisements
- Router Advertisemens.
Router0(config)#
ICMPv6: Received ICMPv6 packet from ::, type 135
ICMPv6: Received ICMPv6 packet from FE80::CE00:13FF:FE68:0, type 136
ICMPv6-ND: Sending NS for FE80::CE01:16FF:FE0C:0 on FastEthernet0/0
!note the NS (neighbor solicitation) this is basically like asking' can I use this address?"
IPV6: source :: (local)
dest FF02::1:FF0C:0 (FastEthernet0/0)
!solicited node multicast address...used for duplicate address detection (DAD). ie essentially we ask 'is anyone using this address? in the segment.)
traffic class 224, flow 0x0, len 64+16, prot 58, hops 255, originating
IPv6: Sending on FastEthernet0/0
ICMPv6-ND: DAD: FE80::CE01:16FF:FE0C:0 is unique.
!Note chances of having a conflict are rare in this case since the address is derived from your mac address.and ICMPv6 acknowledges that the address is indeed unique.
ICMPv6-ND: Sending NA for FE80::CE01:16FF:FE0C:0 on FastEthernet0/0
!next we are advertising that we're an IPV6 neighbor with the address above.
IPV6: source FE80::CE01:16FF:FE0C:0 (local)
dest FF02::1 (FastEthernet0/0)
traffic class 224, flow 0x0, len 72+8, prot 58, hops 255, originating
IPv6: Sending on FastEthernet0/0
ICMPv6-ND: Address FE80::CE01:16FF:FE0C:0/0 is up on FastEthernet0/0
Router0(config)#
ICMPv6-ND: Sending RA to FF02::1 on FastEthernet0/0
ICMPv6-ND: MTU = 1500
IPV6: source FE80::CE00:16FF:FE0C:0 (local)
dest FF02::1 (FastEthernet0/0)
traffic class 224, flow 0x0, len 72+1428, prot 58, hops 255, originating
IPv6: Sending on FastEthernet0/0
Here - above- R0 sends then sends out an RA - router advertisement
and receives an advertisement from R1. Please note no network addresses are set yet, so what you receive is the routers link local address.
ICMPv6: Received ICMPv6 packet from FE80::CE01:16FF:FE0C:0, type 134
ICMPv6-ND: Received RA from FE80::CE01:16FF:FE0C:0 on FastEthernet0/0
Router0#show ipv6 neighborsnote the routers above only have link local processing
IPv6 Address Age Link-layer Addr State Interface
FE80::CE01:16FF:FE0C:0 0 cc01.160c.0000 REACH Fa0/
other commands that show output for different IP versions:
Router0#sh ipv6 int brief
FastEthernet0/0 [up/up]
FE80::CE00:16FF:FE0C:0
!shows the link local addresses on our interfaces.
Router0#sh ip int br
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 1.1.1.1 YES manual up upRouter0#sh ipv6 route
Router0#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 1.1.1.1 - cc00.160c.0000 ARPA FastEthernet0/0
Router0#sh ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
FE80::CE01:16FF:FE0C:0 2 cc01.160c.0000 STALE Fa0/0IPv6 Routing Table - 2 entriesRouter0#sh ipv6 int
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
U - Per-user Static route
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
L FE80::/10 [0/0]
via ::, Null0
L FF00::/8 [0/0]
via ::, Null0
!note the Null0, this is because the traffic is local (remember this are not global addresses yet).
FE80::/10 is the entire range of link local addresses.
Router0#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, FastEthernet0/0FastEthernet0/0 is up, line protocol is upall other commands, telnet etc also work but you need to be specific. Is there get a way to make ipv6 default IPversion
IPv6 is enabled, link-local address is FE80::CE00:16FF:FE0C:0
No global unicast address is configured
Joined group address(es):
FF02::1
!all host multicast, this is where the advertisements are sent to for autoconfiguration.
FF02::2
FF02::1:FF0C:0
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
Hosts use stateless autoconfig for addresses.
Router0#sh ip int
FastEthernet0/0 is up, line protocol is up
Internet address is 1.1.1.1/24
Broadcast address is 255.255.255.255
Address determined by setup command
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
another question:
can you disable IPv4 processing and only have IPV6 processing on a router?
Interesting question came up during this writing:
can you disable IPv4 processing and only have IPV6 processing on a router?
Tuesday, March 10, 2009
IPv6 From the Ground Up : Part - I
The Basics
**Please go through rfc2373 in its entirety. Life will be much easier after that.
Our learning topology is a simple: two routers just to show neighbor discovery: This will mainly be used on PartII and any others that follow.
Understanding IPv6 without using it is might not be easy, however playing around with it while planning a CCIE should set you on the right path.
To get a proper grasp of IPv6, you need to understand:
- A link-local address, site-local and global IPv6 address.
- The loopback address (::1) for the loopback interface
- The multicast addresses of joined groups
- Number of bits on an IPv6 address (128 - bits, 16 bytes)
Also very important, what is a modified EUI-address, its purpose and how its generated. I found it also very important to know and understand IEEE 802 addresses.
Basics on MAC addressing:
The IEEE 802 address consist of 24 bit company identifier and a 24 bit extension ID. this is uniquely assigned and gives you a 48-bit address. This 48-bit address is also called the physical, hardware, or media access control (MAC) address.
EUI-64 Addresses
This addressing extends the '24-bit' extension ID on a MAC address to 40 bits. The company/manufacturer ID is still left at 24-bits. This 64 bits are then used to identify the host/node. This is what is called a link local address. Routers do not forward this addresses.
To convert a MAC address to an EUI address, I use the following method. Note this only gives us the link local address, in part 2 or 3 we'll discuss how the rest of the address is completed/generated....lets use an example:
Host X has a MAC address of 12-34-56-78-90-12
on a router, this would be the burnt in address (bia) or the mac address.
First we insert FFFE between the 3rd and 4th bytes ie between the vendor ID and extension ID which results to 12-34-5F-FF-E6-78-90-12/1234-5678-9012. You can easilly do this by slicing the address into two halves.
Next take the first byte (two characters=1 byte) so in our case the first byte is 12 (note this is in hex) and convert it to binary - 0001 0010.. Take the 7th most significant bit and flip it/or invert it, this gives 0001 0000. Convert this back to hex and you get :
10-34-5F-FF-E6-78-90-12
put this in proper notation for IPv6 and get:
1034:56FF:FE78:9012
In case you get hang up on wording
The IEEE now considers the label MAC-48 to be an obsolete term which was previously used to refer to a specific type of EUI-48 identifier used to address hardware interfaces within existing 802-based networking applications and should not be used in the future. Instead, the term EUI-48 should be used for this purpose.
references:
RFC2373 - IP Version 6 Addressing Architecture
My friend tells me most of what he learnt on IPv6 was solidified at an internetwork experts boot camp so go over to their site and grab some work book, have no idea which one in particular.
Part II
IPv6 Neighbor Discovery:
**Please go through rfc2373 in its entirety. Life will be much easier after that.
Our learning topology is a simple: two routers just to show neighbor discovery: This will mainly be used on PartII and any others that follow.
Understanding IPv6 without using it is might not be easy, however playing around with it while planning a CCIE should set you on the right path.
To get a proper grasp of IPv6, you need to understand:
- A link-local address, site-local and global IPv6 address.
- The loopback address (::1) for the loopback interface
- The multicast addresses of joined groups
- Number of bits on an IPv6 address (128 - bits, 16 bytes)
Also very important, what is a modified EUI-address, its purpose and how its generated. I found it also very important to know and understand IEEE 802 addresses.
Basics on MAC addressing:
The IEEE 802 address consist of 24 bit company identifier and a 24 bit extension ID. this is uniquely assigned and gives you a 48-bit address. This 48-bit address is also called the physical, hardware, or media access control (MAC) address.
EUI-64 Addresses
This addressing extends the '24-bit' extension ID on a MAC address to 40 bits. The company/manufacturer ID is still left at 24-bits. This 64 bits are then used to identify the host/node. This is what is called a link local address. Routers do not forward this addresses.
To convert a MAC address to an EUI address, I use the following method. Note this only gives us the link local address, in part 2 or 3 we'll discuss how the rest of the address is completed/generated....lets use an example:
Host X has a MAC address of 12-34-56-78-90-12
on a router, this would be the burnt in address (bia) or the mac address.
First we insert FFFE between the 3rd and 4th bytes ie between the vendor ID and extension ID which results to 12-34-5F-FF-E6-78-90-12/1234-5678-9012. You can easilly do this by slicing the address into two halves.
Next take the first byte (two characters=1 byte) so in our case the first byte is 12 (note this is in hex) and convert it to binary - 0001 0010.. Take the 7th most significant bit and flip it/or invert it, this gives 0001 0000. Convert this back to hex and you get :
10-34-5F-FF-E6-78-90-12
put this in proper notation for IPv6 and get:
1034:56FF:FE78:9012
In case you get hang up on wording
The IEEE now considers the label MAC-48 to be an obsolete term which was previously used to refer to a specific type of EUI-48 identifier used to address hardware interfaces within existing 802-based networking applications and should not be used in the future. Instead, the term EUI-48 should be used for this purpose.
references:
RFC2373 - IP Version 6 Addressing Architecture
My friend tells me most of what he learnt on IPv6 was solidified at an internetwork experts boot camp so go over to their site and grab some work book, have no idea which one in particular.
Part II
IPv6 Neighbor Discovery:
Subscribe to:
Posts (Atom)
Posts
