On Jun 8, 2011, at 7:18 AM, ryan@u13.net wrote:

On Wed, 8 Jun 2011 09:51:21 -0400, Nick Olsen wrote:

...

I'm sure someone here is doing IPv6 peering with cogent. We've got a Gig

with them, So they don't do that dual peering thing with us. (They do it on another 100Mb/s circuit we have... I despise it.) Just kind of curious how they go about it. Do they issue you a small IPv6 block for your interface, just like they do for IPv4? Is it a separate session? Any things to be aware of before pulling the trigger on it? (Other then them not having connectivity to HE's IPv6 side of things, Wish they would fix that already...)

Nick Olsen Network Operations (855) FLSPEED x106

We have separate v4 and v6 sessions with them on the same dual-stack interface (a v4 /29 and v6 /112 on the interface). One session is between our v4 address and theirs, and carries v4 prefixes only. Then another session between v6 addresses that carries v6 prefixes only.

That's really the best way to do dual stack peering anyway. Keeps things much cleaner. Owen

On Wed, Jun 8, 2011 at 9:58 PM, Kelly Setzer <Kelly.Setzer@wnco.com> wrote:

IPv6 newbie alert!

I thought the maximum prefix length for IPv6 was 64 bits, so the comment about a v6 /112 for peering vexed me.  I have Googled so much that Larry Page called me and asked me to stop.

Can someone please point me to a resource that explains how IPv6 subnets larger than 64 bits function and how they would typically be used?

Hi Kelly, IPv6 netmasks work exactly like IPv4 netmasks. You can even route /128's if you want. Two major caveats: 1. SLAAC (stateless autoconfiguration, the more or less replacement for DHCP) only works if the subnet on your LAN is exactly /64. So unless you're manually configuring the IPv6 address on every machine on your subnet, you're using a /64. 2. Reverse DNS delegates every 4 bits (in IPv4 its every 8 bits). And when you write the address, every 4 bits is one digit. So unless you want to make things needlessly hard, you're also going to choose 4-bit boundaries for everything. I.e. a /56 or a /60 but never a /57. Now, as to why they'd choose a /112 (65k addresses) for the interface between customer and ISP, that's a complete mystery to me. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com  bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

I had to ask this here a while back, so I can now share. :-)

IPv6 addresses are written as 8 16-bit chunk separated by colons (optionally with the longest consecutive set of :0 sections replaced with ::). A /112 means the prefix is 7 of the 8 chunks, which means you can use ::1 and ::2 for every connection.

Of course, just because you allocate a /112 (or shorter) in your database doesn't mean you have to use it. You could also allocate a /112 for a point-to-point link and use a /127 (e.g. addresses ::a and ::b).

Still that doesn't give any reason to provide /112 for point to point connectivitiy. Seriously, I'm peering with a transit provider with /126 and when I asked for a reason they said, ease of management. How come Subnetting /32 to /126 is ease of management??.... thats quite difficult to understand. This debate is there fore quite a long time but everytime it pops up I feel so uncomfortable with this granular subnetting. Regards, Aftab A. Siddiqui

On Thu, Jun 9, 2011 at 10:02 AM, Jack Bates <jbates@brightok.net> wrote:

Some networks prefer a uniform numbering scheme. /112 allows for reasonable addressing needs on a circuit. In addition, while Ethernet is often used in a point-to-point access circuit, such layouts may change and renumbering would be annoying.

Finally, having chunks 4-7 define the circuit and chunk 8 provide the circuit addressing makes it more human readable and is prone to less mistakes by those who suck at math.

Hi Jack, I follow the reasoning, but unless you attach undue importance to the colons you get basically the same result with a /124. I guess choosing /112 for a point to point link is one of the weird side-effects of placing :'s in the address at fixed locations instead of arbitrary locations that serve the writer's mnemonic convenience. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com  bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On Jun 9, 2011, at 7:02 AM, Jack Bates wrote:

On 6/9/2011 1:58 AM, Aftab Siddiqui wrote:

...

Still that doesn't give any reason to provide /112 for point to point connectivitiy. Seriously, I'm peering with a transit provider with /126 and when I asked for a reason they said, ease of management. How come Subnetting /32 to /126 is ease of management??.... thats quite difficult to understand. This debate is there fore quite a long time but everytime it pops up I feel so uncomfortable with this granular subnetting.

Some networks prefer a uniform numbering scheme. /112 allows for reasonable addressing needs on a circuit. In addition, while Ethernet is often used in a point-to-point access circuit, such layouts may change and renumbering would be annoying.

Finally, having chunks 4-7 define the circuit and chunk 8 provide the circuit addressing makes it more human readable and is prone to less mistakes by those who suck at math.

not to disagree how from my vantage point, it's fairly straight forward to assign a /64 and then deploy as a /127. that might be considered wasteful on the other hand a subnet is a subnet.

Jack

On Wed, Jun 08, 2011 at 10:33:29PM -0500, Chris Adams wrote:

Once upon a time, William Herrin <bill@herrin.us> said:

...

Now, as to why they'd choose a /112 (65k addresses) for the interface between customer and ISP, that's a complete mystery to me.

I had to ask this here a while back, so I can now share. :-)

IPv6 addresses are written as 8 16-bit chunk separated by colons (optionally with the longest consecutive set of :0 sections replaced with ::). A /112 means the prefix is 7 of the 8 chunks, which means you can use ::1 and ::2 for every connection.

Of course, just because you allocate a /112 (or shorter) in your database doesn't mean you have to use it. You could also allocate a /112 for a point-to-point link and use a /127 (e.g. addresses ::a and ::b).

Please don't use /127: Use of /127 Prefix Length Between Routers Considered Harmful http://tools.ietf.org/html/rfc3627 More below on use of various prefix lengths. You need to watch out for the EUI-64 'u' and 'g' bits, as well as subnet anycast addresses (top 127 addresses of every subnet): IPv6 Addressing Considerations: http://tools.ietf.org/html/rfc5375 IPv6 Address Assignment to End Sites: http://tools.ietf.org/html/rfc6177 Emerging Service Provider Scenarios for IPv6 Deployment: http://tools.ietf.org/html/rfc6036 IPv6 Optimal Address Plan and Allocation Tool: http://www.ipv6book.ca/allocation.html ARIN Wiki: http://www.getipv6.info/index.php/IPv6_Addressing_Plans (but some of the ARIN-related concepts here are obsolete, such as references to the HD Ratio and non-nibble-boundary allocations)

On 09-06-11 14:01, Chuck Anderson wrote:

Please don't use /127:

Use of /127 Prefix Length Between Routers Considered Harmful http://tools.ietf.org/html/rfc3627

Well, this RFC says not to use PREFIX::/127. You are safe to use other /127's within your prefix. -- Grzegorz Janoszka

On Jun 8, 2011, at 7:24 PM, William Herrin wrote:

On Wed, Jun 8, 2011 at 9:58 PM, Kelly Setzer <Kelly.Setzer@wnco.com> wrote:

...

IPv6 newbie alert!

I thought the maximum prefix length for IPv6 was 64 bits, so the comment about a v6 /112 for peering vexed me. I have Googled so much that Larry Page called me and asked me to stop.

Can someone please point me to a resource that explains how IPv6 subnets larger than 64 bits function and how they would typically be used?

Hi Kelly,

IPv6 netmasks work exactly like IPv4 netmasks. You can even route /128's if you want. Two major caveats:

1. SLAAC (stateless autoconfiguration, the more or less replacement for DHCP) only works if the subnet on your LAN is exactly /64. So unless you're manually configuring the IPv6 address on every machine on your subnet, you're using a /64.

You can actually use DHCPv6 to assign addresses to hosts dynamically on longer than /64 networks. However, you may have to go to some effort to add DHCPv6 support to those hosts first. Owen

...

You can actually use DHCPv6 to assign addresses to hosts dynamically on longer than /64 networks.

However, you may have to go to some effort to add DHCPv6 support to those hosts first.

Also, there is no prefix-length (or default router) option in DHCPv6, so you have to configure the Router Advertisements with the longer prefix length in this case.

It is perfectly possible to use RA *only* for the default router, and not announce any prefix at all. This implies a link-local next hop. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Don't assume that DHCPv6 is the same as DHCP. DHCPv6 does not provide route information because this task is handled by RA in IPv6. An IPv6 RA has flags for Managed (M), Other (O), and Autonomous (A) address configuration. None of these flags are exclusive. While most routers have the A flag set by default (which enables stateless addressing) it can be disabled, and hosts will not pick up a stateless address as a result. The M flag tells hosts to make use of DHCPv6 for an address, and the O flag tells hosts to make use of DHCPv6 for additional configuration, such as DNS. Most popular configurations: You can use the A and O flag for stateless addressing with DHCPv6 for DNS. You can use A, M, and O flags if you want every host to have a stateless address, but want to use DHCPv6 to also give some hosts a predictable address (e.g. for servers), and have them use DHCPv6 for DNS information. You can have only the M and O flags set and hosts will only use DHCPv6 for configuration. Most routers also support relaying of DHCPv6 information to a central server. For those who speak "Cisco" here is an example interface configuration for DHCPv6 only. ipv6 address 2001:DB8:100::1/64 no ipv6 unreachables ipv6 nd reachable-time 900000 ipv6 nd prefix default 900 300 no-autoconfig ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 nd router-preference High ipv6 nd ra interval 300 ipv6 nd ra lifetime 300 no ipv6 redirects ipv6 verify unicast source reachable-via rx ipv6 dhcp relay destination 2001:DB8:200::2 ipv6 dhcp relay destination 2001:DB8:200::3 Leaving out the "no-autoconfig" will also allow stateless if your prefix-length is 64. If you don't have a 64-bit prefix stateless won't work regardless of whether the A flag is set or not. Also note, if using DHCPv6, a DUID is used instead of the MAC address, though 2 out of 3 valid DUID formats include a MAC address of the host and I haven't actually seen the 3rd implemented. DUIDs are stored after the first time they get generated, so if you're imaging hosts you'll need to included deleting the DUID as part of your imaging process, or you'll have conflicts. Ray On Thu, Jun 9, 2011 at 12:59 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

On 9 jun 2011, at 14:19, sthaug@nethelp.no wrote:

...

It is perfectly possible to use RA *only* for the default router, and not announce any prefix at all. This implies a link-local next hop.

Router advertisements always use the router's link local address, you can't get a router's global address from this. IPv6 routing protocols also pretty much only use link locals, so link local next hop and default routes are completely routine.

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

Discussion has been had on-list before, suffice to say I respectfully disagree that there is a problem with the current design. On Thu, Jun 9, 2011 at 1:37 PM, Nick Hilliard <nick@foobar.org> wrote:

On 09/06/2011 18:19, Ray Soucy wrote:

...

DHCPv6 does not provide route information because this task is handled by RA in IPv6.

Thankfully this silliness is in the process of being fixed, along with prefix delegation - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers.

Nick

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

...

...

DHCPv6 does not provide route information because this task is handled by RA in IPv6.

...

Thankfully this silliness is in the process of being fixed,

So where do I point out the stupidity of trying to fix this non-brokenness?

Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid.

...

- so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers.

Good luck with that. Next month, the last major operating system will add support for DHCPv6. Which was published in 2003.

So now you want to change some more stuff so in 2019 we can finally actually start USING DHCPv6?

We're planning to use DHCPv6 and RA (with no prefixes, only for the link local next hop). This is more complex than using DHCPv6 alone, without RA, would be. When and if DHCPv6 without RA is possible, we certainly plan to turn off RA on our BRAS boxes. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On 10 Jun 2011, at 11:20, Iljitsch van Beijnum wrote:

On 10 jun 2011, at 12:10, sthaug@nethelp.no wrote:

...

...

So where do I point out the stupidity of trying to fix this non-brokenness?

...

Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid.

It is a mistake to want this, because having the router tell you who the router is gives you fait sharing so less breakage. It's also unnecessary because you still need cooperation from your switches to be safe from rogue DHCPv6 servers even if you go visit all your hosts and turn off stateless autoconfig in an effort to thwart rogue RAs.

But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes.

Well, remember that, from Google's estimate, only 0.3% of the access networks are IPv6 capable, so there's still 99.7% to deploy. But yes, any changes to add features a la draft-droms-dhc-dhcpv6-default-router-00 would take time, and support in the IETF seems minimal.

...

We're planning to use DHCPv6 and RA (with no prefixes, only for the link local next hop). This is more complex than using DHCPv6 alone, without RA, would be.

