Re: Data Centers in England
On Wed, October 7, 2009 22:33, Philip Lavine wrote: Anyone know a good DC on England that caters to financial industry clients? Cable and Wireless (who I work for) and COLT (who I used to work for). The only other place worth considering is Equinix but from a proximity viewpoint they are just too far away from the square mile. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. n...@domino.org
RE: Data Centers in England
Is there still the Global Crossing place on the junction of New Oxford Street and Tottenham Court Road? -- Leigh Porter -Original Message- From: Neil J. McRae [mailto:n...@domino.org] Sent: Sat 10/17/2009 11:58 AM To: Philip Lavine Cc: nanog Subject: Re: Data Centers in England On Wed, October 7, 2009 22:33, Philip Lavine wrote: Anyone know a good DC on England that caters to financial industry clients? Cable and Wireless (who I work for) and COLT (who I used to work for). The only other place worth considering is Equinix but from a proximity viewpoint they are just too far away from the square mile. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. n...@domino.org
RE: Data Centers in England
And frink-a-basement in Fulham is quite good. They have water cooling when the sewer floods and upto 22Mb/s when there is no water in the junction box. --- original message --- From: Trefor Davies trefor.dav...@timico.co.uk Subject: RE: Data Centers in England Date: 17th October 2009 Time: 12:38:33 pm There's IOMART in Old Street -Original Message- From: Leigh Porter [mailto:leigh.por...@ukbroadband.com] Sent: 17 October 2009 12:31 To: n...@domino.org; Philip Lavine Cc: nanog Subject: RE: Data Centers in England Is there still the Global Crossing place on the junction of New Oxford Street and Tottenham Court Road? -- Leigh Porter -Original Message- From: Neil J. McRae [mailto:n...@domino.org] Sent: Sat 10/17/2009 11:58 AM To: Philip Lavine Cc: nanog Subject: Re: Data Centers in England On Wed, October 7, 2009 22:33, Philip Lavine wrote: Anyone know a good DC on England that caters to financial industry clients? Cable and Wireless (who I work for) and COLT (who I used to work for). The only other place worth considering is Equinix but from a proximity viewpoint they are just too far away from the square mile. Regards, Neil. -- Neil J. McRae -- Alive and Kicking. n...@domino.org
IPv6 Deployment for the LAN
Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Ultimately, the best solution that I've been able to come up with is to preserve the IPv6 allocation schema and reserve a 64-bit prefix for each network, but for the initial deployment use an 80-bit one in its place with the extra 16 bits given a value of 1. The advantages of this: Guarantee that SLAAC will not be initiated for the prefix; Allow for a migration path to 64-bit prefixes in the future; and, Make it easy to identify a network that us making use of an 80-bit prefix by setting the extra bits to a value of 1. This allows us to be fairly confident that extending IPv6 to edge networks will not impact production services, and focus on DHCPv6 for host configuration and address assignment. We have no problem using a 64-bit prefix and letting SLAAC take care of addressing for certain networks where we actually manage the hosts, so that has been included as an exception. All other networks, however, will make use of DHCPv6 or manual configuration to receive native IPv6. So far, this has proven to work well with testing of various hosts and applications. Has anyone run into issues with applications in not using a 64-bit prefix? Of course, the other challenge here is proper DHCPv6 client implementations for host operating systems. Linux, Windows Server 2003 and later, Windows Vista, and Windows 7 all support DHCPv6. Windows XP has a poor implementation of IPv6 but has the option of using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a challenge; it currently has no option for DHCPv6, though newer releases provide for manual configuration of IPv6 addressing. Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. I think the hope is that more systems, like Windows 7, will begin including mature DHCPv6 clients which are enables when the M flag for a router advertisement is set and perhaps make it the default behavior. Is this likely to happen or am I being too optimistic? Anyway, just thought I'd bounce it to NANOG and get some feedback. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy r...@maine.edu wrote: As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Ray, Common wisdom says that? Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. I thought someone had to respond to router solicitations for stateless autoconfig of global scope addresses to happen. On Linux you just don't run the radvd. On Cisco I think it's something like ipv6 nd suppress-ra in the interface config. Does that fail to prevent stateless autoconfig? Or is there a problem with the operation of DHCPv6 if router advertisements aren't happening from the router? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: IPv6 Deployment for the LAN
I thought someone had to respond to router solicitations for stateless autoconfig of global scope addresses to happen. On Linux you just don't run the radvd. On Cisco I think it's something like ipv6 nd suppress-ra in the interface config. Does that fail to prevent stateless autoconfig? Or is there a problem with the operation of DHCPv6 if router advertisements aren't happening from the router? The ipv6 nd suppress-ra config will only suppress unsolicited RA, it will still respond to RA solicitations. Load it up in Wireshark and you'll see. A lot of host implementations of IPv6 seem to enable SLAAC as soon as they see any 64-bit prefix regardless of what flags are set. Making assumptions about IPv6 has proven to be unwise in my experience. So far, the only thing that I've seen that is close to working is to configure the router to not advertise the 64-bit prefix using ipv6 nd prefix prefix no-advertise, but at that point it seems easier to just go with a 80-bit prefix and remove any doubt. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On 18/10/2009, at 2:28 PM, William Herrin wrote: On Sat, Oct 17, 2009 at 8:55 PM, Ray Soucy r...@maine.edu wrote: As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Ray, Common wisdom says that? Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. I thought someone had to respond to router solicitations for stateless autoconfig of global scope addresses to happen. On Linux you just don't run the radvd. On Cisco I think it's something like ipv6 nd suppress-ra in the interface config. Does that fail to prevent stateless autoconfig? Or is there a problem with the operation of DHCPv6 if router advertisements aren't happening from the router? RA is generally required whether you use stateless or stateful autoconfiguration. You have to tell the hosts to send a DHCPv6 DISCOVER message by turning on the managed flag in the RA. RA does not mean that SLAAC happens. Ray, do you have examples of hosts or stacks that ignore AdvAutonomousFlag? -- Nathan Ward
UPDATE: NANOG 47 PGP signing party.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a quick note, The NANOG pgp key signing party will be making an appearance at NANOG 47. The keysigning sessions are going to be held during the monday and tuesday morning break (11:00 - 11:30) in the Desoto Foyer. It is likely that we'll invite the various CA cert notaries to join in the fun. If you plan to participate in the pgp keysigning, please add your key to the keyring at: http://biglumber.com/x/web?ev=97301 Then come to one or both sessions with some form of government issued photo ID. If you have any further questions, feel free to contact me via email or corner one of the people with the pgp signing dots since they mostly know the score. While printouts will probably be available at the sessions, feel free to add your key to the keyring right up to the time of the last keysigning event. Thanks Joel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrajeYACgkQ8AA1q7Z/VrJk6ACeKmcNBgr2kWnkJOiKCIyayudJ E6UAnj2k9jfF8Yx4ZzlgO8ugcth/bcC8 =0DEQ -END PGP SIGNATURE-
Re: IPv6 Deployment for the LAN
On Sat, 2009-10-17 at 20:55 -0400, Ray Soucy wrote: making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Some hosts - very dumb ones or very old ones, probably embedded stacks - may do SLAAC even with a prefix other than 64 bits! Once a stack is broken,, anything is possible, so I'm not sure you win much here. Zig to avoid one dud, you'll have to zag to avoid thenext, and before you know it your life is nothing but dodging. Take the high ground instead. Better to find and cure/replace/isolate broken hosts than break your entire network just to accommodate them. If you start doing the wrong thing to accommodate broken hosts, you will never find peace. Zig to avoid one dud; you'll have to zag to avoid the next and before you know it your life is nothing but dodging. Take the high ground instead. Do the advertisements right, advise sysadmins that hosts should not do SLAAC, and (if you are really concerned about broken hosts) collect MAC address information from your switches and do an automated test of reachability on all SLAAC addresses. You can generate the addresses yourself easily enough from the prefix and the MAC. None should be reachable, and any that are - well, you now know where they are and can take appropriate action. And then block all SLAAC addresses at your routers or firewalls, that'll larn 'em :-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
On Sat, 17 Oct 2009, Ray Soucy wrote: Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. IETF has historically dropped the ball on delivering IPv4/v6 services securely, and all the development for IPv4 done outside the IETF hasn't been integrated into IPv6, which now shows when people are trying to deploy it. There is now some working going on though, you should look into the SAVI working group, they have some nice work going on both for v4 and v6 in this space. The v6ops WG is also producing deployment models for securely deploying v6 in ISP environment. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 Deployment for the LAN
Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. To me, from a small ISP perspective, this is where the largest delima is what 'vendor' is already depolying end user equipment that is ipv6 ready?? Then there's the 'delivering the customer' their ipv6 block (hopefully alongside their ipv4 block). Dual stack seems the way to go... To me, there's still a lot of wiggle room on how this should be deployed to the absolute edge. What's folks experience in rolling this out the the customer ... be it DHCP or SLAAC?? Also from a BBA perspective?? On Sat, Oct 17, 2009 at 7:55 PM, Ray Soucy r...@maine.edu wrote: Looking for general feedback on IPv6 deployment to the edge. As it turns out delivering IPv6 to the edge in an academic setting has been a challenge. Common wisdom says to rely on SLAAC for IPv6 addressing, and in a perfect world it would make sense. Given that historically we have relied on DHCP for a means of NAC and host registration, like many academic institutions, the idea of sweeping changes to accommodate IPv6 was just not going to happen in the near future. The only solution that lets us expand our roll out IPv6 to the edge without major changes to the production IPv4 network seems to point to making use of DHCPv6, so the effort has been focused there. Our current IPv6 allocation schema provides for a 64-bit prefix for each network. Unfortunately, this enables SLAAC; yes, you can suppress the prefix advertisement, and set the M and O flags, but that only prevents hosts that have proper implementations of IPv6 from making use of SLAAC. The concern here is that older hosts with less than OK implementations will still enable IPv6 without regard for the stability and security concerns associated with IPv6. Needless to say, the thought of being able to enable IPv6 on a per-host basis is met with far less resistance than opening up the floodgates and letting SLAAC take control. Ultimately, the best solution that I've been able to come up with is to preserve the IPv6 allocation schema and reserve a 64-bit prefix for each network, but for the initial deployment use an 80-bit one in its place with the extra 16 bits given a value of 1. The advantages of this: Guarantee that SLAAC will not be initiated for the prefix; Allow for a migration path to 64-bit prefixes in the future; and, Make it easy to identify a network that us making use of an 80-bit prefix by setting the extra bits to a value of 1. This allows us to be fairly confident that extending IPv6 to edge networks will not impact production services, and focus on DHCPv6 for host configuration and address assignment. We have no problem using a 64-bit prefix and letting SLAAC take care of addressing for certain networks where we actually manage the hosts, so that has been included as an exception. All other networks, however, will make use of DHCPv6 or manual configuration to receive native IPv6. So far, this has proven to work well with testing of various hosts and applications. Has anyone run into issues with applications in not using a 64-bit prefix? Of course, the other challenge here is proper DHCPv6 client implementations for host operating systems. Linux, Windows Server 2003 and later, Windows Vista, and Windows 7 all support DHCPv6. Windows XP has a poor implementation of IPv6 but has the option of using Dibbler or some other 3rd party DHCPv6 client. Mac OS X is a challenge; it currently has no option for DHCPv6, though newer releases provide for manual configuration of IPv6 addressing. Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? Since the goal for this initial wave is to make IPv6 available to those who request it or have a need for it, we feel its acceptable that there will need to be some user participation in enabling IPv6 for a host. I think the hope is that more systems, like Windows 7, will begin including mature DHCPv6 clients which are enables when the M flag for a router advertisement is set and perhaps make it the default behavior. Is this likely to happen or am I being too optimistic? Anyway, just thought I'd bounce it to NANOG and get some feedback. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
