Mailing List Archive

Browsing Dual-stacked sites shouldn't be noticeable. Due to happy eyeballs. It'll use whatever turns up faster. (Assuming you're using a browser that does Happy eyeballs)

Nick Olsen
Network Operations (855) FLSPEED x106



----------------------------------------
From: "Steve Housego" <Steve.Housego@itps.co.uk>
Sent: Tuesday, December 09, 2014 11:28 AM
To: "ipv6-ops@lists.cluenet.de" <ipv6-ops@lists.cluenet.de>
Subject: Enterprise Dual Stack without IPv6 Transit
Hi,

I 'm looking at a scenario for a client and looking for some help to ratify my thoughts around IPv6 and the client behaviour. I don't have access to anyone with any real-world IPv6 experience, at least in the enterprise.

First a bit of background, a client of mine is looking to deploy Microsoft DirectAccess and as part of that we are planning to Dual Stack IPv6 the path between the direct access clients (who are IPv6 only) instead of being reliant on NAT64/DNS64 which is provided by the DirectAccess Server. (this will be with GUA addressing they already have a /32 allocation from RIPE) They do not however (yet) have an IPv6 internet connection. Whilst I'm confident this will work well for the server/client communication, all the servers that are DualStacked (including the AD/DNS servers) will they have any sort of performance impact when attempting to reach public internet dual-stacked websites? i.e. as it has a global unicast address will it prefer IPv6 and try to reach it with IPv6 first which will obviously fail and then use IPv4?

My second question which is a bit more Microsoft centric - but worth asking - Is there likely to be some issue's with the DirectAccess clients trying to access the IPv4 internet (which is all tunneled through the DA server).. as the DNS server will likely return a 'true' IPv6 address in the DNS response to the client, this bit further boggles me as it needs to be DNS64/NAT64 for this traffic. Im going to lab this up, but if anyone has any comments/advice on enabling IPv6 internally first without having public IPv6 reachability it'd be most grateful.

SteveH



"Helping Your ICT Budget Deliver to its Maximum Potential"

Steve Housego
Principal Consultant

IT Professional Services
Axwell House
Waterside Drive
Metrocentre East Business Park
Gateshead
Tyne & Wear NE11 9HU

T. 0191 442 8300
F. 0191 442 8301

Steve.Housego@itps.co.uk

Check out our new website at www.it-ps.com and see how we can help your IT budget deliver more for less.





Company No. 3930001 registered in England
VAT No. 734 1935 33

On 2014-12-09 17:27, Steve Housego wrote:
> First a bit of background, a client of mine is looking to deploy
> Microsoft DirectAccess and as part of that we are planning to
> Dual Stack IPv6 the path between the direct access clients (who are
> IPv6 only) [..]

Do you mean that the underlying network is IPv6-only while in the
DirectAccess tunnel (read: IPSEC tunnel) you run both IPv4 + IPv6?

What are you expecting clients to contact, only IPv4 or also IPv6
destinations?

Also, watch out for leaks from such tunnels (See RFC7359)

[..]
> They do not however (yet) have an IPv6 internet connection.

Why not? :)

> i.e. as it has a global unicast address will it prefer IPv6 and try to reach it
> with IPv6 first which will obviously fail and then use IPv4?

As long as you do not filter ICMPv6 and your routers return !N you
should be fine. All dual-stacked applications should try other addresses
and fall back. Happy Eyeballs typically makes this 'better'.

> My second question which is a bit more Microsoft centric – but worth
> asking – Is there likely to be some issue’s with the DirectAccess
> clients trying to access the IPv4 internet (which is all tunneled
> through the DA server).. as the DNS server will likely return a 'true'
> IPv6 address in the DNS response to the client, this bit further boggles
> me as it needs to be DNS64/NAT64 for this traffic.

The issues are the same for any other tunneled setup where you NAT outbound.


What is actually the use-case for DirectAccess? Do you want to force
corporate devices to always use the corporate network and never the
locally available connectivity? Or do you just use it to access the
resources in the corporate network?

Oh, and watch out for split-DNS, don't fall for that one ;)

Greets,
Jeroen

-----Original Message-----
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
Date: Tuesday, 9 December 2014 16:35
To: Steve Housego <steve.housego@itps.co.uk>, "ipv6-ops@lists.cluenet.de"
<ipv6-ops@lists.cluenet.de>
Subject: Re: Enterprise Dual Stack without IPv6 Transit