It is. It's also more robust. And doing this is less complex than trying to change DHCPv6 so you get to use a less complex system in the future after a complex transition.

The focus right now should be on getting the existing RA+DHCPv6 to work as intended, and to validate the model within the 0.3% base. I don't buy that a transition from RA+DHCP to DHCP-only is particularly complex though. Turn off the RAs and let DHCP do it's (extra) things. However, you'd then need to know that every device you want to network supports that new DHCP-only operation, and that will be some time off, if it happens at all. Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. Tim

Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6.

This +1. There are plenty of enterprises, employing actual network engineers (allegedly), who are just about getting to grips with CIDR and VLSM. They are *thinking* about reconfiguring their hosts to stop having 10.x.x.x/8 as the interface address, and letting proxy-arp on the routers worry about which subnets are which. They *might* have been convinced that an ATM cloud (or sometimes even MPLS!) has robust traffic separation, and they don't need a full mesh of leased lines any more. IPv6 is hugely scary as it is, without breaking their "hosts and host info" / "routers and routing info" silo model. Not all of the networking world runs on Internet time :( Regards, Tim.

On Jun 10, 2011, at 10:10 AM, sthaug@nethelp.no wrote:

...

...

...

DHCPv6 does not provide route information because this task is handled by RA in IPv6.

...

Thankfully this silliness is in the process of being fixed,

So where do I point out the stupidity of trying to fix this non-brokenness?

Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid.

I wonder if it's just a "violation" of rule #1: stop thinking legacy! People are used to what they have done for a decade or two. It's hard to see the change and results in "why is this all so different and complicated?". It's hard to open ones mind for the new, but it is essential to do with new technology. So I advice people not to get trapped by their legacy habits! /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.

In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. Zeeb wrote:

On Jun 10, 2011, at 10:10 AM, sthaug@nethelp.no wrote:

...

Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid.

I wonder if it's just a "violation" of rule #1: stop thinking legacy!

People are used to what they have done for a decade or two. It's hard to see the change and results in "why is this all so different and complicated?". It's hard to open ones mind for the new, but it is essential to do with new technology.

The problem in this case is that the failure modes are significantly different. Some folks have learned this the hard way. It's a very easy scenario to reconstruct. Consider the "branch office router" in a typical corporate enviornment. We're talking a device with one WAN port, and one LAN port. Configure it for dual stack, speaking IPv4, and in IPv4 configure it the typical corporate way with a "DHCP Helper" forwarding requests over the WAN to a central DHCP server. In IPv6, configure it with RA's, the supposed "better" way. Now, take the 100% working branch router and have it sent back to corporate. Maybe they got a bigger router, maybe the office closed. A network engineer gets the router and is tasked with making it ready to redeploy. The network engineer plugs it into the switch on his desktop, plugs in a serial cable, turns it on and steps out to get a coffee while it boots. He's planning to erase the configuration and then load new software over the network. As soon as the router boots the IPv6 network fails for all the users on his subnet. IPv4 keeps working fine. Oops. What happened? Well, the router sent IPv6 RA's as soon as it came up, and every workstation instantly started using them. In IPv4, the router received DHCPv4 requests and forwarded them per the helper address, except that its WAN port is down, and thus it in fact didn't send them anywhere. The important points: - IPv4 "failed safe" with the DHCP config. This "rogue device" will never disrupt the IPv4 configuration. DHCP snooping isn't even needed in your switches, since it never returns a response. - IPv6 "failed immediately" with the RA configuration. What's worse is if you simply turn the device off after you realized you took down the entire network devices will continue to be broken for 2-4 hours until the RA's time out. The only method to mitigate is to deploy RA guard on all of your switches, which probably means replacing 100% of your hardware with new stuff that can do that, and then deploying new features. The fact of the matter is that the failure modes of these two protocols are vastly different operationally. The DHCP failure semantics are not only better understood, but cause less disruption to the network. Even a properly rouge DHCP server will only damage _new_ clients coming up on a network, existing folks will work just fine. Contrast with RA's which instantly break 100% of the users. Even more annoying is that if I use RA's for the default gateway, I still have to run DHCPv6 anyway. If I don't my boxes don't have DNS servers, NTP servers, know where to tftpboot, etc. It's not a choice of one or the other, it's I always run DHCPv6, do I need RA's or not. Given the failure modes I would much prefer to run with RA's turned off completely, and have DHCPv6 able to provide a default gateway just as it works in IPv4. My opinion comes not from "thinking legacy", indeed my employer has been fully dual stacked since 2003. My opinion comes from the fact that in the 8 years of operational experience we have RA's are significantly more fragile, and IMHO not ready for widespread IPv6 deployment. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

In a message written on Fri, Jun 10, 2011 at 09:37:11AM -0400, Ray Soucy wrote:

You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you?

No, I posed the easiest way to recreate this issue. I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card. I've seen entire corporate networks taken out because someone ran the patch cable to the wrong port. The point is, RA's are operationally fragile and DHCP is operationally robust. You can choose to stick your head in the sand about that if you want, but it's still true. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On 10 jun 2011, at 15:47, Leo Bicknell wrote:

