IPv6 switchover – what should CIOs do (should they even care)?

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

It’s not often that something as mundane as a communications protocol hits the news but last week’s exhaustion of Internet Protocol (IP) addresses has been widely covered by the UK and Irish media. Some are likening the “IPocalypse” to the Year 2000 bug. Others say it’s a non-issue. So what do CIOs need to consider in order to avoid being presented with an unexpected bill for urgent network upgrades?

Focus have produced an infographic which explains the need for an IPv6 migration but, to summarise the main points:

  • The existing Internet address scheme is based on 4 billion internet protocol (IPv4) addresses, allocated in blocks to Regional Internet Registries (RIR) and eventually to individual Internet Service Providers (ISP).
  • A new, and largely incompatible version of the Internet Protocol (IPv6) allows for massive growth in the number of connected devices, with 340 undecillion (2^128) addresses.
  • All of the IPv4 addresses have now been allocated to the RIRs and at some point in the coming months, the availability of IPv4 addresses will dry up.
  • Even though there are huge numbers of unused addresses, they have been already been allocated to companies and academic institutions. Some have returned excess addresses voluntarily; others have not.

The important thing to remember is that the non-availability of IPv4 addresses doesn’t mean that the Internet will suddenly stop working. Essentially, new infrastructure will be built on IPv6 and we’re just entering an extended period of transition. Indeed, in Asia (especially Japan and China), IPv6 adoption is much more mature than in Europe and America.

It’s also worth noting that there are a range of technologies that mitigate the requirement for a full migration to IPv6 including Network Address Translation (NAT) and tunnels that allow hybrid networks to be created over the same physical infrastructure. Indeed, modern operating systems enable IPv6 by default so many organisations are already running IPv6 on their networks – but, whilst there are a number of security, performance and scalability improvements in IPv6, there can be negative impacts on security too if implemented badly.

Network providers are actively deploying IPv6 (as are some large organisations) but it’s likely to be another couple of years before many UK and Ireland’s enterprises consider wide-spread deployment. Ironically, the network side is relatively straightforward and the challenge is with the hardware appliances and applications. The implications for a 100% replacement are massive, however a hybrid approach is workable and will be the way IPv6 is deployed in the enterprise for many years to come.

So, should CIOs worry about IPv6? Well, once the last IPv4 addresses are allocated, any newly formed organisation, or those that require additional address space, will only be accessible over the new protocol. Even so, it will be a gradual transition and the key to success is planning, even if implementation is deferred for a while:

“The move to IPv6 will take a long time – ten years plus, with hybrid networks being the reality in the interim. We are already seeing large scale adoption across the globe, particularly across Asia. Telecommunication providers have deployed backbones and this adoption is growing, enterprise customers will follow. Enterprises need to carefully consider migrations: not all devices in the network can support IPv6 today; it is not uncommon for developers to have ‘hard-coded’ IPv4 addresses and fields in applications; and there are also security implications with how hybrid network are deployed, with the potential to bypass security and firewall policies if not deployed correctly.” [John Keegan, Chief Technology Officer, Fujitsu UK and Ireland Network Solutions Division]

As for whether IPv6 is the new Y2K? I guess it is in the sense that it’s something that’s generating a lot of noise and is likely to result in a lot of work for IT departments but, ultimately it’s unlikely to result in a total infrastructure collapse.

[This post originally appeared on the Fujitsu UK and Ireland CTO Blog and was written with assistance from John Keegan.]

Using DHCP reserved client options for certain devices

Posted on By Mark Wilson
This content is 14 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been struggling with poor Internet connectivity for a while now – the speed is fine (any speed tests I conduct indicate a perfectly healthy 3-5Mbps on on “up to 8Mbps” ADSL line) but I frequently suffer from timeout, only to find that a refresh a few moments later brings the page back quickly.