>On 2014-12-09 17:27, Steve Housego wrote:
>> First a bit of background, a client of mine is looking to deploy
>> Microsoft DirectAccess and as part of that we are planning to
>> Dual Stack IPv6 the path between the direct access clients (who are
>> IPv6 only) [..]
>
>Do you mean that the underlying network is IPv6-only while in the
>DirectAccess tunnel (read: IPSEC tunnel) you run both IPv4 + IPv6?
>
>What are you expecting clients to contact, only IPv4 or also IPv6
>destinations?
>
>Also, watch out for leaks from such tunnels (See RFC7359)

DirectAccess is essentially an IPv6 tunnel between two IPv4 endpoints, the
DA server and a remote user who could be anywhere home/train etc. These
ŒVPN users¹ are only given an IPv6 address.

The DirectAccess server then NAT64/DNS64¹s all the clients traffic into
the IPv4 Œserver LAN¹. Which is effectively a ŒPAT¹ so all the VPN users
appear to come from the DA servers LAN IPv4 address.

Which.. Is horrible, so we want to enable IPv6 for the path from the
Direct Access clients to the Œserver LAN¹ so nothing is NAT¹d.

>
>[..]
>> They do not however (yet) have an IPv6 internet connection.
>
>Why not? :)

ISP doesn¹t support it yet (even for business customers), we have already
asked to be part of their trials.

>
>> i.e. as it has a global unicast address will it prefer IPv6 and try to
>>reach it
>> with IPv6 first which will obviously fail and then use IPv4?
>
>As long as you do not filter ICMPv6 and your routers return !N you
>should be fine. All dual-stacked applications should try other addresses
>and fall back. Happy Eyeballs typically makes this 'better'.

This is interesting, I hadn¹t came across ŒHappy Eyeballs¹ essentially
they attempt both connections simultaneously - this is great.

>
>> My second question which is a bit more Microsoft centric ­ but worth
>> asking ­ Is there likely to be some issue¹s with the DirectAccess
>> clients trying to access the IPv4 internet (which is all tunneled
>> through the DA server).. as the DNS server will likely return a 'true'
>> IPv6 address in the DNS response to the client, this bit further boggles
>> me as it needs to be DNS64/NAT64 for this traffic.
>
>The issues are the same for any other tunneled setup where you NAT
>outbound.
>
>
>What is actually the use-case for DirectAccess? Do you want to force
>corporate devices to always use the corporate network and never the
>locally available connectivity? Or do you just use it to access the
>resources in the corporate network?

Yeah $company really likes the idea of whenever a laptop is switched on
and on the internet that it¹s part of the corporate network, they also
want to control web browsing through the corporate network proxy¹s which
to be honest kind of answers my own question, the proxy will hopefully be
IPv6 enabled available in the Œserver LAN¹ on IPv6 addressing anyway,
worst case I suppose they could live with NAT64 for access to the proxy.

>
>Oh, and watch out for split-DNS, don't fall for that one ;)
>
>Greets,
> Jeroen

Many thanks!

SteveH