I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card.

Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Are there perhaps easier and more timely ways to solve it? (And it's insane that Windows still exhibits this completely broken behavior.)

On 10 jun 2011, at 16:12, Tim Chown wrote:

...

(And it's insane that Windows still exhibits this completely broken behavior.)

We could derail into some broken MacOS X behaviour if you like ;)

Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN.

On 10 Jun 2011, at 15:24, Iljitsch van Beijnum wrote:

On 10 jun 2011, at 16:12, Tim Chown wrote:

...

...

(And it's insane that Windows still exhibits this completely broken behavior.)

...

We could derail into some broken MacOS X behaviour if you like ;)

Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN.

Indeed. Well, hopefully MS is listening to the 6to4-advisory draft. Tim

All I'm saying is that it's generally a bad idea to have different standards for "accidental" and "malicious" traffic. Say you were using DHCPv6 for routing; a malicious user could still inject traffic on the network to disrupt service. People get all uppity about RA because vendors have been painfully slow to implement RA Guard. To be fair, RA Guard probably should have been an early RFC as it was an obvious concern even at the time ICMPv6 was being drafted. I for one look forward to the day where things like RA Guard and MLD Snooping are standard on every switch. Just IPv6 growing pains. Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please. On Fri, Jun 10, 2011 at 10:28 AM, Leo Bicknell <bicknell@ufp.org> wrote:

In a message written on Fri, Jun 10, 2011 at 04:08:06PM +0200, Iljitsch van Beijnum wrote:

...

Ok, so now we've identified the problem.

How exactly does adding default gateway information to DHCPv6 solve this problem?

Please go back and re-read my original scenario and think about it.

The difference here is that if a client gets a DHCP address it generally won't be broken until it tries to renew, and then often won't be broken at renewal because it sends a directed request back.

In specific technical terms: DHCP relies on broadcast _ONCE_ at boot, and then uses static unicast config to verify that is still the correct config.  RA's use broadcast every few seconds to broadcast new information that everyone is supposed to "trust" instantly.

Turn up a Rogue DHCP server on one of your subnets.  It won't affect anyone who's already up and running.  It may grab newly booted machines, depending on a race condition, but it won't break anything that is already working.

Turn up rogue RA's, and everyone instantly fails.

The behavior of these protocols is different, which leads to different failure modes.  My assertion is that in every failure mode you can come up with RA's lead to more clients being down faster and for longer periods of time.

--       Leo Bicknell - bicknell@ufp.org - CCIE 3440        PGP keys at http://www.ufp.org/~bicknell/

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On 6/10/2011 11:22 AM, Matthew Kaufman wrote:

On Jun 10, 2011, at 7:34 AM, Ray Soucy wrote:

...

I for one look forward to the day where things like RA Guard and MLD Snooping are standard on every switch. Just IPv6 growing pains.

I look forward to the day where "layer 2" switches don't need to implement hacks to fix "layer 3" flaws.

Matthew Kaufman

We already have that. Run everything as a point to point for layer 2, and there's no need to implement hacks. :P Granted, RA Guard could also be handled transparent to the layer 2 switches, but that requires a common security model to inform the devices who they are allowed to listen to. MLD Snooping is just a problem of the switch being too stupid to know which ports to send multicast out. It's technically not required if there's a layer 2 protocol to inform the switch, but those are in limited supply. Both issues often suffer heavily from multi-vendor interoperability problems. Jack

In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote:

Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please.

I want that flexability as well, but the IETF won't deliver. The two options delivered so far are: RA's only. DHCPv6 with RA's to learn a default route. I want a third option: DHCPv6 only. I have no desire to remove either of the first two options. In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote:

So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off.

There are various drafts and proposals in the IETF to solve this problem, and they pretty much all focus on the DHCP side of things. You see, in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. To pick on Ray for a moment, the IETF seems to largely have a similar attitude to Ray's. I spent a year or so trying to talk to the various folks involved, only to be told that I "didn't understand IPv6", "didn't know what I was talking about with respect to how RA's work", and "wouldn't want a network with only DHCPv6". I can't tell you how many times I had been told I clearly didn't have enough experience with IPv6, when we've been dual stacked for years. When I do get someone at the IETF who will listen to my operational issues the response is always the same as Ray's. Deploy RA guard. Never mind that until a year or so ago no vendors at all had it. Never mind that even today only a handful of switch models support it. Never mind that it requires me to forklift out every working L2 switch I have just to run IPv6. As far as I can tell the IETF has been killing or stalling the necessary DHCP additions for the better part of 7 years now. If you really want to fix this problem you either need to get a vendor to just implement it and ignore the IETF, or enough operators to go to the IETF meeting with pitchforks that perhaps someone finally listens. I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

Once upon a time, Owen DeLong <owen@delong.com> said:

I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA.

Isn't that what RDNSS (recursive DNS servers) and DNSSL (DNS search list) extensions are? -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong <owen@delong.com> wrote:

Only sort of... This only works if you don't want to auto-configure things like DNS, NTP, etc.

I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA.

The RA's aren't really supposed to be for configuring applications. DNS and NTP are applications in the IPv4 and IPv6 paradigms, not core protocol functions. Another approach to the problem would be defining anycast addresses (in the IPv4 sense of anycast) defined as "nearest DNS resolver" and "nearest NTP server." You then make a request directed to that anycast address to discover the unicast addresses of the servers you should be using. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com  bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

On a side note; I think the RDNSS stuff was pretty silly. Now instead of hosts having a DHCPv6 client, they have a DHCPv6 client AND and RDNSS client. Two services instead of one to do essentially the same thing. That's been my biggest issue with the "let's add things to RA" movement. On Fri, Jun 10, 2011 at 11:38 AM, Ray Soucy <rps@maine.edu> wrote:

There is almost no difference between having RA give out DNS information, and having an "other only" DHCPv6 server from a software standpoint.  The difference is that DHCPv6 is in the application space, while RA is in the kernel space.  It's easier to modify DHCPv6 than RA; so over time when we add options, we don't need to go back and modify the IPv6 implementation in every OS; just update the DHCPv6 client.  We could just re-name DHCPv6 other-only mode and call it "Extended RA" if you like; it wouldn't even require any code change.

Most routers that support IPv6 also support running an "Other Only" (stateless) DHCPv6 server; it's like 3 lines of configuration and costs next to nothing.  We haven't seen any DHCPv6 client implementations for "other only" but it would be equally trivial to write them.  I think the general feeling, though, is that a full DHCPv6 client should be considered a requirement for any host regardless of if the network makes use of DHCPv6 for address assignment or not.

On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong <owen@delong.com> wrote:

...

On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote:

...

In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote:

...

Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please.

I want that flexability as well, but the IETF won't deliver.

The two options delivered so far are:

RA's only.

Only sort of... This only works if you don't want to auto-configure things like DNS, NTP, etc.

I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA.

...

DHCPv6 with RA's to learn a default route.

I want a third option:

DHCPv6 only.

I have no desire to remove either of the first two options.

In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote:

...

So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be "compile DHCPv4 for 128 bits" but guess what, we have "legacy" IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off.

There are various drafts and proposals in the IETF to solve this problem, and they pretty much all focus on the DHCP side of things.

You see, in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64.  While it's not quite as trivial as adding those two fields, it's not that much more complex.  The right behavior for a host that comes up and sees no RA's needs to be documented.

To pick on Ray for a moment, the IETF seems to largely have a similar attitude to Ray's.  I spent a year or so trying to talk to the various folks involved, only to be told that I "didn't understand IPv6", "didn't know what I was talking about with respect to how RA's work", and "wouldn't want a network with only DHCPv6".  I can't tell you how many times I had been told I clearly didn't have enough experience with IPv6, when we've been dual stacked for years.

When I do get someone at the IETF who will listen to my operational issues the response is always the same as Ray's.  Deploy RA guard. Never mind that until a year or so ago no vendors at all had it. Never mind that even today only a handful of switch models support it.  Never mind that it requires me to forklift out every working L2 switch I have just to run IPv6.

As far as I can tell the IETF has been killing or stalling the necessary DHCP additions for the better part of 7 years now.  If you really want to fix this problem you either need to get a vendor to just implement it and ignore the IETF, or enough operators to go to the IETF meeting with pitchforks that perhaps someone finally listens.

I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6.

--       Leo Bicknell - bicknell@ufp.org - CCIE 3440        PGP keys at http://www.ufp.org/~bicknell/

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On 10 jun 2011, at 16:47, Leo Bicknell wrote:

...

So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes.

in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented.

Don't you realize that this doesn't solve anything? The whole point of stateless autoconfig and DHCP is to allow a host that arrives without any prior knowledge about the network to be configured without human intervention so it can communicate over the network. So we must assume a host with no prior configuration. All currently existing IPv6 hosts that I'm aware of have stateless autoconfig enabled by default (save for some *X distros that assume the system will be some kind of server). So if you put such a host with an updated DHCPv6 implementation in a network with rogue RAs, they will autoconfigure addresses in the advertised prefixes exactly the same as today. Like I said before: removing the correct information from RAs does nothing to get rid of the incorrect information in RAs. Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: 1. No longer the fait sharing that comes from RA-learned gateway addresses 2. Old and new hosts may use different gateways on the same network So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority. This way, if there are no rogue RAs the behavior is the same for unupdated and updated hosts. If there are rogue RAs, the updated hosts ignore them. If system administrators screw up and the DHCPv6 info doesn't match the actual routers, everything still works except that there is no rogue RA protection. This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of "legacy IPv6" hosts that need RAs to function and won't go away anytime soon.

On 10 jun 2011, at 17:26, Leo Bicknell wrote:

...

1. No longer the fait sharing that comes from RA-learned gateway addresses

I proport that VRRPv6 is a superior solution to have redundant gateways than using RA's to broadcast both and let the host choose.

It's not about redundancy, it's about misconfiguration. You can't misconfigure an RA to provide the wrong gateway address because the gateway address is the source address of the packet.

My guess is that most networks that use DHCPv6 will disable RA's completely on the routers.

Haven't you been paying attention? One of my main points is that you can't do that for many years to come, becasue CURRENT hosts require them. It took us 8 years to get from the publication of the DHCPv6 RFC to the deployment of DHCPv6 in all big operating systems. What's the point of doing all kinds of stuff now just so you can turn off RAs in 2019? By that time the switches will have all the necessary options so the problem is moot.

I'm going to assume operators aren't going to do such stupid things.

Not sure what universe you live in. In mine, if you give people a way to misconfigure, a good number of them will do so. And a small but vocal group will defend their misconfiguration and claim that this is really the best way to run their network, all the while complaining to their vendors and the IETF about the problems that this creates and that those need to be solved.

Leo Bicknell wrote:

In a message written on Fri, Jun 10, 2011 at 05:13:09PM +0200, Iljitsch van Beijnum wrote:

...

Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues:

1. No longer the fait sharing that comes from RA-learned gateway addresses

I proport that VRRPv6 is a superior solution to have redundant gateways than using RA's to broadcast both and let the host choose.

VRRP is definitely superior to RA's in that you can have many different redundant gateway groups for different purposes. Things like alternate default gateways, gateways to other back-end networks and VPN routers. In all but the most trivial hosting environments RA's will have to be disabled, filtered, and protected against at all cost. VRRPv3 (http://tools.ietf.org/html/rfc5798) is still a bit broken in that it makes mention of "MUST advertise RA's" and inexplicably limits VRRP addresses to link local only (?!)*. But at least we have something, it took years for the RA police at the IETF to allow even this limited solution. * In many cases it may be desirable to have VRRP addresses routed via IGP, especially static routes to VRRP next-hops. - Kevin

Op 12 jun 2011, om 12:05 heeft Daniel Roesen het volgende geschreven:

VRRP communications itself is via link-local addresses. There is a requirement to have a link-local virtual address as well, but there might be many more, e.g. global scope.

In FreeBSD with pfSense I use CARP with a v6 addresses which are GUA, the isp routes my /48 to the GUA address, failover time when rebooting firewalls is in the order of seconds. I see no missed http requests and no existing requests drop. The servers behind it are also configured to use the LAN side GUA CARP ipv6 address as the default gateway. pfsync makes sure that traffic state is being kept.

Otherwise a whole lot of IPv6 VRRP setups won't be working here. :) We use global scope addresses as VRRP virtual router addresses.

Indeed, same here. We have a open ticket iirc to patch our radvd daemon to also announce properly when active on a v6 CARP Address. It's that or being able to manually sending a GUA address as being the gateway. Wait, that sounds suspicously like trying to send a gateway bit by way of DHCP. Luckily servers are statically configured. But now comes the deal that I want all my client nodes on the corporate lan to also use the GUA address (which has stateful failover) for the gateway instead of the link local address of one of my CARP cluster nodes. Other options include crafting a link local address for the CARP address and make sure that radvd uses that. The backup carp node won't hear anything or be heard when the address has BACKUP status. It's on the todo list. Regards, Seth

On 06/10/2011 12:32 PM, Owen DeLong wrote:

I think it's a fine solution as far as it goes and a good part of a complete solution. However, documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. As it currently stands, some hosts which are DHCPv6 capable will not attempt to query DHCP until they receive an RA with the M bit set.

If we go down this path, how long before we hear screaming about rogue DHCPv6 servers giving v4-only networks a false v6 path? (At least that could be nullified by adding actual v6 support and an RA without the M bit.) Jima

On Jun 10, 2011, at 11:18 AM, Valdis.Kletnieks@vt.edu wrote:

On Fri, 10 Jun 2011 12:54:17 CDT, Jima said:

...

If we go down this path, how long before we hear screaming about rogue DHCPv6 servers giving v4-only networks a false v6 path?

Already happened. Good way to install an MITM against any v6-enabled boxes on a v4-only network, been multiple reported uses of that technique.

What's more v4 seem rather less likely to have any countermeasures or methods for detecting this... Back when I worked for a security vendor our endpoint security product specifically disabled ipv6 to address this exposure.

In a message written on Fri, Jun 10, 2011 at 09:57:07PM +0200, Iljitsch van Beijnum wrote:

If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP.

Apparently we don't have a long enough view of history, as history will tell you that this is wrong. You see, we tried the RA experiement once before. Let's go back to the Internet circa 1988, or so. There was a time when it was very common for routers to run RIP. There was a time when Sun systems (in particular, other vendors did the same) shipped with routed enabled by default. Many of these systems learned their default gateway by listening to these RIP announcements. The funny thing is, no one does this anymore. We turned off RIP, turned off routed, and invented things like HSRP to handle router redundancy. These things weren't done because someone was bored, no, they were done because these RIP deployments failed, repeatedly and often. Any device could broadcast bad information, and they did. It could be a legitimate network admin plugging a cable into the wrong jack, or it could be a hacker who rooted a machine and is injecting bad information on purpose. I submit to you those who designed RA's do not remember those days, and did not study history. The only difference is that RA's only carry a default route, where as RIP could carry several routes. The security model is identical. The failure modes are largely overlapping. IPv4 also had a similar feature, ICMP router discovery, RFC 1256. Works a little different than RA's do, but not a lot. Have you ever seen it used? I haven't. Least you think the IETF is proud of their RA work, one needs look no further than RFC 6104, where they carefully document the problem of rogue RA's and provide a list of solutions. Indeed, my proposed DHCP solution is documented in section 3.10. The IETF seems to think SEND is the solution, but it also requires deploying new software to 100% of all devices in order to be the solution.

People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate.

I participated until a working group chair told some protocol wonks "Don't listen to him, he's an operator and doesn't understand IPv6 yet." The IETF has a long history of being openly hostle to operators. That was the day I gave up on the IETF. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

And here I thought with IPv6, we would have learned from our mistakes, fixed those problems. We've had 15 years to think about it. I was looking forward to a future where ICMPv6 might even be used. At this point I'm looking forward to IPv6 being the bane of my career for the next 5 years. On 06/10/2011 03:27 PM, Leo Bicknell wrote:

IPv4 also had a similar feature, ICMP router discovery, RFC 1256. Works a little different than RA's do, but not a lot. Have you ever seen it used? I haven't.

On Jun 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote:

On 10 jun 2011, at 18:06, Leo Bicknell wrote:

...

However, many networks are much more closed deployments. Enterprises have not deployed IPv6 internally yet. Many will not deploy it for another 3-5 years, chosing instead to use web proxies at the edge that speak IPv4 (RFC1918) internally and IPv6 externally. They often can enforce the software deployed on the boxes connected.

If they have such tight control over their network and what attaches to it, then obviously rogue RAs can be clamped down upon in a variety of ways.

Rogue RA is not the problem this seeks to solve. Yes, it helps with that problem also, but, I wouldn't be saying we need this if it was just rogue RA that people are concerned about.

...

The fact that bad standards and software exist today should never be an argument to not design and deploy better software. So what if it takes until 2019, at least from 2019 to the end of IPv6 we'll have something better.

If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP.

So you say, but, the real world doesn't bear out your claim. For one thing, assuming that routers on a link are intended to serve all machines on a link assumes facts not in evidence. You can call that bad network design if you want, but, there are real world requirements and scenarios where that has to happen for a variety of reasons. Those networks have working configurations in DHCPv4 and no ability to move to IPv6 until this is solved. This isn't about fate sharing vs. non-fate sharing. This is about giving administrators a rich set of tools and allowing them to pick the ones that best fit their situation. Nobody is trying to prevent you from using RA/SLAAC on your network. More power to you. I use it on some of my networks too. However, I also deal with customers who have situations that are not well served by it and they need DHCP with the ability to provide different routing configurations to different hosts on the same link.

I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems.

I see no reason that additional DHCPv6 options would have to fragment the installed base or perpetuate the lack of agreed upon DHCPv6 behavior. In fact, I think that adding these options could allow for a set of rules that would be acceptable to all and would allow administrators to make choices based on the needs of their environments. A host which receives a DHCPv6 option it doesn't understand is expected to ignore that option. Administrators who count on DHCPv6 options that are newer than the software/hardware on some of their hosts should expect those hosts to ignore the option. This is easily documented.

People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate.

There were a lot of people who tried to "show up" at the IETF 10 years ago and talk about this stuff from an operational perspective. They were basically told that operators don't know what they want and they should shut up and go away and let real men do the work. Perhaps we should have stood up stronger at the time, but, frankly, we had real work to do that mattered to our users for the next 24 hours rather than a decade later. As such, we had limited bandwidth to attempt to push our goals somewhere where our "interference" was not welcome. So, if you want to blame younger selves, blame the IETF younger selves and the protocol zealots that shouted down the operator community and told us to mind or own business.

On 10 jun 2011, at 19:32, Owen DeLong wrote:

...

Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate router or otherwise.

It's good to want things. Doesn't mean you'll get it.

No, but, it does mean some might reject your shiny new protocol until it provides them the tools they believe they need, whether you agree with their assessment of their needs or not. Personally, I'd rather not have administrators rejecting IPv6 and it seems to me that adding routing information options to DHCPv6 is a light-weight action that is already possible within the existing protocol specification (just need to assign option numbers and attribute/value formats) and makes IPv6 a whole lot more palatable to a rather large number of administrators.

One of the three big RIRs has already run out of IPv4 space, the second will within less than a year. IPv6 deployment is still measured by counting zeroes behind the decimal point. We still don't have good CPE and broadband specs. The "happy eyeballs" stuff is still experimental but much needed. Important operating systems have serious IPv6-related bugs.

And THIS is the time to start asking for a new feature that even when viewed most favorably, is just a nice-to-have? No more that pesky multicast packet once every 200 seconds (or when a new host attaches to the network). Yes, that's really something the IETF and vendors have to spend their cycles on. NOW. Because otherwise, you know, there's this packet. It's really bad. Every 200 seconds!

Yes... This _IS_ the time to ask for a simple additional DHCP option definition that does not require rewriting any existing standards and allows much greater operator flexibility. This _IS_ absolutely the time to solve these issues before we get widespread refusal to deploy a dysfunctional protocol that causes operators to believe that IPv4+more NAT is a superior solution because they can make their networks work well enough for their needs by doing so and IPv6 still won't work in their environment. This isn't about getting rid of the RA packet. Heck, anyone can turn of RAs on almost any host or router easily enough. What this is about is providing missing functionality that a significant number of operators consider vital to their ability to use the protocol in their environment. I know you want to make this about eliminating the RA packet and solving rogue RA because, frankly, if it were about that, the argument here would be pretty weak. However, that's not what it's about. It never was what this is about. This solution would provide some small amount of help to the rogue RA issue, but, it wouldn't solve it and there is already a known complete solution (RA Guard) which just needs to be more widely implemented.

...

There are situations, for example, where the administrator does not want all hosts in a broadcast domain to receive the same set of prefixes and/or the same set of routers. This can be achieved by using different parameters based on the system identifier in the DHCP configuration. It cannot be achieved using RA.

It can also be done using my suggested "DHCP validates RA gateway address" mechanism.

Only if you add the routing information options to DHCP which you seem to be opposing. If you add the routing information options to DHCP, then, we don't need RA any more and we can simply turn it off on the routers and be done.

...

Eliminating rogue RAs is not the problem being described. That problem is solved through RA-Guard.

Well, someone certainly intermingled the discussions, and it wasn't me.

You may not have started the intermingling, but, you certainly exacerbated it.

...

The problem being described is the desire to be able to configure a host from zero to functionally on the internet using DHCP without RAs. I think everyone understands that you don't want to do so. That's fine. However, adding the functionality to DHCPv6 doesn't require you to use it. Making it available for operators that want to use it is not a bad thing.

It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this.

How does this make your life worse? If it's not your network, why do you care? If you're worried that someone running a network you support will make a decision you don't like if we give them that option, then, I don't have a lot of sympathy for you. As to fragmentation of the installed base, I don't see how adding a couple of options to DHCPv6 creates fragmentation. It adds functionality that people can use. It's just another tool. Railing against it as you do is, frankly, about as useful as claiming that we shouldn't allow anyone to develop a non-ethernet layer 2 transport because it will fragment the installed base and turn us away from the everything converges as ethernet path that we currently seem to be on.

I just wish someone had said the same when it was decided that .ip6.int in reverse DNS zone files was ugly and needed to be changed to .ip6.arpa. Or when someone decided that it's a good idea to set the DF bit on ALL packets when doing PMTUD.

Frankly, I agree that ip6.arpa makes more sense than ip6.int. What I don't understand is why we needed a different in-addr SLD to begin with. Why couldn't it be in-addr.arpa? It's not like any valid IPv6 PTR record would conflict with any valid IPv4 PTR record. I don't mind ip6.arpa, but, whatever. Having said that, that decision frankly strikes me as being largely irrelevant to anything of operational concern. Who cares what the zone is called as long as everyone uses the same name and expects the same structures within the zone. What we're talking about here is a lack of functionality that has real operational impact.

This industry has a history of doing stuff that ends up wasting huge amounts of time and money that could easily have been avoided but apparently the voice of reason was absent that day. Not this time.

You're right. Unfortunately, I think you are mistaken who has spoken with the voice of reason in this instance.

...

In some situations, this fate (it's fate, not fait, btw)

Oh, right, I always get that wrong and I know I always get it wrong but still that doesn't help me to get it right.

lol

...

sharing is not desired.

Why not?

Because in some cases, the HOST administrator is not the NETWORK administrator and cannot necessarily control how the administrator of a given router does things. In some cases, this means that the HOST administrator wants his hosts to act in a manner that is not consistent with what the administrator of certain network devices wants to tell other hosts on the same link to do. In the real world, things are not as black and white as the configuration examples in a router manual and there are political issues that require technical functionality to work around. I'm not defending these designs or situations, and, I agree that solving them at layers 8 and 9 would be preferable. However, solving them at layer 8 and 9 is nearly impossible and has to be done differently and uniquely in each circumstance. In the meantime, working around them by adding a couple of DHCPv6 options to the existing standard is harmless and pragmatic.

...

documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO.

Nope, not a good thing. It doesn't work for normal operation because the delay while lack of RAs is observed would be unacceptable. Also, the M and O bits need to be honored.

If there's no RA, there are no M or O bits to honor. If the delay is unacceptable, the administrator can turn on RAs that send the M and O bits and don't deliver any prefixes. If there's no RA, there's nothing lost by having the host fall back to DHCP Only. Yes, the DHCP with RA functionality would still be preferable (though, frankly, I see no reason that a host couldn't send the RS and DHCP Solicitation at the same time and only use the DHCP answer received (if any) if it got back an M|O bit(s) or no RA at all). In this way, the RA delay would be only minimally disruptive and probably well within acceptability in most environments. The M|O bits would still be honored if present.

A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments.

Shouldn't happen. First, if some form of back-off isn't built into DHCPv6, that should be fixed. Second, if your network doesn't have any RAs and your DHCP server isn't answering, it really doesn't matter that it gets clogged up because nothing is working anyway.

And like I said before, we have more pressing things to do than tinker some more with DHCPv6.

Meh... We can achieve a big win for relatively low cost very quickly and make IPv6 much more palatable to a wide audience of enterprise administrators. I can't really say that there's much more pressing than that. Yes, the issues you described above also fit into that category, so, I'd say this is about equal. Owen

On Jun 10, 2011, at 10:21 PM, George Herbert wrote:

On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong <owen@delong.com> wrote:

...

...

And like I said before, we have more pressing things to do than tinker some more with DHCPv6.

Meh... We can achieve a big win for relatively low cost very quickly and make IPv6 much more palatable to a wide audience of enterprise administrators. I can't really say that there's much more pressing than that. Yes, the issues you described above also fit into that category, so, I'd say this is about equal.

Right.

Please, everyone - this is not just an "IPv4 way of thinking". This is different types of networks and network users.

Just because your experience and your network don't have anything affected by these issues with DHCPv6 / RA doesn't mean that others don't.

IPv6 adoption is driven by exhaustion, but it's limited by glitches like this.

-- -george william herbert george.herbert@gmail.com

This is "different types of networks and network users" and also different operational, administrative, and security domains. I am also getting frustrated with the endless discussions that could be immediately shortened by "tinkering with DHCP" to add one or two additional options -- a minimal cost process. Why is the argument not about business needs instead of technical purity? See these quotes from 2009 and let us collectively get off the dime! On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote:

В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа:

...

OK... Here's the real requirement:

Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to:

1. Default Router 2. DNS Resolver information 3. Host can provide name to server so server can supply dynamic DNS update 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) 5. NTP servers 6. Boot server 7. Site specific attribute/value pairs (ala DHCPv4 Options)

These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured.

And to add a real-world case for this - two months ago at HAR (hacking at random, a convention in the Netherlands) I was in the network team, handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6 connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at some point we asked the question around - ok, how should we provide DNS and other useful information for the V6 only people?

After a while with all the brains around, the decision was to write it on the datenklos through the field, where people can read it and configure it in their browsers. This would've been funny if it wasn't so sad.

OTOH, for V4 everything with the DHCP worked fine (as it has always done, even at an event of this size), as is my experience with all the networks I've administered. Saying that DHCP doesn't work for me is extremely weird, as to me this means someone made specific effort to fuck it up.

Finally - we have something that works, that's called DHCP. It might not be perfect, it might have some weird issues and implementations, but it's actually making our lives easier, is tested and works. I'd love anything that would be better, but as an option, not as the only choice I have. And it's not just the protocol that I care about. I care about that it's implemented in a HOST, where I can play with the software as much as possible, instead on a ROUTER, which is a vastly different device with rarely-updated OS, and even in the case where they're both the same machine(as in small office environments), they're again handled at different layers (kernel vs userspace). There are reasons that we're using what we're using, and not all of them are "because we're masochistic idiots". -- Regards, Vasil Kolev

Following on the comments above: The security domain for HOST should not overlap the security domain for ROUTER. That is the primary driver of the separate administration of HOST and ROUTER. Heaven help us if the latest M$ virus, or even social-engineering distributed malware began to affect BGP! Give the router managers the NTP server addresses and their DHCP forwarding list and leave them alone to produce a robust and reliable transport facility! James R. Cutler james.cutler@consultant.com

This is "different types of networks and network users" and also different operational, administrative, and security domains.

I am also getting frustrated with the endless discussions that could be immediately shortened by "tinkering with DHCP" to add one or two additional options -- a minimal cost process. Why is the argument not about business needs instead of technical purity?

I'd have to agree with this. Although from a technical standpoint RA Guard would be a plausible solution to the rogue RA problem. However, the bigger issue seems to be the mixing of what used to be managed by different groups. Now you have IP transport folks implementing parameters sent to client machines or routers. Less than ideal probably. What are the current options for a company to disable RA messages, implement RAGuard, and force clients/routers to use DHCPv6 or static assignment for IPv6 addresses? I believe ignoring M and O bits would break standard though - but what if they never get sent? I know on Cisco you can suppress the RA, but not sure if you can force most clients to make DHCPv6 requests instead of listen for RAs. -- Matt Reath CCIE #27316 (SP) matt@mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath

On Fri, Jun 10, 2011 at 09:12:26PM -0700, Owen DeLong wrote:

You must have RA to at least tell you: Default Router Go ask the DHCP server (M and/or O bit)

As it currently stands, an RFC-compliant host will not attempt to solicit a DHCP response unless it receives an RA with the M inclusive-or O bits set.

RFC 4862 seems to acknowledge otherwise: 5.5.2. Absence of Router Advertisements Even if a link has no routers, the DHCPv6 service to obtain addresses may still be available, and hosts may want to use the service.[...] Could you point to any RFC which implies or explicitly states that DHCPv6 MUST NOT be used in absence of RA with M and/or O=1? Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van Beijnum wrote:

But what's the alternative? Always run DHCPv6 even if there are no router advertisements or router advertisements with O=0, M=0?

Yes.

Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance.

Huh? This is no worse than IPv4 where a host comes up and sends a subnet-broadcast to get DHCP. I have never heard of a network brought to its knees from these requests. A single packet each time a host boots is hardly a high PPS rate.

And networks without RAs are very common. We call those networks "IPv4-only networks".

No, we call those server networks. I've seen lots of IPv6 networks with RA's disabled and all static devices on them. Sometimes having hosts dynamically get addresses and default routes is a bad thing.

And in the current situation DHCPv6 without router advertisements is pointless because you may get an address, but you have no place to send your packets.

Which is what we would like to fix. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On 12 jun 2011, at 15:45, Leo Bicknell wrote:

...

Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance.

Huh? This is no worse than IPv4 where a host comes up and sends a subnet-broadcast to get DHCP.

The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing.

In a message written on Sun, Jun 12, 2011 at 08:12:02PM +0200, Iljitsch van Beijnum wrote:

The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing.

DHCP today uses an exponential backoff if there is no response, I don't see why that can't be kept in IPv6. Plus I wonder how long users would keep on machines that get no useable network connectivity. I really think the number of broadcast packets is a total non-issue. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

-----Original Message----- From: Jimmy Hess [mailto:mysidia@gmail.com] Sent: Sunday, June 12, 2011 8:43 PM To: nanog@nanog.org Subject: Re: The stupidity of trying to "fix" DHCPv6

On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell <bicknell@ufp.org> wrote:

...

DHCP today uses an exponential backoff if there is no response, I don't [snip]

This could have been (but was unfortunately not) mitigated in the v6 specs by adding options to DHCPv4 to configure IPv6 address and gateway at the same time IPv4 configuration is received, in lieu of using v6 based protocols for config; [snip]

I've observed that when the unwashed masses begin deploying new technologies, they have a terrible tendency to be disobedient, to change the rules, to revise specs. While the implementers implement and the operators operate, the professors profess to a quickly emptying lecture hall. I have great faith that the experienced and pragmatic people who have to work with IPv6 on a daily basis will resolve things like the DHCP6/RA imbroglio. IPv6 will be much different in a few years. As a host guy in an enterprise-type organization, I'm looking forward to what you and people like you will cook up. </pep talk> Kelly ******* CONFIDENTIALITY NOTICE ******* This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you.

On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote:

On 12 jun 2011, at 15:45, Leo Bicknell wrote:

...

...

Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance.

...

Huh? This is no worse than IPv4 where a host comes up and sends a subnet-broadcast to get DHCP.

The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing.

Which is no worse than the behavior of an IPv4 host on a network without a DHCP server. Owen

-----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Monday, June 13, 2011 7:55 PM To: nanog@nanog.org Subject: Re: The stupidity of trying to "fix" DHCPv6

[snip]

I understand on some level why the IETF doesn't want DHCPv4 to be able to hand out IPv6 stuff, and doesn't want DHCPv6 to hand out IPv4 stuff. In the long run if you assume we transition to IPv6 and run only IPv6 for years after that it makes sense.

However, I do think a single option is needed in both, "ProtocolsAvailable". Today it could have "4" or "6", or "4,6". [snip]

DNS is "two-legged". DNS and DHCP are so intertwined from an operational perspective, I don't see how we'll get through this without DHCP becoming two-legged.

This would allow end stations to greatly optimize their behavior at all stages of deployment.

+1 Kelly ******* CONFIDENTIALITY NOTICE ******* This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message from your system. Thank you.

On Jun 14, 2011, at 9:43 PM, Joel Jaeggli wrote:

On Jun 13, 2011, at 5:41 PM, Owen DeLong wrote:

...

On Jun 12, 2011, at 11:12 AM, Iljitsch van Beijnum wrote:

...

On 12 jun 2011, at 15:45, Leo Bicknell wrote:

...

...

Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance.

...

Huh? This is no worse than IPv4 where a host comes up and sends a subnet-broadcast to get DHCP.

The IPv4 host does this once and gets its lease. If there is no DHCPv6 server then DHCPv6 clients would keep broadcasting forever. Not a good thing.

Which is no worse than the behavior of an IPv4 host on a network without a DHCP server.

An ipv4 host will in most cases configure itself with a link-local address. A possibly surprising number of people consider this broken, when in fact it's working. the possiblity that autoconfiguration of networks would occur when no routers or dhcp servers exist has some utility just as it did when windows started doing this with ipv4 circa 1998.

Yes, so will an IPv6 host. I'm not understanding your point here. The point of the conversation is that the DHCPv6 packets going out on a network without a DHCPv6 server would be no worse than the DHCPv4 packets on a network without a DHCPv4 server today. Owen

On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote:

On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell <bicknell@ufp.org> wrote:

...

In a message written on Sun, Jun 12, 2011 at 01:04:41PM +0200, Iljitsch van Beijnum wrote:

...

Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance.

Huh? This is no worse than IPv4 where a host comes up and sends a subnet-broadcast to get DHCP.

Broadcast != Multicast. esp. when talking about wireless chipsets. I've yet to find a wifi chipset that didn't completely fuck-up when presented with even a low pps of multicast traffic. Broadcast traffic doesn't seem to bother them -- it doesn't attempt to filter them in any way, or really pay them any attention. If I had to guess, the chip firmware is individually transmitting multicast packets to each peer; a broadcast packet is sent once to all peers.

I've not had any wireless networks disrupted by broadcast traffic -- and with Radware load balancers in the network, there are *plenty* of broadcasts (ARP). Just a few 100pps of multicast and the AP fails. (linksys, netgear, even cisco... all broadcom crap radios.)

by default the multicast rate is at the lowest supported rate on the ap which negatively impacts the performance of everything else.

--Ricky

On Tue, 14 Jun 2011, Owen DeLong wrote:

You would need an AWFUL lot of hosts for this to add up to a few 100pps (or even 10pps) of multicast traffic.

On the AMSIX peering LAN there is more than 100pps of ND traffic (at least there was when we checked). Since they do not do IPv6 multicast intelligent handling (MLD snooping I guess) certain highend (legacy) router platforms run into trouble because all these packets are punted to RP. Implementing access list that filtered all multicast traffic the linecard didn't actually subscribe to, solved the problem.

On Tue, 14 Jun 2011, Owen DeLong wrote:

ND would be a far more frequent occurrence than DHCP requests.

Of course, it was only partly related to the discussion, most likely the network which has problem with multicast would break first because of ND, not because of DHCPv6 requests.

Also, I tend to doubt that ANYONE would do DHCP on an exchange point network, so, it's not exactly an applicable example environment.

It's the largest IPv6 enabled L2 domain I've experienced :P -- Mikael Abrahamsson email: swmike@swm.pp.se

On 14/06/2011 17:02, Owen DeLong wrote:

That was kind of my point. You are unlikely to encounter such a large L2 domain outside of an exchange point.

Indeed so. Apart from large enterprise LANs. And campus LANs. And badly designed large service provider LANs. And other types of large L2 domains. But apart from those exceptions, you'll never see large L2 domains outside of an IXP. Nick

On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong <owen@delong.com> wrote:

That was kind of my point. You are unlikely to encounter such a large L2 domain outside of an exchange point.

I've seen such large networks in private industry (and governements, not just the US) several times. And IPv6 has been designed (poorly, it would now appear) for huge "LAN"s -- LANs are supposed to be /64, after all. One of them "had" to have such stupid large L2 domains because they used RIP (v1) EVERYWHERE. (all networks had to be /22's) They made a god aweful mess trying to switch to OSPF, got fined by a three letter regulatory agency, and are probably still running RIPv1 to this day.

On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong <owen@delong.com> wrote:

The point of /64 is to support automatic configuration and incredibly sparse host addressing. It is not intended to create stupidly large broadcast domains.

Several IETF (and NANOG) discussions say otherwise. While current hardware doesn't handle thousands of hosts, the protocol was designed for a future where that's not true. (there's a future where *everything* is network enabled... microwave oven, doorbell, weed whacker, everything.)

A /22 is probably about the upper limit of a sane broadcast domain, but, even with a /22 or 1022 nodes max, each sending a packet every 10 seconds you don't get to 100s of PPS, you get 102.2pps.

As I said, DHCP isn't the only source of traffic. Setup a 1000 node network today (just IPv4), and you will see a great deal of broadcast traffic (unless those nodes aren't doing anything.) With IPv6, it's all multicast (v6 doesn't have a "broadcast address") hinged on switches filtering the traffic away from where it doesn't need to be. The all-too-common Best Buy $20 white box ethernet switch does no multicast filtering at all. Pretty much all wireless hardware sucks at multicast - period. These are not things that can be fixed with a simple software update... if the silicon doesn't do it, *it doesn't do it*.

Ricky Beam <jfbeam@gmail.com> wrote:

And IPv6 has been designed (poorly, it would now appear) for huge "LAN"s -- LANs are supposed to be /64, after all.

Ethernet is not designed for huge LANs. If you want that you need to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/ Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Fisher, German Bight: Southerly or southwesterly backing southeasterly, 3 or 4, occasionally 5 in Fisher at first, increasing 5 or 6 in Fisher later. Slight, increasing moderate in Fisher. Rain later. Moderate or good, occasionally poor later.

...

Ethernet is not designed for huge LANs. If you want that you need to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/

Hm:

"Our object is to design a communication system which can grow smoothly to accommodate several buildings full of personal computers and the facilities needed for their support."

Ethernet: Distributed Packet Switching for Local Computer Networks Robert M. Metcalfe and David R. Boggs Communications of the ACM Volume 19 Issue 7, July 1976

So let's change it slightly: Ethernet is not designed for huge broadcast domains. How big is huge? To some degree it depends on how broadcast "chatty" the protocols used are - but there's also the matter of having a size which makes it possible to troubleshoot. Personally I'd prefer an upper limit of a few hundred computers. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On Jun 15, 2011, at 10:21 AM, Valdis.Kletnieks@vt.edu wrote:

On Wed, 15 Jun 2011 19:04:44 +0200, sthaug@nethelp.no said:

...

How big is huge? To some degree it depends on how broadcast "chatty" the protocols used are - but there's also the matter of having a size which makes it possible to troubleshoot. Personally I'd prefer an upper limit of a few hundred computers.

And whatever you do, don't be like one med school and build a flat net so big that spanning tree won't converge. ;)