Suspecting a DNS issue (my core infrastructure server only has a Atom processor and is a little light on memory), I decided to bypass my local DNS server for those devices that don’t really need it because all the services they access are on the Internet (e.g. my iPad).

I wasn’t sure how to do this – all of my devices pick up their TCP/IP settings (and more) via DHCP – but then I realised that the Windows Server 2008 R2 DHCP service (and possibly earlier versions too) allows me to configure reserved client options.

I worked out which IP address my iPad was using, then converted the lease to a reservation. Once I had a reservation set for the device, I could configure the reserved client options (i.e. updating the DNS server addresses to only use my ISP servers, OpenDNS, or Google’s DNS servers).

Unfortunately I’m still experiencing the timeouts and it may just be that my elderly Solwise ADSL modem/router needs replacing… oh well, I guess it’s time to go back to the drawing board!

Problems with Hyper-V, ISA Server 2006 and TCP offloading

Posted on By Mark Wilson
This content is 17 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

For the last few days, I’ve been trying to get an ISA Server 2006 installation working and it’s been driving me nuts. I was pretty sure that I had my networking sorted, following Jim Harrison’s article on configuring ISA Server interface settings (although a colleague did need to point out to me that I didn’t have a static route defined on my ADSL router back to the ISA Server’s internal network – doh!) but even once this was checked there was still something up with the configuration.

My server has three NICs – a Broadcom NetXtreme Gigabit Ethernet card, connected to my Netgear ProSafe GS108 switch and two Intel PRO/100+ Management Adapters – one connected to a NetGear DS108 hub and the other disconnected at the moment but reserved for remote management of the server (the first two are both bound to Hyper-V) virtual switches.

The theory is that the Gigabit connection will be used for all my internal IT resources and the Fast Ethernet hub is just connected to the ADSL router. The server will run a few virtual machines (VMs) – the ISA Server (running with Windows Server 2003 R2 and connected to both virtual switches), another VM with Active Directory and DNS (also running Windows Server 2003 R2), my mail server and various test/development machines.

According to Microsoft:

“There are two rules to remember when setting up DNS on ISA Server. These rules apply to any Windows-based DNS configuration:

  • No matter how many network adapters you have, only assign DNS servers to a single adapter (it doesn’t matter which one). There is no need to set up DNS on all network adapters.
  • Always point DNS to either internal servers or external servers, never to both.”

[Configuring DNS Servers for ISA Server 2004]

Following this advice, my internal DNS Server is set to forward any requests that it can’t resolve to my ISP’s servers. The problem was that this DNS server couldn’t access the Internet through the ISA Server. ISA Server could ping hosts on all networks (so the network configuration was sound) and monitoring the traffic across the ISA Server showed the outbound DNS traffic on port 53 but nothing seemed to be coming back from the ISP’s DNS servers.

I checked another colleague’s working ISA Server 2006 configuration and found nothing major that was different (only an alternative DNS configuration – with the external NIC pointing to the internal DNS server where my external NIC has no DNS server specified – and the addition of the Local Host network in the source list for the Unrestricted Internet Access firewall access rule that is included in the Edge Firewall network template).

Then, after seeking advice from more colleagues and spending the entire day (and evening) on the problem, I finally cracked it…

Because the ISA Server was configured to use the internal DNS server for lookups (which, in turn, couldn’t get back through the ISA Server), nslookup domainname.tld didn’t work; however nslookup domainname.tld alternativednsserveripaddress did (e.g. nslookup www.google.com 4.2.2.2). HTTP(S) traffic seemed fine though – if I used IP addresses instead of domain names, I could access websites via the web proxy client.

Meanwhile, on the ISA Server, I could use nslookup for local name resolution but not for anything on the Internet. And pinging servers on the external side of the ISA server gave some very strange results – The first packet would receive a reply but not the subsequent ones.

