Thursday, January 28, 2010

Nat-PT

Hey Guys

Just a quick update, more IPv6 Stuff again. Woops it appears that Nat-PT which i just spent some time studying has been depreciated! Doh!

But basically guys, just so you know: The basic idea was to convert any IPv6 address to IPv4, and vice versa. The reason you might want to do this.. is a pretty damn strange scenario to be honest....

The best reason i could think of was this:

You have Ipv6 Only servers in your network that you want to make accessible out on the internet but your ISP doesn't support IPv6 yet, so you go ahead and make a NAT-PT traversal device so that people on the Ipv4 internet can talk to your IPv6 only network, or the other reason might be that one side of your network only supports Ipv4 and the other Ipv6

But frankly, such situations are going to be extremely rare: because lets face it. your going to use dual-stack machines for the foreseeable future (taht is, any of your Ipv6 hosts will haveIpv4 addresses.)

I can truly see NAT-PT being useful once we have almost finished cutting over, but its easy to see why the IETF have depreciated this RFC!

Thanks for reading
pete

Wednesday, January 27, 2010

IPv6 Transition Mechanisms

Hey Guys

An IPv6 Update just for a change. Today I am going to talk about your IPv6 transition mechanism's as I feel we are getting to that stage now.


First a brief rundown of the different methods:

  • Dual Stack
  • IPv6-Over-IPv4
  • 6to4
  • Terodo
  • ISATAP
Since I work for an integrator I will be looking at this more from an enterprise migration standpoint rather than an ISP standpoint. (You ISP guys have it fairly easy, enable all your routers for IPv6, start advertising your IPv6 Prefixes via BGP, bang done :P (I Joke ofcourse))

Okay, so: First method is dual-stack. fairly self explanatory. Every device in your network routes both IPv6 and IPv4, your hosts have both IPv6 and IPv4 addresses, and by setting up AAAA records in your DNS servers eventually all your hosts will be talking IPv6 natively to each other and IPv6 out to the internet when the other end is IPv6 and IPv4 when they can't.

Sounds great huh?

Meanwhile, back in the real world:


"Bugger, our firewall that we MUST use only supports IPv4"
or
"Bugger, our remote offices connect to the main site through an MPLS cloud and the MPLS cloud hasn't been enabled for IPv6"

I am sure you can think of many other scenarios: The point is, having end to end IPv6 from one end of your network to the other and into your ISP, you'd have to be quite fortunate. So here are some solutions:



First, the vanilla plain old "IPv6 over IPv4" Tunnel. Very simple:

interface tunnel0
ipv6 address <>
tunnel source <>
tunnel dest <>
tunnel mode ipv6ip
!

This config obeys all the normal rules of a GRE tunnel (and in actual fact, you can actually also just use a GRE tunnel, not even requiring the words "tunnel mode ipv6ip" like we have shown here.)

So, just like you might use a tunnel to enable multicast traffic to flow over a non-cooperative ISP's cloud for your WAN sites, here you can use a tunnel to encapsulate your IPv6 traffic. Fairly effective and simple.

What if the situation was, you had no remote sites, but at your head office you had a Cisco IPv6 capable router, and a non-ipv6 upgradable Juniper firewall sitting behind that infront of your users?

Internet <---> Router <---> Firewall <---> Users

ISATAP is your friend at this point.

ISATAP is just a tunneling mechanism too. But it is an automatic tunneling mechanism, basically the IPv6 Node with ISATAP enabled will have a dual-stack host assign itself an address where the last 32 bits are the hexadecimal representation of its own IPv4 address, it will then communicate with other ISATAP nodes by encapsulating its IPv6 traffic in IPv4 when trying to talk to other hosts with IPv6, so now all traffic from that host using IPv6 is actually sent across the wire using IPv4 and can therefore be routed as normal. The only issue with this implementation is that multicast is not supported and ISATAP treats the network like it is one big NBMA network. So you may see that ISATAP is really only useful for the purpose of giving a machine an ADDRESS in the IPv6 space; all its actual traffic will still come out as IPv4.

Now, in saying that however, the next enhancement for ISATAP is when you add your Cisco Router: if your Cisco router has a global IPv6 Address and its own assigned prefix (it will have one) the ISATAP clients can see this and will pick there address from this range. Meaning now they can route out to the global IPv6 Internet. Pretty cool hey

The ISATAP clients discover the closest IPv6 capable router using DNS (since, as we mentioned, no multicast method can be used to discover this as ISATAP is NBMA.)

