Re: IPv6 Deployment for the LAN
Vasil Kolev va...@ludost.net, 2009-10-22 21:03 (+0200): how should we provide DNS and other useful information for the V6 only people? What Router Advertisment server did you use? The radvd server supports RFC 5006, an extension to vanilla RA that gives an address to a resolving DNS server (RDNSS). Granted, the client support is still rather poor. I only know of my own radns: http://hack.org/mc/hacks/radns/ and rdnssd: http://rdnssd.linkfanel.net/ The latter is included in some Linux distributions, at least Debian and Ubuntu. -- M.C. Widerkrantz, http://hack.org/mc/ Plain text e-mail, please. OpenPGP welcome.
Re: {SPAM?} Re: IPv6 Deployment for the LAN
The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Adrian Chadd adr...@creative.net.au wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? I'm not exactly a specialist for wireless, but as far as I remember my lectures the 802.11 has additional MAC fields for the wireless source/destination. Stations always send to the AP, the AP retransmits it to the station. IIRC WPA/WPA2 even has some protection against stations forging the AP MAC with the shared group key, but I don't remember any details. Bernhard
Re: {SPAM?} Re: IPv6 Deployment for the LAN
And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits... Uh, yeah. Owen On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
Re: {SPAM?} Re: IPv6 Deployment for the LAN
It's not all that easy unless the dude has hacked the device driver. Owen DeLong wrote: And of course, a rogue RA station would _NEVER_ mess with that bit in what it transmits... Uh, yeah. Owen On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote: The Wi-Fi MAC protocol has a pair of header bits that mean from AP and to AP. In ad-hoc mode, a designated station acts as an AP, so that's nothing special. There are a couple of non-AP modes for direct link exchanges and peer-to-peer exchances that probably don't set from AP but I'm not sure about that. Adrian Chadd wrote: On Sat, Nov 07, 2009, Bernhard Schmidt wrote: As already said, wireless in infrastructure mode (with access points) always sends traffic between clients through the access point, so a decent AP can filter this. How does the client determine that the traffic came from the AP versus another client? Adrian -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC -- Richard Bennett Research Fellow Information Technology and Innovation Foundation Washington, DC
RE: {SPAM?} Re: IPv6 Deployment for the LAN
Device driver? Nah.
Just use a tool (like Scapy) to just arbitrarily, easily custom-craft any
packet he|she wants ... Yes, it is that easy.
Thanks!
/TJ
-Original Message-
From: Richard Bennett [mailto:rich...@bennett.com]
Sent: Saturday, November 07, 2009 15:37
To: Owen DeLong
Cc: Bernhard Schmidt; nanog@nanog.org
Subject: Re: {SPAM?} Re: IPv6 Deployment for the LAN
It's not all that easy unless the dude has hacked the device driver.
Owen DeLong wrote:
And of course, a rogue RA station would _NEVER_ mess with that bit
in what it transmits...
Uh, yeah.
Owen
On Nov 7, 2009, at 2:41 AM, Richard Bennett wrote:
The Wi-Fi MAC protocol has a pair of header bits that mean from AP
and to AP. In ad-hoc mode, a designated station acts as an AP, so
that's nothing special. There are a couple of non-AP modes for direct
link exchanges and peer-to-peer exchances that probably don't set
from
AP but I'm not sure about that.
Adrian Chadd wrote:
On Sat, Nov 07, 2009, Bernhard Schmidt wrote:
As already said, wireless in infrastructure mode (with access points)
always sends traffic between clients through the access point, so a
decent AP can filter this.
How does the client determine that the traffic came from the AP versus
another client?
Adrian
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
--
Richard Bennett
Research Fellow
Information Technology and Innovation Foundation
Washington, DC
Re: IPv6 Deployment for the LAN
On Thu, 29 Oct 2009 08:40:46 +0900 Randy Bush ra...@psg.com wrote: This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is s wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. As does excessive pessimism.
Re: IPv6 Deployment for the LAN
Iljitsch van Beijnum wrote: This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! A
Re: IPv6 Deployment for the LAN
This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is s wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. randy
Re: IPv6 Deployment for the LAN
Amen to that Randy. MMC Randy Bush wrote: This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is s wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. randy
Re: IPv6 Deployment for the LAN
This is unusual, but, I have to agree with Randy here. Owen On Oct 28, 2009, at 5:09 PM, Matthew Moyle-Croft wrote: Amen to that Randy. MMC Randy Bush wrote: This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. No, what we want are better first hop redundancy protocols, and DHCP for v6, so that everyone who has extracted any value from DHCP in their toolkit can continue to do so, and roll out v6 ! no. what we need is more religious v6 fanatics to make use of v6 hard to roll out on existing networks. after all, v6 is s wonderful we should be happy to double our opex for the privilege of using such a fantastic protocol. v6 fanaticism has done vastly more damage to v6 deployment than the v6 haters. arrogance kills. randy
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Sat, Oct 24, 2009 at 11:33 PM, Karl Auer ka...@biplane.com.au wrote: On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: the mac address of the rouge server pedantic It's R-O-G-U-E - rogue. Rouge is French for red and English for red make-up. Also the name of the Ford assembly plant at which the Monday night social was held. I blame the repeated repetition of the plant name throughout the night for planting it so thoroughly in our collective subconscious. ;) /pedantic Regards, K.
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On wireless networks you can note the mac address of the rouge server and dissociate it from the wireless network, this is rather similar to what we did on switches prior to dhcp protection, it is reactive but it certainly can be automatic. Some controller based wireless systems have ips or nac functionality that does this already. joelja David W. Hankins wrote: On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. There are some wireless equipment that claim to have a setting that forces all packets through the wireless bridge (where all traffic is between clients and bridge, and never client to client), and so one can filter DHCPv6 and maybe RA, but I am kind of skeptical about how much of this is elective and dependent upon client implementation... In both cases there may still be some wireless adapters that receive bogus packets directly from attackers. And then you bring ND into the question and wonder why you bothered with either RA or DHCP filtering. DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic authentication. The problem however has been the key distribution model. Here it all falls down, and leads to poor deployment. But with DHCPv*, we have a hope that we can secure it if we can solve that last problem (and at least I think we can). So if you accept that as an outcome, one must ponder the question: How long will people accept that a secured DHCPv6 session must rely, in order to function to expectations, upon the unsecurable RA and/or questionably secure SEND?
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: the mac address of the rouge server pedantic It's R-O-G-U-E - rogue. Rouge is French for red and English for red make-up. /pedantic Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Sun, 25 Oct 2009 17:33:34 +1100 Karl Auer ka...@biplane.com.au wrote: On Fri, 2009-10-23 at 20:48 -0700, Joel Jaeggli wrote: the mac address of the rouge server pedantic It's R-O-G-U-E - rogue. Rouge is French for red and English for red make-up. /pedantic Also the colour of the faces of angry net admins when they discover a rogue, possibly rouge coloured server. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
Re: IPv6 Deployment for the LAN
WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. I thought ULA-C was dead... Did someone resurrect this unfortunate bad idea? I'm not sure, I've not checked for a pulse recently. Last I looked it seemed that there was ULA-L and ULA-C, and most people were saying use ULA-L unless you needed ULA-C, ULA-C seemed like a good fit for this, if it's been buried then sure ULA-L would fit the bill just as well. Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over. Why pull this out of ULA? Why not pull it out of /16 or one of the other reserved prefixes? With my proposal above it only requires a /96, seems silly to use up an entire /16 on a /96 worth of bits. It shouldn't come out of 2000::/3 because that's globally routable and this is defined to sit within locally scoped addressing. I have no major thoughts either way as to exactly where the range comes from other than it should be an easy to spot, and easy to type range which suggests plenty of 0's :)
Re: IPv6 Deployment for the LAN ... anycast
TJ wrote: WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 FWIW - I think simple anycast fits that bill. I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. There are some protocols that anycasting doesn't work well for, they may require multiple instances. I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? Up to , if you want to announce a service port 30,000 you're in trouble. Also quite a few protocols don't have well known ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports and protocols that don't have well known ports could get an unused one assigned to them. ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per-function mentioned above, then perhaps useful. In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above).
Re: IPv6 Deployment for the LAN
WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? Needs an acronym ... off the top of my head, something like ASPEN - Anycast Service Provisioning for Enterprise Networks ... ? (Although it could be appropriate for an ISP-HomeUser as well ... hmmm, SPATULA - Service Provisioning - Anycast, Transparent, Unique Local, Anycast ... ) major snipping Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over. I have no major thoughts either way as to exactly where the range comes from other than it should be an easy to spot, and easy to type range which suggests plenty of 0's :) I don't have any major thoughts on this either, still thinking out lout / rambling. :) /TJ
Re: IPv6 Deployment for the LAN ... anycast
WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 FWIW - I think simple anycast fits that bill. I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ... There are some protocols that anycasting doesn't work well for, they may require multiple instances. Fair enough; could also standardize something like FD00::port number, FD00::1:port number, and FD00::2:port number ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... ) I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? Up to , if you want to announce a service port 30,000 you're in trouble. Also quite a few protocols don't have well known ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports and protocols that don't have well known ports could get an unused one assigned to them. OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port based on automatically using port numbers (or using automatically registered port numbers, see below). Maybe FD00:::/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses. ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per-function mentioned above, then perhaps useful. In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above). OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...) And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc. /TJ
Re: IPv6 Deployment for the LAN
Owen DeLong wrote: On Oct 22, 2009, at 4:27 PM, Joe Maimon wrote: NAT wasnt a component of IPv4 until it was already had widespread adoption. I remain completely unconvinced that people will not continue to perceive value in PAT6 between their private and their public subnets. People may perceive value, but, I truly hope that they won't be able to obtain the functionality. It's just a very bad idea that does terrible things to the network. NAT/PAT was a necessary evil in IPv4 to extend the lifetime of the addressing until IPv6 could be almost ready. It should be allowed to die with IPv4. I have had the privilege of seeing quite a few different organizations networks up close and personal, from small to very large, networks and organizations. I can recall two, both in academia, that used global unique to the desktop, firewalled of course. I can think of another two who chose to use public ASN and BGP because of input I was part of. Neither obtained PI space. Neither used global unique addresses anywhere near an internal server or desktop. Most of the rest use private space exclusively internal and different chunks of public space from different providers, from /24 - /28. For redundancy and load balancing, the tool of choice is natting load balancers or just plain nat with ecmp. Some even used private ASN (or provider ASN) to get their internet service with some degree of redundancy, but still just some chunks of PA /25 or so. I dont think IPv6 has much to offer these companies. I dont think encouraging all of them to get an ASN and PI /48 is that great an idea for both network operators and these organizations and I highly doubt that PA ipv6 has any real attraction to them at all. Depletion wont have any real affect on them at all. Perhaps it means they wont be able to get /25 or /26, but they most likely will have no issues lighting up new connectivity with a /28 or /29. Should they need native access to IPv6 content/endpoints, they would probably choose to use another nat functionality at the external points in their network. Only if there was no other way to do it would they consider lighting up guIPv6 to the desktop. And they would be quite unhappy about it. Many of these companies have explicit security policies concerning this. Many of these network architects have explicit preferences concerning this. Naturally there are probably many other end user organizations who wont fit in these lines, but my experience suggests that there are large percentages who will. I truly think it is way too early to decide and predict that IPv6 will not ever have widespread use of IPv6 PAT to IPv6 And of course, different forms of NAT are almost certainly required to try to make ipv4 and ipv6 interoperate for as long as people need it to. Sort of, but, yeah. That's OK. Unfortunate, but, OK. I actually think that now that we have a transfer market policy, IPv4 will probably die much faster than it would have otherwise. Owen Depletion wont ring a death knell for any end user with existing connectivity. What it will do is cause providers to start harvesting the fat in their networks. Some providers who will choose to implement private ipv4 along with IPv6 rollouts are likely to have very large amounts of that fat. Other companies with large amounts of fat probably exist as well, from the companies who had the habit of assigning /26 to every leased line customer back in the day to the hosters who handed out /24 like candy. What is a residential cable or DSL company who replaced millions of subscribers guIPv4 address with dual stack (lite?) private ipv4 and guIPv6 going to do with the all that IPv4? Will they cutover to new models that arent guIPv4 centric by attrition or quicker? I believe there will be strong pressure to monetize IPv4 addresses, both for internal customer use and perhaps to transfer it to other organizations. This is not necessarily a bad thing. People who want it will pay for it and those who do not will not. This will likely result in the identification of more IPv4 fat to be harvested. The really nice side effect would hopefully be to provide economic incentive to IPv6 as an alternative to pricey IPv4, which could provide enough acceleration to ipv6 demands to reach a tipover point sooner, rather then later. So in that sense, you could be right. Joe
Re: IPv6 Deployment for the LAN
On Oct 23, 2009, at 5:08 AM, Perry Lorier wrote: WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. I thought ULA-C was dead... Did someone resurrect this unfortunate bad idea? I'm not sure, I've not checked for a pulse recently. Last I looked it seemed that there was ULA-L and ULA-C, and most people were saying use ULA-L unless you needed ULA-C, ULA-C seemed like a good fit for this, if it's been buried then sure ULA-L would fit the bill just as well. Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over. Why pull this out of ULA? Why not pull it out of /16 or one of the other reserved prefixes? With my proposal above it only requires a /96, seems silly to use up an entire /16 on a /96 worth of bits. It shouldn't come out of 2000::/3 because that's globally routable and this is defined to sit within locally scoped addressing. No... You missed my point... I was suggesting that ::/16 already had some assignments for stuff somewhat like this, so, why not use more of that prefix to get a /96 for this... e.g. ::/0 == default, ::1/128 == Loopback, etc. Why not use :::/64 to assign these addresses as: :::inst:ance:serv:ice That is a 32 bit instance number and 32 bit port number, using up just a /64. I was not suggesting the entire /16 for this, the entire /16 there isn't available. I have no major thoughts either way as to exactly where the range comes from other than it should be an easy to spot, and easy to type range which suggests plenty of 0's :) I figured was a good candidate since it's already partially in use for reserved special addresses. Owen
Re: IPv6 Deployment for the LAN ... anycast
On Oct 23, 2009, at 5:45 AM, TJ wrote: WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 FWIW - I think simple anycast fits that bill. I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ... Please remember that IPv6 DNS is OFTEN not stateless as the replies are commonly too large for UDP. There are some protocols that anycasting doesn't work well for, they may require multiple instances. Fair enough; could also standardize something like FD00::port number, FD00::1:port number, and FD00::2:port number ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... ) That's what I meant by prefix::inst:ance:serv:ice instance would be a 32-bit instance value and service would be a 32 bit service value (probably port number in the low order bits initially). I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? Up to , if you want to announce a service port 30,000 you're in trouble. Also quite a few protocols don't have well known ports, so may want to get things assigned. If you're doing assignment you could do nice things like 0x53 for DNS and then ports and protocols that don't have well known ports could get an unused one assigned to them. OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port based on automatically using port numbers (or using automatically registered port numbers, see below). Why use the non-hex converted? Is it really hard to realize that 0x35 = 53? Maybe FD00:::/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses. ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per- function mentioned above, then perhaps useful. In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above). OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...) And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc. Agreed, but, since this mostly doesn't get typed by humans, I think that using 0x35 is much better in this case than using 0x53 - 53 stuff. Owen
Re: IPv6 Deployment for the LAN ... anycast
Once upon a time, Owen DeLong o...@delong.com said: Please remember that IPv6 DNS is OFTEN not stateless as the replies are commonly too large for UDP. Anything that supports IPv6 _should_ also support EDNS0. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: IPv6 Deployment for the LAN
I figured was a good candidate since it's already partially in use for reserved special addresses. But in a totally non-routable fashion, as it stands today. ULA's have the immediate benefit of being routable, but not globally so - and (hopefully) already being in filter lists to prevent accidental implementation. /TJ
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Fri, Oct 23, 2009 at 12:50:47PM +1300, Perry Lorier wrote: I've implemented myself a system which firewalled all ARP within the AP and queried the DHCP server asking for the correct MAC for that lease then sent the ARP back (as well as firewalling DHCP servers and the like). It's quite easily doable, and quite reliable. If nodes were to send packets directly when associated to an AP then the 802.11 protocol would fall apart, I've never met an implementation that broke this requirement of the standard. It had not occurred to me to intercept ARP (or ND) as a transition mechanism, that is pretty clever, but the idea of using DHCPv* leasequery as a way to make IP-MAC resolution both secure and unicast is something I've heard many times. I don't know about my peers, but I would be very interested to see an RFC that describes and examines your results. You can of course pretend you're the AP and send a packet if you're wanting to be vicious enough. Yes, of course, that is much simpler. If the attacker can associate with the real wireless network, they can always bridge and provide a rogue AP to insert themselves in the middle. Sometimes in focusing on packet exchanges, we miss the forest for the trees. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpNQAGCnPio4.pgp Description: PGP signature
Re: IPv6 Deployment for the LAN ... anycast
I think for very small/small networks anycast requires a lot of overhead and understanding. If your big enough to do anycast and/or loadbalancing it's not hard for you to put all three addresses onto one device. Anycast isn't really hard - same address, multiple places, routers see what appear to be multiple routes to same destination, they choose the least expensive. Only tricky part (for stateless things) is ensuring the route announcement is implicitly tied to service availability on that device ... I'm thinking for places like home users and the like which don't really run an IGP, can't correctly identify a router, and when you say anycast think that you might be talking about a new form of fishing. There are some protocols that anycasting doesn't work well for, they may require multiple instances. Fair enough; could also standardize something like FD00::port number, FD00::1:port number, and FD00::2:port number ... is three addresses enough? (IIRC, the Site-Local based automagic DNS used 2 or three addresses ... ) 3 seems to me to be plenty for most cases. For some things like NTP you might want to have 4 or more. OK, so the non-hex converted as above (FD00::x:53; where x=[0,1,2] - reserving FD00::/96) covers us to port based on automatically using port numbers (or using automatically registered port numbers, see below). Maybe FD00:::/112 as a block within the above range to be used for manual assignment of automatic service (potentially anycast) addresses. Seems sane to me. In my humble opinion I'd have them registered, linking them to port numbers means that it's easier on the poor admins brain at 3am while diagnosing faults, but may cause various hassles in the future (see above). OK, so register them - but sign up some well-known ones at very comfortable addresses, like DNS at 53 :). (Or 35 if you prefer hex-conversion ...) And I am sure some would be concerned about hosts performing any sort of automatic service discovery anything, but this atleast has the advantage over multicast in that it doesn't require multicast routing or group membership / state maintenance, only delivers packets to the nearest (not all) instances, etc. Yup, and it makes a sane default, if you want to override with DHCP, or some funky RA option, or manual configuration or whatever, then this gets out of your way and you don't have to care. It doesn't involve any code changes on hosts *or* routers to work today.
Re: IPv6 Deployment for the LAN
On 21 okt 2009, at 22:48, Owen DeLong wrote: The assumption that the router knows it is correct for every host on a given LAN simply does not map to reality deployed today. What I'm saying is that a router knows whether it's a router or not. A DHCP server does not, so it has to make a leap of faith and then sometimes the hosts fall flat on their face if there's no router on the address indicated by the DHCP server. The counter-argument is it works today but my counter-counter-argument is it doesn't work today. I get burned by broken DHCP setups _all_ _the_ _time_ at work, at IETF meetings, at RIPE meetings, etc. Anyone claiming that having a DHCP server direct hosts to a router address in the blind is simply incompetetent, so there is no point in listening to them. If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. Please explain to me how I can achieve this functionality in RA/SLAAC or stop pushing to prevent it from being available in DHCPv6. There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways. Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Stop trying to break the internet and I'll treat you like an adult.
Re: IPv6 Deployment for the LAN
On 21 okt 2009, at 23:34, David W. Hankins wrote: There is a problem with the Both RA and DHCPv6 Model currently proposed by IETF iconoclasts. Should RA fail, for any reason from router, system, software, network path, security, or user error, then the simplest networks imaginable (where hosts and mail/Intranet/ work servers are all co-located on the same broadcast domain) will not be able to talk to one another, Or the rest of the world. Note however that it is very hard to get false negatives for RAs and even harder to get false positives. The only way I've had RAs fail in the real world was with multilayer switches that wouldn't let IPv6 multicasts through because they couldn't do IGMP snooping for those. This affected RAs but also all other neighbor discovery, and would have affected DHCPv6, too. So in this situation IPv6 is completely dead in the water. The good thing is that you don't get any false positives, where a host thinks there's a router somewhere but there's not actually a router there. This is because when a router stops being a router it will also stop sending RAs. All of this works extremely well, I can't think of any instance where there is any trouble with RAs, except of course the problem of rogue routers advertising themselves. However, this is not really any different from the situation in IPv4 where rogue DHCP servers advertise stuff they shouldn't advertise. To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band through some means. Why not simply fix the DHCPv6 protocol so it has a prefix length attribute? DHCP'ers can complain about stateless autoconfig and RAs, but the simple truth is that DHCPv6 has problems that are unrelated to anything outside DHCPv6 that haven't been fixed in the half a decade that I've been paying attention to it. But it may complicate your designs if you are assigning /80's. RFC 3513 says that all interface identifiers for addresses outside ::/ 3 must be 64 bits in size. That doesn't work with a /80. So I'm not sure if using DHCPv6 with /80s will work on all systems. According to the release notes of ISC DHCP 4.1.0, ISC 'dhclient -6' compiles and runs on Mac OSX. I don't actually own a Mac, so I have never used it myself, and our release notes even go into detail about the limitations of the current 'dhclient-script' for the Darwin platform (apparently their configuration system is somewhat opaque). MacOS detects when interface go online and offline and does all kinds of stuff when that happens. For instance, you can't globally enable/ disable stateless autoconfig on MacOS, either. Manually running a script when the interface status changes is a rather blunt way to interact with the system. Does anyone know if Apple has plans to release a DHCPv6 client for Mac OS X? No...but I have heard plans of the exact opposite. [...] When people at the microphone asked why Apple did not include a DHCPv6 client implementation, even a stateless one, I believe Bernard Aboba addressed the concern at the microphone saying, and I am paraphrasing from memory here, We were told by the IETF that RA was all we would ever need, implementing DHCPv6 is optional, so RA is all we are doing. I don't remember that. What I do remember is that Stuart Cheshire of Apple explained how he was unhappy that it was necessary to run a rather involved protocol (DHCPv6) for the relatively simple task of obtaining DNS resolver addresses. To summarize, RA+DHCPv6 implementers are posed with problems: ...which apparently some DHCPv6 people want to solve by ALWAYS running their chatty protocol that wastes a lot of bandwidth on wireless LANs until people give in and just run a DHCPv6 server just to get rid of the constant DHCP retransmissions that can't be stopped any other way because actually looking at the O/M bits is of course way too simple. I hate this crap so much.
Re: IPv6 Deployment for the LAN
On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote: so your not a fan of the smart edge and the stupid network. I'm a fan of getting things right. A server somewhere 5 subnets away doesn't really know what routers are working on my subnet. It can take a guess and then wait for people to complain and then an admin to fix stuff if the guess is wrong, but I wouldn't call that a smart edge. Always learn information from the place where it's actually known.
Re: IPv6 Deployment for the LAN
On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. In any case, anywhere this is actually of vital importance, a routing protocol would be in use. Using the DHCP protocol to deliver information - about anything really - is what it's *for*. That said, making clients depend utterly on the presence of a working DHCP server for basic connectivity seems like a backward step. Of course, different people have different ideas about what constitutes basic connectivity. Stop trying to break the internet and I'll treat you like an adult. Whoa! Tell you what, how about if I break it, and you get to choose which piece you keep? [Bash, bash, thud. Ugh. Hm. It's tougher than it looks!] :-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote: On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote: so your not a fan of the smart edge and the stupid network. I'm a fan of getting things right. A server somewhere 5 subnets away doesn't really know what routers are working on my subnet. It can take a guess and then wait for people to complain and then an admin to fix stuff if the guess is wrong, but I wouldn't call that a smart edge. Always learn information from the place where it's actually known. i'm ok w// that mindset. one should learn routing from the router(s), time from the time servers, DNS from the DNS servers, etc... now -normally- I would expect the router to focus on forwarding packets ... not be the time keeper, DNS server, handing out IP addresses, hosting content for the HTTP protocol etc. sounds to me like your reacting to a particular style of implementation (DHCP servers being multi-hops away) and want to move the function(s) closer to the edge, e.g. in the routers. and if we can get RA/ND -fixed- to accomodate all the functions that folks have grown to depend on over the years from a configuration service like DHCP - then we should be able to converge. I am not a fan of the way DHCPv6 has developed/emerged. And yes, I've re-written both client and server to fix the egergious problems found in the current spec... (it now works just fine for doing things like handing out DNS servers for resolvers, picking mapped addresses for my IVI service, etc.) so my DHCP is non-interoperable w/ anyone elses. Thing is, its easier to fix DHCP code than to fix the router code. And the edge is not the LAN, its the device. --bill
Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. Regards, K. --bill
Re: IPv6 Deployment for the LAN
On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote: The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. And how do they discriminate now, with IPv4? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote: On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote: The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. And how do they discriminate now, with IPv4? Regards, K. IPv4 has no concept of RA/ND. to make this construct work at all in IPv6, all participants have to turn -off- RA/ND to prevent one or more routers trying to impose their views of addressing on their neighbours. --bill
Re: IPv6 Deployment for the LAN
On Thu, 2009-10-22 at 11:08 +, bmann...@vacation.karoshi.com wrote: On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote: On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote: The RA contains a preference level... maybe that doesn't cut it if I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. And how do they discriminate now, with IPv4? IPv4 has no concept of RA/ND. to make this construct work at all in IPv6, all participants have to turn -off- RA/ND to prevent one or more routers trying to impose their views of addressing on their neighbours. But my question was not about IPv6. How do IPv4 routers operate in such a situation? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
bmann...@vacation.karoshi.com wrote: On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote: On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote: so your not a fan of the smart edge and the stupid network. I'm a fan of getting things right. A server somewhere 5 subnets away doesn't really know what routers are working on my subnet. It can take a guess and then wait for people to complain and then an admin to fix stuff if the guess is wrong, but I wouldn't call that a smart edge. Always learn information from the place where it's actually known. i'm ok w// that mindset. one should learn routing from the router(s), time from the time servers, DNS from the DNS servers, etc... I quite liked the old http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea. (tl;dr version: Have a set of well known site local anycast address for recursive name servers). It has a number of nice features such as: * since it's not in globally routable space people can't (ab)use your recursive name servers from outside your network. * you don't have to change recursive name servers when going to a different network -- they're the same everywhere. * the addresses can be set as the default addresses by the OS manufacturer, and then don't need to be configured ever again. * If your recursive name server becomes unreachable, broken or otherwise out of contact, it withdraws the address from your IGP, then since you can any cast these addresses, another node takes over. Similar to the shared fate idea of RA's. * You don't tie your recursive nameservers addresses to any point in the network, since they have their own special range, moving them, reshuffling them, or anything doesn't impact anything. They don't need to cohabit a router sending RA's or anything odd like that. However it has a number of obvious drawbacks, primarily amongst them being that it uses deprecated site local addresses. You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup _ntp._udp.local IN SRV or similar to find your local NTP servers. Another obvious approach might be to have a service discovery protocol where you send to a service discovery multicast group a message asking wheres the nearest nameserver(s)? then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a ServiceDiscovery-Guard feature for switches Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :)
Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 10:18:48PM +1100, Karl Auer wrote: On Thu, 2009-10-22 at 11:08 +, bmann...@vacation.karoshi.com wrote: On Thu, Oct 22, 2009 at 09:44:38PM +1100, Karl Auer wrote: On Thu, 2009-10-22 at 10:30 +, bmann...@vacation.karoshi.com wrote: The RA contains a preference level... maybe that doesn't cut it if I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. And how do they discriminate now, with IPv4? IPv4 has no concept of RA/ND. to make this construct work at all in IPv6, all participants have to turn -off- RA/ND to prevent one or more routers trying to impose their views of addressing on their neighbours. But my question was not about IPv6. How do IPv4 routers operate in such a situation? Regards, K. exchange design 101. each connecting router interface is manually configured with an address of the exchange fabrics IP space. to establish peering, a router needs to know, at a minimum, the targets IP address and ASN - and while arp (if enabled) can get the target IP address, the ASN has to come via another channel - usually manually aquired. this is how the exchanges generally work, regardless of IP address family. more generally, where there are two or more egress routers from a broadcast domain, there will be problems -if- the routers know about each other -and- have the ability to try and set the exit rules for all other participants sharing the broadcast domain. Hence, with IPv6 and RA/ND, the idea of preference levels ... although in most cases I've experienced where there are multiple exit routers - that doesn't work either, since only subsets of the nodes on the shared media can use one or the other egress router. e.g. all the nodes don't fate-share. RA/ND was only an 80% solution anyway. --bill
Re: IPv6 Deployment for the LAN
On 22/10/2009 11:30, bmann...@vacation.karoshi.com wrote: On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance to an IXP? Being one of these artefact operators - and clearly stuck with a very small dinosaur brain - I am having some trouble understanding the point you're attempting to make here. Nick
Re: IPv6 Deployment for the LAN
On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote: You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup _ntp._udp.local IN SRV or similar to find your local NTP servers. Another obvious approach might be to have a service discovery protocol where you send to a service discovery multicast group a message asking wheres the nearest nameserver(s)? then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a ServiceDiscovery-Guard feature for switches ah... well - if your a router centric person, then you want to put everything into the tools you know and love. if your a dns centric person, then you put everything in the DNS. I point you to the DISCOVER' opcode (experimental) in the DNS and the use of DNS over multicast for doing service discovery (e.g. Apples Bonjour)... Most of that is already designed/deployed and in pretty widespread use... over IPv4 or IPv6. And yes, its not RA/ND, or DHCP... its another configuration protocol and its not quite vendor specific. The best thing is, it pushes the smarts closer to the edge (the end device) and this makes me happy. Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :) everyone to their own taste. --bill
Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 12:35:18PM +0100, Nick Hilliard wrote: On 22/10/2009 11:30, bmann...@vacation.karoshi.com wrote: On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance to an IXP? Being one of these artefact operators - and clearly stuck with a very small dinosaur brain - I am having some trouble understanding the point you're attempting to make here. Nick its been a few weeks/years/minutes since I ran an exchange fabric, but when we first turned up IPv6 - the first thing they did was try to hand all the other routers IPv6 addresses. that pesky RA/ND thing... had to turn it off ... RA preference would not work, since there was no -pecking- order - all the routers were peers. we did the manual configuration - no DHCP - it was the only way to ensure things would be deterministic. Hence my comments to Karl re his statement about not happen in a well-tended network. the point. RA/ND was designed to solve what some of its designers thought would be 80% of the problems. It might just be able to do that - for the limited scope that it has. There are other, more robust, decomposable, resilient configuration tools out there that have capabilities people need that are not currently in RA/ND. and even then, not all architectures are ammenable to automated configuration tools. RA/ND is not a panecea. --bill
Re: IPv6 Deployment for the LAN
I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. Bill, could you explain how or why ra or dhcp or dhcpv6 have any relevance to an IXP? Being one of these artefact operators - and clearly stuck with a very small dinosaur brain - I am having some trouble understanding the point you're attempting to make here. IPv6 ND is relevant, obviously. RA, DHCP or DHCPv6 are not relevant here. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: IPv6 Deployment for the LAN
On Thu, 2009-10-22 at 11:30 +, bmann...@vacation.karoshi.com wrote: But my question was not about IPv6. How do IPv4 routers operate in such a situation? exchange design 101. Thanks :-) I was being a bit Socratic. In the IPv4 world, routers in such complex environments are generally manually configured. In other situations they might use a routing protocol. Turning off RA in a similar environment with IPv6 is no loss over IPv6. My point (several messages ago,now) was in regard to DHCP information being used to send preferred route information; seems to me that in a situation where RA preference levels are not cutting it, a DHCP server sending discrimination information is probably not going to cut it either. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
Just to clear things up, I'm not advocating the use of 80-bit prefixes. I was asking if they were a legitimate way to prevent SLAAC in environments with hardware that don't support disabling the autonomous flag for a prefix, or hosts that don't respect the autonomous flag. I've since done some testing in the lab, and have found that the majority of operating systems that are still in use respect the autonomous flag when deciding whether or not to run SLAAC if IPv6 is implemented, so this becomes a non-issue. I agree, sticking with a 64-bit prefix for every network is a good thing. SLAAC itself is also a good thing and I'm not advocating that it go away. I think its rather elegant and provides a lot of flexibility. That said, DHCPv6 is also a key part of IPv6. The fact that we have M and O flags in RA, and the A flag in advertised prefixes is a pretty strong signal that both stateless and stateful configuration are valid choices for IPv6 deployment. Adding DNS information to RA would generally be a bad idea. There is more to host configuration than just DNS, though DNS is the most common. I think that RA knows its role and archives it rather nicely. When you want to provide hosts with other configuration, like DNS, you can do so making use of a lightweight implementation of DHCPv6. In fact, most routers already support this. The argument that implementing DHCPv6 in the client is somehow too much work is ridiculous. DHCPv6 is as essential to IPv6 as ICMPv6 and MLD. You really shouldn't consider an implementation of IPv6 without a functional DHCPv6 client complete. At the same time, adding gateway information to DHCPv6 is also a bad idea. This is already accomplished by RA in an elegant and thoughtful way. This whole line of thinking is a result of the mindset that SLAAC and DHCPv6 are mutually exclusive; they're not. RA, SLAAC, and DHCPv6 compliment one another. They are all important components of the IPv6 addressing architecture. What we have now generally works well. Getting vendors to work together and actually implement things the same way is sometimes a challenge. Perhaps we need to update the language on RFCs from MAY and SHOULD to MUST and eliminate the ambiguity of what needs to be implemented with IPv6. In an enterprise environment, SLAAC has no place. It makes perfect sense to not run SLAAC on prefixes you advertised in this case. Just because SLAAC is the default doesn't mean it's the only method of deployment. There are still some challenges to work out with DHCPv6 implementations, and it may help dual-stack environments if DHCPv6 is amended to include a MAC address in requests when running on a dual-stack network so associations can be made between IP and IPv6 addresses on a host, but the use of DUID is generally a good thing. Once we start seeing more IPAM solutions include support for IPv6 and DHCPv6 I think a lot of the hostility towards DHCPv6 will go away. We've been implementing DHCPv6 support in our home-grown IPAM solution and have found that it all works rather nicely. Mac OS X is a challenge since it doesn't provide a DHCPv6 client, but our position has become that of saying we don't roll out IPv6 to clients with incomplete implementations and to leave it at that. IPv6 isn't quite necessary for all clients just yet. There is very little that is reachable by IPv6 only. Until that changes, we're willing to ignore certain groups of clients in an effort to pressure vendors to come into the fold and support DHCPv6 by default. If we have a case where there is a legitimate need for IPv6, we still have the ability to manually assign an IPv6 address on the host, but this would be on a very limited basis. If you're an ISP and deploying IPv6 for your residential customers, by all means run SLAAC. It's easy and it works. If you manage an enterprise IT environment and need control over your network, disable SLAAC and run DHCPv6. This will allow you to roll out IPv6 at your own pace, giving you time to make sure that hosts and users are prepared for it, all while maintaining the benefits of DHCPv6 in your architecture. That's all I'm trying to say. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On Thu, 22 Oct 2009, bmann...@vacation.karoshi.com wrote: On Thu, Oct 22, 2009 at 09:20:11PM +1100, Karl Auer wrote: On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. And you want to use router advertisments for assigning addresses for them? Huh! Regards, Janos
Re: IPv6 Deployment for the LAN
WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? ... Just thinking 'out loud' ... /TJ Sent from my Verizon Wireless BlackBerry -Original Message- From: Perry Lorier pe...@coders.net Date: Fri, 23 Oct 2009 00:22:52 To: bmann...@vacation.karoshi.com Cc: nanog@nanog.org Subject: Re: IPv6 Deployment for the LAN bmann...@vacation.karoshi.com wrote: On Thu, Oct 22, 2009 at 12:02:14PM +0200, Iljitsch van Beijnum wrote: On 22 okt 2009, at 01:55, bmann...@vacation.karoshi.com wrote: so your not a fan of the smart edge and the stupid network. I'm a fan of getting things right. A server somewhere 5 subnets away doesn't really know what routers are working on my subnet. It can take a guess and then wait for people to complain and then an admin to fix stuff if the guess is wrong, but I wouldn't call that a smart edge. Always learn information from the place where it's actually known. i'm ok w// that mindset. one should learn routing from the router(s), time from the time servers, DNS from the DNS servers, etc... I quite liked the old http://tools.ietf.org/html/draft-ietf-ipv6-dns-discovery-07 idea. (tl;dr version: Have a set of well known site local anycast address for recursive name servers). It has a number of nice features such as: * since it's not in globally routable space people can't (ab)use your recursive name servers from outside your network. * you don't have to change recursive name servers when going to a different network -- they're the same everywhere. * the addresses can be set as the default addresses by the OS manufacturer, and then don't need to be configured ever again. * If your recursive name server becomes unreachable, broken or otherwise out of contact, it withdraws the address from your IGP, then since you can any cast these addresses, another node takes over. Similar to the shared fate idea of RA's. * You don't tie your recursive nameservers addresses to any point in the network, since they have their own special range, moving them, reshuffling them, or anything doesn't impact anything. They don't need to cohabit a router sending RA's or anything odd like that. However it has a number of obvious drawbacks, primarily amongst them being that it uses deprecated site local addresses. You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup _ntp._udp.local IN SRV or similar to find your local NTP servers. Another obvious approach might be to have a service discovery protocol where you send to a service discovery multicast group a message asking wheres the nearest nameserver(s)? then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a ServiceDiscovery-Guard feature for switches Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :)
Re: IPv6 Deployment for the LAN
On Thu, 2009-10-22 at 14:25 +0200, Mohacsi Janos wrote: On Thu, 22 Oct 2009, bmann...@vacation.karoshi.com wrote: I point you to a fairly common Internet architecture artifact, the exchange point... dozens of routers sharing a common media for peering exchange. And you want to use router advertisments for assigning addresses for them? Huh! You've got the wrong end of the stick. The point of this exchange was that RA was not going to do the job. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
On 22/10/2009 12:49, bmann...@vacation.karoshi.com wrote: its been a few weeks/years/minutes since I ran an exchange fabric, but when we first turned up IPv6 - the first thing they did was try to hand all the other routers IPv6 addresses. that pesky RA/ND thing... had to turn it off ... RA preference would not work, since there was no -pecking- order - all the routers were peers. Bill, I am not able to look at this paragraph without being reminded of Charles Babbage's take on the GIGO principal: On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. Nick
Re: IPv6 Deployment for the LAN
Iljitsch van Beijnum wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see. There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways. Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap. Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Stop trying to break the internet and I'll treat you like an adult. At conferences I keep hearing It would be great if the IETF had more operator input. Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work. How do we fix that? - Kevin
Re: IPv6 Deployment for the LAN
Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap. Right. I'll admit some confusion here. If the IETF, due to religion or aesthetics, is blocking attempts at making DHCPv6 do what network operators _need_ (as opposed to want), why haven't network operators routed around the problem and gone and funded folks like ISC, NLNetLabs, Cisco, Juniper, et al., to implement what they need? At conferences I keep hearing It would be great if the IETF had more operator input. Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work. How do we fix that? You seem to be asking how do we make people not stupid. Folks tend to simplify reality so that it fits their world view. Stupid people attempt to force that simplified reality onto others. You can either play their game, attempting to get them to understand reality is often more complicated than we'd like, or route around them. Or you can post to NANOG... :-) Regards, -drc
Re: IPv6 Deployment for the LAN
On 22 okt 2009, at 17:03, Kevin Loch wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see. Lots of people need a gun. If I were living in a place where bears walk around loose I might need one, too. But most guns are used to shoot the owner in the foot most of the time. The world would be a better place without them. Like I said, if there's a bunch of routers announcing their presence and you want a DHCP option to provide guidance to a host as to which one to choose, that would be fine. But pointing to a potentially non- existing address in the hopes that there will magically be a router residing at that address would a serious regression in robustness. There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways. Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. What does that have to with anything? IPv6 stateless autoconfig predates the widespread use of DHCPv4. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap. Absolutely not. Give users the choice between something good that suits their needs 83% and a piece of crap tht suits their needs 84% and they'll choose the latter each and every time. Users get to say what they need. They don't get to design the solution by committee any more than they get to design bridges or airplanes by committee, although of course they do get to choose which ones to use. At conferences I keep hearing It would be great if the IETF had more operator input. Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work. How do we fix that? Tell the IETF your real requirements, don't try to do back seat protocol design. Protocol design is hard, the IETF gets it wrong most of the time (and they do better than some of their colleagues, still). Suggesting specific changes to a protocol as a solution to an unstated real requirement wastes everyone's time. With writing, they tell you listen when people say there is a problem, but ignore them when they tell you what the problem is. Same thing here. Users know their needs, but generally they don't know the best way to meet those needs.
Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009, Iljitsch van Beijnum wrote: What does that have to with anything? IPv6 stateless autoconfig predates the widespread use of DHCPv4. So does IPX and IPX/RIP. Why does this thread seem to rehash some big disconnect between academics, IETF and actual deployment-oriented people who have a job to do? Silly architecture groups.. Adrian (Glad I'm not involved. I'd lose patience and punch people.)
Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 8:44 AM, Iljitsch van Beijnum wrote: On 22 okt 2009, at 17:03, Kevin Loch wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see. Lots of people need a gun. If I were living in a place where bears walk around loose I might need one, too. But most guns are used to shoot the owner in the foot most of the time. The world would be a better place without them. As a strong proponent of the second amendment, it is now clear to me that we have a fundamental disagreement on how society should interoperate which is unlikely to ever be resolved between us. Like I said, if there's a bunch of routers announcing their presence and you want a DHCP option to provide guidance to a host as to which one to choose, that would be fine. But pointing to a potentially non- existing address in the hopes that there will magically be a router residing at that address would a serious regression in robustness. It really isn't a serious regression in robustness in the real world. It really is functioning today. Most DHCP servers are not used to shoot users in the head, despite your claims to the contrary. There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways. Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. What does that have to with anything? IPv6 stateless autoconfig predates the widespread use of DHCPv4. Hmmm... Perhaps you should be asking yourself why IPv6 SLAAC was not used as the model for address assignment in IPv4 instead of DHCPv4 in that case? Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap. Absolutely not. Give users the choice between something good that suits their needs 83% and a piece of crap tht suits their needs 84% and they'll choose the latter each and every time. Yes... As well they should. Meeting their needs 84% of the time is actually vastly superior. Users get to say what they need. They don't get to design the solution by committee any more than they get to design bridges or airplanes by committee, although of course they do get to choose which ones to use. Depends on how you define users. If you don't think that airlines have a substantial amount of technical input into how airliners are designed, you are vastly mistaken. At conferences I keep hearing It would be great if the IETF had more operator input. Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work. How do we fix that? Tell the IETF your real requirements, don't try to do back seat protocol design. Protocol design is hard, the IETF gets it wrong most of the time (and they do better than some of their colleagues, still). Suggesting specific changes to a protocol as a solution to an unstated real requirement wastes everyone's time. With writing, they tell you listen when people say there is a problem, but ignore them when they tell you what the problem is. Same thing here. Users know their needs, but generally they don't know the best way to meet those needs. 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. Owen
Re: IPv6 Deployment for the LAN
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: {SPAM?} Re: IPv6 Deployment for the LAN
This to me is one of the least credible claims of the RA/SLAAC crowd. On the one hand we have carriers around the world with millions and millions of customers getting default routes and other config through DHCPv4 every day. And most of the time it actually works very well! On the other hand we have RA/SLAAC with a vastly smaller customer base, vastly less real life testing - but which is still claimed to be so much better that DHCPv6 is not *allowed* to get a default route option. If the argument against RA being used to provide gateway information is rogue RA, then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? I guess I'm not really seeing the case here. Are people really making use of DHCP to provide hosts on the same network with different default gateway information? If so, why? Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a good idea and it works. You can add options to DHCPv6, but I don't see many vendors implementing default gateway support unless you can make a real case for it. My fear is that your goal is to do away with RA completely and turn to DHCPv6 for all configuration. RA is actually quite nice. You really need to stop fighting it, because it's not going away. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: {SPAM?} Re: IPv6 Deployment for the LAN
In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote: If the argument against RA being used to provide gateway information is rogue RA, then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? It's a huge difference, and any conference network shows it. Let's assume 400 people come into a room, get up and working (with DHCPv4, and IPv6 RA's). Someone now introduces a rogue IPv4 server. Who breaks? Anyone who requests a new lease. That is 400 people keep working just fine. Now, someone introduces a roge RA. Who breaks? All 400 users are instantly down. More importantly, there is another class of misconfigured device. I plugged in a Cisco router to download new code to it on our office network. It had a DHCP forward statement, and IPv6. It was from another site. The DHCP forward didn't work, it pointed to something non-existant that also was never configured for the local subnet. There was zero chance of IPv4 interfearance. The IPv6 network picked up the RA to a router with no routes though, and so simply plugging in the old router took down the entire office network. The operational threats of a DHCP based network and a RA based network are quite different. Try it on your own network. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgptlutTow2Rl.pgp Description: PGP signature
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Sorry, not buying it. The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA. What your proposing as a solution isn't much of a solution at all but just a (seemingly) lesser problem. On Thu, Oct 22, 2009 at 3:29 PM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Thu, Oct 22, 2009 at 03:23:13PM -0400, Ray Soucy wrote: If the argument against RA being used to provide gateway information is rogue RA, then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? It's a huge difference, and any conference network shows it. Let's assume 400 people come into a room, get up and working (with DHCPv4, and IPv6 RA's). Someone now introduces a rogue IPv4 server. Who breaks? Anyone who requests a new lease. That is 400 people keep working just fine. Now, someone introduces a roge RA. Who breaks? All 400 users are instantly down. More importantly, there is another class of misconfigured device. I plugged in a Cisco router to download new code to it on our office network. It had a DHCP forward statement, and IPv6. It was from another site. The DHCP forward didn't work, it pointed to something non-existant that also was never configured for the local subnet. There was zero chance of IPv4 interfearance. The IPv6 network picked up the RA to a router with no routes though, and so simply plugging in the old router took down the entire office network. The operational threats of a DHCP based network and a RA based network are quite different. Try it on your own network. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: {SPAM?} Re: IPv6 Deployment for the LAN
In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote: The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA. Port based solutions don't work well on wireless networks and other mediums. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpdNPR62fPVP.pgp Description: PGP signature
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. On Thu, Oct 22, 2009 at 3:50 PM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Thu, Oct 22, 2009 at 03:42:19PM -0400, Ray Soucy wrote: The solution here, and one that is already being worked on by vendors, is RA gaurd, not changing DHCPv6 in an effort to bypass RA. Port based solutions don't work well on wireless networks and other mediums. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
RE: IPv6 Deployment for the LAN
David Conrad wrote: Ok, lets start with not breaking the functionality we have today in IPv4. Once you get that working again we can look at new ideas (like RA) that might have utility. Let the new stuff live/die on it's own merits. The Internet is very good at sorting out the useful technology from the crap. Right. I'll admit some confusion here. If the IETF, due to religion or aesthetics, is blocking attempts at making DHCPv6 do what network operators _need_ (as opposed to want), why haven't network operators routed around the problem and gone and funded folks like ISC, NLNetLabs, Cisco, Juniper, et al., to implement what they need? At conferences I keep hearing It would be great if the IETF had more operator input. Yet whenever we try to provide operationally useful advice we are ridiculed for not being smart enough to know how things should work. How do we fix that? You seem to be asking how do we make people not stupid. Folks tend to simplify reality so that it fits their world view. Stupid people attempt to force that simplified reality onto others. You can either play their game, attempting to get them to understand reality is often more complicated than we'd like, or route around them. Or you can post to NANOG... :-) The root of the argument I see in this entire thread is the assumption that 'what we have for IPv4 has *always* been there'. There is lots of finger pointing at the IETF for failure to define 15 years ago, what we have evolved as the every-day assumptions about the IPv4 network of today. SLAAC was presented specifically to deal with the DHCP failure modes of the time, and the very real possibility that DHCP might not make it as a technology that operators would want to deploy. While lots of evolution happened in the DHCP space to deal with changing operational requirements, it is still a complex approach (which may be why it is favored by those that like to maintain a high salary). To be fair, there were failures in the IETF, as the SLAAC and DCHP sides couldn't get out of each other's way; so now instead of having 2 independent models for provisioning, we have 2 interdependent models. RFC 5006 is one step at breaking that interdependence, and more are needed on the DHCPv6 side, yet these steps can't happen if people sit in the corner and do the 'they won't listen to me' routine. For those that insist that DHCP is 'the only way to know who is using an address', have you considered dDNS? Oh wait, that moves the trust point to a different service that in the enterprise is typically run by the host admin, not the network admin, or in the SP case crosses the trust boundary in the wrong direction ... my bad. Seriously, there are ways to figure this out, as Ron Broersma pointed out on Monday. I am not arguing for one model over the other, as they each have their benefits and trade-offs. The real issue here is that some people are so locked into one approach that they refuse to even consider that there might be an alternative way to achieve the same goal, or that the actual goal will change over time in the face of external requirements. IPv4 continues to be a work-in-progress 30 years later, and IPv6 will be no different. The fact that there is not functional parity between the operational aspects is due to operators insisting until very recently that 'the only thing that matters is IPv4'. It should not be a surprise that IPv4 is where the majority of the work in the IETF happened. Despite my attempts to get the IETF to stop wasting effort on what is clearly a dead-end, this is still true today. As drc points out, you can continue to post complaints on the nanog list, or if you want real change make sure your vendors get a clear message about IPv6 being the priority, then make your point on the appropriate IETF WG list. At the end of the day, the way networks are operated today is not the way they will be operated in 5 years, just as it is not the same as they way they were operated 5 year ago. Asserting a snap-shot perspective about 'requirements' has its place, but everyone needs to recognize that this is an evolving environment. Changing the base protocol version is just one more step on that evolutionary path. Tony
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. Rogue DHCP doesn't immedately take down the entire subnet of machines with existing DHCP leases. It generally only affects new machines trying to get a lease, or RENEWing machines. The impact of a rogue RA is to immediately break connectivity for every machine on the subnet. Differing impacts leads to different risk assessments of which protocol to use. Regardless, modern wireless deployments use central controllers or smart APs that can filter DHCP. They could be extended to filter RA as well. And this whole point is rather moot because we have RAs and must deal with them. It is too late to get rid of the RA behavior of clients. Even if you don't want to use RAs, your hosts are going to still listen to them which means a Rogue RA is going to take down your network. We have this problem even on IPv4-only subnets, where a Rogue RA (usually a Windows box with routing turned on) breaks connectivity to dual-stack servers for machines on that subnet. Since the hosts prefer native IPv6 connectivity over IPv4, the hosts end up preferring the Rogue RA as the route towards the dual-stack server. We really just need to bug our vendors to implement Rogue RA protection for wired and wireless ASAP, wherever we are in our deployment of IPv6.
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Correct. Not sure if you got the sarcasm in that last reply... As far as I'm concerned, a rogue is a rogue. Knowing about it the instant it happens might even be better than slowly coming to the realization that you're dealing with one. The point is that we need to address rogues regardless of their type, not move from RA to DHCPv6 because the impact of a rogue is slower to disrupt service. On Thu, Oct 22, 2009 at 4:06 PM, Chuck Anderson c...@wpi.edu wrote: On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. Rogue DHCP doesn't immedately take down the entire subnet of machines with existing DHCP leases. It generally only affects new machines trying to get a lease, or RENEWing machines. The impact of a rogue RA is to immediately break connectivity for every machine on the subnet. Differing impacts leads to different risk assessments of which protocol to use. Regardless, modern wireless deployments use central controllers or smart APs that can filter DHCP. They could be extended to filter RA as well. And this whole point is rather moot because we have RAs and must deal with them. It is too late to get rid of the RA behavior of clients. Even if you don't want to use RAs, your hosts are going to still listen to them which means a Rogue RA is going to take down your network. We have this problem even on IPv4-only subnets, where a Rogue RA (usually a Windows box with routing turned on) breaks connectivity to dual-stack servers for machines on that subnet. Since the hosts prefer native IPv6 connectivity over IPv4, the hosts end up preferring the Rogue RA as the route towards the dual-stack server. We really just need to bug our vendors to implement Rogue RA protection for wired and wireless ASAP, wherever we are in our deployment of IPv6. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On 22/10/09 16:06 -0400, Chuck Anderson wrote: On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. Rogue DHCP doesn't immedately take down the entire subnet of machines with existing DHCP leases. It generally only affects new machines trying to get a lease, or RENEWing machines. The impact of a rogue RA is to immediately break connectivity for every machine on the subnet. Differing impacts leads to different risk assessments of which protocol to use. That breaks both ways. You could do maintenance in the middle of the night and break DHCP in unexpected ways (which I've seen happen) and then you have the problem of manually rebooting (or renewing) all those devices the next morning when you notice they're not working. We really just need to bug our vendors to implement Rogue RA protection for wired and wireless ASAP, wherever we are in our deployment of IPv6. VLAN per subscriber fixes this. It's not really appropriate everywhere, but it's a nice solution for wireless and ISP scenarios. -- Dan White
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 12:23 PM, Ray Soucy wrote: This to me is one of the least credible claims of the RA/SLAAC crowd. On the one hand we have carriers around the world with millions and millions of customers getting default routes and other config through DHCPv4 every day. And most of the time it actually works very well! On the other hand we have RA/SLAAC with a vastly smaller customer base, vastly less real life testing - but which is still claimed to be so much better that DHCPv6 is not *allowed* to get a default route option. If the argument against RA being used to provide gateway information is rogue RA, then announcing gateway information though the use of DHCPv6 doesn't solve anything. Sure you'll get around rogue RA, but you'll still have to deal with rogue DHCPv6. So what is gained? Apparently you missed the entire message he responded to about the number of things specified by DHCP and the differences between the groups in control of the routers vs control of the hosts/servers and the actual administrative groups in charge of each? I guess I'm not really seeing the case here. Are people really making use of DHCP to provide hosts on the same network with different default gateway information? If so, why? Yes. A number of different application and business requirements. Some I can go into easily (load balancing among different routers, routers owned by different departments, etc.), some are proprietary to my clients and I can't give enough details without violating NDA. Or is it that you want IPv6 to be a 128-bit version of IPv4? RA is a good idea and it works. You can add options to DHCPv6, but I don't see many vendors implementing default gateway support unless you can make a real case for it. The assignment of gateway information to the host belongs in the hands of the systems administrators and not in the hands of the people running the switches and routers in many organizations. With router information assigned through DHCP, this is preserved. With it being assigned by the router, it is not, and, in fact, the case. With DHCPv6 unable to assign router information you lose that administrative boundary and take away a systems administrators control over their hosts and hand it to the networking group. My fear is that your goal is to do away with RA completely and turn to DHCPv6 for all configuration. RA is actually quite nice. You really need to stop fighting it, because it's not going away. Not at all. People are not saying RA has to go away. They are saying we need the option of DHCPv6 doing the job where we do not feel that RA is the correct tool. More tools are good. Replacing one tool that works today with a new tool that is arguably inferior in many real world cases, on the other hand, is not so good. Owen
Re: IPv6 Deployment for the LAN
On Thu, 22 Oct 2009 21:20:11 +1100 Karl Auer ka...@biplane.com.au wrote: On Thu, 2009-10-22 at 11:40 +0200, Iljitsch van Beijnum wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. The RA contains a preference level... maybe that doesn't cut it if multiple routers are sending the same preference level, but presumably that would not happen in a well-tended network. IPv6 Subnets/VLANs are pretty cheap, maybe if people are having this issue, that's a sign they need to divide their hosts into more subnets/VLANs. More broadly, it seems the argument is where to put networking operational policy - in the network (via e.g. engineered topology), or on the hosts. I think there is value in putting it in the network, because it avoids having to change host located policy when the network policy changes. In any case, anywhere this is actually of vital importance, a routing protocol would be in use. Using the DHCP protocol to deliver information - about anything really - is what it's *for*. That said, making clients depend utterly on the presence of a working DHCP server for basic connectivity seems like a backward step. Of course, different people have different ideas about what constitutes basic connectivity. Stop trying to break the internet and I'll treat you like an adult. Whoa! Tell you what, how about if I break it, and you get to choose which piece you keep? [Bash, bash, thud. Ugh. Hm. It's tougher than it looks!] :-) Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Original Message From: Ray Soucy r...@maine.edu Or is it that you want IPv6 to be a 128-bit version of IPv4? Yes, this is in fact exactly what the network operators keep saying. RA is a good idea and it works. You can add options to DHCPv6, but I don't see many vendors implementing default gateway support unless you can make a real case for it. My fear is that your goal is to do away with RA completely and turn to DHCPv6 for all configuration. RA is actually quite nice. You really need to stop fighting it, because it's not going away. RA may be quite nice for some cases. However, several examples over this thread alone have been provided about some other cases where it is something other than nice. DHCPv4 is not a perfect protocol, but it's widely deployed and understood. It also is a one-stop-shop for centralized host configuration. IPv6 does not currently have a similar one-stop-shop protocol, and this is a major gap in functionality. There are a bunch of very large providers and enterprises which number their DHCP-managed end-sites in the hundreds of thousands or millions. The inability to provide the same centralized configuration management should not be considered a feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: IPv6 Deployment for the LAN
On Thu, 22 Oct 2009 11:40:50 +0200 Iljitsch van Beijnum iljit...@muada.com wrote: On 21 okt 2009, at 22:48, Owen DeLong wrote: The assumption that the router knows it is correct for every host on a given LAN simply does not map to reality deployed today. What I'm saying is that a router knows whether it's a router or not. A DHCP server does not, so it has to make a leap of faith and then sometimes the hosts fall flat on their face if there's no router on the address indicated by the DHCP server. The counter-argument is it works today but my counter-counter-argument is it doesn't work today. I get burned by broken DHCP setups _all_ _the_ _time_ at work, at IETF meetings, at RIPE meetings, etc. Anyone claiming that having a DHCP server direct hosts to a router address in the blind is simply incompetetent, so there is no point in listening to them. If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. Please explain to me how I can achieve this functionality in RA/SLAAC or stop pushing to prevent it from being available in DHCPv6. There is no requirement that the IETF provides all functionality that someone can think up. The list of desired functionality is infinite, and much on that list is a bad idea and/or can be achieved in different ways. Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Stop trying to break the internet and I'll treat you like an adult. Great way to shoot down your own credibility. Just because you don't have or don't understand problems other people have doesn't mean they don't have them or they're invalid. You'd be far better off proposing alternative solutions that use methods that you believe in, or looking to understand better why your methods aren't appropriate. (I don't believe in your agenda to add a prefix length option to DHCPv6 (you probably haven't run an IPX or Appletalk network, and therefore haven't experienced the convenience of fixed length subnets/node addresses), but I don't think it's appropriate to call you a child because of you naivety in this area ...)
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Owen DeLong wrote: Not at all. People are not saying RA has to go away. They are saying we need the option of DHCPv6 doing the job where we do not feel that RA is the correct tool. Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts. DHCPv4 works everywhere and meets every networks needs, from the $50 linksys to the million dollar network. RA already does not. The answer to RA shortcomings is not to turn it into a clone of DHCP, only stateless and chained to the router. More tools are good. Replacing one tool that works today with a new tool that is arguably inferior in many real world cases, on the other hand, is not so good. Owen Sure, leave RA in the IPv6 stack. The market will decide, and we will see if it is still on by default on soho routers and in IOS 15.4T in 2015. Joe
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Port based solutions don't work well on wireless networks and other mediums. Something like PSPF then? (assuming it works properly on IPv6 multicast ... ) /TJ
Re: {SPAM?} Re: IPv6 Deployment for the LAN
Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts. Those two statements are not synonymous ... Sure, leave RA in the IPv6 stack. The market will decide, and we will see if it is still on by default on soho routers and in IOS 15.4T in 2015. That is a more sensible statement. And were I to be a gambling man I would say it will indeed be on by default ... we'll talk more about it then :). Also, I would like to add - there is a difference between the default gateway information and other things, such as NTP|DNS|SIP server information. The default gateway, by definition, is an on-link thing. IMHO, this makes the router a good source for information about the router. I am not saying use cases for fully spec'ed DHCPv6 don't exist or should be ignored. Making the router capable of sharing the missing piece that covers ~95% of use cases is also a Good Thing. Thinking out loud, we could also re-create the idea of an auto-magic DNS by creating a special use case within ULA-space - say FD00::/96, saving the last 32 bits for something like ::53 and using anycast. *(Could abstract same idea to any stateless and/or light-session-based service ... FD00::123 for Automagic ULA-based anycast NTP, etc. Need 32 bits if we don't want to hex convert the things, just in case ...)* /TJ
Re: IPv6 Deployment for the LAN
It's certainly encouraging to see how there is such consensus among NANOG on IPv6 deployment. :-) Recent exchanges seem to be getting a little personal, so we might want to take a step back and breath. I don't think adding default gateway support to DHCPv6 will have much of an impact, but I'm OK with people trying to get it implemented. Another tool in the box. I just wouldn't hold your breath waiting for it. I think the better approach is to take a firm stand on security and make RA gaurd and DHCPv6 snooping expected for network devices. These problems will still exist if default gateway options for DHCPv6 get implemented. As for RA taking down a network quickly, well, it can be restored quickly too. The fact that RA is actually responsive can be a benefit in some situations. Hopefully if anything has come out of this thread its that both stateless and stateful configuration have a place in IPv6, and that there is still work to be done before IPv6 is really ready for the enterprise LAN. Others may have their specific requests from vendors, but here are mine: 1. Include DHCPv6 client functionality as part of any IPv6 implementation. 2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure. A lot of the frustration seems to come from Windows ICS acting as an IPv6 router. I think everyone here has been after Microsoft to either remove ICS or make it more difficult to enable at one point or another. While a rogue RA can come from anywhere, Windows is usually the guilty party. I would argue that since NAT is not a component of IPv6, no host should be implementing ICS-like functionality for IPv6. It's unlikely that there would be a situation on an IPv6 network that a host needed to share it's IPv6 address to get others online. Just my thoughts. Maybe someone from Microsoft who can do something about it lurks on this list. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On 22 okt 2009, at 22:52, Mark Smith wrote: Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Stop trying to break the internet and I'll treat you like an adult. Great way to shoot down your own credibility. Just because you don't have or don't understand problems other people have doesn't mean they don't have them or they're invalid. When people want something which is clearly a bad idea (doing default gateways in DHCPv6 the same way as in DHCPv4) and they ignore it when a better solution is suggested (having a DHCP option that allows a DHCPv6 server to tell hosts which of the available routers to use) then the discussion tends to take a turn for the worse. You'd be far better off proposing alternative solutions that use methods that you believe in, or looking to understand better why your methods aren't appropriate. I often do that. Unfortunately, in many cases, people not only insist on bad ideas, but they won't even take suggestions on how to achieve what they want in less harmful ways. That annoys me a great deal. (I don't believe in your agenda to add a prefix length option to DHCPv6 (you probably haven't run an IPX or Appletalk network, and therefore haven't experienced the convenience of fixed length subnets/node addresses), but I don't think it's appropriate to call you a child because of you naivety in this area ...) But wouldn't hardcoding a prefix length also be a bad idea? We now pretty much always have /64 but there are just enough exceptions to make it dangerous to just assume /64. However, I firmly believe that whether is done with DHCPv6 it will continue to have problems. Even if DHCPv6 itself would operate well and consistently in all cases, then there are still the permuations between hosts that support stateless autoconfig and not DHCP, those that support both, those that are configured to only do DHCP, those that listen for the M/O bits and those that don't... There's simply no way to get consistent behavior out of a set of hosts unless those hosts all run the same version of the same OS. Now for anything else than a configuration protocol that wouldn't be a disaster but for a configuration protocol this is fairly inconvenient.
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 4:32 PM, Ray Soucy wrote: Knowing about it the instant it happens might even be better than slowly coming to the realization that you're dealing with one. Might just be me, but I'm more worried about the rogue RA (or DHCPv4) server that does not disrupt communication at all...
Re: IPv6 Deployment for the LAN
bmann...@vacation.karoshi.com wrote: On Fri, Oct 23, 2009 at 12:22:52AM +1300, Perry Lorier wrote: You could imagine extending this to other services such as NTP, but I'm not sure that you really would want to go that far, perhaps using DNS to lookup _ntp._udp.local IN SRV or similar to find your local NTP servers. Another obvious approach might be to have a service discovery protocol where you send to a service discovery multicast group a message asking wheres the nearest nameserver(s)? then nameserver implementations could listen on this multicast group and reply. Again shared fate. This does have the downside of people running rogue nameservers and needing a ServiceDiscovery-Guard feature for switches ah... well - if your a router centric person, then you want to put everything into the tools you know and love. Generally I don't think of myself as a router centric person ;) if your a dns centric person, then you put everything in the DNS. This has always sounded like a nice solution to me, however, DNS is starting to look a little long in the tooth, overloading it with more and more semantics seems to be pushing it well beyond it's design envelope. (EDNS0?) I point you to the DISCOVER' opcode (experimental) in the DNS and the use of DNS over multicast for doing service discovery (e.g. Apples Bonjour)... Most of that is already designed/deployed and in pretty widespread use... over IPv4 or IPv6. Yup, they're good ways to discover some local resources. To my understanding mDNS works over the local subnet, unless you're going to start having your routers run as mDNS relays (is there any standards for this? How do you stop mDNS relays from creating loops and broadcast storms?). mDNS works over a a single multicast group with a single port 5353 which makes it hard to filter different types of services (People on this switch can announce their iTunes sharing, but they're not allowed to announce a local DNS server) without DPI, you're more likely to find network engineers just filter the entire multicast group breaking it for other purposes If you're not going to have mDNS forwarders on your routers, then you're going to need to reconfigure your entire configuration on every segment as well. (IMHO) there are different types of configuration: * Network related (routes, addressing). RA's seem to do a fairly good job at at least 80% of this. * Network provided services, such as DNS, NTP. Well known anycast addresses seems to be (IMHO) the best way to advertise these. Currently you need DHCPv6 to get this information. * Application settings (web proxy, local outgoing SMTP relay, default printer location, local SIP/RTP proxy, local home/intranet page, what the current local timezone rules are). This seems to be currently done by a variety of adhoc protocols, usually bundled over well known DNS names with HTTP, often replicating the same information in a wide range of different places in different formats. This seems an ugly solution, but I have no other suggestions. I'm sure there are several RFCs/Drafts around somewhere that tries to solve this. * Ephemeral end user provided services, which is already provided today by the well documented, and deployed mDNS. in theory you can kinda pick and choose between those, for instance you can run just mDNS on a network without RA's or DHCPv6 and things will work (for the limited value of work that involves only whatever the ephemeral services are being announced). You can run RA's by themselves, and your bittorrent will work fine. And yes, its not RA/ND, or DHCP... its another configuration protocol and its not quite vendor specific. The best thing is, it pushes the smarts closer to the edge (the end device) and this makes me happy. Theres a general issue of access control. While I like a very smart edge, you don't want some misinformed user turning on a feature and suddenly having the rest of your network ending up using it. Personally I like the first option (anycast addresses) better, you can control who has access to your IGP and if your IGP is down, then for all intents and purposes your recursive nameservers are offline too :) everyone to their own taste. Yup. There are different systems, they have different tradeoffs. Pick the one that trades off things you don't care about for things you do care about. :)
Re: IPv6 Deployment for the LAN
On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see. It would be a tool, and if someone wants to use a tool, they can. It won't be my thumb they hit :-) But I can't see how a DHCP server can know enough about the routers to be able to send out useful discrimination information. So it will have to be manually entered, or come from an IPAM, or... Nor can I see how the DHCP server can identify the routers to the host except by their addresses, and these can change or be removed without the DHCP server finding out. The only way I can see it working is if the host were smart enough to compare the DHCP router discrimination info with the information it has received via RA and delete mismatches, or possibly just revert to using RA information if any mismatches at all are detected. That would be an item the DHCP server could specify as well - what to do in case of a mismatch. It could even be specified on a per-router basis, though the whole thing seems to be getting a bit unwieldy now. The DHCP servers will not be on the same subnets as all the routers involved, so they can't sniff the RAs themselves - unless we set up an RA relay... hmm. I don't see DHCP-delivered router preferences as being something that will break the Internet. In the vast majority of cases they will be unnecessary. For those that do need it though, and if it can be done, why not? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 11:12:14AM +1100, Karl Auer wrote: To work around this problem, some DHCPv6 software implementers have elected to temporarily apply a fixed /64 bit prefix to all applied addresses until a prefix length can be made available in-band through some means. This does neatly work around the problem; the hosts may now speak to one another. I don't understand this. Could you elaborate? It seems to me that the simplest network imaginable should still operate on link local addresses. To use a link local address, you also have to supply the application with the interface name for it to be used upon. The application has to pass this as an extra argument when opening a socket; it isn't part of the regular gethostbyname/socket/connect. Provided you have applications that have a separate dialog field for the interface name so LL's can be used, you're probably going to be entering in the IPv6 LL address in all its glory. First, you are not going to have LL addresses in /etc/resolv.conf because you can't list interface names there (I think it is the same for other OS's analogues of their nameservers list), and second people are not going to be very well motivated to put LL addresses in DNS because those addresses are not globally applicable; they would have to use DNS views. So it is not really very realistic to expect LL to actually be used except to bootstrap. Maybe it's possible for some proprietary printer or fileshare network stuff to continue working on LL's (or, ironically, routing protocols or DHCPv6 itself), but anywhere else (mail.example.com, contacts.example.com), anywhere real, and the network goes dark. Unless of course it can fall back on native IPv4, or has entered a bogus covering /64. -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpK1IOWTvfyQ.pgp Description: PGP signature
Re: IPv6 Deployment for the LAN
Iljitsch van Beijnum wrote: On 22 okt 2009, at 22:52, Mark Smith wrote: Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Stop trying to break the internet and I'll treat you like an adult. Great way to shoot down your own credibility. Just because you don't have or don't understand problems other people have doesn't mean they don't have them or they're invalid. When people want something which is clearly a bad idea (doing default gateways in DHCPv6 the same way as in DHCPv4) and they ignore it when a better solution is suggested (having a DHCP option that allows a DHCPv6 server to tell hosts which of the available routers to use) then the discussion tends to take a turn for the worse. Thats your opinion. However ICMP router advertisment and before that RIP have always been available to provide default router in IPv4 and the userbase has already decided which they prefer. History is not on your side on this one. That doesnt mean that DHCPv6 could not do a better job, such as being able to configure hosts with multiple specific routes, including a default one, or being able to tell hosts to use RA or which potential RA learnt gateways should be used and in which preference order. But requiring default gateway information be learnt from RA and that RA be operational for DHCPv6 operation is as clearly to me a bad idea as is allowing people to use DHCP with ipv6 in a manner they have come to rely on it for IPv4 is to you. A DHCP server that requires a working router RA is like having a 3 legged race. But wouldn't hardcoding a prefix length also be a bad idea? We now pretty much always have /64 but there are just enough exceptions to make it dangerous to just assume /64. There is no reason to assume we will be stuck with /64. Once upon a time nobody thought subnet masks would ever be anything longer than /24 /16 or /8 depending on the first few bits in the address. I dont think that lasted very long and was completely erased by CIDR adoption. The one lesson we should be taking from that is not to assign magic and sacred powers to bit boundaries. However, I firmly believe that whether is done with DHCPv6 it will continue to have problems. Even if DHCPv6 itself would operate well and consistently in all cases, then there are still the permuations between hosts that support stateless autoconfig and not DHCP, those that support both, those that are configured to only do DHCP, those that listen for the M/O bits and those that don't... So in effect, you are saying that now that this mess has been created over peoples strenuous objections that they are forced to live with it? Thats not going to win any arguments. And in any effect, you are probably making the point that using non /64 subnet lengths with a properly operational DHCPv6 is actually a good idea for those who wish to completely skip all RA. Joe
Re: IPv6 Deployment for the LAN
On Thu, 2009-10-22 at 16:16 -0700, David W. Hankins wrote: Unless of course it can fall back on native IPv4, or has entered a bogus covering /64. I think it was really this that I was wanting more info on. Entered where? Sorry to be obtuse, clearly I am missing something obvious. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: IPv6 Deployment for the LAN
Ray Soucy wrote: Others may have their specific requests from vendors, but here are mine: 1. Include DHCPv6 client functionality as part of any IPv6 implementation. 2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure. I can agree with that. I would also add that there is plenty of work that can be done to DHCP, such as adding full route support, multiple gateways with preference and even transitioning from a binary only protocol. A lot of the frustration seems to come from Windows ICS acting as an IPv6 router. I think everyone here has been after Microsoft to either remove ICS or make it more difficult to enable at one point or another. While a rogue RA can come from anywhere, Windows is usually the guilty party. I would argue that since NAT is not a component of IPv6, NAT wasnt a component of IPv4 until it was already had widespread adoption. I remain completely unconvinced that people will not continue to perceive value in PAT6 between their private and their public subnets. And of course, different forms of NAT are almost certainly required to try to make ipv4 and ipv6 interoperate for as long as people need it to. no host should be implementing ICS-like functionality for IPv6. It's unlikely that there would be a situation on an IPv6 network that a host needed to share it's IPv6 address to get others online. Just my thoughts. Maybe someone from Microsoft who can do something about it lurks on this list. Good luck. Joe
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Thu, Oct 22, 2009 at 03:57:40PM -0400, Ray Soucy wrote: Really. How do we deal with rouge DHCP on the wireless LAN, obviously this is such a complex issue that we couldn't possibly have a solution that could be applied to RA. There are some wireless equipment that claim to have a setting that forces all packets through the wireless bridge (where all traffic is between clients and bridge, and never client to client), and so one can filter DHCPv6 and maybe RA, but I am kind of skeptical about how much of this is elective and dependent upon client implementation... In both cases there may still be some wireless adapters that receive bogus packets directly from attackers. And then you bring ND into the question and wonder why you bothered with either RA or DHCP filtering. DHCPv6 (and DHCPv4 with RFC 3118) has per-message cryptographic authentication. The problem however has been the key distribution model. Here it all falls down, and leads to poor deployment. But with DHCPv*, we have a hope that we can secure it if we can solve that last problem (and at least I think we can). So if you accept that as an outcome, one must ponder the question: How long will people accept that a secured DHCPv6 session must rely, in order to function to expectations, upon the unsecurable RA and/or questionably secure SEND? -- David W. HankinsIf you don't do it right the first time, Software Engineeryou'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins pgpf4lygcPQdK.pgp Description: PGP signature
Re: IPv6 Deployment for the LAN
trej...@gmail.com wrote: WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over.
Re: {SPAM?} Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 2:31 PM, TJ wrote: Then let me say it. RA needs to be able to be completely turned off. DHCPv6 needs to be able to completely configure all requesting hosts. Those two statements are not synonymous ... They may not be synonymous, but, there is a set of operators for whom both are true. Sure, leave RA in the IPv6 stack. The market will decide, and we will see if it is still on by default on soho routers and in IOS 15.4T in 2015. That is a more sensible statement. And were I to be a gambling man I would say it will indeed be on by default ... we'll talk more about it then :). Also, I would like to add - there is a difference between the default gateway information and other things, such as NTP|DNS|SIP server information. Maybe. The default gateway, by definition, is an on-link thing. IMHO, this makes the router a good source for information about the router. It does in some cases. In other cases, it does not. I am not saying use cases for fully spec'ed DHCPv6 don't exist or should be ignored. Making the router capable of sharing the missing piece that covers ~95% of use cases is also a Good Thing. I don't think most people are arguing that it should not be possible to configure a network for RA/SLAAC with the RA providing the gateway information. In fact, I think most of us would like to see RA/SLAAC capable of providing the other needed pieces of the puzzle. That said, there is a group of operators for whom RA is a bad thing, SLAAC is also a bad thing, and, their current usage of DHCPv4 does not map to any existing IPv6 technology, so, they are crying foul and want their needs addressed. I think that is 100% legitimate, regardless of whether Iljitsch thinks we are old enough to play with power tools or not. Thinking out loud, we could also re-create the idea of an auto-magic DNS by creating a special use case within ULA-space - say FD00::/96, saving the last 32 bits for something like ::53 and using anycast. That's a fine solution for part of the problem space, but, moving the router assignment function for hosts to a device controlled by the host administrator is a necessary administrative boundary issue for a number of organizations. *(Could abstract same idea to any stateless and/or light-session-based service ... FD00::123 for Automagic ULA-based anycast NTP, etc. Need 32 bits if we don't want to hex convert the things, just in case ...)* NOOO... If you're going to do fd00:: for this, the 123 case really should be fd00::7b, not fd00::123 Owen
Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 4:12 PM, Karl Auer wrote: On Thu, 2009-10-22 at 11:03 -0400, Kevin Loch wrote: If, on the other hand, the REAL desire is to have a DHCP server break the tie in the selection between several routers that advertise their presence, that wouldn't be unreasonable. In some configurations not all hosts are supposed to use the same router. We need the _option_ to specify a default gateway and have the override any RA's a host may see. It would be a tool, and if someone wants to use a tool, they can. It won't be my thumb they hit :-) But I can't see how a DHCP server can know enough about the routers to be able to send out useful discrimination information. So it will have to be manually entered, or come from an IPAM, or... Current practice in the environments I know that are doing this is that groups of hosts are maintained in a database (including MAC addresses) and this database is used to build the DHCP configuration. The host group is assigned a default router address which is actually a VRRP group address. The routers then elect an appropriate VRRP active/standby configuration and the hosts route via the Active router for their VRRP group. If the host administrators find that a host needs to be part of a different VRRP group for whatever reason, there are tools at their disposal to address that issue. DHCP lease times can be short since the addresses are actually static anyway (yes, lots of people use DHCP to assign static addresses in production environments because it allows table-driven central management of host assignment). Nor can I see how the DHCP server can identify the routers to the host except by their addresses, and these can change or be removed without the DHCP server finding out. In most environments I know, there are addresses reserved for the VRRP groups that the routers participate in and the router administrators are well aware of the damage they will bring if they change them without extensive planning and notice. The only way I can see it working is if the host were smart enough to compare the DHCP router discrimination info with the information it has received via RA and delete mismatches, or possibly just revert to using RA information if any mismatches at all are detected. That would be an item the DHCP server could specify as well - what to do in case of a mismatch. It could even be specified on a per-router basis, though the whole thing seems to be getting a bit unwieldy now. That would be a terrible choice because you have eliminated one of the key reasons that some installations need DHCP to assign router information instead of RA. While what you propose is probably technically cleaner from a pure protocol design perspective, the reality is that pure protocol design is not how the real world thinks or operates. In the real world, one must make the protocol adapt to the business rules and other odd parameters that don't always make logical sense from a protocol design perspective. This is one such example when you have different administrative groups responsible for hosts and routers. SARCASMI know it is rare to find an enterprise where the network infrastructure is not run by the same group that does the systems administration./SARCASM But in many of these organizations, this means that having the router specify the default gateway to the host is not going to work well for the systems administrators. In today's world, they don't have to worry about this and, the network group, surprisingly, is pretty good at keeping the VRRP groups numbered as they are supposed to be (usually .1, .2, etc. or .254, .253, .252, etc., or whatever the first/last addresses of a segment happen to be). The DHCP servers will not be on the same subnets as all the routers involved, so they can't sniff the RAs themselves - unless we set up an RA relay... hmm. They don't need to. I don't see DHCP-delivered router preferences as being something that will break the Internet. In the vast majority of cases they will be unnecessary. For those that do need it though, and if it can be done, why not? Why do router preferences instead of just routers? Sure, the DHCP server doesn't know which router should be doing the routing, but, VRRP can take care of that as it does today. The DHCP server just needs to assign the VRRP group. Owen \
Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 4:27 PM, Joe Maimon wrote: Ray Soucy wrote: Others may have their specific requests from vendors, but here are mine: 1. Include DHCPv6 client functionality as part of any IPv6 implementation. 2. Support RA-gaurd and DHCPv6 snooping in L2 network infrastructure. I can agree with that. I would also add that there is plenty of work that can be done to DHCP, such as adding full route support, multiple gateways with preference and even transitioning from a binary only protocol. A lot of the frustration seems to come from Windows ICS acting as an IPv6 router. I think everyone here has been after Microsoft to either remove ICS or make it more difficult to enable at one point or another. While a rogue RA can come from anywhere, Windows is usually the guilty party. I would argue that since NAT is not a component of IPv6, NAT wasnt a component of IPv4 until it was already had widespread adoption. I remain completely unconvinced that people will not continue to perceive value in PAT6 between their private and their public subnets. People may perceive value, but, I truly hope that they won't be able to obtain the functionality. It's just a very bad idea that does terrible things to the network. NAT/PAT was a necessary evil in IPv4 to extend the lifetime of the addressing until IPv6 could be almost ready. It should be allowed to die with IPv4. And of course, different forms of NAT are almost certainly required to try to make ipv4 and ipv6 interoperate for as long as people need it to. Sort of, but, yeah. That's OK. Unfortunate, but, OK. I actually think that now that we have a transfer market policy, IPv4 will probably die much faster than it would have otherwise. Owen
Re: IPv6 Deployment for the LAN
On Oct 22, 2009, at 5:00 PM, Perry Lorier wrote: trej...@gmail.com wrote: WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. I thought ULA-C was dead... Did someone resurrect this unfortunate bad idea? ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over. Why pull this out of ULA? Why not pull it out of /16 or one of the other reserved prefixes? Owen
RE: IPv6 Deployment for the LAN ... anycast
WRT Anycast DNS; Perhaps a special-case of ULA, FD00::53? You want to allow for more than one for obvious fault isolation and load balancing reasons. The draft suggested using prefix:::1 FWIW - I think simple anycast fits that bill. I personally would suggest getting a well known ULA-C allocation assigned to IANA, then use prefix::protocol assignment:1 prefix::protocol assignment:2 and prefix::protocol assignment:3, where protocol assignment could be 0035 for DNS, and 007b for NTP, and if you're feeling adventurous you could use 0019 for outgoing SMTP relay. IMHO non-hex-converted port numbers works cleanly ... ? I thought ULA-C was dead... Did someone resurrect this unfortunate bad idea? Anything is dead until someone uses it. I was thinking FD00 just to have symmetry with anyone using ULAs today, so FC00::/8 could be outright blocked ... ? FC may make sense as they are, de facto, registered ... ... Heck, start a registry (@IANA) and add in FD00::101, etc. ... Maybe reserve FD00::/96 for this type of ULA port-based anycast allocation. (16bits would only reach w/o hex-conversion (if hex-converted could reserve FD00::/112 ... But would be less obvious)) Thinking further, if simply based on port#s wouldn't even need a registry. Unless it was decided to implement the multiple-addresses-per-function mentioned above, then perhaps useful. Easily identified, not globally routable, can be pre-programmed in implementations/applications ... ? Exactly, seems easy, straight forward, robust, reliable and allows for things like fate sharing and fail over. Why pull this out of ULA? Why not pull it out of /16 or one of the other reserved prefixes? ULAs are already defined as internally routable, but not globally routable - which is exactly how I would envision these being used. IOW, seemed to make sense to me! /TJ
Re: IPv6 Deployment for the LAN
On 18 okt 2009, at 5:51, Karl Auer wrote: Do the advertisements right, advise sysadmins that hosts should not do SLAAC, Doesn't it tell you something that you're fighting this hard to avoid hosts from doing what comes naturally? It occurs to me that I haven't met anyone who uses the term SLAAC who uses IPv6 in a way that I would consider normal. (Or at all.)
Re: IPv6 Deployment for the LAN
On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. And DHCPv6 is just a case of very bad design, don't expect it to work well without bending over backwards even farther than you're used to with DHCPv4. It's time for this DHC stuff to reach its final resting place.
Re: IPv6 Deployment for the LAN
Iljitsch, On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. [...] It's time for this DHC stuff to reach its final resting place. I'm curious: are you anticipating IPv4 network operators are willing/interested/planning on redesigning/rebuilding their entire provisioning and backend systems in order to support IPv6? Regards, -drc
Re: IPv6 Deployment for the LAN
On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. Fate sharing between the device that advertises the presence of a router and the device that forwards packets makes RAs much more robust than DHCPv4. And DHCPv6 is just a case of very bad design, don't expect it to work well without bending over backwards even farther than you're used to with DHCPv4. It's time for this DHC stuff to reach its final resting place. You keep arguing this and you're still wrong. There are very good reasons that some people need this in their real world networks. I'm happy for you that you don't need or want to run DHCPv6 in your environment. I'm somewhat happy for me that I almost don't need it in mine. However, making it available as an option in DHCPv6 allows the end- user/operator to choose the technology that fits their needs best. I do not know why you are so determined to prevent this choice at the operator level. Owen
Re: IPv6 Deployment for the LAN
On 21 okt 2009, at 21:50, David Conrad wrote: On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. [...] It's time for this DHC stuff to reach its final resting place. I'm curious: are you anticipating IPv4 network operators are willing/ interested/planning on redesigning/rebuilding their entire provisioning and backend systems in order to support IPv6? No. Hence the low IPv6 utilization. Then again, if we remove all the improvements from IPv6 what's the point of adopting it? The problem with DHCP is that it is an old answer to an even older question. Strangely, DHCPv6 is even worse in this regard than DCHPv4. Some protocol designers were clearly sleeping on the job there, or they were to busy getting in the way of those of us who wanted a non- DHCP way to configure DNS resolvers. Whathever the reason, DHCPv6 is riddled with a badly specified way to interact with manual configuration and stateless autoconfig, it lacks a prefix length option and it has two modes, where the server knows which mode should be used but the client has to guess the right one. In this day and age it doesn't make an iota worth of sense to update binary protocols on two sides whenever there is something new to discover. What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration. Of course that's not going to happen but taking stuff away from IPv6 that actually works (RA fate sharing) isn't going to solve the DHCPv6 problems.
Re: IPv6 Deployment for the LAN
I respectfully disagree. In my opinion there is no future for IPv6 that doesn't involve DHCPv6. DHCPv6 is part of the design of IPv6 as is clear by the existence of M, O, and A flags in RA. Without DHCPv6, SLAAC has no way to provide DNS (or other) configuration information, the fact that IPv6 was designed in a way where SLAAC could be used for addressing and DHCPv6 for other configuration is an example of how DHCPv6 is an integral component of IPv6. SLAAC was designed to make IPv6 work out of the box for ad-hoc networks (link local scope for example). It's increasingly clear that the designers never intended for SLAAC to replace DHCPv6 or that DHCPv6 wasn't a necessary part of IPv6, especially once you deploy it in an enterprise environment. What we've seen is a community of early adopters who are so eager to deploy IPv6 that they're willing to make compromises that most would question. I think we need to get into the mindset that any implementation of IPv6 that doesn't include a DHCPv6 client is as incomplete as one that doesn't support ICMPv6. Support from vendors will eventually fall into place. If more of the so-called advocates of IPv6 would stop talking about how DHCPv6 isn't necessary it would likely happen more quickly. Both SLAAC and DHCPv6 have their roles to fill; both are required. As for the use of the term SLAAC... it's usage is pretty widespread. On Wed, Oct 21, 2009 at 3:42 PM, Iljitsch van Beijnum iljit...@muada.com wrote: On 18 okt 2009, at 5:51, Karl Auer wrote: Do the advertisements right, advise sysadmins that hosts should not do SLAAC, Doesn't it tell you something that you're fighting this hard to avoid hosts from doing what comes naturally? It occurs to me that I haven't met anyone who uses the term SLAAC who uses IPv6 in a way that I would consider normal. (Or at all.) -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On 21 okt 2009, at 21:55, Owen DeLong wrote: However, making it available as an option in DHCPv6 allows the end- user/operator to choose the technology that fits their needs best. I do not know why you are so determined to prevent this choice at the operator level. For the same reason that we don't let the kids play with the powertools: giving them what they want here just makes everything end in tears. If people want to run DHCPv6, fine, we're all adults. If they want to go to the IETF and fix what's wrong with DHCPv6, so much the better. But taking the information from the place where we can make sure it's correct and putting it in a place where we can only guess so we break the network regularly is A VERY BAD IDEA.
Re: IPv6 Deployment for the LAN
On Oct 21, 2009, at 1:08 PM, Ray Soucy wrote: Without DHCPv6, SLAAC has no way to provide DNS (or other) configuration information, the fact that IPv6 was designed in a way where SLAAC could be used for addressing and DHCPv6 for other configuration is an example of how DHCPv6 is an integral component of IPv6. Didn't RFC 4339 cover most of this? http://tools.ietf.org/html/rfc4339
Re: IPv6 Deployment for the LAN
Once upon a time, Iljitsch van Beijnum iljit...@muada.com said: What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration. You want to invent yet _another_ form of configuration management? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: IPv6 Deployment for the LAN
On 21 okt 2009, at 22:23, Chris Adams wrote: What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration. You want to invent yet _another_ form of configuration management? Short answer: no, life is too short and I have other problems that need solving. Long answer: what we have now is a mess, if we want to clean up the mess we have to get it right, and putting new options in binary protocols is not right in any way, shape or form.
[DHCPv6] was Re: IPv6 Deployment for the LAN
We have networks and businesses to run. Why are we rehashing this yet again? For example, in December 200l http://www.merit.edu/mail.archives/nanog/2007-12/msg00280.html shows messages regarding exactly this issue. for emphasis I redundantly requote, You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Just in case the URL is faulty, here is the primary content of the referenced page of NANOG list history: And, besides the list forwarded below, Designated printers, Preferred DNS Servers, and, maybe, more. Even in a large enterprise, the ratio of routers to DHCP servers makes control of many end system parameters via DHCP a management win compared to configuration of routers with this non-network core data. (In case I was to abstruse, It is cheaper to maintain end system parameters in a smaller number of DHCP servers than in a larger number of routers.) This is completely separate from the fact that many experienced router engineers are smart enough configure routers with NTP server addresses in preference to DNS names, and likewise for many other parameters. The end system population has requirements which respond much more dynamically to business requirements than do router configurations, which respond mostly to wiring configurations which are, by comparison, static. The statement that DHCP is not needed for IPv6 packet routing may well be exactly accurate. The absence of good DHCP support in IPv6 has costly consequences for enterprise management, of which IP routing is a small part. You have seen this before from me: Consider the Customer/Business Management viewpoint, not just that of routing packets around between boxes. Pull your head out of your patch panel and look at all the business requirements. If you can show me a more cost effective way to distribute all the parameters mentioned here to all end systems, I'll support it. In the meantime, don't use religious arguments to prevent me from using whatever is appropriate to manage my business. I'll even use NAT boxes, if there is no equivalently affordable stateful firewall box! Cutler Begin forwarded message: From: Leo Bicknell bickn...@xxx Date: December 27, 2007 7:33:08 PM EST To: North American Network Operators Group na...@x Subject: Re: v6 subnet size for DSL leased line customers In a message written on Thu, Dec 27, 2007 at 10:57:59PM +0100, Iljitsch van Beijnum wrote: It is wih IPv6: you just connect the ethernet cable and the RAs take care of the rest. _You_ _really_ _don't_ _need_ _DHCP_ _for_ _IPv6_. If you need extreme control then manual configuration will give you that, which may be appropriate in some cases, such as servers. Really. I didn't know RA's could: - Configure NTP servers for me. - Tell me where to netboot from. - Enter dynamic DNS entries in the DNS tree for me. - Tell me my domain name. - Tell me the VLAN to use for IP Telephony. Those are things I use on a regular basis I'd really rather not manually configure. -- Leo Bicknell - bickn...@xxx - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-requ...@, www.tmbg.org James R. Cutler james.cut...@consultant.com
Re: IPv6 Deployment for the LAN
What we have now is not a mess. What we have is a solid base to build on. The problem is in education, the fact that both stateless and stateful configuration are valid components to IPv6 for example, and proper implementation by vendors. There are a few challenges with IPv6 that need to be worked out, like RA-gaurd and DHCPv6 snooping, for example, but the core of IPv6 was generally done right. Reading this thread can get rather frustrating, what I've gotten out of the most recent exchange is that the combined suggestion is to add DNS to RA, and to add gateway information to DHCPv6. Well, DHCPv6 already handles DNS quite nicely (and DHCPv6 is about more than just DNS mind you), and RA does a perfect job handling gateway selection. I would love to understand how you feel that the roles of RA and DHCPv6 should be swapped. On Wed, Oct 21, 2009 at 4:33 PM, Iljitsch van Beijnum iljit...@muada.com wrote: On 21 okt 2009, at 22:23, Chris Adams wrote: What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration. You want to invent yet _another_ form of configuration management? Short answer: no, life is too short and I have other problems that need solving. Long answer: what we have now is a mess, if we want to clean up the mess we have to get it right, and putting new options in binary protocols is not right in any way, shape or form. -- Ray Soucy Communications Specialist +1 (207) 561-3526 Communications and Network Services University of Maine System http://www.maine.edu/
Re: IPv6 Deployment for the LAN
On Oct 21, 2009, at 1:08 PM, Iljitsch van Beijnum wrote: On 21 okt 2009, at 21:55, Owen DeLong wrote: However, making it available as an option in DHCPv6 allows the end- user/operator to choose the technology that fits their needs best. I do not know why you are so determined to prevent this choice at the operator level. For the same reason that we don't let the kids play with the powertools: giving them what they want here just makes everything end in tears. If people want to run DHCPv6, fine, we're all adults. If they want to go to the IETF and fix what's wrong with DHCPv6, so much the better. But taking the information from the place where we can make sure it's correct and putting it in a place where we can only guess so we break the network regularly is A VERY BAD IDEA. You're incorporating a lot of assertions into your statement there. The assumption that the router knows it is correct for every host on a given LAN simply does not map to reality deployed today. DHCPv4 router assignments don't end in tears for the most part today, and, I don't think that DHCPv6 router assignment would be any more broken than the RA system. In many cases, it will be less broken. The assumption that all routers of a given priority are equal for all hosts on a given LAN also doesn't quite work out. DHCPv4 allows me to have multiple sets of VRRP addresses and balance my outbound routing from large LAN segments (imagine a /22 full of 10-g servers pushing ~6G each into a set of routers... Because they're a rendering farm, and the software is somewhat brain-dead, they need to be in the same broadcast domain.) (Yes, I know that broadcast goes away in IPv6, but, this can just as easily be a link-local multicast). With DHCPv4, I can assign different VRRP groups to the systems (with different IPv4 unicast addresses) based either on mac-addresses, or whatever other criteria I choose. Please explain to me how I can achieve this functionality in RA/SLAAC or stop pushing to prevent it from being available in DHCPv6. Seriously, we're all adults. So treating us like children and taking away the power tools is not appreciated. Owen
Re: IPv6 Deployment for the LAN
On Oct 21, 2009, at 1:05 PM, Iljitsch van Beijnum wrote: On 21 okt 2009, at 21:50, David Conrad wrote: On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote: On 18 okt 2009, at 10:03, Andy Davidson wrote: Support default-routing options for DHCPv6 ! This would be a big mistake. [...] It's time for this DHC stuff to reach its final resting place. I'm curious: are you anticipating IPv4 network operators are willing/interested/planning on redesigning/rebuilding their entire provisioning and backend systems in order to support IPv6? No. Hence the low IPv6 utilization. Then again, if we remove all the improvements from IPv6 what's the point of adopting it? Bigger address space -- The only real improvement in IPv6. The problem with DHCP is that it is an old answer to an even older question. Strangely, DHCPv6 is even worse in this regard than DCHPv4. Some protocol designers were clearly sleeping on the job there, or they were to busy getting in the way of those of us who wanted a non-DHCP way to configure DNS resolvers. Whathever the reason, DHCPv6 is riddled with a badly specified way to interact with manual configuration and stateless autoconfig, it lacks a prefix length option and it has two modes, where the server knows which mode should be used but the client has to guess the right one. I agree that DHCPv6 should be fixed, but, fixing it should include adding the ability to assign routing information. In this day and age it doesn't make an iota worth of sense to update binary protocols on two sides whenever there is something new to discover. What we need is a thing that gives us what we need to connect to the network (addresses, DNS servers) and then a pointer in the form of an HTTP or HTTPS URL for all other configuration. Yes and no. RA giving out DNS information and a pointer might help, but, it doesn't solve everything. There is functionality provided by DHCPv4 today that is not available in DHCPv6, RA, or SLAAC or any combination. This must get resolved. It is an impediment to IPv6 adoption in the real world. The other features and improvements are all well and good if they work and they don't prevent the protocol from being accepted and/or deployed in the real world. With less than two years of remaining IANA IPv4 free pool, I think it is far more important that we get a deployable protocol with bigger addresses than one which contains a bunch of other features that aren't universally regarded as an improvement at the cost of existing functionality that has demand from real network operators. Of course that's not going to happen but taking stuff away from IPv6 that actually works (RA fate sharing) isn't going to solve the DHCPv6 problems. Nobody is proposing taking RA away from networks that want to use it. We're proposing making it an option to assign router information in DHCPv6. So, given that the question isnt' taking away what you want, can we please now add capabilities that many people actually need? Owen
Re: IPv6 Deployment for the LAN
- Original Message From: Iljitsch van Beijnum iljit...@muada.com Then again, if we remove all the improvements from IPv6 what's the point of adopting it? How about IPv4 address depletion? I'm perfectly happy with how my network works. I do, however, want it to keep growing, and this requires more addresses. The requirement for organizations with thousands (or in some cases millions) of deployed customers to dramatically change how they can associate an IP address with customer ports (or provide remote configuration of said customers' devices) is not an attractive feature. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