After hours of Googling, I came across some good advice in a TechNet forum thread – download and run the ISA Server Best Practices Analyzer (BPA) tool. The ISA BPA presented me with a number of minor warnings (for example, that running ISA Server in a virtual environment can’t protect the underlying operating system) but two seemed particularly significant:

“Receive-side scaling (RSS) is enabled by the Windows Server operating system. If a network adapter installed on the local ISA Server computer supports RSS, ISA Server may function incorrectly. […]”

and:

“TCP-Acceleration (TCPA) is enabled by the Windows Server operating system. If a network adapter installed on the local ISA Server computer supports TCPA, ISA Server may function incorrectly. […]”

I made the registry edits to disable RSS and TCPA (Further details are available in Microsoft knowledge base articles 927695 and 936594), restarted the computer and crossed my fingers.

Even after this change, I still couldn’t successfully ping resources on the external side of the ISA Server from the private network, but I was sure I was onto something. I stopped looking for problems with ISA Server and DNS, and instead I focused my efforts on TCP Offload issues with Hyper-V. That’s when I found Stefaan Pouseele’s post about ISA Server and Windows Server 2003 service pack 2. Stefaan recommends not only disabling RSS and TCPA but also turning off TCP offload and the TCP chimney.

A big more googling and I found a TechNet Forum thread about ISA Server 2006 in a virtual environment where (Virtual PC Guy) Ben Armstrong and VistaGuyRay (Raymond Comvalius) had discussed disabling TCP offloading in the VM. As it happens, only yesterday, Ray blogged about how disabling TCP offloading in the virtual machine (not on the host) had resolved his problems with a Broadcom gigabit Ethernet adapter and Hyper-V (further details are available in Microsoft knowledge base article 888750). So, after making this change (but not doing anything with the TCP chimney) and a final reboot of my ISA server, I noticed that Windows wanted to apply some updates. That meant that name resolution was working, which in turn meant that the internal DNS server was successfully forwarding requests to the ISP servers via the ISA Server and my ADSL router. Result.

The final set of registry changes that I made were as follows:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnableTCPA"=dword:00000000
"EnableRSS"=dword:00000000
"DisableTaskOffload"=dword:00000001

I’ve only made the registry changes on the ISA Server at the moment and the VM running AD/DNS seems to be fine, so this might not be an issue for all virtual machines connected to the Hyper-V virtual switch bound to the Broadcom NetXtreme NIC. What does seem reasonably certain though is that Hyper-V, ISA Server 2006 and TCP offloading don’t play nicely together in this scenario.

Basic TCP/IP troubleshooting

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

For the last couple of days, I’ve been mystified as to why I could access a SharePoint site from other Windows servers on the same LAN but not from clients (Mac, Linux or Windows) elsewhere on the network (and on the Internet).

Strangely, the server responded to ping requests, but I couldn’t successfully traceroute ipaddress. Now I’ve realised why… I had the wrong default gateway set in the TCP/IP stack. So simple, yet so crucial. Furthermore, tracert ipaddress on Windows worked (tricking me into thinking it was a Mac OS X/Linux problem) – it turns out that many Unix-derived operating systems use UDP for traceroute whereas the Windows implementation (tracert) uses ICMP. As ping (which uses ICMP) was working, my Windows trace was successful but, because ICMP operates at the network layer in the OSI model and UDP is at the transport layer, the return UDP packets to a Mac OS X or Linux client would have been unable to reach me because of the incorrect gateway on the SharePoint server.