by the time you throw trill and vpls into the mix it may be a common or pseudo-common broadcast domain but it's not flat.

"Ethernet doesn't scale because of large amounts of broadcast traffic."

We started to introduce multicast, and multicast-aware switches in IPv4; in IPv6 there is no broadcast traffic. We won't be able to scale networks up until we can turn off IPv4,

In other words, probably not for another decade at least?

but once we can IPv6 will be able to grow much larger in terms of per-LAN. The best practice of no more than 512 per broadcast domain will seem very outdated at that point; especially when you add in multicast flood protection, the available bandwidth goes up, and performance of network interfaces improves.

Yes and no. If you remove the broadcast traffic you can *in theory* scale higher. However, this does nothing for the difficulty of L2 troubleshooting, which is a real problem in large flat L2 networks.

The link you pointed to is talking about flat networks of tens of thousands of hosts; that might be excessive right now... But I can certainly see an IPv6-only LAN (with some filtering to make sure ARP and IPv4 traffic is dropped at the port) scaling easily to thousands of hosts with today's hardware.

I'm afraid I remain sceptical, unless we come up with significantly improved methods for L2 troubleshooting. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Are you not using managed switches?

Certainly.

It takes me about 1 second to find exactly which device and which port a device is connected to. Once you know that; you have a pretty nice collection of statistics and log messages that usually tell you exactly what is wrong.

