Choice of address for IPv6 default gateway
I'm having trouble finding authoritative sources on the best common practice (if there even is one) for the choice of address for an IPv6 default gateway in a production server environment (not desktops). For example in IPv4 it is common to chose the first or last address in the subnet (.1 or .254 for example) as the VIP for VRRP/HSRP. I'm interested in input from production environments and or ARIN/RIPE/IANA/etc or top vendors. I've seen some documentation using <prefix>::1 with either a global prefix or link-local (fe80::1). Anyone use either of these in production and have negative or positive feedback? fe80::1 is seductive because it is short and the idea of having the same default gateway configured everywhere might be simple. At the same time using the same address all around the network seems to invite confusion or problems if two interfaces with the address ever ended up in the same broadcast domain. What about using RAs to install the default route on the servers? The 'priority' option (high/medium/low) easy fits with an architecture using an active/standby router setup where the active router is configured with the 'high' priority and the standby 'medium'. With the timeout values tuned for relatively rapid (~3 seconds) failover this might be feasible. Anyone use this in production? I note that VRRPv3 (and keepalived) and HSRP both support IPv6. Since we use VRRP for IPv4, using it for IPv6 would keep our architecture the same, which has merit too. Thanks in advance, Daniel STICKNEY
I've had good luck in a corporate environment using fe80::1 on Cisco 6500/7600 with newer IOS. However, some software routers still won't let you use a link-local as a VIP (at least in HSRP). I'm upgrading one of our 7200 tonight running 15.1(4)M1 to M3, hopefully that will fix it (we are upgrading it for other reasons). For example: int vlan110 standby 110 ipv6 FE80::1 standby 110 timers msec 250 msec 750 standby 110 priority 110 standby 110 preempt delay minimum 180 ---- Matthew Huff | 1 Manhattanville Rd Director of Operations | Purchase, NY 10577 OTA Management LLC | Phone: 914-460-4039 aim: matthewbhuff | Fax: 914-460-4139
-----Original Message----- From: Daniel STICKNEY [mailto:dstickney@optilian.com] Sent: Wednesday, January 25, 2012 9:42 AM To: nanog@nanog.org Subject: Choice of address for IPv6 default gateway
I'm having trouble finding authoritative sources on the best common practice (if there even is one) for the choice of address for an IPv6 default gateway in a production server environment (not desktops). For example in IPv4 it is common to chose the first or last address in the subnet (.1 or .254 for example) as the VIP for VRRP/HSRP. I'm interested in input from production environments and or ARIN/RIPE/IANA/etc or top vendors.
I've seen some documentation using <prefix>::1 with either a global prefix or link-local (fe80::1). Anyone use either of these in production and have negative or positive feedback? fe80::1 is seductive because it is short and the idea of having the same default gateway configured everywhere might be simple. At the same time using the same address all around the network seems to invite confusion or problems if two interfaces with the address ever ended up in the same broadcast domain.
What about using RAs to install the default route on the servers? The 'priority' option (high/medium/low) easy fits with an architecture using an active/standby router setup where the active router is configured with the 'high' priority and the standby 'medium'. With the timeout values tuned for relatively rapid (~3 seconds) failover this might be feasible. Anyone use this in production?
I note that VRRPv3 (and keepalived) and HSRP both support IPv6. Since we use VRRP for IPv4, using it for IPv6 would keep our architecture the same, which has merit too.
Thanks in advance,
Daniel STICKNEY
In a message written on Wed, Jan 25, 2012 at 03:41:36PM +0100, Daniel STICKNEY wrote:
I've seen some documentation using <prefix>::1 with either a global prefix or link-local (fe80::1). Anyone use either of these in production and have negative or positive feedback? fe80::1 is seductive because it is short and the idea of having the same default gateway configured everywhere might be simple. At the same time using the same address all around the network seems to invite confusion or problems if two interfaces with the address ever ended up in the same broadcast domain.
I don't think the industry has really found a best practice to document yet. There are people trying different ideas. We find the following convention allows us to keep things organized: <prefix>::1 - Default gateway <prefix>::<last octect IPv4> - Statically assigned servers. <prefix>:<eui-64> - Auto-configured host If you need them to co-exist, you can also do things like: <prefix>::<10240-20480> - DHCP Pool And if a host learns a default gateway via RA, it will show up as fe80::<eui-64> in the routing table. A static server at 10.0.1.34 has an IPv6 address of <prefix>::34. It's visually very easy for an admin to see everything is configured correctly, and helps reduce confusion a lot when troubleshooting. We use .1 in IPv4 for a default gateway, so ::1 similarly reduces confusion.
What about using RAs to install the default route on the servers? The 'priority' option (high/medium/low) easy fits with an architecture using an active/standby router setup where the active router is configured with the 'high' priority and the standby 'medium'. With the timeout values tuned for relatively rapid (~3 seconds) failover this might be feasible. Anyone use this in production?
No. We avoid RA's where possible, because of the "rogue RA" problem. Rogue in this case usually means an admin fat fingering something or plugging into the wrong port, not an actual, but it quickly causes an outage. Unless you happen to have new enough switches that support RA Guard extreme care is warranted. (Note, we're also a server enviornment, not an end user one, and servers tend to end up "statically" configured (possibly via script) anyway for reasons that have nothing to do with IPv4 or IPv6.) That said, it can be used where redundancy is required, and your routers do not yet support the VRRP or HSRP protocols that support IPv6. Generally speaking across the board we find it makes a lot of sense to treat IPv6 as "IPv4 with bigger addresses", and do things the same way as before. That's not to say we don't take advantage of /64's on LAN's, or RA's in some cases, but it reduces admin confusion where you can make things operate the same way. In a lot of cases, like a default gateway of ::1, or a BGP policy that looks the same config parity can be achieved and works out really well. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
On Wed, Jan 25, 2012 at 10:06 AM, Leo Bicknell <bicknell@ufp.org> wrote:
I don't think the industry has really found a best practice to document yet. There are people trying different ideas. We find the following convention allows us to keep things organized:
<prefix>::1 - Default gateway <prefix>::<last octect IPv4> - Statically assigned servers. <prefix>:<eui-64> - Auto-configured host
This is essentially what we do (except we use the hex value of the last octet, so .34 would be ::22, probably just the purist in me). If you have an environment where hosts will be statically configured, then you probably want to use a global default, if only to avoid confusion from users or poorly written software that expects the default to be in the same prefix as the address. If people understand their prefix is 2001:DB8::/64, and the gateway is 2001:DB8::1 it raises a lot less questions than "your prefix is 2001:DB8::/64 but your default router is FE80...". -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
On Jan 25, 2012, at 8:40 AM, Ray Soucy wrote:
On Wed, Jan 25, 2012 at 10:06 AM, Leo Bicknell <bicknell@ufp.org> wrote:
I don't think the industry has really found a best practice to document yet. There are people trying different ideas. We find the following convention allows us to keep things organized:
<prefix>::1 - Default gateway <prefix>::<last octect IPv4> - Statically assigned servers. <prefix>:<eui-64> - Auto-configured host
This is essentially what we do (except we use the hex value of the last octet, so .34 would be ::22, probably just the purist in me).
Having done both hex-conversion and BCD (in fact I mention both possibilities in the IPv6 courses that I teach), I have to say that the purist loses to the pragmatist in my mind and BCD makes much more sense. You can, actually, safely BCD up to the last three IPv4 octets in an IPv6 address without violating the 12-bits of zeroes rule to avoid EUI-64 collisions, so, for example, 10.1.2.3 could become <prefix>::1:2:3, or, 10.209.198.144 could be <prefix>::209:198:144.
If you have an environment where hosts will be statically configured, then you probably want to use a global default, if only to avoid confusion from users or poorly written software that expects the default to be in the same prefix as the address.
Well, any software should be able to handle a link-local default, but, otherwise, yes.
If people understand their prefix is 2001:DB8::/64, and the gateway is 2001:DB8::1 it raises a lot less questions than "your prefix is 2001:DB8::/64 but your default router is FE80...".
People will have to get used to the fe80 thing pretty quickly anyway, since that's what you get with RAs regardless. Owen
On Jan 25, 2012, at 7:06 AM, Leo Bicknell wrote:
In a message written on Wed, Jan 25, 2012 at 03:41:36PM +0100, Daniel STICKNEY wrote:
I've seen some documentation using <prefix>::1 with either a global prefix or link-local (fe80::1). Anyone use either of these in production and have negative or positive feedback? fe80::1 is seductive because it is short and the idea of having the same default gateway configured everywhere might be simple. At the same time using the same address all around the network seems to invite confusion or problems if two interfaces with the address ever ended up in the same broadcast domain.
I don't think the industry has really found a best practice to document yet. There are people trying different ideas. We find the following convention allows us to keep things organized:
<prefix>::1 - Default gateway <prefix>::<last octect IPv4> - Statically assigned servers. <prefix>:<eui-64> - Auto-configured host
If you need them to co-exist, you can also do things like:
<prefix>::<10240-20480> - DHCP Pool
I'll note that 10240-20480 are not valid IPv6 suffixes and that you would need to represent that as <prefix>::<2800-5000> and would probably be better off to use something more like <prefix>::8:* as your DHCP pool. Owen
In a message written on Wed, Jan 25, 2012 at 03:22:37PM -0800, Owen DeLong wrote:
On Jan 25, 2012, at 7:06 AM, Leo Bicknell wrote:
<prefix>::<10240-20480> - DHCP Pool
I'll note that 10240-20480 are not valid IPv6 suffixes and that you would need to represent that as <prefix>::<2800-5000> and would probably be better off to use something more like <prefix>::8:* as your DHCP pool.
Yeah, I'm not sure why my brain put 0's on the end when typing. I intended to say <prefix>::1024-2048, but as you point out using <prefix>::1:1-n works just as well. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Hi Daniel, On Jan 25, 2012, at 8:41 AM, Daniel STICKNEY wrote:
I'm having trouble finding authoritative sources on the best common practice (if there even is one) for the choice of address for an IPv6 default gateway in a production server environment (not desktops). For example in IPv4 it is common to chose the first or last address in the subnet (.1 or .254 for example) as the VIP for VRRP/HSRP. I'm interested in input from production environments and or ARIN/RIPE/IANA/etc or top vendors.
Well, you're not going to find anything authoritative per se, but we are using fe80::1 with HSRP on every LAN with v6 enabled. More recent HSRP implementations also support <prefix>::1, but that doesn't seem to make any sense to me since link-local is where your gateway lives.
What about using RAs to install the default route on the servers? The 'priority' option (high/medium/low) easy fits with an architecture using an active/standby router setup where the active router is configured with the 'high' priority and the standby 'medium'. With the timeout values tuned for relatively rapid (~3 seconds) failover this might be feasible. Anyone use this in production?
Our servers are statically assigned with prefix::1000 and counting up, and fe80::1%int for the gateway. Some servers are doing an IP per service / customer. In some initial deployments I did, RA Priority did not seem to be observed. That was 8 or 9 years ago so maybe that has changed, but it was not comforting. We were more worried about unintentional & rogue RA vs active/standby routers. Now that we have RA Guard deployed on > 100,000 edge ports, that doesn't really matter anymore. Dale
On Jan 25, 2012, at 6:41 AM, Daniel STICKNEY wrote:
I'm having trouble finding authoritative sources on the best common practice (if there even is one) for the choice of address for an IPv6 default gateway in a production server environment (not desktops). For example in IPv4 it is common to chose the first or last address in the subnet (.1 or .254 for example) as the VIP for VRRP/HSRP. I'm interested in input from production environments and or ARIN/RIPE/IANA/etc or top vendors.
It's mostly a matter of personal preference. If you want to just use RAs (which is a perfectly fine alternative in most server environments if you're not especially paranoid), then that will automatically use the link local address of the router as next-hop. If you want to go with something configured via static configuration (note, you CANNOT currently provide default gateway information in DHCPv6), then ::1 or ::<something>:1 or whatever is a perfectly viable alternative, so long as your ops folks can all agree on using pretty much the same thing on every subnet. Using different default gateways on different subnets is perfectly functional, but, leads to human factors complications that tend to outweigh any perceived benefit to doing so.
I've seen some documentation using <prefix>::1 with either a global prefix or link-local (fe80::1). Anyone use either of these in production and have negative or positive feedback? fe80::1 is seductive because it is short and the idea of having the same default gateway configured everywhere might be simple. At the same time using the same address all around the network seems to invite confusion or problems if two interfaces with the address ever ended up in the same broadcast domain.
I don't recommend fe80::1 because not all platforms support configuration of link local addresses vs. using the IID based address or in addition to the IID based address. Also, HSRP/VRRP comes with overhead which you can avoid by using RA. Note, you can use RA for default gateway while still using static addressing.
What about using RAs to install the default route on the servers? The 'priority' option (high/medium/low) easy fits with an architecture using an active/standby router setup where the active router is configured with the 'high' priority and the standby 'medium'. With the timeout values tuned for relatively rapid (~3 seconds) failover this might be feasible. Anyone use this in production?
Yes, many people use RA in production. The timeout is, I believe, usually more on the order of 1,000 ms or less.
I note that VRRPv3 (and keepalived) and HSRP both support IPv6. Since we use VRRP for IPv4, using it for IPv6 would keep our architecture the same, which has merit too.
Support for VRRP IPv6 varies from vendor to vendor and while you might keep the same architecture, there are likely differences in the vendor- specific behaviors and/or bugs for their IPv6 VRRP implementations. RA being a much simpler protocol is somewhat less likely to get screwed up in the implementation process by the vendors. It's also the part of the code that gets exercised by more of their IPv6 using customers at this point. Owen
Hi On 1/25/12 23:53 , Owen DeLong wrote: [...]
Note, you can use RA for default gateway while still using static addressing.
Could you give me a little bit more on this? It seems to me that most platforms stop listening to RAs once you give them a static address. Letting a host run slaac and then add a static address is not good enough as the slaac address might be chosen for locally generated packets. If it works with listening on RAs when running with statically configured address, why HSRP/VRRP? [...]>
Owen
/Tias
On Thu, 26 Jan 2012, Mathias Wolkert wrote:
Hi
On 1/25/12 23:53 , Owen DeLong wrote: [...]
Note, you can use RA for default gateway while still using static addressing.
Could you give me a little bit more on this?
It seems to me that most platforms stop listening to RAs once you give them a static address.
Static address + RA working on FreeBSD and Linux. Sorry we don't have other servers, where we are using statically configured IPv6 addresses.
Letting a host run slaac and then add a static address is not good enough as the slaac address might be chosen for locally generated packets.
Define for every application your bind address - locally generated packets will use it. If it is not possible Use RFC 3484 source address selection for selecting static source addresses.
If it works with listening on RAs when running with statically configured address, why HSRP/VRRP?
Statically configured default gateways worked for us with VRRP/HSRP. VRRP/HSRP is for first-hop redundancy. Best Regards, Janos Mohacsi
Letting a host run slaac and then add a static address is not good enough as the slaac address might be chosen for locally generated packets.
Define for every application your bind address - locally generated packets will use it. If it is not possible Use RFC 3484 source address selection for selecting static source addresses.
Actually, RFC 3484 would be the preferred mechanism over configuring every application. Application specific address binding should only be used for applications that need an exception to the host-wide source address selection choice. + Fewer surprises for your ops team + Lower probability of a mistake leading to incorrect source address selection + Reduced probability of configuration mistake time-bombs + Reduces the amount of configuration required for a host Owen
I have sites using "all of the above", and concur with Owen's comment regarding it being a "personal preference" issue. RA route learning simply "works", and I (surprisingly) have not yet had problems where the high/med/low settings were not correctly honored (95% Cent/Deb environments, FWIW). FAIR WARNING: You should tune your advertisement interval, valid lifetime, etc. to values appropriate to your environment, as most router defaults I've worked with are quite high. The issue of using FE80::1 everywhere (as the virtual IP in your FHRP of choice) is operationally a wash, in terms of perceived complexity from the front lines. Do people give me quizzical expressions the first time they learn/use it? Absolutely. But a small amount of "getting comfortable" with def.gwy subnet =/= the intentionally provisioned subnet is outweighed by the ease of "oh, it's the same everywhere now." FHRPs gaining the use of global prefixes seems to be coming along nicely across product lines, although not yet universally supported. ...and on the <?!?> front, I'd just as soon use the VRRP virtual MAC + ID formula converted to EUI-64, but the RFC says you're not supposed to. :)
Hi,
The issue of using FE80::1 everywhere (as the virtual IP in your FHRP of choice) is operationally a wash, in terms of perceived complexity from the front lines. Do people give me quizzical expressions the first time they learn/use it? Absolutely. But a small amount of "getting comfortable" with def.gwy subnet =/= the intentionally provisioned subnet is outweighed by the ease of "oh, it's the same everywhere now."
I agree. I only had problems with VMWare ESXi here. You can't explicitly specify the interface for the default route there. With VMWare ESX you could, but since VSphere5 we don't have that option anymore :-( - Sander
On Thu, Jan 26, 2012 at 04:16, Mathias Wolkert <tias@netnod.se> wrote:
Note, you can use RA for default gateway while still using static addressing.
Could you give me a little bit more on this?
Easy: have the RAs sent w/ a prefix information option included, but w/o the A bit being set.
It seems to me that most platforms stop listening to RAs once you give them a static address.
That is (IMHO) a broken implementation. A static address, or even a statically configured default gateway, should not prevent RAs from being processed. /TJ
On Wed, 25 Jan 2012, Daniel STICKNEY wrote:
I'm having trouble finding authoritative sources on the best common practice (if there even is one) for the choice of address for an IPv6 default gateway in a production server environment (not desktops). For example in IPv4 it is common to chose the first or last address in the subnet (.1 or .254 for example) as the VIP for VRRP/HSRP. I'm interested in input from production environments and or ARIN/RIPE/IANA/etc or top vendors.
I've seen some documentation using <prefix>::1 with either a global prefix or link-local (fe80::1). Anyone use either of these in production and have negative or positive feedback? fe80::1 is seductive because it is short and the idea of having the same default gateway configured everywhere might be simple. At the same time using the same address all around the network seems to invite confusion or problems if two interfaces with the address ever ended up in the same broadcast domain.
Up to your taste. Most cases it is recommended to use link-local default gateway. If you use the same address - even link local - your node should complain about the duplicate address on the same link. You can rely on the autoconfigured link-local address for default gateways (and use RA).
What about using RAs to install the default route on the servers? The 'priority' option (high/medium/low) easy fits with an architecture using an active/standby router setup where the active router is configured with the 'high' priority and the standby 'medium'. With the timeout values tuned for relatively rapid (~3 seconds) failover this might be feasible. Anyone use this in production?
Yes we are using NUD (and using RA to install default gateway) to switch from primary rotuer to secondary - due to no VRRP support on a particular platform. But in case of RA usage you should also use RA-guard especially if you don't have full control on servers connected to your switches.
I note that VRRPv3 (and keepalived) and HSRP both support IPv6. Since we use VRRP for IPv4, using it for IPv6 would keep our architecture the same, which has merit too.
If you want consistent and more predictable behavoir use VRRP or maybe HSRP if your vendor supports it. Best Regards, Janos Mohacsi
Thanks everyone for your input! I now have a more complete perspective on the pros and cons of the options available. -Daniel Le 26/01/2012 09:18, Mohacsi Janos a écrit :
On Wed, 25 Jan 2012, Daniel STICKNEY wrote:
I'm having trouble finding authoritative sources on the best common practice (if there even is one) for the choice of address for an IPv6 default gateway in a production server environment (not desktops). For example in IPv4 it is common to chose the first or last address in the subnet (.1 or .254 for example) as the VIP for VRRP/HSRP. I'm interested in input from production environments and or ARIN/RIPE/IANA/etc or top vendors.
I've seen some documentation using <prefix>::1 with either a global prefix or link-local (fe80::1). Anyone use either of these in production and have negative or positive feedback? fe80::1 is seductive because it is short and the idea of having the same default gateway configured everywhere might be simple. At the same time using the same address all around the network seems to invite confusion or problems if two interfaces with the address ever ended up in the same broadcast domain.
Up to your taste. Most cases it is recommended to use link-local default gateway. If you use the same address - even link local - your node should complain about the duplicate address on the same link. You can rely on the autoconfigured link-local address for default gateways (and use RA).
What about using RAs to install the default route on the servers? The 'priority' option (high/medium/low) easy fits with an architecture using an active/standby router setup where the active router is configured with the 'high' priority and the standby 'medium'. With the timeout values tuned for relatively rapid (~3 seconds) failover this might be feasible. Anyone use this in production?
Yes we are using NUD (and using RA to install default gateway) to switch from primary rotuer to secondary - due to no VRRP support on a particular platform. But in case of RA usage you should also use RA-guard especially if you don't have full control on servers connected to your switches.
I note that VRRPv3 (and keepalived) and HSRP both support IPv6. Since we use VRRP for IPv4, using it for IPv6 would keep our architecture the same, which has merit too.
If you want consistent and more predictable behavoir use VRRP or maybe HSRP if your vendor supports it. Best Regards, Janos Mohacsi
participants (11)
-
Dale W. Carder -
Daniel STICKNEY -
Jeff Hartley -
Leo Bicknell -
Mathias Wolkert -
Matthew Huff -
Mohacsi Janos -
Owen DeLong -
Ray Soucy -
Sander Steffann -
TJ