It just shows that, from time to time, it can be useful to go back to basics when troubleshooting TCP/IP issues:

  • Firstly, check that the cable is plugged in. Believe me, it’s amazing how many times that is the cause of the problem!
  • Next, check that the computer has correct IP addressing details. IP addresses starting with 169.254 are link-local or automatic private IP addressing (APIPA) addresses, used when a DHCP server cannot be located. Key settings to check are the IP address itself, subnet mask, default gateway/router address (used to find the next hop) and nameserver (DNS or WINS) addresses (used to locate a server to resolve friendly names to IP addresses).
  • If you think the TCP/IP settings are correct then ping ipaddress from the computer to localhost (127.0.0.1), the default gateway, a known host elsewhere on the network, a known host on the Internet (in that order) – this approach will help to identify whether the issue is local to the computer, the local subnet, further out on the network or on the Internet (incidentally, many web servers will not respond to pings in order to avoid denial of service attacks such as the ping of death – so no reply from an Internet host doesn’t necessarily mean there is a problem). If pings from the computer are successful, try pings to the computer from elsewhere on the network.
  • Finally, tracert ipaddress (Windows) or traceroute ipaddress (Mac OS X/Linux) can be used to check that packets are being routed correctly. Windows users also have a utility called pathping which is a combination of ping and tracert.

Some other commands that can be useful include:

  • ipconfig /release followed by ipconfig /renew (Windows) or ifdown interface then ifup interface (Mac OS X/Linux) can be used to obtain a new IP address from the DHCP server (alternatively, just use ipconfig /renew or ifup interface to renew the existing address).
  • The nslookup tool can be used to check the results returned by the DNS server for a particular host. If DNS is working and Internet access is available then further tests can be carried out at the DNS Stuff website.
  • ipconfig /flushdns can be used for Windows users to flush the DNS cache and force a new lookup for a previously visited host.
  • The netstat command can be used to see all the connections that are currently open (strange entries may indicate a problem with certain types of malware).
  • telnet ipaddress portname can be useful to test a connection to a host.
  • If the command line is too confusing, Windows users can use netsh diag gui as a last resort!

The OSI reference model and how it relates to TCP/IP

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Earlier today, whilst on a client site, waiting for a PC to rebuild (5 times – and I thought my desktop support days were over… maybe that’s why they should be…), I saw a diagram of the open systems interconnection (OSI) reference model pinned up above a desk. I’ve seen many OSI model representations over the years, but this one was probably the clearest example I’ve seen in a while (especially for TCP/IP), so I’ve reproduced it here:

MOM 2005 architecture

The joys of sending e-mail from a telnet session

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Whilst checking out Steve Lamb and Kathryn Tewson/Steve Riley‘s articles in the November/December issue of TechNet magazine, I came across a link to an article by R’ykandar Korra’ti asking how simple is SMTP? I remember having great fun sending SMTP directly by telneting into a server when I first learnt about Exchange Server back in 1996 and you can read how to do it. Then, just because I can, I sent myself a mail using a telnet connection to my ISP’s relay.

Setting up IP forwarding on a Windows network

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

My network at home has two subnets joined by a wireless link (note that the IP addresses have been changed to protect the innocent):

IP forwarding

You might wonder why it doesn’t all sit under my desk (after all we’re not talking about a multinational corporation here) but the simple fact is that most of my kit has been procured from an eclectic mix of sources over the years (so it is hardly what you might call standard) and the server (on which I do a lot of testing) is a noisy beast, as is the 24-port switch that it’s plugged into – hence the reason they are stored away in the basement.

The trouble with this configuration is that the dual-homed PC which acts as a bridge between the wired and wireless segments in the basement is exactly that – dual-homed – i.e. it needs the 802.3 adapter to be on one subnet and the 802.11b adapter to be on another (otherwise this could all have been on one flat subnet). That means that it also needs to be able to route traffic to and from each subnet, otherwise the server is invisible to the rest of the network (and vice versa).

That’s where IP forwarding comes in (aka IP masquerading in Linux-speak).

Disabled by default in Windows 2000, XP and Server 2003, IP forwarding basically allows a dual-homed host to act as a network bridge. Microsoft knowledge base article 323339 details the registry setting to enable this on Windows Server 2003 – there are other articles for Windows 2000 and XP but they are pretty much identical.