Here is where we differ. In my universe, finding which device and port has a particular MAC address is only a small part of L2 troubleshooting. In any case, I guess we'll find out in a decade or so how popular large flat L2 networks are going to be. Steinar Haug, Nethelp consulting, sthaug@nethelp.no

On Jun 15, 2011, at 8:52 AM, Iljitsch van Beijnum wrote:

On 15 jun 2011, at 16:52, Tony Finch wrote:

...

Ethernet is not designed for huge LANs. If you want that you need to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/

Hm:

"Our object is to design a communication system which can grow smoothly to accommodate several buildings full of personal computers and the facilities needed for their support."

Ethernet: Distributed Packet Switching for Local Computer Networks Robert M. Metcalfe and David R. Boggs Communications of the ACM Volume 19 Issue 7, July 1976

If you take that to mean that they intended to support all of that within a single ethernet broadcast domain, then, they most definitely failed. If you take that to mean that they intend it to be a technology which, with multiple ethernet segments, connected by routers, could scale to meet that goal, then, yes, they succeeded. Owen

On 14 jun 2011, at 10:20, Mikael Abrahamsson wrote:

On the AMSIX peering LAN there is more than 100pps of ND traffic (at least there was when we checked). Since they do not do IPv6 multicast intelligent handling (MLD snooping I guess) certain highend (legacy) router platforms run into trouble because all these packets are punted to RP.

That is really pathetic. I thought that any Ethernet chip built the previous decade could filter 64 or so multicast addresses in hardware. Only when you're subscribed to more multicast groups than what your Ethernet chip can filter in hardware does the software for an IPv4-only system have to encounter IPv6 multicasts, or an IPv6 system random neighbor solicitations, which are load balanced over a wide range of multicast addresses just for this reason. Also strange that there would be this much neighbor discovery traffic, probably the same reason AMS-IX used to have 15 kbps of ARP traffic: stale BGP peerings to addresses that no longer exist.

On Jun 14, 2011, at 1:30 PM, Ricky Beam wrote:

On Tue, 14 Jun 2011 04:00:22 -0400, Owen DeLong <owen@delong.com> wrote:

...

You would need an AWFUL lot of hosts for this to add up to a few 100pps (or even 10pps) of multicast traffic.

You're missing the point... most WAPs are horrible with multicast. It doesn't matter if it's v4 or v6, at L2, multicast is multicast.

At 100pps the WAP disappears from the network. "It's dead, Jim!" In many cases, a single multicast packet is enough to disrupt traffic flow as the AP stops to fire the multicast frame, individually, at each associated peer.

As others have pointed out, IPv6 uses multicast all over the place. DHCPv6 is just one of many sources.

All we're saying is DHCPv6 should be like DHCPv4... have a backoff period and eventually give up entirely. (yes, there are v4 agents that continue to try, i.e. restart every 5min, etc.)

Dude... I said that from the beginning. Point is that DHCPv6 isn't going to be the thing that pushes your AP over the edge. Owen

On Jun 12, 2011, at 4:04 AM, Iljitsch van Beijnum wrote:

On 12 jun 2011, at 12:35, Daniel Roesen wrote:

...

Could you point to any RFC which implies or explicitly states that DHCPv6 MUST NOT be used in absence of RA with M and/or O=1?

But what's the alternative? Always run DHCPv6 even if there are no router advertisements or router advertisements with O=0, M=0?