The final option is 6to4 tunnels, basically they encapsulate IPv6 inside IPv4 but tunnels are setup automatically. A future blog post will address this and teredodo (which is a solution for home users or people who do not have IPv6 capable routers (can I interest you in a nice 2911?)

Until next time.

Pete




Saturday, January 23, 2010

DHCPv6

There is now also some huge updates to DHCPv6.

The concepts around this are actually really cool: Basically There are three parts that make up a DHCPv6 in IPv6:

A DHCPv6 Client
A DHCPv6 Server
A DHCPv6 relay


a router can be any of the above (although there are some restrictions to how much DHCP server stuff it can do.)

Now, one of the things I like in IPv6 with DHCP is the Relay function. You are probably all familiar with the IP Helper-address right? Just a super quick recap: If in an IPv4 network you have a DHCP server at your head office, and you want your clients at a remote office to use DHCP, you can use ip helper-address (or dhcp relay) so that a local DHCP server is not required, your clients will broadcast a DHCP request, the local router will see that DHCP request and forward it onto a server of your choosing, and the server will then unicast the reply back to your router which will then broadcast back a DHCP reply so your machine can pick up an address!

Example:


int fa0/1
ip address 10.1.1.1 255.255.255.0
ip helper-address 10.2.2.1
!

In this example, we have a subnet 10.1.1.0/24 which we want to provide DHCP for, so what we would do is setup a server with a scope for 10.1.1.0/24 and then point the router to this server (in our case 10.2.2.1) so it can intercept the DHCP requests

O.K.

So, what cool function does IPv6 provide? well a very funky feature is that in IPv6 the idea of "scope" is used pretty heavily, basically all addresses are "scoped" as either link-local, site-local or global unicast and this controls how far in a network they travel (it could be just on the local link (hence link local) within the organization (hence site-local) or even on the internet (hence global unicast.)

So, what some smart guy said was "hey, why don't we use the Site-local multicast prefix to make an address that all DHCPv6 servers in an organization listen on and have DHCP relays send there DHCP relay requests to that?"

This is really cool because it means you don't have to maintain a list of DHCP servers on your routers that you have setup to act as relays, you just tell them to relay and they will go ahead and send a multicast packet to this site-local dhcp server address and send back a reply!

Sunday, January 10, 2010

Really quick post about SIP in CCM

Hey Guys, playing with the beta of CCM 8 at the moment. quite a few more options than i've seen so far! A new menu called "advanced features" kinda gives that away ;)

(One cool feature i've seen so far: when you go to create a phone, when selecting either SCCP or SIP you can also specify a BAT template for it so it will go and copy all the info from your BAT template. VERY VERY COOL)

But i super quickly wanted to talk about converting to SIP phones:

first off: Its relatively easy, but its important to note that a phone runs either SCCP or SIP image, and the first thing you need to do is get it to use a SIP image (by default SCCP is the default image) the easiest way to do this is with the phone migration tool which automatically changes the firmware on the phone. This can be found under BAT -> Phones -> Phone Migration

HOWEVER, it is very buggy, and it personally did not work for me. So based on this your second option is to go ahead and find the

"phone load information"

field on your phone and fill this in with the name of the SIP image which you can find by going
to Device - Device Settings - Device Defaults, so for example for a 7960 Phone the SIP image is:

"P0S3-8-12-00"

Put that in the phone load info, reset the phone and it will go ahead and upgrade to SIP!


Once its there though, prepare to be underwhelmed, SIP on your phone doesn't give you any new features and actually changes a few behaviors, First of all the phone responds to key presses even if the CCM is down (you just get an error when you try to make a call or set a call-forward or something like that)

the other reallyyy weird behavior is the call-routing is done when all dialing is complete! So the digit matching is done when you click "dial" and not before, this kind of sucks when your used to digit-by-digit instant matching, because for example if you have a block pattern for 0011(international dialing here in australia) when people dial an int number on an SCCP phone they will get the block straight after they've hit 0011, where as in SIP they could dial there whole number before getting blocked. It just kind of rubbed me the wrong way.

You can also see the 3 digit identifiers used in the SIP messages on the phone screen itself. I found that very strange.

(please note: all this testing was conducted on a 7960 phone and thus the messages and dialing behavior may change from phone to phone.)


Hope you found this interesting! Cheers

Tuesday, January 5, 2010

Really quick CCME 7 updates

Hi Guys, super quick update on CCM 7.1 that im installing for a customer



1. You can now do broadcast hunt groups!!! (There called "parellel" hunt groups)


voice hunt-group 1 parallel

final 700

list 699,651,663,692,636

timeout 60 pilot 4004

Saturday, January 2, 2010

More IPV6 updates

Hi Guys,


Just quickly updating you on some more IPv6 stuff I am discovering.

So one of the important things to keep in mind with IPv6 is how they are planning subnet allocation. Its a common question because we have never seen prefixes as big as /64 in IPv4!

So, in IPv6 the vision that Cisco and I believe the IETF has is that your average site subnet willl have a /64 allocation for all the hosts (massive right?) So we have /64 for the "prefix" and /64 for the hosts.

Now, what will tend to happen is an enterprise will be assigned either a /32 or a /48 from there ISP, I am going to go with /32 now as that is the example cisco give.

So you might have for example

2001:CDB1::/32

This written in non short hand looks like this:

2001:CDB1:0000:0000:0000:0000:0000:0000

So, the first /32 (2001:CDB1) is your top level prefix, the next
0000 is your "site-level prefix" (i.e. geographical site) (making this a /48) and then finally
the next 0000 is your "subnet-level prefix" (making this a /64)

So thats how they want you to allocate your subnets. Now there is a little bit more to it than that, The IETF also want you to assign your site-level prefixes and number them by altering the LEFT MOST BITS first.

The reason for this is quite simple: over time sites will start to require more and more subnets, if you allocate your site-level prefixes from the right-most bit you will limit the room for growth in this site. (For example, if you needed to increase the size of a site-prefix from /48 to 47 or /46 for example, because you had started with the right-most bits you would need to renumber some sites in order to be able to change the prefix!)

Your actual subnets (your /64's) can be allocated starting from the right most bit as normal.

Confused yet? I am still studying away on the rest of IPv6 and have many unanswered questions such as what subnet to use over a point to point link. As I get more information dear reader: you will too.

Speak Soon

Pete