There are, however, a couple of important points to note:

  • Only one interface should have a default gateway. In my case, the default gateway for the bridge’s wired connection is blank.
  • I also had to put a static route to 192.168.2.0/24 on my ADSL router using the IP address of the bridge’s wireless connection as a gateway (so that outbound traffic to the Internet from the 192.168.2.x network has a return path).

For comparison purposes, the routing table on my bridge (192.168.1.50/192.168.2.50) looks like this:

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10003 ...00 08 02 xx xx xx ...... Intel(R) PRO/100 VM Network Connection
0x10004 ...00 80 c8 xx xx xx ...... D-Link AirPlus DWL-520+ Wireless PCI Adapter
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.50 25
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.1.0 255.255.255.0 192.168.1.50 192.168.1.50 25
192.168.1.50 255.255.255.255 127.0.0.1 127.0.0.1 25
192.168.1.255 255.255.255.255 192.168.1.50 192.168.1.50 25
192.168.2.0 255.255.255.0 192.168.2.50 192.168.2.50 20
192.168.2.50 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.2.255 255.255.255.255 192.168.2.50 192.168.2.50 20
224.0.0.0 240.0.0.0 192.168.1.50 192.168.1.50 25
224.0.0.0 240.0.0.0 192.168.2.50 192.168.2.50 20
255.255.255.255 255.255.255.255 192.168.1.50 192.168.1.50 1
255.255.255.255 255.255.255.255 192.168.2.50 192.168.2.50 1
Default Gateway: 192.168.1.1
===========================================================================
Persistent Routes:
None

Whilst on the ADSL router it looks like this:

Network Destination Netmask NextHop IF Type Origin
0.0.0.0 0.0.0.0 isprouter ppp-0 Indirect Dynamic
127.0.0.0 255.0.0.0 127.0.0.1 lo-0 Direct Dynamic
192.168.1.0 255.255.255.0 192.168.1.1 eth-0 Direct Dynamic
192.168.1.1 255.255.255.255 127.0.0.1 lo-0 Direct Dynamic
192.168.2.0 255.255.255.0 192.168.1.50 eth-0 Indirect Local
isprouter 255.255.255.255 mypublicipaddress ppp-0 Direct Dynamic
mypublicipaddress 255.255.255.255 127.0.0.1 lo-0 Direct Dynamic
btrouter1 255.255.255.255 btrouter2 ppp-0 Direct Dynamic

For the other LAN-connected devices, the important details are that for LAN 1 the default gateway is 192.168.1.1 and for LAN 2 the default gateway is 192.168.2.50.

Migrating DHCP databases between Windows servers

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One side effect of rebuilding the server that runs pretty much everything on my home network was that I had to migrate the DHCP database (twice – first to a virtual machine operating as a temporary server, and then back to the original hardware after it had been rebuilt).

I knew that it was possible (I did it from NT 4.0 to Windows 2000 for a client few years back) but hadn’t done it recently.

It turned out to be pretty straightforward – all of the details are in Microsoft knowledge base article 325473 but basically on the source (Windows 2000 Server) server, stop the DHCP service and use jetpack.exe to tidy up the database, then use the DHCP database export/import resource kit tool (dhcpexim.exe) to dump the database and finally import it on the target (Windows Server 2003) server using the network shell (netsh.exe). The second migration was even quicker – for a Windows Server 2003 source and target it just involves a couple of netsh commands. Finally, don’t forget to disable redundant DHCP services (or deauthorise the servers in Active Directory) to prevent multiple DHCP servers from servicing clients simultaneously.

Using netsh to set multiple DNS server addresses in Windows

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

During my recent two days of torment caused by a flaky Java application, I had to change the preferred and alternate DNS server entries for one of my network cards. Ordinarily that would be simple, but with an unresponsive Explorer interface refusing to open any network connection dialogs I needed to do it from the command line.

Enter the network shell (netsh) – a fantastic command line utility that has sneaked into recent versions of Windows and seems to have more and more functionality added with each new release.