The alternative is as follows (can be done today without significant harm, only requires a couple of new DHCPv6 options and trivial changes to host DHCPv6 implementations): Interface is initialized. IPv6 is initialized on the interface. Interface builds link-local address. Link local DAD is performed (Failure: Shut down IPv6 on interface... Done.) Look for static configuration. If Found, Apply static configuration, end. Initialize Backoff Timer = 3 Initialize Tries = 0 LOOP A: Link Local->{All Routers,Link scope} Multicast ICMP RS packet is sent. Link Local->{All DHCP Servers, Link scope} Multicast DHCPv6 Solicit is sent Select(RA,DHCP while Backoff) Backoff*=1.5 if Backoff < 300 tries++ if (tries > 10 && !RA && !DHCP) Error, End repeat LOOP A if (!RA && !DHCP) if (RA) Process RA if (M || O) { if (DHCP) { Process DHCP as determined by {M,O} bits. End } LOOP B: DHCPv6 Solicit (as in Loop A) tries++ if (tries > 10 && !DHCP) Error, End repeat LOOP B if (!DHCP) process RA+DHCP according to M End } } if (DHCP) { # DHCP, but, no RA received LOOP C: Router Solicit (as in Loop A) tries++ repeat LOOP C if (tries < 5 && !RA) if (RA) { Process RA+DHCP according to {M,O} bits in RA. } else { Process DHCP as if RA received with no data and M bit } } }

Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance.

I don't see how the above would do so. It's mostly compatible with what we have today and it would take a very very large number of hosts (generally in excess of most switches forwarding table capacities) to contribute significant network pollution. Additionally, the multicast rate would only be increased on hosts which had no static configuration and the network had no functional RA and/or DHCP services.

And networks without RAs are very common. We call those networks "IPv4-only networks".

Fair point. However, even in such a scenario, I don't believe that the traffic provided above (up to 20 multicast packets provided over 422 seconds worst case) would constitute the kind of problem you are describing.

And in the current situation DHCPv6 without router advertisements is pointless because you may get an address, but you have no place to send your packets.

The point is that part of the solution needs to include adding routing information options to DHCPv6. That doesn't even require significant modification to the DHCP software, just definitions for new fields and a little bit of UI coding on the server and the ability to process the new options on the client. Owen

Iljitsch, On Jun 11, 2011, at 7:21 AM, Iljitsch van Beijnum wrote:

There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4.

As should be apparent by now, the vast majority of people don't want to move to IPv6. They simply want access to "the Internet". ISPs are looking for the easiest/cheapest way to do this, which generally means the way they've done it in the past. Forcing them to change simply slows things down. Regards, -drc

On Jun 11, 2011, at 7:21 AM, Iljitsch van Beijnum wrote:

On 11 jun 2011, at 4:03, Owen DeLong wrote:

...

You can call that bad network design if you want, but, there are real world requirements and scenarios where that has to happen for a variety of reasons.

...

Those networks have working configurations in DHCPv4 and no ability to move to IPv6 until this is solved.

Yeah, and they needed provider independent space to be able to move to IPv6, too. Didn't happen to a measurable degree either.

IPv6 PI has actually proven to be good and did result in a measurable increase in the IPv6 adoption rate among end-sites. Unfortunately, it's still not as well known as would be ideal. I still get a lot of enterprise administrators saying to me "How can I move to IPv6, I can't get PI space." Seems a lot of administrators don't pay close enough attention to know that policies changed several years ago.

There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4.

Agreed... However, that's not what this is.

Just because someone wants it doesn't make something a good idea. Especially because time and time again people take some underlying need, translate that in some technical "need" that is an extremely bad way to address that underlying need. So just giving people what they ask for invariably leads to sub-par results. Your doctor doesn't just give you the medicine you ask for either.

True. However, since a lot of people need it, it doesn't hurt anyone who isn't using it, and is relatively easy to implement, it is a good idea. I respect it's not your chosen solution. Your chosen solution is not the solution others think is the best. In fact, many people think that your chosen solution is an extremely bad way to address that underlying need. Giving people alternatives and letting them decide what is best for their network invariably leads to results. If the network administrator doesn't like the results and has other options, then, he is free to choose different options seeking better results. Failing to give the network administrator options invariably leads to sub-par results which may only be considered optimal by someone who isn't even familiar with the particular situation in question. As to my doctor and medicine, actually, my doctor knows that I have some medical background and we do discuss drug choices openly. I don't ask for things that don't make sense and my doctor has generally either convinced me that there is a better choice through an open discussion or has prescribed the drug I chose/requested. You are not talking about a doctor/patient scenario here where the doctor is an expert and the people asking for this have no medical training. Here, we are talking about requirements coming from network engineers that are every bit as skilled as you are in the field and every bit as capable of making informed decisions about the correct solution for their environment. The difference is that they are not trying to tell you that you can't have the solution you want, they're merely trying to also have the ability to choose a different solution. Choice never leads to sub-par solutions. It invariably leads to the solution most favored by the people making the choices.

Yes, I know this carries an implicit accusation of stupidity. I can live with that, and I'm not impressed if people are offended. (You get used to that surprisingly quickly.)

Yes, I'm well familiar with your level of arrogance. I'm not impressed by that any more than you are impressed by people being offended when you call them stupid.

...

...

I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems.

...

I see no reason that additional DHCPv6 options would have to fragment the installed base or perpetuate the lack of agreed upon DHCPv6 behavior.

Risks are in the eye of the beholder. I'm sure the financial sector didn't see any problems coming their way in 2007 either. I'm sure I sometimes see problems that never materialize. Still better safe than sorry. Especially because this is all nonsense in the margin that we can all very easily live without. What are we talking about here? One RA message every 200 seconds? Is that so bad?

You're still railing on the idea that the goal here is to eliminate the RA message. That's simply not the case. The goal here is to deal with the fact that host administration is NOT the purview of people who run routers and people who run hosts do NOT want the network guys configuring their hosts. This is about administrative boundaries and the ability for the correct group within a company to have the correct policy controls over their pieces of the puzzle. If they could make the hosts flat-out ignore the RA, they could (for the most part) care less about the RA being there or not. The goal is to eliminate the ability of those whack-jobs that run the network to dictate the fate of the host administration team. (Yes, I realize that I just implicitly called you a whack-job, but, realize that I'm part of the networking team, too, so, we're both whack-jobs in the eyes of the system administrators. You get used to that surprisingly quickly as well.)

...

...

People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate.

...

There were a lot of people who tried to "show up" at the IETF 10 years ago and talk about this stuff from an operational perspective. They were basically told that operators don't know what they want and they should shut up and go away and let real men do the work.

So what has changed now? Is it helpful to take that advice for 10 years and THEN revisit the issue?

Yes, because now the issue is more pressing and more important to more administrators. 10 years ago, it was a fight over something that might become relevant later. Today, it's a fight over something that matters today or maybe tomorrow at the latest.

BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like).

Good for you. Did you try proposing anything that was contrary to the current religion at the time or did you join the ivory tower biggots in supporting solutions that work better in theory than in operational reality and embrace their bold new failure to address major concerns (such as scalable routing) while focusing on irrelevant minutiae such as 8+8 vs. GSE? If you just went to drink the Kool-aid, I'm sure you didn't encounter that attitude. OTOH, if you told them you didn't like their Kool-aid and proposed a new flavor, your results would probably have been closer to mine.

...

Personally, I'd rather not have administrators rejecting IPv6 and it seems to me that adding routing information options to DHCPv6 is a light-weight action that is already possible within the existing protocol specification (just need to assign option numbers and attribute/value formats) and makes IPv6 a whole lot more palatable to a rather large number of administrators.

Assuming facts not in evidence.

Not really. I talk to a lot of enterprise administrators in my job and this is a pretty universal issue.

There is a small group of people that is never happy. Give them more, they remain unhappy. The adagium "don't feed the trolls" applies to them.

While that is true, I don't think it is an accurate portrayal of the situation in this case. For one thing, if you analyze it carefully, you see that they aren't asking for more. They are merely asking for the functionality and capabilities that they already have to be made available in what they are being told is their next protocol whether they like it or not.

...

...

It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this.

...

How does this make your life worse? If it's not your network, why do you care?

Because it allows one more configuration that works for some stuff and not other stuff. I get around enough that I'll encounter such a configuration at some point.

I have no sympathy for you here. If you choose to be a consultant, then, you knew the job was dangerous when you took it. If it wasn't this, it would be something else. That's the nature of the job. If we consider the protocol to be set in stone, it will never advance and you have taken a giant step backwards from the very things that made IPv4 successful. Look at the number of serious changes that have happened to IPv4 since IPv6 was first published.

...

As to fragmentation of the installed base, I don't see how adding a couple of options to DHCPv6 creates fragmentation. It adds functionality that people can use.

No, it add functionality that allows administrators to remove functionality but that only works if there are no systems that don't have the first functionality and hence can do without the second functionality. It'll take years for operating systems to catch up, and all of that just to fix something that isn't broken in the first place.

Since the administrator knows his network, it's up to the administrator to make that determination. Obviously this would not be a good solution for $RANDOM_COFFEESHOP_WIFI. OTOH, for an enterprise with a relatively homogenous set of host requirements (and most enterprises do actually have this in order to reduce their administrative costs), that's not an issue. It doesn't remove functionality. It provides the same functions (and a few more) in a different manner. The fact that you don't like that particular manner is irrelevant to the discussion, nobody is asking you to use it. Remember, I'm not proposing that we just add default-route to DHCP. I'm proposing routing information. This would include functionality that would allow multiple specific static routes to be defined, for example.

(Remember, not talking about rogue RAs!)

Neither am I. We already agree that RA-Guard is the better solution to that problem.

...

Because in some cases, the HOST administrator is not the NETWORK administrator and cannot necessarily control how the administrator of a given router does things. In some cases, this means that the HOST administrator wants his hosts to act in a manner that is not consistent with what the administrator of certain network devices wants to tell other hosts on the same link to do.

Again, why NOW?

Because NOW IPv6 is starting to become an operational discussion that matters to administrators rather than a theoretical discussion that matters to a bunch of people in an ivory tower somewhere where they hopefully can't do too much harm to the operational network.

We are just getting to the point where DHCPv6 can actually be used. Quit while you're ahead.

The fact that this was such a battle is testament to the ivory-tower failure of the IETF and the dysfunction of allowing decisions to be made without input from the operational community who is generally too busy keeping the present working to spend a lot of time debating the (presently) irrelevant minutiae of possible futures.

And fixing protocols to make them work even in the face of explicit misconfiguration is a road that leads nowhere quickly.

Huh? That's not what anyone is discussing here.

...

...

A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments.

...

Shouldn't happen. First, if some form of back-off isn't built into DHCPv6, that should be fixed.

Right, first we break, then we fix. Job security all around!

If DHCP doesn't back off, it's already broken. The fact that this breakage would only affect networks with the M bit set presently where it would break more universally under my proposal does not make it less broken.

...

Second, if your network doesn't have any RAs and your DHCP server isn't answering, it really doesn't matter that it gets clogged up because nothing is working anyway.

Oh right, IPv4 only networks aren't considered to be "working" these days.

IPv4 networks don't work if the DHCP server doesn't answer unless the network is statically configured. IPv4 DHCP _DOES_ have a backoff built in to the protocol. If your IPv6 network is statically configured, then it won't have a bunch of hosts trying DHCPv6. I'm not sure I see the relevance of your statement there. Owen

On 11 jun 2011, at 17:05, Owen DeLong wrote:

...

Your doctor doesn't just give you the medicine you ask for either.

You are not talking about a doctor/patient scenario here where the doctor is an expert and the people asking for this have no medical training. Here, we are talking about requirements coming from network engineers that are every bit as skilled as you are in the field and every bit as capable of making informed decisions about the correct solution for their environment.

It's true that the patient also knows some stuff here. There's a lot of bitching here on the NANOG list about how operators get no respect at the IETF. But that's a two-way street. There's also tons of people in operations who have no appreciation to what the IETF brings to the table. Operators tend to see issues in isolation, or at the very least only see the connections that are relevant to their environment. The IETF has to take into consideration all possible environments. Sometimes things that seem a clear win in a constrained environment could be a disaster if they were used all over the internet. You know what they say: a doctor who treats himself has a fool for a patient.

Yes, I'm well familiar with your level of arrogance.

Yes, I know I stick out like a sore thumb in these humble parts.

...

BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like).