[http://www.it-ps.com/wp-content/uploads/2013/12/itps-logo.png]

"Helping Your ICT Budget Deliver to its Maximum Potential"

Steve Housego
Principal Consultant

IT Professional Services
Axwell House
Waterside Drive
Metrocentre East Business Park
Gateshead
Tyne & Wear NE11 9HU

T. 0191 442 8300
F. 0191 442 8301

Steve.Housego@itps.co.uk<mailto:Steve.Housego@itps.co.uk>


Check out our new website at www.it-ps.com <http://www.it-ps.com/> and see how we can help your IT budget deliver more for less.

[http://itpswebhost01.it-ps.com/customer_images/itps/twitter]<http://twitter.com/#!/itpsltd> [http://itpswebhost01.it-ps.com/customer_images/itps/facebook] <http://www.facebook.com/pages/ITPS/180607505381380> [http://itpswebhost01.it-ps.com/customer_images/itps/linkedin] <http://uk.linkedin.com/in/itpsltd>

Company No. 3930001<tel:3930001> registered in England
VAT No. 734 1935 33<tel:734%201935%2033>

On 2014-12-09 17:59, Steve Housego wrote:
[..]
>> On 2014-12-09 17:27, Steve Housego wrote:
>>> First a bit of background, a client of mine is looking to deploy
>>> Microsoft DirectAccess and as part of that we are planning to
>>> Dual Stack IPv6 the path between the direct access clients (who are
>>> IPv6 only) [..]
>>
>> Do you mean that the underlying network is IPv6-only while in the
>> DirectAccess tunnel (read: IPSEC tunnel) you run both IPv4 + IPv6?
>>
>> What are you expecting clients to contact, only IPv4 or also IPv6
>> destinations?
>>
>> Also, watch out for leaks from such tunnels (See RFC7359)
>
> DirectAccess is essentially an IPv6 tunnel between two IPv4 endpoints, the
> DA server and a remote user who could be anywhere home/train etc. These
> ŒVPN users¹ are only given an IPv6 address.

Almost. It uses either native-IPv6 or 6to4/Teredo/IP-HTTPS to get an
IPv6 address, then it just does IPSEC-AH+ESP using that IPv6 address.

Clients will thus not have an address out of your own PI range.

(unless something really heavily changed in Direct Access that I am not
aware about; you could IPv6 NAT them on the DA, but that breaks
end-to-end and then why would one bother with this; hmm I suddenly
wonder how the return traffic gets forced through the DA to IPSEC-sign
that traffic again, maybe route-jacking?)

> The DirectAccess server then NAT64/DNS64¹s all the clients traffic into
> the IPv4 Œserver LAN¹. Which is effectively a ŒPAT¹ so all the VPN users
> appear to come from the DA servers LAN IPv4 address.
>
> Which.. Is horrible, so we want to enable IPv6 for the path from the
> Direct Access clients to the Œserver LAN¹ so nothing is NAT¹d.

That is only horrible because you are trying to solve your problem with
the wrong tool (the NAT64/DNS64 part at minimum).

You clearly want each client to have their own IPv4 and IPv6 addresses.

This (NAT64/DNS64 portion) was made to avoid this whole IPv4 address
assignment.

You either have to configure it so that each IPv6 address gets a
separate outbound IPv4 address (no idea if that is possible) or use a
completely different tunneling method (OpenVPN comes to mind) that puts
both an IPv4 and IPv6 address on the box, which is likely better in the
short term as then you don't need any hacks any more with NAT64/DNS64.


>> [..]
>>> They do not however (yet) have an IPv6 internet connection.
>>
>> Why not? :)
>
> ISP doesn¹t support it yet (even for business customers), we have already
> asked to be part of their trials.

Only answer: vote with your money. It is 2014.

Any ISP that is willing to route IP prefixes should be able to do IPv6.
If they cannot do that today then take your business elsewhere.


>>> i.e. as it has a global unicast address will it prefer IPv6 and try to
>>> reach it
>>> with IPv6 first which will obviously fail and then use IPv4?
>>
>> As long as you do not filter ICMPv6 and your routers return !N you
>> should be fine. All dual-stacked applications should try other addresses
>> and fall back. Happy Eyeballs typically makes this 'better'.
>
> This is interesting, I hadn¹t came across ŒHappy Eyeballs¹ essentially
> they attempt both connections simultaneously - this is great.

It is 'great' till you have to debug why something is 'slow' and you
forget about this and are looking at IPv4 or IPv6 and sometimes it does
and sometimes it does not work.

Determinism is a good thing. Be happy that you are in a Windows
environment at that point as OSX is far less deterministic (and there is
no switch to turn that behavior off).

>>> My second question which is a bit more Microsoft centric ­ but worth
>>> asking ­ Is there likely to be some issue¹s with the DirectAccess
>>> clients trying to access the IPv4 internet (which is all tunneled
>>> through the DA server).. as the DNS server will likely return a 'true'
>>> IPv6 address in the DNS response to the client, this bit further boggles
>>> me as it needs to be DNS64/NAT64 for this traffic.
>>
>> The issues are the same for any other tunneled setup where you NAT
>> outbound.
>>
>>
>> What is actually the use-case for DirectAccess? Do you want to force
>> corporate devices to always use the corporate network and never the
>> locally available connectivity? Or do you just use it to access the
>> resources in the corporate network?
>
> Yeah $company really likes the idea of whenever a laptop is switched on
> and on the internet that it¹s part of the corporate network

Direct Access does not make that like that.

The address that the client has will be a IPv6 address that is local.
eg, if the user has no native IPv6 and uses Teredo they will come from a
2001::/32 address.

The only reason why you can 'trust' that address is because it is IPSEC
signed. The DA server just strips that authentication after validating it.

> they also
> want to control web browsing through the corporate network proxy¹s which
> to be honest kind of answers my own question, the proxy will hopefully be
> IPv6 enabled available in the Œserver LAN¹ on IPv6 addressing anyway,
> worst case I suppose they could live with NAT64 for access to the proxy.

Sounds like you want good old SOCKS.

I would personally never bother with anything NAT, be that NAT64 or IPv4
NAT, in such an environment.

Greets,
Jeroen

On Tue, Dec 09, 2014 at 04:59:05PM +0000, Steve Housego wrote:
> This is interesting, I hadn¹t came across ?Happy Eyeballs¹ essentially
> they attempt both connections simultaneously - this is great.

But proper Happy Eyeballs implementations give IPv6 a positive bias so
to help get traffic moved to IPv6 instead of IPv4. Some (one single?)
selfish implementation uses "whatever is connecting faster" with
associated bad effects for transition and troubleshooting. That's got
called "Hampering Eyeballs".

Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On 2014-12-09 20:34, Daniel Roesen wrote:
> On Tue, Dec 09, 2014 at 04:59:05PM +0000, Steve Housego wrote:
>> This is interesting, I hadn¹t came across ?Happy Eyeballs¹ essentially
>> they attempt both connections simultaneously - this is great.
>
> But proper Happy Eyeballs implementations give IPv6 a positive bias so
> to help get traffic moved to IPv6 instead of IPv4. Some (one single?)
> selfish implementation uses "whatever is connecting faster" with
> associated bad effects for transition and troubleshooting. That's got
> called "Hampering Eyeballs".

The 'whatever is faster' is actually pretty deterministic.

OSX does it with a magic combo that apparently consists out of latency
and throughput... and unless somebody figured it out the exact
parameters are unknown.

Greets,
Jeroen

Hi,

On Wed, Dec 10, 2014 at 12:59:40AM +0100, Jeroen Massar wrote:
> The 'whatever is faster' is actually pretty deterministic.
>
> OSX does it with a magic combo that apparently consists out of latency
> and throughput... and unless somebody figured it out the exact
> parameters are unknown.

Yes, and if you have a well-designed network that has IPv4 follow the
same packet path as IPv6, OSX will happily flip-flop back and forth
between IPv4 and IPv6 between http request to the same server.

Not overly deterministic, and not helpful when looking for "sometimes
it does not work" errors (like, an Apache ACL mistakenly permitting only
one of the protocols).

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On 12/10/2014 16:14, Gert Doering wrote:
> Hi,
>
> On Wed, Dec 10, 2014 at 12:59:40AM +0100, Jeroen Massar wrote:
>> The 'whatever is faster' is actually pretty deterministic.
>>
>> OSX does it with a magic combo that apparently consists out of latency
>> and throughput... and unless somebody figured it out the exact
>> parameters are unknown.
>
> Yes, and if you have a well-designed network that has IPv4 follow the
> same packet path as IPv6, OSX will happily flip-flop back and forth
> between IPv4 and IPv6 between http request to the same server.
>
> Not overly deterministic, and not helpful when looking for "sometimes
> it does not work" errors (like, an Apache ACL mistakenly permitting only
> one of the protocols).
>
> Gert Doering
> -- NetMaster
>

