Re: The stupidity of trying to "fix" DHCPv6
In message , Owen DeLong write s: > > 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 - bickn...@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 But very few are "experimental" and stay that way. Many stay at "proposed standard". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The stupidity of trying to "fix" DHCPv6
On Jun 15, 2011, at 10:21 AM, valdis.kletni...@vt.edu wrote: > On Wed, 15 Jun 2011 19:04:44 +0200, sth...@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.
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 10:56 PM, Iljitsch van Beijnum wrote: > On 15 jun 2011, at 7:33, Owen DeLong wrote: > >> Bottom line, I expect it's easier to get cooperation from OS vendors and >> BIOS vendors to make changes >> because experience has shown that they are more willing to do so than >> vertical software vendors. > >> As such, yes, I'd like to see some harmless extensions added to DHCPv6 that >> solve some real world >> problems. > > BTW, as long as you're making harmless changes: not putting a hard line end > just _after_ 80 characters would make your messages easier to read. > OK... Line endings removed per your request. > As established before, all of this is not harmless and OS vendors (not sure > what you're talking about with BIOS) aren't all that willing to make changes, > at least not on short timescales. > It is harmless. Adding routing information options to DHCPv6 does not in any way harm existing implementations. Adding the ability to simultaneously request DHCP information and RA is a tiny amount of additional traffic on the network (thus also harmless). When I talk about BIOS, I'm taking into account that some DHCP implementations are in the PXE for diskless booting and installation processes, etc. Admittedly, I'm not sure how many BIOS contain IPv6 capability for this as yet anyway, but, it is an area that must eventually get implemented. > It seems to me that the easiest solution to work around broken IPv4-only > software isn't messing with the IPv6 protocol stack, but to create an IPv4 > overlay on top of IPv6 that seems like a big IPv4 broadcast domain despite > going through IPv6 routers. > I'm not sure how you propose creating an IPv4 broadcast domain that isn't an iPv6 link. I mean the theory sounds great, but, in practice, it seems rather far-fetched. > Actually this would also be quite useful in hosting environments where it > would be easy to give every IPv6 customer their own VLAN but the IPv4 subnets > are entangled. Indeed, if it were even remotely possible. Owen
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
> 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, sth...@nethelp.no
Re: The stupidity of trying to "fix" DHCPv6
Are you not using managed switches? 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. Or am I missing something? On Thu, Jun 16, 2011 at 2:37 PM, wrote: >> "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, sth...@nethelp.no > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: The stupidity of trying to "fix" DHCPv6
> "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, sth...@nethelp.no
Re: The stupidity of trying to "fix" DHCPv6
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 - bickn...@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
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
The beauty of Ethernet is that it's simple. "Ethernet" has evolved considerably, and continues to do so. It's not really fair to make comments about it's sociability and talk about it as if it were still in the state it was 20 years ago: "Ethernet doesn't scale because of collisions and exponential backoff" We got around large collision domains by replacing hubs with switches, effectively shrinking the collision domain to the link between the host and the switch (and only in half-duplex). "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, 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. 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 know the post is a little off topic; but as someone who's met Metcalfe several times I think it's only fair to not make Ethernet out to be the only thing preventing scaleability of networks. On Wed, Jun 15, 2011 at 1:04 PM, 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 > > 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, sth...@nethelp.no > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: The stupidity of trying to "fix" DHCPv6
On Wed, 2011-06-15 at 17:52 +0200, Iljitsch van Beijnum wrote: > "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 To be fair, though, the concept of "large LAN" might have changed a little since 1976... and "buildings full" is not exactly a precise unit of measurement. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 signature.asc Description: This is a digitally signed message part
Re: The stupidity of trying to "fix" DHCPv6
On 06/15/2011 11:45 AM, Iljitsch van Beijnum wrote: 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. Thanks for the citation, right. I also probably should also have cited http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_in_operating_systems -- the notable holdouts to RDNSS (that support DHCPv6) seem to be Windows, Solaris, AIX, and IBM i. Unfortunate. Jima
Re: The stupidity of trying to "fix" DHCPv6
On Wed, 15 Jun 2011 19:04:44 +0200, sth...@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. ;) pgp8F9sViVLs1.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
> > 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, sth...@nethelp.no
Re: The stupidity of trying to "fix" DHCPv6
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.
Re: The stupidity of trying to "fix" DHCPv6
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpfwvpmkFsSV.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
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:::1%1 fec0:0:0:::2%1 fec0:0:0:::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
Re: The stupidity of trying to "fix" DHCPv6
Ricky Beam 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.finchhttp://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.
Re: The stupidity of trying to "fix" DHCPv6
On 15 jun 2011, at 7:33, Owen DeLong wrote: > Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS > vendors to make changes > because experience has shown that they are more willing to do so than > vertical software vendors. > As such, yes, I'd like to see some harmless extensions added to DHCPv6 that > solve some real world > problems. BTW, as long as you're making harmless changes: not putting a hard line end just _after_ 80 characters would make your messages easier to read. As established before, all of this is not harmless and OS vendors (not sure what you're talking about with BIOS) aren't all that willing to make changes, at least not on short timescales. It seems to me that the easiest solution to work around broken IPv4-only software isn't messing with the IPv6 protocol stack, but to create an IPv4 overlay on top of IPv6 that seems like a big IPv4 broadcast domain despite going through IPv6 routers. Actually this would also be quite useful in hosting environments where it would be easy to give every IPv6 customer their own VLAN but the IPv4 subnets are entangled.
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 5:50 PM, Ricky Beam wrote: > On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong 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.) > Sure, but, that future still doesn't need stupidly large numbers of hosts on a common link. >> 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*. Depends on a number of factors. Yes, there are lots of issues. However, they aren't caused by the small number of additional packets from DHCP. Owen
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 6:00 PM, Ricky Beam wrote: > On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum > 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
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 3:44 PM, Iljitsch van Beijnum wrote: > On 15 jun 2011, at 0:05, Owen DeLong wrote: > >> 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.) > > Strange that you don't apply the logic of "the existing software is what > there is" to the code deep inside hundreds of millions of hosts, but rather > to obscure stuff that presumably hardly anyone uses. > > If changing this software is so hard, what these people need is some > filtering switches so the application multicasts get forwarded but the IP > provisioning multicasts don't. No standards action required. > > BTW, does this broken software run over IPv6, anyway? No, but, it require the v4 stack on the hosts to be on the same link, which means that the v6 stack will also be on the same link. There are less broken scenarios, too. Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS vendors to make changes because experience has shown that they are more willing to do so than vertical software vendors. As such, yes, I'd like to see some harmless extensions added to DHCPv6 that solve some real world problems. Owen
Re: The stupidity of trying to "fix" DHCPv6
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. > Owen > > >
RE: The stupidity of trying to "fix" DHCPv6
> > 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. > When I was young and the earth was still cooling, I attended my very first University level Computer and Information Science lecture. There was the normal administatrivia followed by a discussion of how lucky we were to be in the generation of programmers who would address the Year 2K problem. Just to set expectations that was 1969 (okay the earth was actually getting warmer) more than three decades before the event. Somehow I remember a bit of a scramble to get everything ready on the evening. Fast forward a few years and a bunch of us are going to see a very similar event, foretold well in advance and not addressed until the last minute. The parallels are amazing, many very large corporations will need to fix (notice the future tense) a ton of software that is not IPv6 ready and the last time any of it was reviewed was for Y2K and that guy is long since gone and it is written in a language that no one understands and testing will require at least one of each type of environment (IPv4, IPv6, Dual-Stack, ArcNet ^H^H^H^H^H^H) --Dave (How many sick days do I have left?)
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
On Tue, 14 Jun 2011 18:44:22 -0400, Iljitsch van Beijnum 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
Re: The stupidity of trying to "fix" DHCPv6
On Tue, 14 Jun 2011 18:16:10 -0400, Owen DeLong 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*.
Re: The stupidity of trying to "fix" DHCPv6
On 15 jun 2011, at 0:05, Owen DeLong wrote: > 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.) Strange that you don't apply the logic of "the existing software is what there is" to the code deep inside hundreds of millions of hosts, but rather to obscure stuff that presumably hardly anyone uses. If changing this software is so hard, what these people need is some filtering switches so the application multicasts get forwarded but the IP provisioning multicasts don't. No standards action required. BTW, does this broken software run over IPv6, anyway?
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 1:30 PM, Ricky Beam wrote: > On Tue, 14 Jun 2011 04:00:22 -0400, 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. > > 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
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 1:15 PM, Ricky Beam wrote: > On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong 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. The point of /64 is to support automatic configuration and incredibly sparse host addressing. It is not intended to create stupidly large broadcast domains. 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. Owen
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
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 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/
Re: The stupidity of trying to "fix" DHCPv6
In a message written on Tue, Jun 14, 2011 at 05:01:24PM -0400, Ben Jencks wrote: > > 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. You can do VRRPv6 (now, finally, on some platforms). However, the standard way this works is, wait for it, advertising the default gateway via RA's! At least you can static route to the VRRPv6 address and that works without RA's. Again, it would be nice to give out the address in DHCPv6 and not need RA's at all, but alas there is no default route field in DHCPv6. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpmrTRpQ7Fij.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
On Tue, Jun 14, 2011 at 12:41, Ray Soucy wrote: > > 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. There was a thread on this subject over on ipv6-ops (Hello to the list and RA guard evasion technique) recently which outlined some of the problems currently facing vendors and implementing those 'easy upgrade' L2 security features. Due to the current state of host stacks with regards to fragment reassembly it's almost impossible to implement easily on a layer 2 device without exposing yourself to other DoS possibilities. There're also some I-Ds which cover the issues: http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-00.txt http://tools.ietf.org/id/draft-gont-6man-nd-extension-headers-00.txt ~Matt
Re: The stupidity of trying to "fix" DHCPv6
On Tue, 14 Jun 2011 04:00:22 -0400, 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. 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.)
Re: The stupidity of trying to "fix" DHCPv6
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. The problem for most folks is that it becomes an "in addition to" thing to support, troubleshoot, and debug. To make that ok, you have to look at the cost/benefits. 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. 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. People aren't noticing this today because they are dual stack, and end up reaching their DNS servers from IPv4 DHCP information over IPv4 transport. They may then get 's, and use IPv6 after that. Your box is dead in the water. How do you get DNS servers? Today the answer is to run DHCPv6. Of course if you need other options (netboot information, NTP servers, domain controllers, and so on) you also need DHCPv6 to get a functioning box. 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. 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! 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. 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. Depending on your environment this may or may not be as "feature rich" for you. For instance RA's timers aren't as adjustable (as they depend on end hosts), and I don't know of any vendor who implements interface tracking for RA's the way it is done with HSRP/VRRP. We need more folks using IPv6 in production to find this stuff. If you spin up a dual stacked box in the lab with a single router RA's work great, DHCPv4 gives you DNS, and you'll never notice any issues. Run a dual-router IPv6 only production network for some end users, and you'll notice some differences, and I think find that some of those differences are deficiencies. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp1frxQAdR53.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
On Tue, 14 Jun 2011 12:02:18 -0400, Owen DeLong 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.
Re: The stupidity of trying to "fix" DHCPv6
> 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. 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. On Tue, Jun 14, 2011 at 2:00 PM, 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. 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. 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. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 9:41 AM, Ray Soucy wrote:
> 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.
>
No, the energy in this thread needs to be directed to both of those
issues. However, your characterization of the needed behavior
and the time to deploy it is not entirely accurate.
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.
> I think that was the original spirit of this thread.
>
No, the original spirit of the thread revolved around the last 2
items in the above list. The first 4 have been discussed and already
resolved at the IETF level and are merely awaiting vendor implementation.
> Full static assignment is always an option if you don't want to use RA
> or DHCPv6.
>
Sure, but, the issue is people that don't want to use RA, but, want to use
DHCPv6.
> 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.
>
There's actually no reason this couldn't be done with DHCPv6, too, but,
it's not there currently.
> 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.
>
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.
Owen
> On Tue, Jun 14, 2011 at 12:15 PM, Nick Hilliard 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/
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 9:18 AM, Nick Hilliard wrote: > 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 Even on large enterprise LANS, campus LANs, and badly designed large service provider LANs, you don't tend to have the kind of perversely large L2 environment that is present at AMSIX. Also, as was pointed out, they have a rather unique situation of stale peering sessions continuously banging away at ND and ARP. Owen
Re: The stupidity of trying to "fix" DHCPv6
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 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/
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 1:48 AM, Mikael Abrahamsson wrote: > 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 > Indeed, it tends to be a perversely large L2 domain, but, not one where DHCP would likely occur. That was kind of my point. You are unlikely to encounter such a large L2 domain outside of an exchange point. Owen
Re: The stupidity of trying to "fix" DHCPv6
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 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 wrote: > > In a message written on Fri, Jun 10, 2011 at 01:03:01PM +, Bjoern A. > Zeeb wrote: > > On Jun 10, 2011, at 10:10 AM, sth...@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 th
Re: The stupidity of trying to "fix" DHCPv6
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.
Re: The stupidity of trying to "fix" DHCPv6
In a message written on Tue, Jun 14, 2011 at 10:20:07AM +0200, 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. Note that an exchange point LAN is a bit of an odd duck. RA's are supposed to be disabled. There is no DHCP. Rather, the ND behavior is casued by people statically configuring BGP sessions and then a participant leaving. So ND (or even ARP) tries over and over to find the missing participant. The thing to investigate here is if ND rate limiting is implemented correctly by the vendors involved, similar to ARP rate limiting. I'm not sure if there are standards requirements that could be in play as well. I'm not sure this has anything to do with the RA/DHCP issues... -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp3sJn4cl35i.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
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 Abrahamssonemail: swm...@swm.pp.se
Re: The stupidity of trying to "fix" DHCPv6
On Jun 14, 2011, at 1:20 AM, Mikael Abrahamsson wrote: > 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. ND would be a far more frequent occurrence than DHCP 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. Owen
Re: The stupidity of trying to "fix" DHCPv6
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.
Re: The stupidity of trying to "fix" DHCPv6
On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote: > On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell 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.) > > --Ricky You would need an AWFUL lot of hosts for this to add up to a few 100pps (or even 10pps) of multicast traffic. Owen
Re: The stupidity of trying to "fix" DHCPv6
On Jun 12, 2011, at 6:42 PM, Jimmy Hess wrote: > On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell wrote: >> 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. > > Rather than deem it a non-issue; I would say The impact of broadcast packets > depends on the network they are transmitted over. > If you have a Layer 2 domain with 5 hosts on it; the number of per-host > broadcast packets will be much more important than if you have a broadcast > domain with 1000 hosts. > If you have a layer 2 domain with 50,000 hosts on it, you probably did something very wrong in your network design to begin with. Likely you already have issues with forwarding table exhaustion on your L2 switching infrastructure. > 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; > Doing so would have created a situation where it was virtually impossible to run IPv6 without IPv4. Clearly not a desirable outcome. > Requiring configuration to be grabbed _two_ times per host is inefficient -- > ONE > DHCP discovery for every host on the LAN (either RA+DHCPv6 or DHCPv4) would > be more efficient. > Only if you assume that the world will never move beyond dual-stack to IPv6 monostack. This is an inherently bad assumption for a variety of reasons. What you are asking would be akin to asking for a DHCPv4 option to hand out IPX and Appletalk addresses too. It doesn't make sense for a wide variety of reasons even though you are correct that for a very narrow set of cases, it could provide a slight increase in efficiency. > If v6 hosts are dual stack, and v4 information is already pulled from > DHCP how much > sense does it really make to need a second discovery process to find a v6 > server > to config the host, particularly when there exists possibility of > conflicting options; DHCP > can config some non-interface-specific things such as time zone, hostname, > etc. > Just like v4 hosts, there are two classes of v6 hosts. Dual stack and mono-stack. The difference is that today, v4 mono-stack is much more common than v4 dual-stack and v6 dual-stack is much more common than v6 mono-stack. There will come a day (possibly many years from now) where v6 mono-stack will be more common than v6 dual-stack. > > There is a potential for greater issues on networks where the number > of broadcasts > may not have been an issue for IPv4;the IPv6 broadcast messages > have a larger > payload, because there are 96 more bits in an IPv6 address than an > IPv4 address. Unlikely that this would become a significant issue in the real world. The low frequency of requests, exponential backoff, and relatively small number of likely simultaneously affected hosts all add up to a very very low probability of significant bandwidth being used in this process. It's not like anyone does DHCP on a DS0. > The broadcasts for configuring IPv6 are incurred _on top_ of the broadcasts > already existing for IPv4 on a dual stack network, since IPv6 hosts > still have to config > IPv4 simultaneously. > Only if they need IPv4. Also, remember, the IPv6 packets aren't broadcasts. They are multicast and would go to the IPv6 All DHCP Servers Multicast group, not the All Nodes multicast group. Owen
RE: The stupidity of trying to "fix" DHCPv6
> -Original Message- > From: Leo Bicknell [mailto:bickn...@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.
Re: The stupidity of trying to "fix" DHCPv6
In a message written on Mon, Jun 13, 2011 at 05:41:12PM -0700, Owen DeLong 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. > > > > Which is no worse than the behavior of an IPv4 host on a network without a > DHCP server. 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". In the future, who knows. The idea being if I am a dual stacked host and I do DHCPv4 and get back that only 4 is available, I might stop doing DHCPv6 or at least make my exponential backoff even more exponential. Similarly, if I get back "4,6", I might know to immediately try the other protocol as well. This would allow end stations to greatly optimize their behavior at all stages of deployment. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpu12UcpMj2U.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
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
RE: The stupidity of trying to "fix" DHCPv6
> -Original Message- > From: Jimmy Hess [mailto:mysi...@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 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. 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.
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
On Jun 13, 2011, at 12:50 PM, Ricky Beam wrote: > On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell 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 >
Re: The stupidity of trying to "fix" DHCPv6
On Sun, 12 Jun 2011 09:45:01 -0400, Leo Bicknell 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.) --Ricky
Re: The stupidity of trying to "fix" DHCPv6
On Sun, Jun 12, 2011 at 8:29 PM, Leo Bicknell wrote: > 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. Rather than deem it a non-issue; I would say The impact of broadcast packets depends on the network they are transmitted over. If you have a Layer 2 domain with 5 hosts on it; the number of per-host broadcast packets will be much more important than if you have a broadcast domain with 1000 hosts. 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; Requiring configuration to be grabbed _two_ times per host is inefficient -- ONE DHCP discovery for every host on the LAN (either RA+DHCPv6 or DHCPv4) would be more efficient. If v6 hosts are dual stack, and v4 information is already pulled from DHCP how much sense does it really make to need a second discovery process to find a v6 server to config the host, particularly when there exists possibility of conflicting options; DHCP can config some non-interface-specific things such as time zone, hostname, etc. There is a potential for greater issues on networks where the number of broadcasts may not have been an issue for IPv4;the IPv6 broadcast messages have a larger payload, because there are 96 more bits in an IPv6 address than an IPv4 address. The broadcasts for configuring IPv6 are incurred _on top_ of the broadcasts already existing for IPv4 on a dual stack network, since IPv6 hosts still have to config IPv4 simultaneously. -- -JH
Re: The stupidity of trying to "fix" DHCPv6
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpfIuE4NcuY4.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
On Sun, Jun 12, 2011 at 08:12:02PM +0200, 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. You're not working from comparable situations. An IPv4 network without a DHCP server will probably have lots of IPv4 hosts banging out broadcast packets constantly as well. - Matt -- A committee is a cul-de-sac down which ideas are lured and then quietly strangled. -- Sir Barnett Cocks (1907-1989) (QOTD 20 Feb 2003)
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
On 6/12/2011 4:01 AM, Iljitsch van Beijnum wrote: 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. Well, at least you're being honest here. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/
Re: The stupidity of trying to "fix" DHCPv6
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.
Re: The stupidity of trying to "fix" DHCPv6
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. For my future ipv6 server network I tried to go without ra - but ran into troubles. I use ucarp from freebsd for the ipv4 servers to have a failover gateway - but this does not work because of dad. So I have now a ip for each gateway, still failover via ucarp to bring the interface up / down and advertise the active default gw via ra. Kind regards, Ingo Flaschberger
Re: The stupidity of trying to "fix" DHCPv6
On Sun, Jun 12, 2011 at 01:04:41PM +0200, 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? That would seem to be the logical outcome, yes. > Like I said before, that would pollute the network with many multicasts > which can seriously degrade wifi performance. Regardless of it's potential downsides, the issue at hand was the RFC compliance of such a setup. Owen DeLong contended that: On Fri, Jun 10, 2011 at 09:12:26PM -0700, Owen DeLong wrote: > 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. Daniel was merely requesting a reference for that assertion. If you have one, I'm sure Daniel (and Owen) would appreciate it. - Matt
Re: The stupidity of trying to "fix" DHCPv6
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp42BwastNEI.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
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? Like I said before, that would pollute the network with many multicasts which can seriously degrade wifi performance. And networks without RAs are very common. We call those networks "IPv4-only networks". 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.
Re: The stupidity of trying to "fix" DHCPv6
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.
Re: The stupidity of trying to "fix" DHCPv6
On 11 jun 2011, at 16:39, David Conrad 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. Ok, removed my snarky comments on trying to be fast this late in the game. The problem is changing DHCPv6 so people want to deploy it more means waiting a couple of years for the changes to start appearing and then many more years for the non-changed systems to disappear. How doing this makes anything faster is a mystery to me. People just have to get over the fact that IPv6 is different from IPv4 in some regards and it's too late now to change that, because we're already way behind deploying IPv6 before the IPv4 addresses run out.
Re: The stupidity of trying to "fix" DHCPv6
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: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: The stupidity of trying to "fix" DHCPv6
On Sat, Jun 11, 2011 at 12:41:17PM -0400, Kevin Loch wrote: > VRRPv3 (http://tools.ietf.org/html/rfc5798) is still a bit broken > in that it makes mention of "MUST advertise RA's" That's unintentional as per recent discussion on IETF VRRP mailing list where I seeked for clarification as JUNOS complains on every commit about no RAs for VRRP units. See http://www.ietf.org/mail-archive/web/vrrp/current/msg01447.html and response. I have yet to draft the RFC Erratum clarifying that unintentional interpretation. > and inexplicably limits VRRP addresses to link local only (?!)*. I cannot see that in RFC5798, and implementations and operational experience differs. 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. Otherwise a whole lot of IPv6 VRRP setups won't be working here. :) We use global scope addresses as VRRP virtual router addresses. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: The stupidity of trying to "fix" DHCPv6
On 2011-06-10 21:03, Owen DeLong wrote: On Jun 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote: 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. The PTRs would never conflict, but the v4 NS records would pre-empt delegation of certain v6 prefixes. Case in point: if authority for 2.0.0.0/24 were delegated (which it is), any requests for authoritative information for 2001::/16 would have to go through their servers. Compare: 0.0.2.in-addr.arpa. 1.0.0.2.in-addr.arpa. Oops. And yes, I tested this little theory -- it actually applies to large chunks of 2000::/4. Jima
RE: The stupidity of trying to "fix" DHCPv6
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:bickn...@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 I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
I'm sorry, but IPv4 DHCP was a wonderful solution to many issues, which are very very difficult in IPv6. RA is a solution looking for an actual problem. That being said, I like having the option of RA, but it is only useful in a very small subset of use cases, many it actually causes issues, instead of solving them. Not all devices are client computers, and it is *MUCH* harder to build scripting to determine what config options are specific to a network for a portable device like a SIP phone, than to simply add the options into DHCP. As it stands, IPv6 is a complete non starter to about half of my customer's VLANs due to the above. The best comment I've seen goes something like this: "We don't run RIP w/ a default route on our routers now for a reason, why do you suddenly think now it's a good idea, and willfully/ignorantly ignore the past 15 years" -Blake
Re: The stupidity of trying to "fix" DHCPv6
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 coul
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
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. There is no point in repeating all the IPv4 mistakes with IPv6, if that's what you want, stay on IPv4. 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. 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.) >> 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? >> 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? BTW, I first went to the IETF 10 years ago and didn't encounter such an attitude (although many others I didn't like). > 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. 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. >> 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. > 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. (Remember, not talking about rogue RAs!) > 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? We are just getting to the point where DHCPv6 can actually be used. Quit while you're ahead. And fixing protocols to make them work even in the face of explicit misconfiguration is a road that leads nowhere quickly. >> 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 multic
Re: The stupidity of trying to "fix" DHCPv6
On Jun 10, 2011, at 8:36 PM, Matthew Reath wrote: > >> 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? > Currently, you cannot disable RA unless you want to statically configure EVERYTHING. 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. > 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. > You cannot. You also cannot (as it currently stands) get DHCP to issue prefix length information (other than through PD which is different and not what most hosts will ask for) or routing information (default or a series of static routes). This is why we need the following: 1. Add options to DHCPv6 for routing configuration 2. Add the ability to have site-defined and/or vendor-speciic options to DHCPv6 if it hasn't been added yet (I'm not sure of the current state on this one). 3. Add options to DHCPv6 to specify prefix information, including prefix length. These are light-weight adds to the DHCP specification that can be very easily implemented by DHCP server producers. Hosts would also need to be modified as follows: 1. If the M bit is set or no RA was received, the host should only use the RA default gateway if there is no routing information in the DHCPv6 options. This would require updates to the DHCP client and possibly the parts of the OS that handle RA route installation. Also relatively simple modifications and probably easy to get into the OS relatively quickly once documented. In addition, it is _VERY_ desirable to modify the host autoconfiguration specification going forward to require hosts to: 1. Solicit an RA (as they do now). 2. Solicit DHCP (immediately, without waiting for an RA with the M or O bit). 3. Wait seconds for RA to come back. 4. If RA received, process it appropriately and finish the DHCP transaction if specified (M and/or O bit in RA). 5. If no RA received, complete the DHCP transaction as if an empty RA with the M bit set was received. While it will take a year or so for this to start making its way into boot-ROM firmware and such, and, another 3-5 years of technology refresh for that to become the PXE default behavior, it will actually make it into OS updates much faster and that covers the majority of dynamically addressed systems anyway. Note, in the meantime, sites that don't want to use RA can limp along with the existing process by providing DHCPv6 configuration information and essentially empty RAs with the M bit set (once host modification 1 in the previous list is implemented). Owen
Re: The stupidity of trying to "fix" DHCPv6
On Fri, Jun 10, 2011 at 07:53:36AM -0700, Owen DeLong 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. RFC6106... the future is nooow... I like it, inasmuch as I don't need to run a separate DHCPv6 server on a simple network, but that'd be equally solved by merging radvd into the DHCP server and just running that. The client-side configuration is annoying for RDNSS. - Matt
Re: The stupidity of trying to "fix" DHCPv6
> 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) m...@mattreath.com | http://mattreath.com Twitter: http://twitter.com/mpreath
Re: The stupidity of trying to "fix" DHCPv6
On Jun 10, 2011, at 10:21 PM, George Herbert wrote: > On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong 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.herb...@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.cut...@consultant.com
Re: The stupidity of trying to "fix" DHCPv6
On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong 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.herb...@gmail.com
Re: The stupidity of trying to "fix" DHCPv6
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
Re: The stupidity of trying to "fix" DHCPv6
On Jun 10, 2011, at 11:18 AM, valdis.kletni...@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.
Re: The stupidity of trying to "fix" DHCPv6
On 10 jun 2011, at 23:30, Rhys Rhaven wrote: > 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. What are you talking about?? ICMPv6 does what IPv4 ICMP does as well as ARP and then some.
Re: The stupidity of trying to "fix" DHCPv6
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.
Re: The stupidity of trying to "fix" DHCPv6
On Jun 10, 2011, at 12:21 PM, Steve Clark 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! engaging in ad homenim in the course of a technical argument on this list is not appropriate. >> Honestly. This whole argument is getting ridiculous.
Re: The stupidity of trying to "fix" DHCPv6
On Fri, 10 Jun 2011 13:27:58 PDT, Leo Bicknell said: > 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. Has senility set in, or wasn't there even an incident where somebody advertised 127/8 via RIP - and lots of nodes *believed* it, even though they should have realized that they had an interface on that network already? (And yes, I know of *multiple* failures of broadcasting a default route and getting swamped as a result - this one was 127/8 specifically)... pgpG9DmPaUFbk.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp3y705EkFbJ.pgp Description: PGP signature
Re: The stupidity of trying to "fix" DHCPv6
On Fri, 10 Jun 2011 09:47:44 -0400, Leo Bicknell 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.)
Re: The stupidity of trying to "fix" DHCPv6
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. > 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. 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. 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. 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. 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! > 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. > 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. > 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. 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. 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. > 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. > sharing is not desired. Why not? > 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. 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. And like I said before, we have more pressing things to do than tinker some more with DHCPv6.
Re: The stupidity of trying to "fix" DHCPv6
On Fri, Jun 10, 2011 at 2:21 PM, Steve Clark 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.
Re: The stupidity of trying to "fix" DHCPv6
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 wrote: In a message written on Fri, Jun 10, 2011 at 01:03:01PM +, Bjoern A. Zeeb wrote: On Jun 10, 2011, at 10:10 AM, sth...@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 - bickn...@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.cl...@netwolves.com http://www.netwolves.com