Good for you. Did you try proposing anything that was contrary to the current religion at the time or did you join the ivory tower biggots in supporting solutions that work better in theory than in operational reality and embrace their bold new failure to address major concerns (such as scalable routing) while focusing on irrelevant minutiae such as 8+8 vs. GSE?

Judge for yourself: http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt Let me wrap up this discussion with the following: IPv6 address configuration is a house of cards. Touch it and it all comes crashing down. DHCPv6 has a number of significant flaws, and the interaction between DHCPv6 and router advertisements only barely makes sense. All of this makes it seem like a good idea to tweak stuff to make it better, but in reality that's a mistake: it just means more opportunities for things to fail. What we need is to rethink the host configuration problem from the ground up, starting at the host and what it should do when it sees its interface come up. One model that seems attractive here is the on the iPhone uses, where you can modify the IP configuration on a per-wifi network basis. If we can apply this kind of logic to wired networks, too, then suddenly we're no longer limited to having one monolithic set of client side behavior that must always be followed, but we can be much more flexible.

On Jun 12, 2011, at 4:01 AM, Iljitsch van Beijnum wrote:

On 11 jun 2011, at 17:05, Owen DeLong wrote:

...

...

Your doctor doesn't just give you the medicine you ask for either.

...

You are not talking about a doctor/patient scenario here where the doctor is an expert and the people asking for this have no medical training. Here, we are talking about requirements coming from network engineers that are every bit as skilled as you are in the field and every bit as capable of making informed decisions about the correct solution for their environment.

It's true that the patient also knows some stuff here.

There's a lot of bitching here on the NANOG list about how operators get no respect at the IETF. But that's a two-way street. There's also tons of people in operations who have no appreciation to what the IETF brings to the table.

Operators tend to see issues in isolation, or at the very least only see the connections that are relevant to their environment. The IETF has to take into consideration all possible environments. Sometimes things that seem a clear win in a constrained environment could be a disaster if they were used all over the internet.

Sure, but, doing that for something that is only locally significant, such as RA/DHCP means that you should implement a true superset of the operational requirements so that operators can choose the tools that best fit their environment, rather than a rag tag set of incomplete tools that require operators to implement ALL of them in order to form a single complete solution and offer no flexibility on which set of solutions is chosen. Guess which one more accurately describes the current state of RA/DHCPv6 from an operator perspective?

You know what they say: a doctor who treats himself has a fool for a patient.

Yes, but, a doctor who accepts the word of another doctor without doing his own analysis is unlikely to be a patient for very long. Death has a way of terminating doctor patient relationships.

...

Yes, I'm well familiar with your level of arrogance.

Yes, I know I stick out like a sore thumb in these humble parts.

OK... Point taken. However...

...

...

BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like).

...

Good for you. Did you try proposing anything that was contrary to the current religion at the time or did you join the ivory tower biggots in supporting solutions that work better in theory than in operational reality and embrace their bold new failure to address major concerns (such as scalable routing) while focusing on irrelevant minutiae such as 8+8 vs. GSE?

Judge for yourself:

http://www.muada.com/drafts/draft-van-beijnum-multi6-isp-int-aggr-01.txt

I'm sure that got reasonably well shouted down, but, it's close enough to a few pieces of IETF dogma that I suspect it probably didn't result in "fool, go home" style comments from too many places.

Let me wrap up this discussion with the following:

IPv6 address configuration is a house of cards. Touch it and it all comes crashing down. DHCPv6 has a number of significant flaws, and the interaction between DHCPv6 and router advertisements only barely makes sense. All of this makes it seem like a good idea to tweak stuff to make it better, but in reality that's a mistake: it just means more opportunities for things to fail. What we need is to rethink the host configuration problem from the ground up, starting at the host and what it should do when it sees its interface come up.

I'm fine with that latter idea and it may well yield a better solution. However, in the operational world, we cannot wait for that and what we have today is not sufficiently adequate to meet real world requirements as they exist today. As such, we MUST modify what we have today in ways that extend it to have the capabilities that are required. I understand you find this distasteful. I even understand some of your reasons. I even agree with some of them. However, we do not have the option if we are to make IPv6 deployable in the enterprise of ignoring these requirements. These aren't situations that have existing workarounds and the administrators are simply opposed to doing things differently. These are situations where the fundamental operation of the network cannot be accomplished under IPv6 within the current organizational requirements. Asking organizations to restructure their networks is one thing. Asking them to also reorganize their organizational politics around that network restructuring is, well, "recipe for fail" seems like an understatement.

One model that seems attractive here is the on the iPhone uses, where you can modify the IP configuration on a per-wifi network basis. If we can apply this kind of logic to wired networks, too, then suddenly we're no longer limited to having one monolithic set of client side behavior that must always be followed, but we can be much more flexible.

The real goal should be to have a way (or ways) for hosts to operate across a wide variety of environments with zeroconf. Having to build profiles for different networks is a great workaround for failures in that effort, but, it is not what I would call a good solution to the problem in general. Owen

On Jun 10, 2011, at 7:03 PM, Owen DeLong wrote:

I see no reason that additional DHCPv6 options would have to fragment the installed base or perpetuate the lack of agreed upon DHCPv6 behavior. In fact, I think that adding these options could allow for a set of rules that would be acceptable to all and would allow administrators to make choices based on the needs of their environments.

Indeed, and agreed. I've got a number of large, multi-national enterprise customers who are in this very situation, they need the options because they're trying to get away from a lot of nasty, inherited, legacy configurations. The only way they can safely migrate from those is if we (well, IETF, via RFC, and then vendors) provide them the options to be flexible. This thread is somewhat like the DLV/DNSSEC thread on dns-operations. Some are arguing DLV should die, but frankly it's giving operators options to *migrate* to DNSSEC rather than making forklift changes in their networks. I'd simply like to see the option of doing RA, or not, or DHCP with option.routers, etc.

...

People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate.

There were a lot of people who tried to "show up" at the IETF 10 years ago and talk about this stuff from an operational perspective. They were basically told that operators don't know what they want and they should shut up and go away and let real men do the work.

Indeed, again. I stopped going to IETF (for good or ill) in 1997 or so, but still following the mailing lists. I haven't been since, but sounds like this is still the status quo. -b

RA is fine for residential use, its enterprises and institutions that would benefit most from a route option with DHCPv6. Frank -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Friday, June 10, 2011 9:48 AM To: Ray Soucy; Iljitsch van Beijnum Cc: nanog@nanog.org Subject: Re: The stupidity of trying to "fix" DHCPv6 <snip> I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

On Fri, Jun 10, 2011 at 10:51 AM, Owen DeLong <owen@delong.com> wrote:

Seems to me that adding a routing information option to DHCPv6 solves the problem without breaking the legacy hosts.

What's wrong with that idea?

Owen

Thank you, Owen. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Fri, 10 Jun 2011 09:47:44 -0400, Leo Bicknell <bicknell@ufp.org> wrote:

The point is, RA's are operationally fragile and DHCP is operationally robust.