Also problematic with dual-stack websites that rely on IP in their "user
is authenticated" cookie. Example - Linode manager.

--
staticsafe
https://staticsafe.ca

Hi,

On Wed, Dec 10, 2014 at 04:37:58PM -0500, staticsafe wrote:
> Also problematic with dual-stack websites that rely on IP in their "user
> is authenticated" cookie. Example - Linode manager.

Well, such websites need to go the way of the dodo anyway.

Like, we've never heard of proxy farms before...

Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

Sorry for the delay in responding to your last email, I’ve been busy
building this in the lab.

Im pretty much done now I think, I have the answers I need :) I very much
appreciate your experience, thanks for taking the time to reply. Just to
close this off I’ve added some comments inline below.

-----Original Message-----
From: Jeroen Massar <jeroen@massar.ch>
Organization: Massar
Date: Tuesday, 9 December 2014 19:19
To: Steve Housego <steve.housego@itps.co.uk>, "ipv6-ops@lists.cluenet.de"
<ipv6-ops@lists.cluenet.de>
Subject: Re: Enterprise Dual Stack without IPv6 Transit
Resent-From: Steve Housego <Steve.Housego@it-ps.com>

>On 2014-12-09 17:59, Steve Housego wrote:
>[..]
>>> On 2014-12-09 17:27, Steve Housego wrote:
>>>> First a bit of background, a client of mine is looking to deploy
>>>> Microsoft DirectAccess and as part of that we are planning to
>>>> Dual Stack IPv6 the path between the direct access clients (who are
>>>> IPv6 only) [..]
>>>
>>> Do you mean that the underlying network is IPv6-only while in the
>>> DirectAccess tunnel (read: IPSEC tunnel) you run both IPv4 + IPv6?
>>>
>>> What are you expecting clients to contact, only IPv4 or also IPv6
>>> destinations?
>>>
>>> Also, watch out for leaks from such tunnels (See RFC7359)
>>
>> DirectAccess is essentially an IPv6 tunnel between two IPv4 endpoints,
>>the
>> DA server and a remote user who could be anywhere home/train etc. These
>> ŒVPN users¹ are only given an IPv6 address.
>
>Almost. It uses either native-IPv6 or 6to4/Teredo/IP-HTTPS to get an
>IPv6 address, then it just does IPSEC-AH+ESP using that IPv6 address.