After entering the netsh shell, interface ip got me to the TCP/IP interface settings; then show dns gave me the details of the current DNS servers; set dns "Local Area Connection" ipaddress allowed me to set the preferred DNS server and add dns "Local Area Connection" ipaddress index=2 set the alternate DNS server (that was the difficult one to work out – I had tried to set dns with a list of IP addresses but that does not work!); finally, exit the network shell and type ipconfig -all to check settings the normal way.

I love the command prompt!

An introduction to IPSec

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been meaning to write something about Internet protocol security (IPSec) ever since I heard Steve Lamb talk about it a few months back but Owen Cutajar blogged about Steve Friedl’s Illustrated Guide to IPSec a few days back which gives a much better description than I ever will! Steve’s site has a whole load of useful technical tips, but as his URL might give away, he comes at things from a UNIX perspective.

For Windows users who are interested in implementing IPSec, I recommend that you read both Steve Lamb’s blog and Steve Friedl’s Illustrated Guide to IPSec, but what follows is a brief description of some high-level concepts which might help to put it all into context.

Although it sounds complex, symmetric key cryptography is a very basic method of encrypting messages (e.g. DES or AES/Rijndael) using a shared secret. The plain text input is encrypted to produce cipher text which is transmitted to the intended recipient, who can then decrypt it to produce plain text output. An example of such a mechanism is the Caesar shift, whereby characters are shifted by a known number of places (the shared secret), so that for example if the shared secret is 3, A becomes D, B becomes E, and so on. Symmetric key cryptography is simple, and fast, but relies on some form of mechanism for exchanging keys (shared secrets).

Symmetric key cryptography

Public key cryptography is an asymmetric encryption mechanism, whereby knowledge of the encryption key doesn’t provide the methods to decrypt the message. The recipient of the message generates a pair of keys (using a certificate authority) and publishes the public key in a directory so that anyone can send them encrypted messages that only they can read. This pair of keys is actually a single key split mathematically using a one-way algorithm (i.e. one which current mathematics does not allow to be reversed). When sending a message, it is encrypted with the recipient’s public key and they can decrypt it (using their private key). Unfortunately even this method has its weaknesses as it is slow, subject to what is known as a “known ciphertext” attack and requires the public key to be trusted (i.e. to be from a known certificate authority).

Asymmetric key cryptography

The real-world answer is often a hybrid encryption process whereby a symmetric session key is encrypted using the recipient’s public key and then, once this key has been decrypted by the recipient (using their private key), they can read messages encrypted using the session key. The session key is transmitted with the encrypted message as a digital envelope. Once the message exchange is complete (whether that is literally the transfer of a message, or a communication session) the session key is disregarded (i.e. its life is finite – dictated by the length of the session).

IPSec is used to authenticate and/or encrypt TCP/IP communications, securing either specific ports or all IP traffic and is obligatory for IPv6.

In an Active Directory environment, IPSec is generally configured via group policy and both the client and the server must be configured. No reply is issued to rejected packets – they are simply dropped. Installing a certificate authority (CA) is a simple process (although because a lot of the configuration is wizard-based, it can be difficult to appreciate exactly what has been done). Windows Server 2003 Certificate Services allows a hierarchy of CAs to be implemented (generally with the root CA kept offline once the hierarchy is established) as well as adhering to public key standards from RSA, Entrust and Verisign (licensed by Microsoft to avoid any per-certificate cost issues). Once a certificate has been issued the client no longer needs to communicate with the CA. Of course, internal CAs are only suitable for internal use of IPSec (a trusted CA needs to be used for securing traffic across the Internet).

One of the advantages of IPSec is that, because it works at the network layer, it can be used to provide secure data transfer without affecting applications; however the downside is that architects (or administrators) should carefully consider the impact that encrypting all traffic would cause as some security software (e.g. intrusion detection systems) will no longer function.