No. Both are just as fragile... if you haven't taken steps to protect them. If you aren't doing any sort of DHCP snooping, anyone can setup a rogue DHCP server and kill your network -- been there, laughed at them. Even my *home* lan has DHCP snooping configured. The only question is support for "RA Guard" in your network hardware. A lot of old gear isn't going to support it. But DHCP was no different. --Ricky PS: Don't read into this... I hate SLAAC and RA, more than most people. (it's been a bad idea from day one.)

On Fri, Jun 10, 2011 at 2:21 PM, Steve Clark <sclark@netwolves.com> wrote:

On 06/10/2011 09:37 AM, Ray Soucy wrote:

...

You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you?

You are the moron - this stuff happens and wishing it didn't doesn't stop it. Get a clue!

No matter how much stupidity you try account for, there is infinitely more to come.

Wow, I don't recall making it personal? I have broken networks before by connecting miss-configured devices, by the way, and I was a moron for doing so. I don't base my network design decisions around preventing people with full access to configure the network breaking it; but rather restrict the level of access people have and impingement sane policies on when and how changes are made; like most of the people on this list. The point was you shouldn't base protocol design around the possibility that someone might tell it to do something you don't want it to do; otherwise you'll end up with a one-size-fits-all protocol that has zero flexibility (and might not even be functional at all). Similar problems existed in IPv4; but over time networks evolved and better protection methods became available. The days of the dumb switch are over; and at the price and performance of today's switches we should expect features like RA guard and MLD snooping to be standard. We threw out Ethernet hubs a decade or two ago for good reason, and there was resistance then too. On a side note, if you're going to resort to direct personal attacks, maybe you shouldn't be doing so while representing your company. Everything on NANOG is archived and sticks around for a very, very long time. Ray On Fri, Jun 10, 2011 at 3:21 PM, Steve Clark <sclark@netwolves.com> wrote:

On 06/10/2011 09:37 AM, Ray Soucy wrote:

You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you?

You are the moron - this stuff happens and wishing it didn't doesn't stop it. Get a clue!

Honestly. This whole argument is getting ridiculous.

On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknell <bicknell@ufp.org> wrote:

In a message written on Fri, Jun 10, 2011 at 01:03:01PM +0000, Bjoern A. Zeeb wrote:

On Jun 10, 2011, at 10:10 AM, sthaug@nethelp.no wrote:

Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid.

I wonder if it's just a "violation" of rule #1: stop thinking legacy!

People are used to what they have done for a decade or two.  It's hard to see the change and results in "why is this all so different and complicated?". It's hard to open ones mind for the new, but it is essential to do with new technology.

The problem in this case is that the failure modes are significantly different.  Some folks have learned this the hard way.

It's a very easy scenario to reconstruct.  Consider the "branch office router" in a typical corporate enviornment.  We're talking a device with one WAN port, and one LAN port.  Configure it for dual stack, speaking IPv4, and in IPv4 configure it the typical corporate way with a "DHCP Helper" forwarding requests over the WAN to a central DHCP server.  In IPv6, configure it with RA's, the supposed "better" way.

Now, take the 100% working branch router and have it sent back to corporate.  Maybe they got a bigger router, maybe the office closed. A network engineer gets the router and is tasked with making it ready to redeploy.

The network engineer plugs it into the switch on his desktop, plugs in a serial cable, turns it on and steps out to get a coffee while it boots. He's planning to erase the configuration and then load new software over the network.

As soon as the router boots the IPv6 network fails for all the users on his subnet.  IPv4 keeps working fine.

Oops.

What happened?  Well, the router sent IPv6 RA's as soon as it came up, and every workstation instantly started using them.  In IPv4, the router received DHCPv4 requests and forwarded them per the helper address, except that its WAN port is down, and thus it in fact didn't send them anywhere.

The important points:

- IPv4 "failed safe" with the DHCP config.  This "rogue device" will  never disrupt the IPv4 configuration.  DHCP snooping isn't even needed  in your switches, since it never returns a response.

- IPv6 "failed immediately" with the RA configuration.  What's worse is  if you simply turn the device off after you realized you took down the  entire network devices will continue to be broken for 2-4 hours until  the RA's time out.  The only method to mitigate is to deploy RA guard  on all of your switches, which probably means replacing 100% of your  hardware with new stuff that can do that, and then deploying new  features.

The fact of the matter is that the failure modes of these two protocols are vastly different operationally.  The DHCP failure semantics are not only better understood, but cause less disruption to the network.  Even a properly rouge DHCP server will only damage _new_ clients coming up on a network, existing folks will work just fine.  Contrast with RA's which instantly break 100% of the users.

Even more annoying is that if I use RA's for the default gateway, I still have to run DHCPv6 anyway.  If I don't my boxes don't have DNS servers, NTP servers, know where to tftpboot, etc.  It's not a choice of one or the other, it's I always run DHCPv6, do I need RA's or not.

Given the failure modes I would much prefer to run with RA's turned off completely, and have DHCPv6 able to provide a default gateway just as it works in IPv4.

My opinion comes not from "thinking legacy", indeed my employer has been fully dual stacked since 2003.  My opinion comes from the fact that in the 8 years of operational experience we have RA's are significantly more fragile, and IMHO not ready for widespread IPv6 deployment.

--       Leo Bicknell - bicknell@ufp.org - CCIE 3440        PGP keys at http://www.ufp.org/~bicknell/

-- Stephen Clark NetWolves Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.clark@netwolves.com http://www.netwolves.com

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

The energy in this thread should be focused on switch vendors to actually implement L2 security features for IPv6, which is usually an easy upgrade; rather than calling for all host implementations of IPv6 to work differently; which will take a decade to implement and be a band-aid at best; not a good long-term design for the protocol. I think that was the original spirit of this thread. Full static assignment is always an option if you don't want to use RA or DHCPv6. Presenting suggestions in the form of an RFC draft would be more useful than ranting about it for the 100th time on-list. At least then you could point to something that can actually be worked on constructively; rather than a lot of straw-man arguments because you don't personally like the way things are currently done. If you get a bad DHCP server on the network it can take hours to undo the damage thanks to lease times; if you get bad RA you can usually fix the problem as soon as you find it. Apples and Oranges, really. If connecting the rogue DHCP server doesn't obviously break things when connected, you might not even notice it until it's too late. More responsive to change is better in my opinion. I hate having to wait hours or days for changes to propagate; it feels like the 1990s, or the days of mainframes and batch jobs. On Tue, Jun 14, 2011 at 12:15 PM, Nick Hilliard <nick@foobar.org> wrote:

On 14/06/2011 16:12, Ray Soucy wrote:

...

The point was you shouldn't base protocol design around the possibility that someone might tell it to do something you don't want it to do; otherwise you'll end up with a one-size-fits-all protocol that has zero flexibility (and might not even be functional at all).

sensible engineering dictates that design should aim to be fail-safe.  I.e. not "failsafe" in the common usage of the term (= doesn't fail), but rather cogniscent of the fact that all systems fail from time to time, and when they do, they ought to fail in such a way that the collateral damage is minimised.  This principal is recodified in various ways ("be liberal in what you accept", etc), but the underlying idea is the same.

In IPv6-land, we appear not to have learned the lessons from ipv4 history, and our vendors aren't yet shipping switches with native RA- and DHCPv6- guard (yes, there are some exceptions to the former).

Nick

-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:

Then use RA and move on. However, please understand that yours is not the only environment and that there are real-world scenarios where having the router-guys dictate the host configuration is considered unacceptable at best.

This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying. -Ben

On Jun 14, 2011, at 11:14 AM, Ray Soucy wrote:

...

On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote: What is needed is:

- Native RA Guard in switches - Native DHCPv6 Snooping in switches - Native RA Guard in WAPs - Native DHCPv6 Snooping in WAPs - Additional options to DHCPv6 for Routing Information - Eventual changes to host DHCPv6 Client behavior so that DHCP does occur when RA not present.

Agree 100%

Especially with the last one; DHCPv6 clients shouldn't even be started unless they see the M flag set; but that's an implementation challenge.

That's the current broken behavior. The goal is to correct that problem.

Would probably include something analogous to ARP inspection for neighbor discovery; and that router implementations are modified so that once full, the neighbor table won't throw out known associations in favor of unknown associations to mitigate the denial of service attack vector present when using 64-bit prefixes. Perhaps DAD flooding protection too. It's a "new" protocol, so it will take a while for all these things to be worked out and become standard.

That would also likely be good, but, I don't think that requires IETF effort.

On Tue, Jun 14, 2011 at 2:00 PM, Ben Jencks <ben@bjencks.net> wrote:

...

This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying.

And This.

Really, people make way too big a deal about RA, and I think most of it comes from the lack of vendor support for filtering of rouge RA and the fact that Windows ICS happily sends them out.

No, that is not the only place it comes from. There are real world networks that don't have a good solution with RA because RA assumes that link==subnet and that simply isn't true in all cases.

I still blame vendors; this design has been known for a long time now and they still haven't come up to speed, in part because people spend their time complaining on NANOG instead of to their sales rep.

Believe me, I've done both. Owen

-- Ray Soucy

Epic Communications Specialist

Phone: +1 (207) 561-3526

Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/

On Jun 14, 2011, at 4:25 PM, Leo Bicknell wrote:

In a message written on Tue, Jun 14, 2011 at 02:00:35PM -0400, Ben Jencks wrote:

...

This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying.

[snipped long explanation that you do in fact need DNS servers]

So just like in IPv4, IPv6 requires DHCP to have a functioning end user box. DHCP remains a hard requirement. The odd part now is that in IPv4 DHCP carries the default gateway, while in IPv6 land you must also run Router Advertisements on your router and have the host listen to them.

The industry has taken a robust single protocol solution and turned it into a dual, co-dependent protocol situation.

I'm just not seeing how this actually adds more configuration overhead. Rather than looking at a protocol count, try looking at the number of actual items you need to configure and where they get configured. This is actually *smaller* in IPv6, because the DHCPv6 server doesn't need to know what the default gateways are anymore (I have no problem with a routing information option, but that's optional, not *needed*). The fact that the information is distributed over different protocols seems to make a lot of people really pissed off, but seems ancillary to the actual issues of what information is configured where and what options are available.

The IETF is working on one solution, which is to add DNS information to the RA's! So now you'll configure your routers to hand out DNS servers to clients, and then everything else (NTP servers, Domain Controllers, etc) in DHCP!

I agree, that's never seemed like a good idea.

What I and others are suggesting is the other way around, how about we just put a default route in DHCPv6 like we did in v4, and forget all about RA's so we're back to a single protocol solution?

Beyond that it is important to notice that the failure modes and attack vectors for RA's and DHCP are different. I argue DHCP is "better", but I also realize that's a very subjective judgment. That said, there are cases where people may prefer DHCP's robustness and/or failure modes, and cases where people might prefer RA's.

There are differences in failure modes, but I'd argue that's not enough justification to fragment the configuration options. If there are two overlapping ways to configure things, then I'd bet that all but the most mainstream or high-end implementations will have poor support for at least one. That was the one you chose? Too bad, you have to support both now. So much for the "operator choice" you keep arguing for.

Lastly, there's a hidden bit here many people haven't dealt with yet in lab networks. In IPv4 critical environments it's typical to use HSRP or VRRP to provide a single gateway across two routers. The IPv6 way to do this is to have both advertise RA's, possibly with different priorities.

Erm, I thought the IPv6 way to do it was to use IPv6 VRRP... I've heard of some vendor bugs on it, but it's implemented. Multiple routers sending RAs can be useful, but not for the same kind of HA that VRRP is designed for. -Ben

On 06/14/2011 03:25 PM, Leo Bicknell wrote:

I urge everyone in this thread to try a simple experiment. Configure an IPv6 segment in your lab. Make sure there is no IPv4 on it, not on the router, and that the IPv4 stack (to the extent possible) is disabled on the hosts. Now try to use one of the hosts to access IPv6 content.

Been there, done that, fairly happily -- with both Windows 7 and Linux (Fedora 13 or 14, I forget).

You'll find the box does SLAAC just fine and gets an address. You'll find RA's provide a default gateway and can get your packets out to the world. You'll also find absolutely nothing works, at a bare minimum because you have no DNS servers.

Err, no, that's not universally true. The version of NetworkManager in recent-ish Fedora and Ubuntu (can't attest to other distros) supports the RDNSS field in RAs (available in radvd since 1.0, ~2006-11-01). You do need to explicitly disable IPv4 in NM, however, or it'll consider the lack of DHCPv4 to be a general network failure. RHEL 5 won't work without manually configuring a DNS address; everything I've heard indicates that RHEL 6 supports RDNSS, however. Windows 7 is a bit of an odd duck; without any defined DNS servers it defaults to the following (deprecated) site-local addresses: fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 Adding a route/config for those on your actual DNS server(s) allows Windows to get working DNS, as well. (I don't recall if I had to explicitly disable IPv4 to get IPv6-only working, though.) I will agree that Windows XP is more or less dead in the water in your defined scenario (I've heard you can shoehorn IPv6 DNS servers into its config, but it's not trivial; I haven't confirmed this); I haven't tested Vista but I believe its behavior is probably closer to 7 than XP.

The IETF is working on one solution, which is to add DNS information to the RA's! So now you'll configure your routers to hand out DNS servers to clients, and then everything else (NTP servers, Domain Controllers, etc) in DHCP!

Oh, oops; you did touch upon this. You might want to let the people who've implemented RDNSS in software know that the IETF is working on it. I'm sure that'll be a relief. Jima

On 15 jun 2011, at 18:39, Leo Bicknell wrote:

Maybe I'm missing something, but the last update on this was RFC 5006 I think, which is marked as "experimental", and I thought the IETF still had a working group discussing it.

You missed the upgrade to proposed standard: http://tools.ietf.org/html/rfc6106

That is, I didn't think it was a finalized standard yet.

The IETF rarely gets around to bringing something from proposed standard to standard. For instance, HTTP and BGP aren't standards either.

On Jun 15, 2011, at 9:39 AM, Leo Bicknell wrote:

In a message written on Wed, Jun 15, 2011 at 10:22:12AM -0500, Jima wrote:

...

Oh, oops; you did touch upon this. You might want to let the people who've implemented RDNSS in software know that the IETF is working on it. I'm sure that'll be a relief.

Maybe I'm missing something, but the last update on this was RFC 5006 I think, which is marked as "experimental", and I thought the IETF still had a working group discussing it.

That is, I didn't think it was a finalized standard yet.

-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

Many of the most widely used technologies on the internet do not become finalized standards at the IETF level until long after they have been in widespread use. Owen

On Jun 14, 2011, at 11:00 AM, Ben Jencks wrote:

On Jun 14, 2011, at 1:41 PM, Owen DeLong wrote:

...

Then use RA and move on. However, please understand that yours is not the only environment and that there are real-world scenarios where having the router-guys dictate the host configuration is considered unacceptable at best.

This has always confused me. What aspect of host configuration is the router providing that's so problematic? The prefix, which has to match on the router and host in order for anything to work anyway? The indication to go use DHCPv6, which doesn't really add anything since you need to configure a DHCPv6 proxy anyway? There's just so little information in an RA, and the router needs to know it all anyway, that I'm having trouble understanding what environment would find this so horrifying.

-Ben

Imagine this scenario... [RA] [RB] [RC] [RD] | | | | [-+---+---+---+---+----+---+---+---+---+---+---+---+---+---+-] | | | | | | | | | | | [AR] [AP] [ACCTG] [D1] | [D2] | [D3] | [W1] [W2] [L1] [R1] AR is Accts Receivable AP is Accts Payable ACCTG is the Accts server D1-D3 are developer workstations. W1-W2 are internal application web servers L1 is the lobby computer (badging kiosk) R1 is the Receptionist. RA, RB are routers which are run by IT and connect off to the IT subnets in the main building. RC, RD are routers which are run by the DEV group and connect off to the DEV group subnets in the main building. See... This is an oversimplification, but, these things happen in the real world. The desire is for the AR/AP/ACCTG/L1/R1 hosts to use the RA/RB prefixes and default gateways. Currently that's done by the DHCP server knowing which MAC addresses to expect for those systems. Everything else gets shunted to the DEV network. Yes, the right solution would be to at least separate the VLANs and clean up this mess. However, due to software packages that need to talk to each other over common local broadcast across that boundary, this isn't possible in this particular organization (don't get me started on the bad software, but, that's what there is.) There are large varieties of other situations where having the router supply prefix and default gateway information on the theory that all routers on a link are created equal and anyone on a link may use any router (priority doesn't help here because the goal is to have different hosts use different sets of gateways). Which prefix does "the prefix" have to match? How, using RA, do you assign the RC/RD prefix(es) to the D1-D3 hosts and the RA/RB prefix(es) to everything else (or vice versa)? Sometimes link != subnet. Owen

On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

BTW, does this broken software run over IPv6, anyway?

Poorly designed network plus poorly designed software... I don't know which chicken came first, and it doesn't matter. IPv6 is totally different barnyard. Build the v6 network properly -- one gateway (one router, vrrp, whatever) -- and retool the software properly. IPv6 doesn't have a broadcast address; as such if the software is setup to use an appropriate multicast target (presumably in "user defined" space), then it'll talk to exactly the right machines, and it's routable. --Ricky

On Jun 14, 2011, at 6:00 PM, Ricky Beam wrote:

On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum <iljitsch@muada.com> wrote:

...

BTW, does this broken software run over IPv6, anyway?

Poorly designed network plus poorly designed software... I don't know which chicken came first, and it doesn't matter.

IPv6 is totally different barnyard. Build the v6 network properly -- one gateway (one router, vrrp, whatever) -- and retool the software properly. IPv6 doesn't have a broadcast address; as such if the software is setup to use an appropriate multicast target (presumably in "user defined" space), then it'll talk to exactly the right machines, and it's routable.

--Ricky

Sounds great, but, sometimes proprietary vertical software is a lot harder to move forward than you might think. Owen