We are using IP-HTTPS exclusively, 6to4 and Teredo have different
requirements which we are unable to provide to the DA server, we need to
‘NAT’ which basically just leaves us with IP-HTTPS.

>
>Clients will thus not have an address out of your own PI range.
>
>(unless something really heavily changed in Direct Access that I am not
>aware about; you could IPv6 NAT them on the DA, but that breaks
>end-to-end and then why would one bother with this; hmm I suddenly
>wonder how the return traffic gets forced through the DA to IPSEC-sign
>that traffic again, maybe route-jacking?)

Ive just finished labing this, and the DirectAccess Clients when out of
the office can infact be given global unicast addressing (a /64 is
assigned for all DA clients), and they use this address to communicate to
the internal IPv6 network. The DA Client can ping the Active Directory DC
using its global unicast address., and when doing a packet trace the
source is the assigned IPv6 address of the DA Client.

>
>> The DirectAccess server then NAT64/DNS64¹s all the clients traffic into
>> the IPv4 Œserver LAN¹. Which is effectively a ŒPAT¹ so all the VPN users
>> appear to come from the DA servers LAN IPv4 address.
>>
>> Which.. Is horrible, so we want to enable IPv6 for the path from the
>> Direct Access clients to the Œserver LAN¹ so nothing is NAT¹d.
>
>That is only horrible because you are trying to solve your problem with
>the wrong tool (the NAT64/DNS64 part at minimum).
>
>You clearly want each client to have their own IPv4 and IPv6 addresses.

No, definitely not, I’m aware the DirectAccess clients are IPv6 only. Yes,
they have an IPv4 address from whatever connection there using out there
in the world, but we want to tunnel all their traffic through the direct
access server.

>
>This (NAT64/DNS64 portion) was made to avoid this whole IPv4 address
>assignment.
>
>You either have to configure it so that each IPv6 address gets a
>separate outbound IPv4 address (no idea if that is possible) or use a
>completely different tunneling method (OpenVPN comes to mind) that puts
>both an IPv4 and IPv6 address on the box, which is likely better in the
>short term as then you don't need any hacks any more with NAT64/DNS64.

I think I haven’t explained myself very well here. Theres two aspects to
my original email.

1. DirectAccess clients - how to they get access to the IPv4 internet
- I’ve now solved this by enabling IPv6 on the internal interface of our
web proxy server (its external interface is IPv4 only)

2. Within the server LAN, because the servers are dual stacked, how would
they behave when they have both an IPv4 and an IPv6 address, when there is
no IPv6 ‘Internet Access’.
- Happy eyeballs takes care of this for web browsing (useful for Citrix
servers etc), which to be honest was the biggest worry as I saw the
problem of accessing dual-stacked websites. Individual application testing
will have to ensue to see the impact it has for other things.

>
>
>>> [..]
>>>> They do not however (yet) have an IPv6 internet connection.
>>>
>>> Why not? :)
>>
>> ISP doesn¹t support it yet (even for business customers), we have
>>already
>> asked to be part of their trials.
>
>Only answer: vote with your money. It is 2014.
>
>Any ISP that is willing to route IP prefixes should be able to do IPv6.
>If they cannot do that today then take your business elsewhere.

If only it were that easy in business :) 5year contract :(

>
>
>>>> i.e. as it has a global unicast address will it prefer IPv6 and try to
>>>> reach it
>>>> with IPv6 first which will obviously fail and then use IPv4?
>>>
>>> As long as you do not filter ICMPv6 and your routers return !N you
>>> should be fine. All dual-stacked applications should try other
>>>addresses
>>> and fall back. Happy Eyeballs typically makes this 'better'.
>>
>> This is interesting, I hadn¹t came across ŒHappy Eyeballs¹ essentially
>> they attempt both connections simultaneously - this is great.
>
>It is 'great' till you have to debug why something is 'slow' and you
>forget about this and are looking at IPv4 or IPv6 and sometimes it does
>and sometimes it does not work.
>
>Determinism is a good thing. Be happy that you are in a Windows
>environment at that point as OSX is far less deterministic (and there is
>no switch to turn that behavior off).
>
>>>> My second question which is a bit more Microsoft centric ­ but worth
>>>> asking ­ Is there likely to be some issue¹s with the DirectAccess
>>>> clients trying to access the IPv4 internet (which is all tunneled
>>>> through the DA server).. as the DNS server will likely return a 'true'
>>>> IPv6 address in the DNS response to the client, this bit further
>>>>boggles
>>>> me as it needs to be DNS64/NAT64 for this traffic.
>>>
>>> The issues are the same for any other tunneled setup where you NAT
>>> outbound.
>>>
>>>
>>> What is actually the use-case for DirectAccess? Do you want to force
>>> corporate devices to always use the corporate network and never the
>>> locally available connectivity? Or do you just use it to access the
>>> resources in the corporate network?
>>
>> Yeah $company really likes the idea of whenever a laptop is switched on
>> and on the internet that it¹s part of the corporate network
>
>Direct Access does not make that like that.
>
>The address that the client has will be a IPv6 address that is local.
>eg, if the user has no native IPv6 and uses Teredo they will come from a
>2001::/32 address.

As above, using IP-HTTPS (never tried teredo) I can give the client a GUA
address within the PI /32.

>
>The only reason why you can 'trust' that address is because it is IPSEC
>signed. The DA server just strips that authentication after validating it.
>
>> they also
>> want to control web browsing through the corporate network proxy¹s which
>> to be honest kind of answers my own question, the proxy will hopefully
>>be
>> IPv6 enabled available in the Œserver LAN¹ on IPv6 addressing anyway,
>> worst case I suppose they could live with NAT64 for access to the proxy.
>
>Sounds like you want good old SOCKS.
>
>I would personally never bother with anything NAT, be that NAT64 or IPv4
>NAT, in such an environment.

Agree’d! The proxy is my best option here I think for my DA users internet
access, and it tests well so I’m going with it!

Many thanks again, you’ve been very helpful, I hope I can add some value
to this list in future :)

SteveH


[http://www.it-ps.com/wp-content/uploads/2013/12/itps-logo.png]

"Helping Your ICT Budget Deliver to its Maximum Potential"

Steve Housego
Principal Consultant

IT Professional Services
Axwell House
Waterside Drive
Metrocentre East Business Park
Gateshead
Tyne & Wear NE11 9HU

T. 0191 442 8300
F. 0191 442 8301

Steve.Housego@itps.co.uk<mailto:Steve.Housego@itps.co.uk>


Check out our new website at www.it-ps.com <http://www.it-ps.com/> and see how we can help your IT budget deliver more for less.

[http://itpswebhost01.it-ps.com/customer_images/itps/twitter]<http://twitter.com/#!/itpsltd> [http://itpswebhost01.it-ps.com/customer_images/itps/facebook] <http://www.facebook.com/pages/ITPS/180607505381380> [http://itpswebhost01.it-ps.com/customer_images/itps/linkedin] <http://uk.linkedin.com/in/itpsltd>

Company No. 3930001<tel:3930001> registered in England
VAT No. 734 1935 33<tel:734%201935%2033>