Re: Cogent HE
On Fri, Jun 10, 2011 at 2:18 AM, Jimmy Hess mysi...@gmail.com wrote: HE doesn't need to buy IPv6 transit, because they are in effect transit-free (except to Cogent). It's not just a Cogent issue. They also chose not to buy from Level3 or buy those routes through a Level3 peer: From HE's route-server: route-server sh bgp ipv6 regexp _3356_ % No Results route-server sh bgp ipv6 regexp _174_ % No Results - Andy
Re: Quick comparison of LSNs and NAT64
On Thu, Jun 09, 2011 at 06:39:18PM -0400, Jeff Hartley wrote: We've been using two workarounds: 1. Separate DNS resolvers (both BIND 9.8; one DNS64 and the other DNS6). Have the client provisioning system assign the appropriate DNS server IPs (dual-stack to anycast set 1, v6-only to anycast set 2). 2. Use range-specific views to determine whether or not to apply DNS64 (this setup isn't standard BIND, though). One is a kludge, and the other is vendor-specific, but they work. Not for SLAAC environments and others where there is no mandatory endpoint registration. E.g. residential LANs. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Quick comparison of LSNs and NAT64
On Fri, Jun 10, 2011 at 09:29:47AM +1000, Mark Andrews wrote: DS-lite and NAT444 don't break existing applications. They do, to different degrees. There is plenty of evidence for that. Each solution fits well for some set of constraints and objectives Pick your poison. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Cogent IPv6
Here in the Netherlands we got it 'free' (i.e. dual-stack on top of the IPv4 transit without extra cost) But we're currently looking into an alternative for a provider with non-broken IPv6 transit and cancel our contract with Cogent. They called us once asking how satisfied we were with their IPv6 transit. After bringing up the HE issue the conversation ended surprisingly fast. The Google depeering thing was the final straw, all our transits can provide a reasonably complete IPv6 prefix table, except for Cogent. On 6/9/11 7:14 PM, Jeff Wheeler wrote: but just two weeks ago I heard about this IPv6 surcharge stupidity still being applied to Cogent's customers in Europe. -- Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeh...@easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl
Re: Ready For A Good Laugh
On Friday 10 Jun 2011 05:31:44 Michael Painter wrote: Jimi Thompson wrote: Now I'm going to go off on you people - What kind of crack are you people smoking? The same stuff they're smoking over at PayPal. Some genius decided to send out E-mails which said: Hello name removed, It looks like you may be using an outdated browser with known security issues. Help keep your computer and your PayPal account protected by updating your browser today. and included a link (different from what was represented). Even magaged to fool the folks at sp...@paypal.com 11 pages of wtf? at: https://www.paypal-community.com/t5/Fraud-phishing-and-spoof/New-scam/td- p/273626 PayPal has been doing this for as long as I've been a member. They are terrible ones for sending out e-mails to teach you to type passwords into the spam. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them signature.asc Description: This is a digitally signed message part.
The stupidity of trying to fix DHCPv6
On 9 jun 2011, at 19:37, Nick Hilliard wrote: DHCPv6 does not provide route information because this task is handled by RA in IPv6. Thankfully this silliness is in the process of being fixed, So where do I point out the stupidity of trying to fix this non-brokenness? along with prefix delegation Also works fine. - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers. Good luck with that. Next month, the last major operating system will add support for DHCPv6. Which was published in 2003. So now you want to change some more stuff so in 2019 we can finally actually start USING DHCPv6?
IPv6 routing protocols
On 9 jun 2011, at 19:41, Nick Hilliard wrote: Iljitsch noted: IPv6 routing protocols also pretty much only use link locals. This is not true in the general case. So which routing protocols communicate using global addresses then? As far as I know only BGP but BGP runs over TCP so it's different from all other routing protocols. And it still carries link local next hop addresses.
Re: The stupidity of trying to fix DHCPv6
DHCPv6 does not provide route information because this task is handled by RA in IPv6. Thankfully this silliness is in the process of being fixed, So where do I point out the stupidity of trying to fix this non-brokenness? Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. - so in future, there will be no requirement for either RA or cartloads of per-interface configuration on routers. Good luck with that. Next month, the last major operating system will add support for DHCPv6. Which was published in 2003. So now you want to change some more stuff so in 2019 we can finally actually start USING DHCPv6? We're planning to use DHCPv6 and RA (with no prefixes, only for the link local next hop). This is more complex than using DHCPv6 alone, without RA, would be. When and if DHCPv6 without RA is possible, we certainly plan to turn off RA on our BRAS boxes. Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 12:10, sth...@nethelp.no wrote: So where do I point out the stupidity of trying to fix this non-brokenness? Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. It is a mistake to want this, because having the router tell you who the router is gives you fait sharing so less breakage. It's also unnecessary because you still need cooperation from your switches to be safe from rogue DHCPv6 servers even if you go visit all your hosts and turn off stateless autoconfig in an effort to thwart rogue RAs. But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. We're planning to use DHCPv6 and RA (with no prefixes, only for the link local next hop). This is more complex than using DHCPv6 alone, without RA, would be. It is. It's also more robust. And doing this is less complex than trying to change DHCPv6 so you get to use a less complex system in the future after a complex transition.
Re: IPv6 routing protocols
On 10/06/2011 11:03, Iljitsch van Beijnum wrote: As far as I know only BGP but BGP runs over TCP so it's different from all other routing protocols. OSPF runs over protocol ospf, so it's also different from the other routing protocols. EIGRP uses protocol 88 and ISIS runs over CLNS so both of them must be different too. On the other hand, RIP runs on UDP, so I guess that it must be the same as all the other routing protocols. (sorry, but I'm lost as to what point you were making here :-) And it still carries link local next hop addresses. it's a bit more subtle than that - it depends on how the underlying router operating system handles next-hop resolution and how you configure your BGP. Nick
Re: IPv6 routing protocols
On 10 jun 2011, at 12:20, Nick Hilliard wrote: [nothing to support his earlier claim] And it still carries link local next hop addresses. it's a bit more subtle than that - it depends on how the underlying router operating system handles next-hop resolution and how you configure your BGP. It doesn't depend. RFC 4760: An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute.
Re: IPv6 routing protocols
On 10 jun 2011, at 12:27, Iljitsch van Beijnum wrote: RFC 4760: An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute. Sorry, this is stupid. I should have read beyond LOCAL. So it depends a little, but I still don't see any implementation leeway in RFC 2545: 3. Constructing the Next Hop field A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop. The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field. The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16).
Re: The stupidity of trying to fix DHCPv6
On 10 Jun 2011, at 11:20, Iljitsch van Beijnum wrote: On 10 jun 2011, at 12:10, sth...@nethelp.no wrote: So where do I point out the stupidity of trying to fix this non-brokenness? Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. It is a mistake to want this, because having the router tell you who the router is gives you fait sharing so less breakage. It's also unnecessary because you still need cooperation from your switches to be safe from rogue DHCPv6 servers even if you go visit all your hosts and turn off stateless autoconfig in an effort to thwart rogue RAs. But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. Well, remember that, from Google's estimate, only 0.3% of the access networks are IPv6 capable, so there's still 99.7% to deploy. But yes, any changes to add features a la draft-droms-dhc-dhcpv6-default-router-00 would take time, and support in the IETF seems minimal. We're planning to use DHCPv6 and RA (with no prefixes, only for the link local next hop). This is more complex than using DHCPv6 alone, without RA, would be. It is. It's also more robust. And doing this is less complex than trying to change DHCPv6 so you get to use a less complex system in the future after a complex transition. The focus right now should be on getting the existing RA+DHCPv6 to work as intended, and to validate the model within the 0.3% base. I don't buy that a transition from RA+DHCP to DHCP-only is particularly complex though. Turn off the RAs and let DHCP do it's (extra) things. However, you'd then need to know that every device you want to network supports that new DHCP-only operation, and that will be some time off, if it happens at all. Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. Tim
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 12:40, Tim Chown wrote: But it's stupid to want to change DHCPv6 just now the last major OS is about to start supporting it. That continues the current situation where anyone who isn't happy with autoconfig-only can't make a configuration that works will all major OSes. Well, remember that, from Google's estimate, only 0.3% of the access networks are IPv6 capable, so there's still 99.7% to deploy. There's deployment of code and deployment of configuration. The former is in good shape now, so better not tinker with it unnecessarily. It's also not very useful to count the 80% of the internet that consists of home users behind the cheapest home gateway running with the default settings the same way as we count the other 20% who actually have an opinion on the matter. I don't buy that a transition from RA+DHCP to DHCP-only is particularly complex though. Turn off the RAs and let DHCP do it's (extra) things. Well, but if you turn off RAs while there are still systems that can't understand a new DHCPv6 router address option, then those systems have no idea where the routers are so they don't work. Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. The trouble is that having the correct router NOT send RAs buys you very little: in theory you can now skip coordination between different departments if the DHCPv6 and router configs are handled by different people. In practice, you need to coordinate regardless because the routers need to know where to send the packets so they need to have the prefixes that the DHCPv6 servers assign from configured on their interfaces. What you really want is for the hosts to ignore RAs sent by incorrect routers. This means turning off autoconfig on the hosts, which seems, at the very least, an uphill struggle unless we're talking about places with hosts bolted to the floor so the configuration can be tied to a specific network. And in that case you can do tons of other stuff, such as SEND or simply statically configuring everything. Lest anyone accuse me of raining on their parade: I think very workable compromise would be to have a router preference option in DHCPv6. This way, routers still advertise themselves, but if there are multiple routers, the DHCPv6 info is the tie breaker so rogue RAs are avoided when this option is understood. But doing this doesn't impose difficulties on hosts that don't implement the new option.
Strongest Solar Tsunami in Years to Hit Earth Today
http://www.ibtimes.com/articles/159964/20110609/nasa-solar-flare-tsunami-earth-sun-radio-satellite-interference-aurora-displays-coronal-mass-ejectio.htm -Hank
Re: IPv6 routing protocols
On 10/06/2011 11:37, Iljitsch van Beijnum wrote: So it depends a little, but I still don't see any implementation leeway in RFC 2545: On all competently constructed interior networks, ibgp will use loopbacks as the session endpoints. This means that the loopback address will be carried as the next-hop in the UPDATE messages rather than the link local address. Ok, you can do physical interface to physical interface on ibgp if you want, and if you do, good luck with that idea. For those bgp sessions which use directly connected subnets (e.g. most ebgp and badly configured interior networks), this is implementation dependent. Some stacks by default provide both the link-local and the global address; others provide just the global address; others still will provide link-local depending on interface configuration (e.g. the per-interface ipv6 enable command on IOS). Once the router has learned the next-hop, it may or may not choose to display it differently when you're displaying ipv6 forwarding information. Some router stacks implement implicit next-hop resolution for their own RIB to forwarding table; others don't. Some will display this information and others don't. So really, it depends. Nick
Re: IPv6 routing protocols
On 10 jun 2011, at 14:26, Nick Hilliard wrote: [...] Of course none of this supports your original claim: IPv6 routing protocols also pretty much only use link locals. This is not true in the general case.
Re: The stupidity of trying to fix DHCPv6
Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. This +1. There are plenty of enterprises, employing actual network engineers (allegedly), who are just about getting to grips with CIDR and VLSM. They are *thinking* about reconfiguring their hosts to stop having 10.x.x.x/8 as the interface address, and letting proxy-arp on the routers worry about which subnets are which. They *might* have been convinced that an ATM cloud (or sometimes even MPLS!) has robust traffic separation, and they don't need a full mesh of leased lines any more. IPv6 is hugely scary as it is, without breaking their hosts and host info / routers and routing info silo model. Not all of the networking world runs on Internet time :( Regards, Tim.
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 10:10 AM, sth...@nethelp.no wrote: DHCPv6 does not provide route information because this task is handled by RA in IPv6. Thankfully this silliness is in the process of being fixed, So where do I point out the stupidity of trying to fix this non-brokenness? Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. I wonder if it's just a violation of rule #1: stop thinking legacy! People are used to what they have done for a decade or two. It's hard to see the change and results in why is this all so different and complicated?. It's hard to open ones mind for the new, but it is essential to do with new technology. So I advice people not to get trapped by their legacy habits! /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.
Re: The stupidity of trying to fix DHCPv6
Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. I wonder if it's just a violation of rule #1: stop thinking legacy! If having a significant infrastructure that supports IPv4 DHCP is legacy, yes then you could argue that this is legacy. Stop thinking legacy is easy to say - however, it has a very real *cost* if you need to change large parts of this infrastructure. From my own point of view, I also regard the dependency DHCPv6 on RA as a completely *unnecessary* dependency which has been introduced with IPv6. I would much rather have DHCPv6 as a protocol that can be operated on its own, without RA. [Yes, you would still need Neighbor Discovery / Neighbor Solicitation.] Steinar Haug, Nethelp consulting, sth...@nethelp.no
Re: Strongest Solar Tsunami in Years to Hit Earth Today
On Jun 10, 2011, at 8:22 AM, Hank Nussbacher wrote: http://www.ibtimes.com/articles/159964/20110609/nasa-solar-flare-tsunami-earth-sun-radio-satellite-interference-aurora-displays-coronal-mass-ejectio.htm -Hank If you are interested in the actual event, watch the AIA video of the explosion (flare) itself in the highest bandwidth you can tolerate : http://sohowww.nascom.nasa.gov/hotshots/index.html/ Regards Marshall
Re: The stupidity of trying to fix DHCPv6
My goodness, this argument comes up a lot. Firstly, RA isn't broken, and DHCPv6 isn't broken. Second, work IS being done to provide DHCPv6 with a method of handing out additional routing information: http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-01 So I'm not sure what all the fuss is about here. Third, the point of keeping RA and DHCPv6 separate was exactly this. You make a change to RA and it will take 10 years to get implemented; you add a feature to DHCPv6 and you have a good chance of seeing it adopted in months rather than years. While I support the route option in DHCPv6; I support it for administrators who need non-standard routing setups because they're stuck on some archaic topology that they are unable to migrate away from. I'd counter the OPs assertion that RA is silly with the suggestion of using DHCPv6 only and not RA is even more silly. The router knows if it's up, the router knows what it's connected to, the router can making routing decisions in real time. The DHCPv6 server has no idea if the router is up or what it's connected to beyond what it's been told, and because updates are infrequent it makes any changes take very long. You still need to protect against rogue DHCPv6, and it still needs to be done at the switch. Not really sure what everyone is so worked up about here, aside from wanting IPv6 to be more like IPv4 (ignoring that they were probably the ones complaining about IPv4 working this way when they were migrating away from Apple Talk or IPX). On Fri, Jun 10, 2011 at 8:48 AM, Tim Franklin t...@pelican.org wrote: Standing back a little, I can see an argument that IPv6 would be an easier 'sell' if there were two modes of operation, one with only RAs, and one with only DHCPv6. This +1. There are plenty of enterprises, employing actual network engineers (allegedly), who are just about getting to grips with CIDR and VLSM. They are *thinking* about reconfiguring their hosts to stop having 10.x.x.x/8 as the interface address, and letting proxy-arp on the routers worry about which subnets are which. They *might* have been convinced that an ATM cloud (or sometimes even MPLS!) has robust traffic separation, and they don't need a full mesh of leased lines any more. IPv6 is hugely scary as it is, without breaking their hosts and host info / routers and routing info silo model. Not all of the networking world runs on Internet time :( Regards, Tim. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: The stupidity of trying to fix DHCPv6
In a message written on Fri, Jun 10, 2011 at 01:03:01PM +, Bjoern A. Zeeb wrote: On Jun 10, 2011, at 10:10 AM, sth...@nethelp.no wrote: Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. I wonder if it's just a violation of rule #1: stop thinking legacy! People are used to what they have done for a decade or two. It's hard to see the change and results in why is this all so different and complicated?. It's hard to open ones mind for the new, but it is essential to do with new technology. The problem in this case is that the failure modes are significantly different. Some folks have learned this the hard way. It's a very easy scenario to reconstruct. Consider the branch office router in a typical corporate enviornment. We're talking a device with one WAN port, and one LAN port. Configure it for dual stack, speaking IPv4, and in IPv4 configure it the typical corporate way with a DHCP Helper forwarding requests over the WAN to a central DHCP server. In IPv6, configure it with RA's, the supposed better way. Now, take the 100% working branch router and have it sent back to corporate. Maybe they got a bigger router, maybe the office closed. A network engineer gets the router and is tasked with making it ready to redeploy. The network engineer plugs it into the switch on his desktop, plugs in a serial cable, turns it on and steps out to get a coffee while it boots. He's planning to erase the configuration and then load new software over the network. As soon as the router boots the IPv6 network fails for all the users on his subnet. IPv4 keeps working fine. Oops. What happened? Well, the router sent IPv6 RA's as soon as it came up, and every workstation instantly started using them. In IPv4, the router received DHCPv4 requests and forwarded them per the helper address, except that its WAN port is down, and thus it in fact didn't send them anywhere. The important points: - IPv4 failed safe with the DHCP config. This rogue device will never disrupt the IPv4 configuration. DHCP snooping isn't even needed in your switches, since it never returns a response. - IPv6 failed immediately with the RA configuration. What's worse is if you simply turn the device off after you realized you took down the entire network devices will continue to be broken for 2-4 hours until the RA's time out. The only method to mitigate is to deploy RA guard on all of your switches, which probably means replacing 100% of your hardware with new stuff that can do that, and then deploying new features. The fact of the matter is that the failure modes of these two protocols are vastly different operationally. The DHCP failure semantics are not only better understood, but cause less disruption to the network. Even a properly rouge DHCP server will only damage _new_ clients coming up on a network, existing folks will work just fine. Contrast with RA's which instantly break 100% of the users. Even more annoying is that if I use RA's for the default gateway, I still have to run DHCPv6 anyway. If I don't my boxes don't have DNS servers, NTP servers, know where to tftpboot, etc. It's not a choice of one or the other, it's I always run DHCPv6, do I need RA's or not. Given the failure modes I would much prefer to run with RA's turned off completely, and have DHCPv6 able to provide a default gateway just as it works in IPv4. My opinion comes not from thinking legacy, indeed my employer has been fully dual stacked since 2003. My opinion comes from the fact that in the 8 years of operational experience we have RA's are significantly more fragile, and IMHO not ready for widespread IPv6 deployment. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpK2tojIauJp.pgp Description: PGP signature
Re: Yup; the Internet is screwed up.
On Jun 9, 2011, at 8:43 PM, Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster I would describe this as local market failure. It's common even in highly populated areas, not just rural ones here in the US. What I have observed is the roll-out of the ATT U-verse service (aka internet-lite as it is not possible to disable some of their ALG on the gateway) skip areas along the way to hit higher density neighborhoods. They are getting better with their pair bonding, but many people are unable to get access at the edges of these populated areas. - Jared (who would have rather seen google roll into an entire county that faces these challenges vs major cities)
Re: The stupidity of trying to fix DHCPv6
You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? Honestly. This whole argument is getting ridiculous. On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Fri, Jun 10, 2011 at 01:03:01PM +, Bjoern A. Zeeb wrote: On Jun 10, 2011, at 10:10 AM, sth...@nethelp.no wrote: Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. I wonder if it's just a violation of rule #1: stop thinking legacy! People are used to what they have done for a decade or two. It's hard to see the change and results in why is this all so different and complicated?. It's hard to open ones mind for the new, but it is essential to do with new technology. The problem in this case is that the failure modes are significantly different. Some folks have learned this the hard way. It's a very easy scenario to reconstruct. Consider the branch office router in a typical corporate enviornment. We're talking a device with one WAN port, and one LAN port. Configure it for dual stack, speaking IPv4, and in IPv4 configure it the typical corporate way with a DHCP Helper forwarding requests over the WAN to a central DHCP server. In IPv6, configure it with RA's, the supposed better way. Now, take the 100% working branch router and have it sent back to corporate. Maybe they got a bigger router, maybe the office closed. A network engineer gets the router and is tasked with making it ready to redeploy. The network engineer plugs it into the switch on his desktop, plugs in a serial cable, turns it on and steps out to get a coffee while it boots. He's planning to erase the configuration and then load new software over the network. As soon as the router boots the IPv6 network fails for all the users on his subnet. IPv4 keeps working fine. Oops. What happened? Well, the router sent IPv6 RA's as soon as it came up, and every workstation instantly started using them. In IPv4, the router received DHCPv4 requests and forwarded them per the helper address, except that its WAN port is down, and thus it in fact didn't send them anywhere. The important points: - IPv4 failed safe with the DHCP config. This rogue device will never disrupt the IPv4 configuration. DHCP snooping isn't even needed in your switches, since it never returns a response. - IPv6 failed immediately with the RA configuration. What's worse is if you simply turn the device off after you realized you took down the entire network devices will continue to be broken for 2-4 hours until the RA's time out. The only method to mitigate is to deploy RA guard on all of your switches, which probably means replacing 100% of your hardware with new stuff that can do that, and then deploying new features. The fact of the matter is that the failure modes of these two protocols are vastly different operationally. The DHCP failure semantics are not only better understood, but cause less disruption to the network. Even a properly rouge DHCP server will only damage _new_ clients coming up on a network, existing folks will work just fine. Contrast with RA's which instantly break 100% of the users. Even more annoying is that if I use RA's for the default gateway, I still have to run DHCPv6 anyway. If I don't my boxes don't have DNS servers, NTP servers, know where to tftpboot, etc. It's not a choice of one or the other, it's I always run DHCPv6, do I need RA's or not. Given the failure modes I would much prefer to run with RA's turned off completely, and have DHCPv6 able to provide a default gateway just as it works in IPv4. My opinion comes not from thinking legacy, indeed my employer has been fully dual stacked since 2003. My opinion comes from the fact that in the 8 years of operational experience we have RA's are significantly more fragile, and IMHO not ready for widespread IPv6 deployment. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Yup; the Internet is screwed up.
Once upon a time, Jared Mauch ja...@puck.nether.net said: On Jun 9, 2011, at 8:43 PM, Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster I would describe this as local market failure. It's common even in highly populated areas, not just rural ones here in the US. I'd go so far as to say user failure. If I wanted cable TV (especially if I needed it at home as part of my job), I wouldn't buy/rent/lease/whatever a home without checking that cable TV is available at that location. I live in a city with two cable providers, each of which covers the whole city, yet there are pockets where one (or even both) don't provide service. Before I bought my house, I made sure I could get my preferred Internet service at my house. There are definately things wrong with the state of last-mile Internet access in the US, but moving somewhere without checking is IMHO your own fault. -- 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: The stupidity of trying to fix DHCPv6
In a message written on Fri, Jun 10, 2011 at 09:37:11AM -0400, Ray Soucy wrote: You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? No, I posed the easiest way to recreate this issue. I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card. I've seen entire corporate networks taken out because someone ran the patch cable to the wrong port. The point is, RA's are operationally fragile and DHCP is operationally robust. You can choose to stick your head in the sand about that if you want, but it's still true. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp4tP1jsVsiP.pgp Description: PGP signature
Re: The stupidity of trying to fix DHCPv6
I can also take down a network with spanning-tree, but oh wait, we protect against that don't we. Maybe protecting against rogue RA to begin with would be a better idea than waiting until a problem happens. Just saying. On Fri, Jun 10, 2011 at 9:47 AM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Fri, Jun 10, 2011 at 09:37:11AM -0400, Ray Soucy wrote: You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? No, I posed the easiest way to recreate this issue. I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card. I've seen entire corporate networks taken out because someone ran the patch cable to the wrong port. The point is, RA's are operationally fragile and DHCP is operationally robust. You can choose to stick your head in the sand about that if you want, but it's still true. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Yup; the Internet is screwed up.
I think the point is the ubiquity of access isn't what it should be. On Fri, Jun 10, 2011 at 9:47 AM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jared Mauch ja...@puck.nether.net said: On Jun 9, 2011, at 8:43 PM, Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster I would describe this as local market failure. It's common even in highly populated areas, not just rural ones here in the US. I'd go so far as to say user failure. If I wanted cable TV (especially if I needed it at home as part of my job), I wouldn't buy/rent/lease/whatever a home without checking that cable TV is available at that location. I live in a city with two cable providers, each of which covers the whole city, yet there are pockets where one (or even both) don't provide service. Before I bought my house, I made sure I could get my preferred Internet service at my house. There are definately things wrong with the state of last-mile Internet access in the US, but moving somewhere without checking is IMHO your own fault. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- Kyle Creyts Information Assurance Professional
Re: Yup; the Internet is screwed up.
On Fri, Jun 10, 2011 at 09:47, Chris Adams cmad...@hiwaay.net wrote: I'd go so far as to say user failure. If I wanted cable TV (especially if I needed it at home as part of my job), I wouldn't buy/rent/lease/whatever a home without checking that cable TV is available at that location. Yeah, he messed up, but the social problem is still real. The Internet is now more important than electricity or water -- you can go off the grid or dig your own well, but more and more you can't get a job or talk to the government without web access and email.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 15:47, Leo Bicknell wrote: I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card. Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Are there perhaps easier and more timely ways to solve it? (And it's insane that Windows still exhibits this completely broken behavior.)
Re: The stupidity of trying to fix DHCPv6
On Fri, Jun 10, 2011 at 6:01 AM, Iljitsch van Beijnum iljit...@muada.com wrote: On 9 jun 2011, at 19:37, Nick Hilliard wrote: DHCPv6 does not provide route information because this task is handled by RA in IPv6. Thankfully this silliness is in the process of being fixed, So where do I point out the stupidity of trying to fix this non-brokenness? Hi Iljitsch, There are three schools of thought on that: 1. SLAAC is the optimal way to configure IP addresses under IPv6. DHCPv6 should only facilitate configuration of other things that SLAAC doesn't deal with (e.g. DNS resolver) 2. SLAAC was a clever idea that for a variety of reasons (e.g. the server configuration knowledge leak) isn't panning out. DHCPv6 should replace SLAAC. It should do the same work as IPv4 DHCP, as expected by folks used to IPv4. 3. Give it to me both ways. I'll make the choice I decide is optimal for my network. With my operations hat on, I'm a fan of option #3. I find the theorists' intrusion into my prerogative as a system administrator (option #1) to be disagreeable. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The stupidity of trying to fix DHCPv6
On 10 Jun 2011, at 15:08, Iljitsch van Beijnum wrote: (And it's insane that Windows still exhibits this completely broken behavior.) We could derail into some broken MacOS X behaviour if you like ;) Tim
RE: Yup; the Internet is screwed up.
The umbra of it all. We have jobs though. ~Jay We move the information that moves your world. “Engineering is about finding the sweet spot between what's solvable and what isn't. “Good engineering demands that we understand what we’re doing and why, keep an open mind, and learn from experience.” Radia Perlman If human beings are perceived as potentials rather than problems, as possessing strengths instead of weaknesses, as unlimited rather than dull and unresponsive, then they thrive and grow to their capabilities. Please consider the environment before printing e-mail -Original Message- From: Kyle Creyts [mailto:kyle.cre...@gmail.com] Sent: Friday, June 10, 2011 8:01 AM To: Chris Adams; NANOG Subject: Re: Yup; the Internet is screwed up. I think the point is the ubiquity of access isn't what it should be. On Fri, Jun 10, 2011 at 9:47 AM, Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Jared Mauch ja...@puck.nether.net said: On Jun 9, 2011, at 8:43 PM, Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster I would describe this as local market failure. It's common even in highly populated areas, not just rural ones here in the US. I'd go so far as to say user failure. If I wanted cable TV (especially if I needed it at home as part of my job), I wouldn't buy/rent/lease/whatever a home without checking that cable TV is available at that location. I live in a city with two cable providers, each of which covers the whole city, yet there are pockets where one (or even both) don't provide service. Before I bought my house, I made sure I could get my preferred Internet service at my house. There are definately things wrong with the state of last-mile Internet access in the US, but moving somewhere without checking is IMHO your own fault. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- Kyle Creyts Information Assurance Professional
Re: Yup; the Internet is screwed up.
On Jun 10, 2011, at 10:01 AM, Kyle Creyts wrote: I think the point is the ubiquity of access isn't what it should be. I think there were several good points made in the article. 1) Data caps and how they impact software updates (or downloads) - hughesnet was mentioned but .. Looking to the near future, Apple is selling a 4GB download for $30 in the next month or so. That will have a large impact on networks that day IMHO. If you have a 3G/4G/LTE/whatnot device it makes it impossible to pull down the image without hitting your 5GB or 10GB cap compared to a fixed access network. Even assuming you go to the local Panera/McDonalds/Starbucks/Library access, if you get 2MB/s (16Mb/s) you're talking about 20-25 minutes. Those locales don't usually have that fast of a network though. 2) Last mile is expensive to install and hard to justify for people. This is because of a long history of universal service and subsidization/regulation. In Michigan you could get a phone line installed for $42 (not sure, haven't installed POTS in a long time, may have gone up) regardless of the cost to the carrier. This isn't the case when you want to extend other utilities (eg Gas, electric, water...). People are willing to pay 10k+ to install these services as part of their construction expense. Their other utility cost is masked in part due to the past 100+ years of telecom history. The cost of lighting a 20km strand of fiber at 1Gb/s is somewhere in the $600, including ONT, etc. Many people here on nanog would happily pay that amount. Now, the 12-100k per mile to build the fiber is the hard part to eat. 3) Certainly he did a poor job of site selection. Perhaps he was misled or even lied to. I've faced similar challenges when working with both hardware vendors and carriers out there. The sales peoples eyes get big once you start talking about doing something, but the engineers at the table generally start asking serious questions. (I certainly will not move anywhere that doesn't have a HFC or PON/FTTH network. Sorry ATT/Centurylink/others but the plusses don't justify the minuses). - It's certainly possible that we will see improved last-mile access. The USDA/RUS and DOC/NTIA efforts are to be applauded. If you look at the current ATT + T-Mobile merger people are talking about it will bring broadband to 97% of the country, and help ATT (mobility division) with last-mile/local tower regulatory hurdles. They are not talking about how it will remove the need for data caps that are 1/30th the size of their 150GB cap on their mobile side elements. I suspect there's a lot that could be improved by each market player here, but as happened with Verizon in the Northeast, I expect the less-dense markets will need to have better local service from regional players vs the big guys. Overall this will be good, but the costs will also have to be paid for more with the local subscriber. - Jared
Re: Yup; the Internet is screwed up.
On Jun 10, 2011, at 10:04 AM, Scott Brim wrote: On Fri, Jun 10, 2011 at 09:47, Chris Adams cmad...@hiwaay.net wrote: I'd go so far as to say user failure. If I wanted cable TV (especially if I needed it at home as part of my job), I wouldn't buy/rent/lease/whatever a home without checking that cable TV is available at that location. Yeah, he messed up, but the social problem is still real. The Internet is now more important than electricity or water -- you can go off the grid or dig your own well, but more and more you can't get a job or talk to the government without web access and email. I have an off-the-grid location I can go to. I can get internet access there with a VZ MIFI at speeds of 1Mb/s. What I can't get is a software update over that service to keep my devices secure. The 5GB data cap gets in the way. The current set of iphone/ipad firmware updates are about 700mb per device. Not counting the latest combo updater (or incremental) for MacOS. (Hopefully with the 5.0 software announced they will do OTA updates on a different APN that doesn't count against ones data limits). I don't use windows so not sure what those weigh in at, but they're bound to be a few hundred megs. - Jared
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 16:12, Tim Chown wrote: (And it's insane that Windows still exhibits this completely broken behavior.) We could derail into some broken MacOS X behaviour if you like ;) Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN.
Re: The stupidity of trying to fix DHCPv6
In a message written on Fri, Jun 10, 2011 at 04:08:06PM +0200, Iljitsch van Beijnum wrote: Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Please go back and re-read my original scenario and think about it. The difference here is that if a client gets a DHCP address it generally won't be broken until it tries to renew, and then often won't be broken at renewal because it sends a directed request back. In specific technical terms: DHCP relies on broadcast _ONCE_ at boot, and then uses static unicast config to verify that is still the correct config. RA's use broadcast every few seconds to broadcast new information that everyone is supposed to trust instantly. Turn up a Rogue DHCP server on one of your subnets. It won't affect anyone who's already up and running. It may grab newly booted machines, depending on a race condition, but it won't break anything that is already working. Turn up rogue RA's, and everyone instantly fails. The behavior of these protocols is different, which leads to different failure modes. My assertion is that in every failure mode you can come up with RA's lead to more clients being down faster and for longer periods of time. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpkEAjKS3of3.pgp Description: PGP signature
Re: The stupidity of trying to fix DHCPv6
Windows ICS has been a thorn in everyone's side at one point or another; I for one think that it's been a force for good, though, as it's put protection against rogue RA on people's radar; without ICS I'm sure I'd be having a lot of augments on NANOG about whether or not RA Guard is needed with people saying I run IPv6 without it and never have problems etc. On Fri, Jun 10, 2011 at 10:24 AM, Iljitsch van Beijnum iljit...@muada.com wrote: On 10 jun 2011, at 16:12, Tim Chown wrote: (And it's insane that Windows still exhibits this completely broken behavior.) We could derail into some broken MacOS X behaviour if you like ;) Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: The stupidity of trying to fix DHCPv6
On 10 Jun 2011, at 15:24, Iljitsch van Beijnum wrote: On 10 jun 2011, at 16:12, Tim Chown wrote: (And it's insane that Windows still exhibits this completely broken behavior.) We could derail into some broken MacOS X behaviour if you like ;) Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN. Indeed. Well, hopefully MS is listening to the 6to4-advisory draft. Tim
Re: The stupidity of trying to fix DHCPv6
All I'm saying is that it's generally a bad idea to have different standards for accidental and malicious traffic. Say you were using DHCPv6 for routing; a malicious user could still inject traffic on the network to disrupt service. People get all uppity about RA because vendors have been painfully slow to implement RA Guard. To be fair, RA Guard probably should have been an early RFC as it was an obvious concern even at the time ICMPv6 was being drafted. I for one look forward to the day where things like RA Guard and MLD Snooping are standard on every switch. Just IPv6 growing pains. Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please. On Fri, Jun 10, 2011 at 10:28 AM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Fri, Jun 10, 2011 at 04:08:06PM +0200, Iljitsch van Beijnum wrote: Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Please go back and re-read my original scenario and think about it. The difference here is that if a client gets a DHCP address it generally won't be broken until it tries to renew, and then often won't be broken at renewal because it sends a directed request back. In specific technical terms: DHCP relies on broadcast _ONCE_ at boot, and then uses static unicast config to verify that is still the correct config. RA's use broadcast every few seconds to broadcast new information that everyone is supposed to trust instantly. Turn up a Rogue DHCP server on one of your subnets. It won't affect anyone who's already up and running. It may grab newly booted machines, depending on a race condition, but it won't break anything that is already working. Turn up rogue RA's, and everyone instantly fails. The behavior of these protocols is different, which leads to different failure modes. My assertion is that in every failure mode you can come up with RA's lead to more clients being down faster and for longer periods of time. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Yup; the Internet is screwed up.
Funny, how in the title refers to the Internet globally when the article is specific about the USA. I live in europe and we have at home 100Mbps . Mid sized city of 500k people. Some ISPs even spread WiFi across town so that subscribers can have internet access outside their homes. On Fri, Jun 10, 2011 at 3:22 PM, Jared Mauch ja...@puck.nether.net wrote: On Jun 10, 2011, at 10:04 AM, Scott Brim wrote: On Fri, Jun 10, 2011 at 09:47, Chris Adams cmad...@hiwaay.net wrote: I'd go so far as to say user failure. If I wanted cable TV (especially if I needed it at home as part of my job), I wouldn't buy/rent/lease/whatever a home without checking that cable TV is available at that location. Yeah, he messed up, but the social problem is still real. The Internet is now more important than electricity or water -- you can go off the grid or dig your own well, but more and more you can't get a job or talk to the government without web access and email. I have an off-the-grid location I can go to. I can get internet access there with a VZ MIFI at speeds of 1Mb/s. What I can't get is a software update over that service to keep my devices secure. The 5GB data cap gets in the way. The current set of iphone/ipad firmware updates are about 700mb per device. Not counting the latest combo updater (or incremental) for MacOS. (Hopefully with the 5.0 software announced they will do OTA updates on a different APN that doesn't count against ones data limits). I don't use windows so not sure what those weigh in at, but they're bound to be a few hundred megs. - Jared -- Ricardo Ferreira
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 16:28, Leo Bicknell wrote: Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Please go back and re-read my original scenario and think about it. I don't have to, as you restate pretty much all of it here... So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be compile DHCPv4 for 128 bits but guess what, we have legacy IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off.
Re: IPv6 routing protocols
On Jun 10, 2011, at 3:37 AM, Iljitsch van Beijnum wrote: On 10 jun 2011, at 12:27, Iljitsch van Beijnum wrote: RFC 4760: An UPDATE message that carries the MP_REACH_NLRI MUST also carry the ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP exchanges). Moreover, in IBGP exchanges such a message MUST also carry the LOCAL_PREF attribute. Sorry, this is stupid. I should have read beyond LOCAL. So it depends a little, but I still don't see any implementation leeway in RFC 2545: 3. Constructing the Next Hop field A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop. The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field. The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16). I read that as: If the peer is directly connected and the next hop is local, there is the option of sending both the global unicast address and the link local address for the directly connected link. In all other cases, you must send only the global unicast address of the next hop. That sounds like not using link local in the general case and having it available as an option in the directly adjacent case. Owen
Contact at BNSF Railway
Anyone on here have a contact at BNSF Railway in Fort Worth, Texas, who could contact me off-list? I think something is mucked up with their mail servers and is starting to refuse incoming mail. Don't know if it's just from my domain or more globally, but my company handles the lion's share of BNSF's employee communications, which is fairly critical. --- Andy Ringsmuth andyr...@inebraska.com
Re: The stupidity of trying to fix DHCPv6
In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please. I want that flexability as well, but the IETF won't deliver. The two options delivered so far are: RA's only. DHCPv6 with RA's to learn a default route. I want a third option: DHCPv6 only. I have no desire to remove either of the first two options. In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be compile DHCPv4 for 128 bits but guess what, we have legacy IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. There are various drafts and proposals in the IETF to solve this problem, and they pretty much all focus on the DHCP side of things. You see, in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. To pick on Ray for a moment, the IETF seems to largely have a similar attitude to Ray's. I spent a year or so trying to talk to the various folks involved, only to be told that I didn't understand IPv6, didn't know what I was talking about with respect to how RA's work, and wouldn't want a network with only DHCPv6. I can't tell you how many times I had been told I clearly didn't have enough experience with IPv6, when we've been dual stacked for years. When I do get someone at the IETF who will listen to my operational issues the response is always the same as Ray's. Deploy RA guard. Never mind that until a year or so ago no vendors at all had it. Never mind that even today only a handful of switch models support it. Never mind that it requires me to forklift out every working L2 switch I have just to run IPv6. As far as I can tell the IETF has been killing or stalling the necessary DHCP additions for the better part of 7 years now. If you really want to fix this problem you either need to get a vendor to just implement it and ignore the IETF, or enough operators to go to the IETF meeting with pitchforks that perhaps someone finally listens. I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpYetvKqwpKO.pgp Description: PGP signature
Re: The stupidity of trying to fix DHCPv6
From: Iljitsch van Beijnum iljit...@muada.com Subject: Re: The stupidity of trying to fix DHCPv6 To: Tim Chown t...@ecs.soton.ac.uk Cc: NANOG list nanog@nanog.org (...) Not saying that Apple is perfect, but at least their IPv6-related bugs don't ruin the day for others on the LAN. Let them (Apple) finally (*dooohhh*) fix the 2.4GHz/DHCP bug on the iPad ... Those §$%§$!§!%$§$%-censored didn't make my day, really. :-( #m
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 7:37 AM, Iljitsch van Beijnum wrote: On 10 jun 2011, at 16:28, Leo Bicknell wrote: Ok, so now we've identified the problem. How exactly does adding default gateway information to DHCPv6 solve this problem? Please go back and re-read my original scenario and think about it. I don't have to, as you restate pretty much all of it here... So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be compile DHCPv4 for 128 bits but guess what, we have legacy IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. Seems to me that adding a routing information option to DHCPv6 solves the problem without breaking the legacy hosts. What's wrong with that idea? Owen
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote: In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please. I want that flexability as well, but the IETF won't deliver. The two options delivered so far are: RA's only. Only sort of... This only works if you don't want to auto-configure things like DNS, NTP, etc. I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA. DHCPv6 with RA's to learn a default route. I want a third option: DHCPv6 only. I have no desire to remove either of the first two options. In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be compile DHCPv4 for 128 bits but guess what, we have legacy IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. There are various drafts and proposals in the IETF to solve this problem, and they pretty much all focus on the DHCP side of things. You see, in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. To pick on Ray for a moment, the IETF seems to largely have a similar attitude to Ray's. I spent a year or so trying to talk to the various folks involved, only to be told that I didn't understand IPv6, didn't know what I was talking about with respect to how RA's work, and wouldn't want a network with only DHCPv6. I can't tell you how many times I had been told I clearly didn't have enough experience with IPv6, when we've been dual stacked for years. When I do get someone at the IETF who will listen to my operational issues the response is always the same as Ray's. Deploy RA guard. Never mind that until a year or so ago no vendors at all had it. Never mind that even today only a handful of switch models support it. Never mind that it requires me to forklift out every working L2 switch I have just to run IPv6. As far as I can tell the IETF has been killing or stalling the necessary DHCP additions for the better part of 7 years now. If you really want to fix this problem you either need to get a vendor to just implement it and ignore the IETF, or enough operators to go to the IETF meeting with pitchforks that perhaps someone finally listens. I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: The stupidity of trying to fix DHCPv6
Once upon a time, Owen DeLong o...@delong.com said: I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA. Isn't that what RDNSS (recursive DNS servers) and DNSSL (DNS search list) extensions are? -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: The stupidity of trying to fix DHCPv6
On 6/10/2011 10:53 AM, Owen DeLong wrote: I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA. +1. /Jason
Re: The stupidity of trying to fix DHCPv6
On Fri, Jun 10, 2011 at 10:51 AM, Owen DeLong o...@delong.com wrote: Seems to me that adding a routing information option to DHCPv6 solves the problem without breaking the legacy hosts. What's wrong with that idea? Owen Thank you, Owen. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 16:47, Leo Bicknell wrote: So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. Don't you realize that this doesn't solve anything? The whole point of stateless autoconfig and DHCP is to allow a host that arrives without any prior knowledge about the network to be configured without human intervention so it can communicate over the network. So we must assume a host with no prior configuration. All currently existing IPv6 hosts that I'm aware of have stateless autoconfig enabled by default (save for some *X distros that assume the system will be some kind of server). So if you put such a host with an updated DHCPv6 implementation in a network with rogue RAs, they will autoconfigure addresses in the advertised prefixes exactly the same as today. Like I said before: removing the correct information from RAs does nothing to get rid of the incorrect information in RAs. Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: 1. No longer the fait sharing that comes from RA-learned gateway addresses 2. Old and new hosts may use different gateways on the same network So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority. This way, if there are no rogue RAs the behavior is the same for unupdated and updated hosts. If there are rogue RAs, the updated hosts ignore them. If system administrators screw up and the DHCPv6 info doesn't match the actual routers, everything still works except that there is no rogue RA protection. This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of legacy IPv6 hosts that need RAs to function and won't go away anytime soon.
Re: The stupidity of trying to fix DHCPv6
On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong o...@delong.com wrote: Only sort of... This only works if you don't want to auto-configure things like DNS, NTP, etc. I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA. The RA's aren't really supposed to be for configuring applications. DNS and NTP are applications in the IPv4 and IPv6 paradigms, not core protocol functions. Another approach to the problem would be defining anycast addresses (in the IPv4 sense of anycast) defined as nearest DNS resolver and nearest NTP server. You then make a request directed to that anycast address to discover the unicast addresses of the servers you should be using. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: The stupidity of trying to fix DHCPv6
In a message written on Fri, Jun 10, 2011 at 05:13:09PM +0200, Iljitsch van Beijnum wrote: Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: 1. No longer the fait sharing that comes from RA-learned gateway addresses I proport that VRRPv6 is a superior solution to have redundant gateways than using RA's to broadcast both and let the host choose. 2. Old and new hosts may use different gateways on the same network This problem already exists. Have IPv4 hosts come up with IPv4, change the gateway on the server, and let some new hosts come up. I agree having two different methods to configure a default gateway is silly. You can do it in IPv4, broadcast a default route in RIP and learn one via DHCP. I'm going to assume operators aren't going to do such stupid things. So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority. I think that would probably be an acceptable solution. I'm pondering that off the top of my head, but I don't see any major, crazy flaws. My guess is that most networks that use DHCPv6 will disable RA's completely on the routers. Sure, they can't disable rogue RA's until more switches support filtering them, but that will happen over time. This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of legacy IPv6 hosts that need RAs to function and won't go away anytime soon. You have now hit my greatest frustration on the head. This problem has been known and documented for 7-8 years, at least. I believe the first time I saw RA's take down a conference network was in 2005. Proposed solutions have been floating around almost as long. We could have solved this before a lot of hosts were deployed. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: The stupidity of trying to fix DHCPv6
I don't mind being picked on; and I hope I don't come off as hostile. It's all in good fun. I'm really kind of a young punk compared to a lot of people on list, and there usually isn't a day that goes by where something I said the previous day comes back to haunt me. ;-) I think we have a lot of IPv6 that is usable, and better than IPv4, in place already. People were complaining about DHCPv6 being useless and saying everything should be SLAAC; then we started seeing good client and server implementations for DHCPv6 and people started coming around. As you roll out IPv6 you're going to make some mistakes, you're going to learn a bit, and you're going to look back at comments you made in the past and laugh a little. My idea of IPv6 a year ago was very different than it is today; tough today I have IPv6 deployed state-wide on an RE network, and have met a lot of the technical and political challenges that I never anticipated along the way. Given that IPv6 has taken so long to implement to begin with, I usually have a negative reaction to people marching in on a pony and telling everyone how IPv6 needs to be re-written because it could be better. I don't see the DHCPv6 route option being viable as the primary method for default nexthop for several years. It not only needs to become an actual standard, but then it needs to be implemented, and you need to wait out the legacy systems. So what we have for IPv6 today is generally a good starting point. I'm of the mindset that it's reasonable to expect more form network switches, so RA Guard being a requirement for IPv6, while a messy transition, is something I'm OK with in the long run. The addressing piece is something a lot of people get hung up on because it's very, very different than IPv4, and it's the first thing people new to IPv6 are exposed to; but I think once you understand it it's not really a roadblock from deployment. The next step is figuring out how we deliver IPv6 to the SMB that currently makes use of a dinky Dual-WAN NAT box for redundancy. We don't want these guys in the BGP tables; but we don't want to tell them that they're stuck with a single provider either. I think that's where things start to get a lot more interesting, not all this DHCPv6 vs SLAAC talk ;-) On Fri, Jun 10, 2011 at 10:47 AM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please. I want that flexability as well, but the IETF won't deliver. The two options delivered so far are: RA's only. DHCPv6 with RA's to learn a default route. I want a third option: DHCPv6 only. I have no desire to remove either of the first two options. In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be compile DHCPv4 for 128 bits but guess what, we have legacy IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. There are various drafts and proposals in the IETF to solve this problem, and they pretty much all focus on the DHCP side of things. You see, in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. To pick on Ray for a moment, the IETF seems to largely have a similar attitude to Ray's. I spent a year or so trying to talk to the various folks involved, only to be told that I didn't understand IPv6, didn't know what I was talking about with respect to how RA's work, and wouldn't want a network with only DHCPv6. I can't tell you how many times I had been told I clearly didn't have enough experience with IPv6, when we've been dual stacked for years. When I do get someone at the IETF who will listen to my operational issues the response is always the same as Ray's. Deploy RA guard. Never mind that until a year or so ago no vendors at all had it. Never mind that even today only a handful of switch models support it. Never mind that it requires me to forklift out every working L2 switch I have just to run IPv6. As far as I can tell the IETF has been killing or stalling the necessary DHCP additions for the better part of 7 years now. If you really want to fix this problem you either need to get a vendor to just implement it and ignore the IETF, or enough operators to go to the IETF meeting with pitchforks that perhaps someone
Re: IPv6 routing protocols
That sounds like not using link local in the general case and having it available as an option in the directly adjacent case. I'd like to second that. All in all, protocol nexthop has to be reachable via IGP, otherwise, your v6 routes won't be installed in the forwarding table. By its name, I would think link local addresses are meant to be used only on a link, not igp. Best, Leon
Re: The stupidity of trying to fix DHCPv6
On Fri, 10 Jun 2011, Leo Bicknell wrote: In a message written on Fri, Jun 10, 2011 at 09:37:11AM -0400, Ray Soucy wrote: You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? No, I posed the easiest way to recreate this issue. I've seen the entire NANOG and IETF lans taken out because some dork enabled microsoft connecting sharing to their cell card. I've seen entire corporate networks taken out because someone ran the patch cable to the wrong port. The point is, RA's are operationally fragile and DHCP is operationally robust. You can choose to stick your head in the sand about that if you want, but it's still true. I don't see, why do you claim that DHCP is more robust, than SLAAC. I have seen half day outage due to broken/misbehaving DHCP server I agree with Wiliam Herrin: have both SLAAC and DHCPv6 as an option. Give me both waysAnd probably I will use both... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882
Re: The stupidity of trying to fix DHCPv6
There is almost no difference between having RA give out DNS information, and having an other only DHCPv6 server from a software standpoint. The difference is that DHCPv6 is in the application space, while RA is in the kernel space. It's easier to modify DHCPv6 than RA; so over time when we add options, we don't need to go back and modify the IPv6 implementation in every OS; just update the DHCPv6 client. We could just re-name DHCPv6 other-only mode and call it Extended RA if you like; it wouldn't even require any code change. Most routers that support IPv6 also support running an Other Only (stateless) DHCPv6 server; it's like 3 lines of configuration and costs next to nothing. We haven't seen any DHCPv6 client implementations for other only but it would be equally trivial to write them. I think the general feeling, though, is that a full DHCPv6 client should be considered a requirement for any host regardless of if the network makes use of DHCPv6 for address assignment or not. On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong o...@delong.com wrote: On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote: In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please. I want that flexability as well, but the IETF won't deliver. The two options delivered so far are: RA's only. Only sort of... This only works if you don't want to auto-configure things like DNS, NTP, etc. I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA. DHCPv6 with RA's to learn a default route. I want a third option: DHCPv6 only. I have no desire to remove either of the first two options. In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be compile DHCPv4 for 128 bits but guess what, we have legacy IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. There are various drafts and proposals in the IETF to solve this problem, and they pretty much all focus on the DHCP side of things. You see, in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. To pick on Ray for a moment, the IETF seems to largely have a similar attitude to Ray's. I spent a year or so trying to talk to the various folks involved, only to be told that I didn't understand IPv6, didn't know what I was talking about with respect to how RA's work, and wouldn't want a network with only DHCPv6. I can't tell you how many times I had been told I clearly didn't have enough experience with IPv6, when we've been dual stacked for years. When I do get someone at the IETF who will listen to my operational issues the response is always the same as Ray's. Deploy RA guard. Never mind that until a year or so ago no vendors at all had it. Never mind that even today only a handful of switch models support it. Never mind that it requires me to forklift out every working L2 switch I have just to run IPv6. As far as I can tell the IETF has been killing or stalling the necessary DHCP additions for the better part of 7 years now. If you really want to fix this problem you either need to get a vendor to just implement it and ignore the IETF, or enough operators to go to the IETF meeting with pitchforks that perhaps someone finally listens. I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: The stupidity of trying to fix DHCPv6
On a side note; I think the RDNSS stuff was pretty silly. Now instead of hosts having a DHCPv6 client, they have a DHCPv6 client AND and RDNSS client. Two services instead of one to do essentially the same thing. That's been my biggest issue with the let's add things to RA movement. On Fri, Jun 10, 2011 at 11:38 AM, Ray Soucy r...@maine.edu wrote: There is almost no difference between having RA give out DNS information, and having an other only DHCPv6 server from a software standpoint. The difference is that DHCPv6 is in the application space, while RA is in the kernel space. It's easier to modify DHCPv6 than RA; so over time when we add options, we don't need to go back and modify the IPv6 implementation in every OS; just update the DHCPv6 client. We could just re-name DHCPv6 other-only mode and call it Extended RA if you like; it wouldn't even require any code change. Most routers that support IPv6 also support running an Other Only (stateless) DHCPv6 server; it's like 3 lines of configuration and costs next to nothing. We haven't seen any DHCPv6 client implementations for other only but it would be equally trivial to write them. I think the general feeling, though, is that a full DHCPv6 client should be considered a requirement for any host regardless of if the network makes use of DHCPv6 for address assignment or not. On Fri, Jun 10, 2011 at 10:53 AM, Owen DeLong o...@delong.com wrote: On Jun 10, 2011, at 7:47 AM, Leo Bicknell wrote: In a message written on Fri, Jun 10, 2011 at 10:34:57AM -0400, Ray Soucy wrote: Also agree that I want flexibility to use RA or DHCPv6; the disagreement is that RA needs to be removed or changed from IPv6. Don't go breaking my IPv6 stack for your own ambitions, please. I want that flexability as well, but the IETF won't deliver. The two options delivered so far are: RA's only. Only sort of... This only works if you don't want to auto-configure things like DNS, NTP, etc. I would like to see both protocols made optionally complete, so, in addition to fixing DHCPv6 by adding routing information options, I'd also like to see something done where it would be possible to add at least DNS servers to RA. DHCPv6 with RA's to learn a default route. I want a third option: DHCPv6 only. I have no desire to remove either of the first two options. In a message written on Fri, Jun 10, 2011 at 04:37:24PM +0200, Iljitsch van Beijnum wrote: So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. In a greenfield situation that solution could be compile DHCPv4 for 128 bits but guess what, we have legacy IPv6 systems that aren't compatible with that, and we want results before those systems are all killed off. There are various drafts and proposals in the IETF to solve this problem, and they pretty much all focus on the DHCP side of things. You see, in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. To pick on Ray for a moment, the IETF seems to largely have a similar attitude to Ray's. I spent a year or so trying to talk to the various folks involved, only to be told that I didn't understand IPv6, didn't know what I was talking about with respect to how RA's work, and wouldn't want a network with only DHCPv6. I can't tell you how many times I had been told I clearly didn't have enough experience with IPv6, when we've been dual stacked for years. When I do get someone at the IETF who will listen to my operational issues the response is always the same as Ray's. Deploy RA guard. Never mind that until a year or so ago no vendors at all had it. Never mind that even today only a handful of switch models support it. Never mind that it requires me to forklift out every working L2 switch I have just to run IPv6. As far as I can tell the IETF has been killing or stalling the necessary DHCP additions for the better part of 7 years now. If you really want to fix this problem you either need to get a vendor to just implement it and ignore the IETF, or enough operators to go to the IETF meeting with pitchforks that perhaps someone finally listens. I really beieve this is going to be the single largest impediment to deploying _end user_ IPv6. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 17:26, Leo Bicknell wrote: 1. No longer the fait sharing that comes from RA-learned gateway addresses I proport that VRRPv6 is a superior solution to have redundant gateways than using RA's to broadcast both and let the host choose. It's not about redundancy, it's about misconfiguration. You can't misconfigure an RA to provide the wrong gateway address because the gateway address is the source address of the packet. My guess is that most networks that use DHCPv6 will disable RA's completely on the routers. Haven't you been paying attention? One of my main points is that you can't do that for many years to come, becasue CURRENT hosts require them. It took us 8 years to get from the publication of the DHCPv6 RFC to the deployment of DHCPv6 in all big operating systems. What's the point of doing all kinds of stuff now just so you can turn off RAs in 2019? By that time the switches will have all the necessary options so the problem is moot. I'm going to assume operators aren't going to do such stupid things. Not sure what universe you live in. In mine, if you give people a way to misconfigure, a good number of them will do so. And a small but vocal group will defend their misconfiguration and claim that this is really the best way to run their network, all the while complaining to their vendors and the IETF about the problems that this creates and that those need to be solved.
Re: The stupidity of trying to fix DHCPv6
In a message written on Fri, Jun 10, 2011 at 05:49:51PM +0200, Iljitsch van Beijnum wrote: One of my main points is that you can't do that for many years to come, becasue CURRENT hosts require them. It took us 8 years to get from the publication of the DHCPv6 RFC to the deployment of DHCPv6 in all big operating systems. What's the point of doing all kinds of stuff now just so you can turn off RAs in 2019? By that time the switches will have all the necessary options so the problem is moot. You may be correct for folks who deploy the free public WiFi at the local beverage vendor. However, many networks are much more closed deployments. Enterprises have not deployed IPv6 internally yet. Many will not deploy it for another 3-5 years, chosing instead to use web proxies at the edge that speak IPv4 (RFC1918) internally and IPv6 externally. They often can enforce the software deployed on the boxes connected. I very much think there are a lot of people who could deploy RA-less networks in the timeframe you describe, if and only if the standard to do so where published. If we had a standard today you could have patches from a vendor in a year, and still be well before many of these folks deploy anything. The fact that bad standards and software exist today should never be an argument to not design and deploy better software. So what if it takes until 2019, at least from 2019 to the end of IPv6 we'll have something better. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp3h7iNCBaKz.pgp Description: PGP signature
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 7:34 AM, Ray Soucy wrote: I for one look forward to the day where things like RA Guard and MLD Snooping are standard on every switch. Just IPv6 growing pains. I look forward to the day where layer 2 switches don't need to implement hacks to fix layer 3 flaws. Matthew Kaufman
Re: The stupidity of trying to fix DHCPv6
On 6/10/2011 11:22 AM, Matthew Kaufman wrote: On Jun 10, 2011, at 7:34 AM, Ray Soucy wrote: I for one look forward to the day where things like RA Guard and MLD Snooping are standard on every switch. Just IPv6 growing pains. I look forward to the day where layer 2 switches don't need to implement hacks to fix layer 3 flaws. Matthew Kaufman We already have that. Run everything as a point to point for layer 2, and there's no need to implement hacks. :P Granted, RA Guard could also be handled transparent to the layer 2 switches, but that requires a common security model to inform the devices who they are allowed to listen to. MLD Snooping is just a problem of the switch being too stupid to know which ports to send multicast out. It's technically not required if there's a layer 2 protocol to inform the switch, but those are in limited supply. Both issues often suffer heavily from multi-vendor interoperability problems. Jack
RE: Thank you Microsoft (and others)
I've been saved by the sound of Microsoft. ~Jay We move the information that moves your world. “Engineering is about finding the sweet spot between what's solvable and what isn't. “Good engineering demands that we understand what we’re doing and why, keep an open mind, and learn from experience.” Radia Perlman Please consider the environment before printing e-mail -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Wednesday, June 08, 2011 7:20 PM To: Shahid Shafi Cc: NANOG list Subject: Thank you Microsoft (and others) I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) - Jared On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: I dont think ISOC dashboard is updating any more. Google is no longer advertising but dashboard still shows green and TTLs were short on those records.
Re: The stupidity of trying to fix DHCPv6
Sent from my iPad On Jun 10, 2011, at 10:13, Iljitsch van Beijnum iljit...@muada.com wrote: On 10 jun 2011, at 16:47, Leo Bicknell wrote: So we agree on the problem. Now the only thing we have to do is come up with a solution that everybody likes. in DHCPv6 it was decided to not implment a field for the default gateway or subnet mask, under the logic that the former was learned via RA's, and the latter was always a /64. While it's not quite as trivial as adding those two fields, it's not that much more complex. The right behavior for a host that comes up and sees no RA's needs to be documented. Don't you realize that this doesn't solve anything? Actually, it does. It doesn't solve the problem you choose to argue about below. That problem is addressed by RA Guard. However, it does solve a different problem. Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate router or otherwise. There are situations, for example, where the administrator does not want all hosts in a broadcast domain to receive the same set of prefixes and/or the same set of routers. This can be achieved by using different parameters based on the system identifier in the DHCP configuration. It cannot be achieved using RA. The whole point of stateless autoconfig and DHCP is to allow a host that arrives without any prior knowledge about the network to be configured without human intervention so it can communicate over the network. Sure, but... So we must assume a host with no prior configuration. All currently existing IPv6 hosts that I'm aware of have stateless autoconfig enabled by default (save for some *X distros that assume the system will be some kind of server). So if you put such a host with an updated DHCPv6 implementation in a network with rogue RAs, they will autoconfigure addresses in the advertised prefixes exactly the same as today. Like I said before: removing the correct information from RAs does nothing to get rid of the incorrect information in RAs. Eliminating rogue RAs is not the problem being described. That problem is solved through RA-Guard. The problem being described is the desire to be able to configure a host from zero to functionally on the internet using DHCP without RAs. I think everyone understands that you don't want to do so. That's fine. However, adding the functionality to DHCPv6 doesn't require you to use it. Making it available for operators that want to use it is not a bad thing. Now you could argue that the DHCPv6-supplied gateway addresses should have higher priority than the ones learned from RAs. At least that solves the problem. However, that solution still has two issues: 1. No longer the fait sharing that comes from RA-learned gateway addresses 2. Old and new hosts may use different gateways on the same network In some situations, this fate (it's fate, not fait, btw) sharing is not desired. In some situations, the use of VRRP is a more useful alternative. So my suggestion is: learn gateway addresses from RAs as we do today, but in addition create a DHCPv6 option that contains gateway addresses, and then when a gateway address is in the DHCPv6 list, it gets a higher priority. That would be a fine partial solution. However, it is desirable (IMHO) to provide for a more generic DHCPv6 option that allows one to convey routing information so that DHCPv6 could be used to convey a predetermined static routing table of arbitrary complexity. (yes, this would usually be a single default route, but, there are circumstances where it is desirable for a host to have additional static routes). This way, if there are no rogue RAs the behavior is the same for unupdated and updated hosts. If there are rogue RAs, the updated hosts ignore them. If system administrators screw up and the DHCPv6 info doesn't match the actual routers, everything still works except that there is no rogue RA protection. This should make everyone happy except those so set in their IPv4 ways that they insist on removing RAs. Which is not only a bad idea, but an exercise in futility because of the large number of legacy IPv6 hosts that need RAs to function and won't go away anytime soon. I think it's a fine solution as far as it goes and a good part of a complete solution. However, documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. As it currently stands, some hosts which are DHCPv6 capable will not attempt to query DHCP until they receive an RA with the M bit set. Yes, there will be an issue with legacy IPv6 hosts needing to catch up with the protocol change for some time. However, this has been the case with many changes over time in IPv4 as well. Look at the transition from BootP to DHCP. Administrators are actually capable of adapting to or in some cases influencing the level of required hardware/software
Re: The stupidity of trying to fix DHCPv6
On 06/10/2011 12:32 PM, Owen DeLong wrote: I think it's a fine solution as far as it goes and a good part of a complete solution. However, documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. As it currently stands, some hosts which are DHCPv6 capable will not attempt to query DHCP until they receive an RA with the M bit set. If we go down this path, how long before we hear screaming about rogue DHCPv6 servers giving v4-only networks a false v6 path? (At least that could be nullified by adding actual v6 support and an RA without the M bit.) Jima
Re: The stupidity of trying to fix DHCPv6
On Fri, 10 Jun 2011 12:54:17 CDT, Jima said: If we go down this path, how long before we hear screaming about rogue DHCPv6 servers giving v4-only networks a false v6 path? Already happened. Good way to install an MITM against any v6-enabled boxes on a v4-only network, been multiple reported uses of that technique. pgp1srm18rxHv.pgp Description: PGP signature
RE: Thank you Microsoft (and others)
Thank you for the thanks :) We'll be leaving the www.xbox.com web properties online indefinitely. We're holding on other properties but are moving forward at a brisk pace. Best, Chris -Original Message- From: Murphy, Jay, DOH [mailto:jay.mur...@state.nm.us] Sent: Friday, June 10, 2011 9:49 AM To: Jared Mauch; Shahid Shafi Cc: NANOG list Subject: RE: Thank you Microsoft (and others) I've been saved by the sound of Microsoft. ~Jay We move the information that moves your world. “Engineering is about finding the sweet spot between what's solvable and what isn't. “Good engineering demands that we understand what we’re doing and why, keep an open mind, and learn from experience.” Radia Perlman Please consider the environment before printing e-mail -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Wednesday, June 08, 2011 7:20 PM To: Shahid Shafi Cc: NANOG list Subject: Thank you Microsoft (and others) I think it's important to thank Microsoft for leaving sites like xbox IPv6 enabled. Hope many other participants leave it on as well. I think it's a certain sign of the maturity of the protocol and networks at this stage of the game. I have observed some traffic step-down in the network, but it's not entirely clear if it's lowered to levels pre-v6-day. Looking forward to those sharing data at NANOG next week. (I'm not convinced the data I have is worth sharing, but will send it over to the nanogpc soon enough..) - Jared On Jun 8, 2011, at 9:09 PM, Shahid Shafi wrote: I dont think ISOC dashboard is updating any more. Google is no longer advertising but dashboard still shows green and TTLs were short on those records.
Re: The stupidity of trying to fix DHCPv6
On 06/10/2011 09:37 AM, Ray Soucy wrote: You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? You are the moron - this stuff happens and wishing it didn't doesn't stop it. Get a clue! Honestly. This whole argument is getting ridiculous. On Fri, Jun 10, 2011 at 9:32 AM, Leo Bicknellbickn...@ufp.org wrote: In a message written on Fri, Jun 10, 2011 at 01:03:01PM +, Bjoern A. Zeeb wrote: On Jun 10, 2011, at 10:10 AM, sth...@nethelp.no wrote: Several large operators have said, repeatedly, that they want to use DHCPv6 without RA. I disagree that this is stupid. I wonder if it's just a violation of rule #1: stop thinking legacy! People are used to what they have done for a decade or two. It's hard to see the change and results in why is this all so different and complicated?. It's hard to open ones mind for the new, but it is essential to do with new technology. The problem in this case is that the failure modes are significantly different. Some folks have learned this the hard way. It's a very easy scenario to reconstruct. Consider the branch office router in a typical corporate enviornment. We're talking a device with one WAN port, and one LAN port. Configure it for dual stack, speaking IPv4, and in IPv4 configure it the typical corporate way with a DHCP Helper forwarding requests over the WAN to a central DHCP server. In IPv6, configure it with RA's, the supposed better way. Now, take the 100% working branch router and have it sent back to corporate. Maybe they got a bigger router, maybe the office closed. A network engineer gets the router and is tasked with making it ready to redeploy. The network engineer plugs it into the switch on his desktop, plugs in a serial cable, turns it on and steps out to get a coffee while it boots. He's planning to erase the configuration and then load new software over the network. As soon as the router boots the IPv6 network fails for all the users on his subnet. IPv4 keeps working fine. Oops. What happened? Well, the router sent IPv6 RA's as soon as it came up, and every workstation instantly started using them. In IPv4, the router received DHCPv4 requests and forwarded them per the helper address, except that its WAN port is down, and thus it in fact didn't send them anywhere. The important points: - IPv4 failed safe with the DHCP config. This rogue device will never disrupt the IPv4 configuration. DHCP snooping isn't even needed in your switches, since it never returns a response. - IPv6 failed immediately with the RA configuration. What's worse is if you simply turn the device off after you realized you took down the entire network devices will continue to be broken for 2-4 hours until the RA's time out. The only method to mitigate is to deploy RA guard on all of your switches, which probably means replacing 100% of your hardware with new stuff that can do that, and then deploying new features. The fact of the matter is that the failure modes of these two protocols are vastly different operationally. The DHCP failure semantics are not only better understood, but cause less disruption to the network. Even a properly rouge DHCP server will only damage _new_ clients coming up on a network, existing folks will work just fine. Contrast with RA's which instantly break 100% of the users. Even more annoying is that if I use RA's for the default gateway, I still have to run DHCPv6 anyway. If I don't my boxes don't have DNS servers, NTP servers, know where to tftpboot, etc. It's not a choice of one or the other, it's I always run DHCPv6, do I need RA's or not. Given the failure modes I would much prefer to run with RA's turned off completely, and have DHCPv6 able to provide a default gateway just as it works in IPv4. My opinion comes not from thinking legacy, indeed my employer has been fully dual stacked since 2003. My opinion comes from the fact that in the 8 years of operational experience we have RA's are significantly more fragile, and IMHO not ready for widespread IPv6 deployment. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -- Stephen Clark *NetWolves* Sr. Software Engineer III Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com
Re: The stupidity of trying to fix DHCPv6
On Fri, Jun 10, 2011 at 2:21 PM, Steve Clark scl...@netwolves.com wrote: On 06/10/2011 09:37 AM, Ray Soucy wrote: You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? You are the moron - this stuff happens and wishing it didn't doesn't stop it. Get a clue! No matter how much stupidity you try account for, there is infinitely more to come.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 18:06, Leo Bicknell wrote: However, many networks are much more closed deployments. Enterprises have not deployed IPv6 internally yet. Many will not deploy it for another 3-5 years, chosing instead to use web proxies at the edge that speak IPv4 (RFC1918) internally and IPv6 externally. They often can enforce the software deployed on the boxes connected. If they have such tight control over their network and what attaches to it, then obviously rogue RAs can be clamped down upon in a variety of ways. The fact that bad standards and software exist today should never be an argument to not design and deploy better software. So what if it takes until 2019, at least from 2019 to the end of IPv6 we'll have something better. If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP. I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. On 10 jun 2011, at 19:32, Owen DeLong wrote: Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate router or otherwise. It's good to want things. Doesn't mean you'll get it. One of the three big RIRs has already run out of IPv4 space, the second will within less than a year. IPv6 deployment is still measured by counting zeroes behind the decimal point. We still don't have good CPE and broadband specs. The happy eyeballs stuff is still experimental but much needed. Important operating systems have serious IPv6-related bugs. And THIS is the time to start asking for a new feature that even when viewed most favorably, is just a nice-to-have? No more that pesky multicast packet once every 200 seconds (or when a new host attaches to the network). Yes, that's really something the IETF and vendors have to spend their cycles on. NOW. Because otherwise, you know, there's this packet. It's really bad. Every 200 seconds! There are situations, for example, where the administrator does not want all hosts in a broadcast domain to receive the same set of prefixes and/or the same set of routers. This can be achieved by using different parameters based on the system identifier in the DHCP configuration. It cannot be achieved using RA. It can also be done using my suggested DHCP validates RA gateway address mechanism. Eliminating rogue RAs is not the problem being described. That problem is solved through RA-Guard. Well, someone certainly intermingled the discussions, and it wasn't me. The problem being described is the desire to be able to configure a host from zero to functionally on the internet using DHCP without RAs. I think everyone understands that you don't want to do so. That's fine. However, adding the functionality to DHCPv6 doesn't require you to use it. Making it available for operators that want to use it is not a bad thing. It is a bad thing because of the installed base fragmentation and the reduced robustness resulting from using such an option. As such, my life will be worse when this is done so I'm against doing this. I just wish someone had said the same when it was decided that .ip6.int in reverse DNS zone files was ugly and needed to be changed to .ip6.arpa. Or when someone decided that it's a good idea to set the DF bit on ALL packets when doing PMTUD. This industry has a history of doing stuff that ends up wasting huge amounts of time and money that could easily have been avoided but apparently the voice of reason was absent that day. Not this time. In some situations, this fate (it's fate, not fait, btw) Oh, right, I always get that wrong and I know I always get it wrong but still that doesn't help me to get it right. sharing is not desired. Why not? documenting that a host which sees no RA should attempt DHCPv6 would also be a good thing, IMHO. Nope, not a good thing. It doesn't work for normal operation because the delay while lack of RAs is observed would be unacceptable. Also, the M and O bits need to be honored. A really bad situation would be an IPv6-only network where tons of hosts keep broadcasting DHCPv6 multicasts. This can easily clog up wifi bandwidth, as multicasts are sent at very low bitrates because they lack acknowledgments. And like I said before, we have more pressing things to do than tinker some more with DHCPv6.
Re: Yup; the Internet is screwed up.
On Jun 10, 2011, at 10:06 AM, Ricardo Ferreira wrote: I live in europe and we have at home 100Mbps . Mid sized city of 500k people. Some ISPs even spread WiFi across town so that subscribers can have internet access outside their homes. Cablevision does that somewhat. Greg
Re: The stupidity of trying to fix DHCPv6
On Fri, 10 Jun 2011 09:47:44 -0400, Leo Bicknell bickn...@ufp.org wrote: The point is, RA's are operationally fragile and DHCP is operationally robust. No. Both are just as fragile... if you haven't taken steps to protect them. If you aren't doing any sort of DHCP snooping, anyone can setup a rogue DHCP server and kill your network -- been there, laughed at them. Even my *home* lan has DHCP snooping configured. The only question is support for RA Guard in your network hardware. A lot of old gear isn't going to support it. But DHCP was no different. --Ricky PS: Don't read into this... I hate SLAAC and RA, more than most people. (it's been a bad idea from day one.)
Re: The stupidity of trying to fix DHCPv6
In a message written on Fri, Jun 10, 2011 at 09:57:07PM +0200, Iljitsch van Beijnum wrote: If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP. Apparently we don't have a long enough view of history, as history will tell you that this is wrong. You see, we tried the RA experiement once before. Let's go back to the Internet circa 1988, or so. There was a time when it was very common for routers to run RIP. There was a time when Sun systems (in particular, other vendors did the same) shipped with routed enabled by default. Many of these systems learned their default gateway by listening to these RIP announcements. The funny thing is, no one does this anymore. We turned off RIP, turned off routed, and invented things like HSRP to handle router redundancy. These things weren't done because someone was bored, no, they were done because these RIP deployments failed, repeatedly and often. Any device could broadcast bad information, and they did. It could be a legitimate network admin plugging a cable into the wrong jack, or it could be a hacker who rooted a machine and is injecting bad information on purpose. I submit to you those who designed RA's do not remember those days, and did not study history. The only difference is that RA's only carry a default route, where as RIP could carry several routes. The security model is identical. The failure modes are largely overlapping. IPv4 also had a similar feature, ICMP router discovery, RFC 1256. Works a little different than RA's do, but not a lot. Have you ever seen it used? I haven't. Least you think the IETF is proud of their RA work, one needs look no further than RFC 6104, where they carefully document the problem of rogue RA's and provide a list of solutions. Indeed, my proposed DHCP solution is documented in section 3.10. The IETF seems to think SEND is the solution, but it also requires deploying new software to 100% of all devices in order to be the solution. People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. I participated until a working group chair told some protocol wonks Don't listen to him, he's an operator and doesn't understand IPv6 yet. The IETF has a long history of being openly hostle to operators. That was the day I gave up on the IETF. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp3y705EkFbJ.pgp Description: PGP signature
Re: The stupidity of trying to fix DHCPv6
On Fri, 10 Jun 2011 13:27:58 PDT, Leo Bicknell said: The funny thing is, no one does this anymore. We turned off RIP, turned off routed, and invented things like HSRP to handle router redundancy. These things weren't done because someone was bored, no, they were done because these RIP deployments failed, repeatedly and often. Any device could broadcast bad information, and they did. It could be a legitimate network admin plugging a cable into the wrong jack, or it could be a hacker who rooted a machine and is injecting bad information on purpose. Has senility set in, or wasn't there even an incident where somebody advertised 127/8 via RIP - and lots of nodes *believed* it, even though they should have realized that they had an interface on that network already? (And yes, I know of *multiple* failures of broadcasting a default route and getting swamped as a result - this one was 127/8 specifically)... pgpG9DmPaUFbk.pgp Description: PGP signature
Re: So... is it time to do IPv6 day monthy yet?
So should monthly IPv6 day be the same week as Microsoft Patch Tuesday? :-)
IPv6 Week (was Re: So... is it time to do IPv6 day monthy yet?)
My thoughts are that we need either a week or a 36-48 hour period. I thought this before the events of last week. I am very happy with the results and that based on the public statements so far (Looking forward to hearing what is presented at NANOG on this as well) that it was viewed as didn't break much by the major players. This affirms to me what we've observed for many years. Having IPv6 enabled doesn't break much, and not in a way that is any more broken by the issues you can observe in networks otherwise. - Jared On Jun 10, 2011, at 4:39 PM, Bill Stewart wrote: So should monthly IPv6 day be the same week as Microsoft Patch Tuesday? :-)
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 12:21 PM, Steve Clark wrote: On 06/10/2011 09:37 AM, Ray Soucy wrote: You really didn't just write an entire post saying that RA is bad because if a moron of a network engineer plugs an incorrectly configured device into a production network it may cause problems, did you? You are the moron - this stuff happens and wishing it didn't doesn't stop it. Get a clue! engaging in ad homenim in the course of a technical argument on this list is not appropriate. Honestly. This whole argument is getting ridiculous.
Re: The stupidity of trying to fix DHCPv6
And here I thought with IPv6, we would have learned from our mistakes, fixed those problems. We've had 15 years to think about it. I was looking forward to a future where ICMPv6 might even be used. At this point I'm looking forward to IPv6 being the bane of my career for the next 5 years. On 06/10/2011 03:27 PM, Leo Bicknell wrote: IPv4 also had a similar feature, ICMP router discovery, RFC 1256. Works a little different than RA's do, but not a lot. Have you ever seen it used? I haven't.
Re: The stupidity of trying to fix DHCPv6
On 10 jun 2011, at 23:30, Rhys Rhaven wrote: And here I thought with IPv6, we would have learned from our mistakes, fixed those problems. We've had 15 years to think about it. I was looking forward to a future where ICMPv6 might even be used. What are you talking about?? ICMPv6 does what IPv4 ICMP does as well as ARP and then some.
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 11:18 AM, valdis.kletni...@vt.edu wrote: On Fri, 10 Jun 2011 12:54:17 CDT, Jima said: If we go down this path, how long before we hear screaming about rogue DHCPv6 servers giving v4-only networks a false v6 path? Already happened. Good way to install an MITM against any v6-enabled boxes on a v4-only network, been multiple reported uses of that technique. What's more v4 seem rather less likely to have any countermeasures or methods for detecting this... Back when I worked for a security vendor our endpoint security product specifically disabled ipv6 to address this exposure.
BGP Update Report
BGP Update Report Interval: 02-Jun-11 -to- 09-Jun-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS19743 33461 2.4%5576.8 -- 2 - AS718431256 2.3% 538.9 -- Universidad Verecruzana 3 - AS982922167 1.6% 26.2 -- BSNL-NIB National Internet Backbone 4 - AS27738 16576 1.2% 48.9 -- Ecuadortelecom S.A. 5 - AS32528 16367 1.2%2045.9 -- ABBOTT Abbot Labs 6 - AS702915057 1.1% 7.8 -- WINDSTREAM - Windstream Communications Inc 7 - AS476614915 1.1% 6.3 -- KIXS-AS-KR Korea Telecom 8 - AS33475 13665 1.0% 99.0 -- RSN-1 - RockSolid Network, Inc. 9 - AS949813223 1.0% 25.7 -- BBIL-AP BHARTI Airtel Ltd. 10 - AS17974 12061 0.9% 23.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 11 - AS24560 11947 0.9% 23.1 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 12 - AS11492 10573 0.8% 18.1 -- CABLEONE - CABLE ONE, INC. 13 - AS14420 10259 0.8% 15.2 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 14 - AS3320 9990 0.7% 285.4 -- DTAG Deutsche Telekom AG 15 - AS154759873 0.7% 17.7 -- NOL 16 - AS455959187 0.7% 30.3 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 17 - AS9228 8969 0.7% 332.2 -- CENTRALONLINE-ID-AS-AP PT. Total Info Kharisma 18 - AS8551 8070 0.6% 25.1 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone 19 - AS4788 7758 0.6% 5.1 -- TMNET-AS-AP TM Net, Internet Service Provider 20 - AS3454 7439 0.5%7439.0 -- Universidad Autonoma de Nuevo Leon TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS3454 7439 0.5%7439.0 -- Universidad Autonoma de Nuevo Leon 2 - AS19743 33461 2.4%5576.8 -- 3 - AS32528 16367 1.2%2045.9 -- ABBOTT Abbot Labs 4 - AS174083479 0.2%1739.5 -- ABOVE-AS-AP AboveNet Communications Taiwan 5 - AS246666687 0.5%1671.8 -- AXA-AS AXA Luxembourg S.A 6 - AS517221668 0.1%1668.0 -- EAD-TELECOM-AS EAD TELECOM SRL 7 - AS441001044 0.1%1044.0 -- ARIELTV-AS Ariel TV AD 8 - AS383882837 0.2% 945.7 -- BEN-AS-KR Bukbu District Office of Education in Seoul 9 - AS49600 901 0.1% 901.0 -- LASEDA La Seda de Barcelona, S.A 10 - AS42934 739 0.1% 739.0 -- SSIF-AS CONFIDENT INVEST Bucuresti SA 11 - AS39263 657 0.1% 657.0 -- ILIMIT Ilimit Comunicacions, S.L. Barcelona Spain 12 - AS3 596 0.0% 735.0 -- RC-IKT RC IKT, d.o.o. 13 - AS5313 547 0.0% 547.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 14 - AS718431256 2.3% 538.9 -- Universidad Verecruzana 15 - AS104452400 0.2% 480.0 -- HTG - Huntleigh Telcom 16 - AS56050 455 0.0% 455.0 -- NEW-SHINE-INTERNET-TH 134 Yenchit Road 17 - AS445841764 0.1% 441.0 -- PTLINE-AS Progress Tehnologiya LLC 18 - AS38021 439 0.0% 439.0 -- IIFTNET-AS-AP Network of Indian Institute of Foreign Trade, 19 - AS285191286 0.1% 428.7 -- Universidad Autonoma de Guadalajara, A.C. 20 - AS37178 766 0.1% 383.0 -- ALPHA-BETA-CONSULTING TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 11703 0.8% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 91.217.214.0/249547 0.6% AS3320 -- DTAG Deutsche Telekom AG 3 - 130.36.34.0/24 8173 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8169 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 200.23.202.0/247439 0.5% AS3454 -- Universidad Autonoma de Nuevo Leon 6 - 65.122.196.0/246386 0.4% AS19743 -- 7 - 65.163.182.0/245418 0.4% AS19743 -- 8 - 65.162.204.0/245416 0.4% AS19743 -- 9 - 72.164.144.0/245415 0.4% AS19743 -- 10 - 66.238.91.0/24 5414 0.4% AS19743 -- 11 - 66.89.98.0/24 5412 0.4% AS19743 -- 12 - 202.153.174.0/24 3478 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 13 - 195.39.244.0/242136 0.1% AS24666 -- AXA-AS AXA Luxembourg S.A 14 - 193.110.190.0/24 2134 0.1% AS24666 -- AXA-AS AXA Luxembourg S.A 15 - 65.181.192.0/232111 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 16 - 77.81.5.0/24 1668 0.1% AS51722 -- EAD-TELECOM-AS EAD TELECOM SRL 17 - 202.54.86.0/24 1408 0.1% AS4755 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 18 - 24.116.1.0/24 1405 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 19 - 24.116.2.0/24 1373 0.1% AS11492 -- CABLEONE - CABLE ONE, INC. 20 -
Re: Yup; the Internet is screwed up.
Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster That can't be good. ignorant? up to 10 percent of the country can't even get basic broadband I think I saw much larger numbers a few years ago when I read some hype stories about how broadband access in the USA sucks. I am positively surprised the gap has narrowed that much. I wonder, what's wrong with dialup through ISDN? You get speed that is about the same as low end broadband I'd say. And I think it'd be available at these locations where DSL is not. To quote http://en.wikipedia.org/wiki/Broadband_Internet_access#ISDN A basic rate ISDN line (known as ISDN-BRI) is an ISDN line with 2 data bearer channels (DS0 - 64 kbit/s each). Using ISDN terminal adapters (erroneously called modems), it is possible to bond together 2 or more separate ISDN-BRI lines to reach bandwidths of 256 kbit/s or more. The ISDN channel bonding technology has been used for video conference applications and broadband data transmission. My low end home DSL connection has similar bandwidth. With regards to the writer's main gripe, if your telecommute work typically consists of ssh sessions and email then even y'olde dialup will do just fine. /ignorant? -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: Yup; the Internet is screwed up.
On Jun 10, 2011, at 7:43 PM, Jeroen van Aart wrote: Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster That can't be good. ignorant? up to 10 percent of the country can't even get basic broadband I think I saw much larger numbers a few years ago when I read some hype stories about how broadband access in the USA sucks. I am positively surprised the gap has narrowed that much. I wonder, what's wrong with dialup through ISDN? You get speed that is about the same as low end broadband I'd say. And I think it'd be available at these locations where DSL is not. To quote http://en.wikipedia.org/wiki/Broadband_Internet_access#ISDN A basic rate ISDN line (known as ISDN-BRI) is an ISDN line with 2 data bearer channels (DS0 - 64 kbit/s each). Using ISDN terminal adapters (erroneously called modems), it is possible to bond together 2 or more separate ISDN-BRI lines to reach bandwidths of 256 kbit/s or more. The ISDN channel bonding technology has been used for video conference applications and broadband data transmission. My low end home DSL connection has similar bandwidth. With regards to the writer's main gripe, if your telecommute work typically consists of ssh sessions and email then even y'olde dialup will do just fine. /ignorant? Try ordering one. If I wanted one here I couldn't order one today. Years ago I had a bonded BRI serving my first server and and it took 3 months to get it working. I am not sure central offices have that capability any more. There was also a distance constraint from the CO (kinda like the distance issue from the DSLAM demark) I have a fishing cabin out in the middle of nowhere and I get broadband via a small ISP that serves via Canopy coresiding on 300 ft cell towers. This provides 1-20Mbps service even when the cell towers only provide Edge Tom
Re: Yup; the Internet is screwed up.
I love how articles like this seem to convienently ignore the fact that the US is a BIG COUNTRY, and countries like Korea and Japan are very small countries comparitively. I haven't done any research to backup the following claim, but I suspect that the Russian Federation's internet probably isn't on the level of these much smaller, denser countries. Anecdotal evidence from friends in Russia about the quality (or lack thereof) of their connections would support this claim though. On Jun 10, 2011 4:44 PM, Jeroen van Aart jer...@mompl.net wrote: Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster That can't be good. ignorant? up to 10 percent of the country can't even get basic broadband I think I saw much larger numbers a few years ago when I read some hype stories about how broadband access in the USA sucks. I am positively surprised the gap has narrowed that much. I wonder, what's wrong with dialup through ISDN? You get speed that is about the same as low end broadband I'd say. And I think it'd be available at these locations where DSL is not. To quote http://en.wikipedia.org/wiki/Broadband_Internet_access#ISDN A basic rate ISDN line (known as ISDN-BRI) is an ISDN line with 2 data bearer channels (DS0 - 64 kbit/s each). Using ISDN terminal adapters (erroneously called modems), it is possible to bond together 2 or more separate ISDN-BRI lines to reach bandwidths of 256 kbit/s or more. The ISDN channel bonding technology has been used for video conference applications and broadband data transmission. My low end home DSL connection has similar bandwidth. With regards to the writer's main gripe, if your telecommute work typically consists of ssh sessions and email then even y'olde dialup will do just fine. /ignorant? -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: Yup; the Internet is screwed up.
On Fri, 10 Jun 2011 16:43:39 PDT, Jeroen van Aart said: Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster That can't be good. ignorant? up to 10 percent of the country can't even get basic broadband I think I saw much larger numbers a few years ago when I read some hype stories about how broadband access in the USA sucks. I am positively surprised the gap has narrowed that much. The FCC numbers say 10% can't get it, computed on a per-county basis. However, if *one* person in one corner of the county closest to a major city can get broadband, then *everybody in the county* is counted as can get broadband by the FCC, even if 99.8% of them are 15 or 20 cable miles away from actually getting anything usable. So the *actual* numbers are much worse than the FCC numbers. pgpBtHxNiZa5x.pgp Description: PGP signature
Re: Yup; the Internet is screwed up.
valdis.kletni...@vt.edu wrote: So the *actual* numbers are much worse than the FCC numbers. Be that as it may, when I moved to the States I had to give up DSL back in the Netherlands. But since I got flat rate dialup in return in the USA it wasn't such a big deal, for me the internet worked just fine on 56K dialup between 2002 and 2006. The reason I really wanted DSL in the first place is to get rid of those excessive phone bills. Increased speed was just an added bonus. Since most countries do not offer flat rate local phone calls I'd say that makes it a more urgent matter for them to move to broadband. Maybe flat rate local phone calls is one of the reasons broadband lags behind here. Because your bills actually increase with broadband. From a mere $10 to something like $30 and up per month. That's a considerable difference for many households. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
Re: Yup; the Internet is screwed up.
2) Last mile is expensive to install and hard to justify for people. This is because of a long history of universal service and subsidization/regulation. Not only that, it makes it even worse when you hear firsthand accounts of yea, this customer's DSL is screwed because att was too cheap to install proper guage wires like they did down the street in the same neighborhood!! from an actual att digital technician. And yes, this was in the middle of a US city with almost 500k population. So much for rethink possible, I guess we'll just have to live with reach out and touch someone.. -- m On Fri, Jun 10, 2011 at 9:17 AM, Jared Mauch ja...@puck.nether.net wrote: On Jun 10, 2011, at 10:01 AM, Kyle Creyts wrote: I think the point is the ubiquity of access isn't what it should be. I think there were several good points made in the article. 1) Data caps and how they impact software updates (or downloads) - hughesnet was mentioned but .. Looking to the near future, Apple is selling a 4GB download for $30 in the next month or so. That will have a large impact on networks that day IMHO. If you have a 3G/4G/LTE/whatnot device it makes it impossible to pull down the image without hitting your 5GB or 10GB cap compared to a fixed access network. Even assuming you go to the local Panera/McDonalds/Starbucks/Library access, if you get 2MB/s (16Mb/s) you're talking about 20-25 minutes. Those locales don't usually have that fast of a network though. 2) Last mile is expensive to install and hard to justify for people. This is because of a long history of universal service and subsidization/regulation. In Michigan you could get a phone line installed for $42 (not sure, haven't installed POTS in a long time, may have gone up) regardless of the cost to the carrier. This isn't the case when you want to extend other utilities (eg Gas, electric, water...). People are willing to pay 10k+ to install these services as part of their construction expense. Their other utility cost is masked in part due to the past 100+ years of telecom history. The cost of lighting a 20km strand of fiber at 1Gb/s is somewhere in the $600, including ONT, etc. Many people here on nanog would happily pay that amount. Now, the 12-100k per mile to build the fiber is the hard part to eat. 3) Certainly he did a poor job of site selection. Perhaps he was misled or even lied to. I've faced similar challenges when working with both hardware vendors and carriers out there. The sales peoples eyes get big once you start talking about doing something, but the engineers at the table generally start asking serious questions. (I certainly will not move anywhere that doesn't have a HFC or PON/FTTH network. Sorry ATT/Centurylink/others but the plusses don't justify the minuses). - It's certainly possible that we will see improved last-mile access. The USDA/RUS and DOC/NTIA efforts are to be applauded. If you look at the current ATT + T-Mobile merger people are talking about it will bring broadband to 97% of the country, and help ATT (mobility division) with last-mile/local tower regulatory hurdles. They are not talking about how it will remove the need for data caps that are 1/30th the size of their 150GB cap on their mobile side elements. I suspect there's a lot that could be improved by each market player here, but as happened with Verizon in the Northeast, I expect the less-dense markets will need to have better local service from regional players vs the big guys. Overall this will be good, but the costs will also have to be paid for more with the local subscriber. - Jared
Re: Yup; the Internet is screwed up.
On Fri, 10 Jun 2011 17:59:38 PDT, Jeroen van Aart said: Maybe flat rate local phone calls is one of the reasons broadband lags behind here. Because your bills actually increase with broadband. From a mere $10 to something like $30 and up per month. That's a considerable difference for many households. That *is* a consideration for many, but it's generally not regarded as one of the biggest issues. The lack of an enforced build-out similar to what Ma Bell had to do 50 years ago for telephone service, and related regulatory issues that result in most areas having essentially one telco and one cable operator, both of whom are free to pick-and-choose their service areas, is a bigger issue. (Biggest single issue? Probably that some companies got really big incentives a number of years ago to deploy broadband, and were allowed to pocket the money without actually deploying. Will take quite a bit to reverse *that* fiasco...) pgptHKCwD0k7O.pgp Description: PGP signature
Re: Yup; the Internet is screwed up. - Land Assistance...
Hi List, Farmer Don here... Wonder if I could get some help please? 40°46'42.77N - 73°58'0.83W I found a bit of land that I like the look of, with what appears to be a nice water reserve so my animals can drink and I can water the grass. Being from New Zealand (a farming community a bit below and east of Australia), I'm sorry but I don't know much about regulations to install irrigation systems in the area that I'm quite keen to set up my next farming venture. I'm wondering if anyone can give me some pointers? Being from Christchurch (site of two massive earthquakes) I know a reasonable amount about demolition now, so I'm not worried at all about the adjacent buildings as we can deal with those as we need to expand the farm. I'm attracted to this area for a number of reasons, mainly because of the abundant wireless broadband options across the entire property. I've done some factoring and the cash I can save by not having to invest in my own wireless network spanning across the country will mean I can pay for my new dairy milking shed within 3 years, (unlike the investment I've had to make on a family property in New Zealand where our property was out side of the reach of the local Telephone companies high speed DSL service and we were going to be limited to sub ADSL1 speeds!) After reading this post on NANog and following the link provided, it really struck me as a great place to ask for assistance. Some may be wondering why I don't want a more rural setting? I want to be able to enjoy a city life style every day, and I really don't feel that's unreasonable given the rant I hearing about the right to enjoy a rural life style while also having all the quality refinements that an urban city provides. Further, I don't see why I should have to invest in my community and why others shouldn't be focused and tasked with just doing it for me! I do hope that my desire to use some of your land for my smelly cows doesn't offend any of you, but I really think my right to enjoy looking at tall buildings every day has to be respected! Cheers Farmer Don On 10/06/2011 12:43 p.m., Jay Ashworth wrote: Even Cracked realizes this: http://www.cracked.com/blog/5-reasons-internet-access-in-america-disaster That can't be good. Cheers, -- jra -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699
Re: Yup; the Internet is screwed up.
(Biggest single issue? Probably that some companies got really big incentives a number of years ago to deploy broadband, and were allowed to pocket the money without actually deploying. Will take quite a bit to reverse *that* fiasco...) It sounds, Valdis, like you've been listening to Bruce Kushnick. The good news is that, after years of windward urination by Bruce, renewed scrutiny resulting from the recent T-Mobile gambit has brought more than one investigative journalist to his door. One hopes for major coverage soon. -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: Yup; the Internet is screwed up.
On 6/10/2011 7:43 PM, Jeroen van Aart wrote: I wonder, what's wrong with dialup through ISDN? You get speed that is about the same as low end broadband I'd say. And I think it'd be available at these locations where DSL is not. Well, it was available. I had one ~15 years ago, and a Cisco 801 to boot. There was a big build-out in some areas, the small-town local Bell (not yet Borg'ed into the conglomerate) went all digital (well, digital at the time) on their new nnx CO. Still recall the Northern Telecom network interface boxes on the sides of houses. Closer to the city, it was order and wait as you had to be crossed over or patched to the nearest ISDN CO. They weren't wholesale digital. Most of that has converted over to DSL. But ISDN is still available (we have some video conferencing gear that uses bonded ISDN). Jeff
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 12:57 PM, Iljitsch van Beijnum wrote: On 10 jun 2011, at 18:06, Leo Bicknell wrote: However, many networks are much more closed deployments. Enterprises have not deployed IPv6 internally yet. Many will not deploy it for another 3-5 years, chosing instead to use web proxies at the edge that speak IPv4 (RFC1918) internally and IPv6 externally. They often can enforce the software deployed on the boxes connected. If they have such tight control over their network and what attaches to it, then obviously rogue RAs can be clamped down upon in a variety of ways. Rogue RA is not the problem this seeks to solve. Yes, it helps with that problem also, but, I wouldn't be saying we need this if it was just rogue RA that people are concerned about. The fact that bad standards and software exist today should never be an argument to not design and deploy better software. So what if it takes until 2019, at least from 2019 to the end of IPv6 we'll have something better. If only. Having third parties point to routers is less robust than having routers announce their own presence. In the telco world, there's a separation between the control and data channels, which has important security advantages. But the IETF has always favored fate sharing. It makes routing protocols more robust and it makes RA more robust than IPv4 DHCP. So you say, but, the real world doesn't bear out your claim. For one thing, assuming that routers on a link are intended to serve all machines on a link assumes facts not in evidence. You can call that bad network design if you want, but, there are real world requirements and scenarios where that has to happen for a variety of reasons. Those networks have working configurations in DHCPv4 and no ability to move to IPv6 until this is solved. This isn't about fate sharing vs. non-fate sharing. This is about giving administrators a rich set of tools and allowing them to pick the ones that best fit their situation. Nobody is trying to prevent you from using RA/SLAAC on your network. More power to you. I use it on some of my networks too. However, I also deal with customers who have situations that are not well served by it and they need DHCP with the ability to provide different routing configurations to different hosts on the same link. I'm all for improvements, but only if they can be made without fragmenting the installed base and perpetuating the situation we are finally leaving behind where there is no agreed upon DHCPv6 behavior across different operating systems. I see no reason that additional DHCPv6 options would have to fragment the installed base or perpetuate the lack of agreed upon DHCPv6 behavior. In fact, I think that adding these options could allow for a set of rules that would be acceptable to all and would allow administrators to make choices based on the needs of their environments. A host which receives a DHCPv6 option it doesn't understand is expected to ignore that option. Administrators who count on DHCPv6 options that are newer than the software/hardware on some of their hosts should expect those hosts to ignore the option. This is easily documented. People who don't like this should blame their younger selves who failed to show up at the IETF ten years ago to get this done while DHCPv6 was still clean slate. There were a lot of people who tried to show up at the IETF 10 years ago and talk about this stuff from an operational perspective. They were basically told that operators don't know what they want and they should shut up and go away and let real men do the work. Perhaps we should have stood up stronger at the time, but, frankly, we had real work to do that mattered to our users for the next 24 hours rather than a decade later. As such, we had limited bandwidth to attempt to push our goals somewhere where our interference was not welcome. So, if you want to blame younger selves, blame the IETF younger selves and the protocol zealots that shouted down the operator community and told us to mind or own business. On 10 jun 2011, at 19:32, Owen DeLong wrote: Some administrators want DHCP to be a complete solution and do not want to use RA at all, whether from a legitimate router or otherwise. It's good to want things. Doesn't mean you'll get it. No, but, it does mean some might reject your shiny new protocol until it provides them the tools they believe they need, whether you agree with their assessment of their needs or not. Personally, I'd rather not have administrators rejecting IPv6 and it seems to me that adding routing information options to DHCPv6 is a light-weight action that is already possible within the existing protocol specification (just need to assign option numbers and attribute/value formats) and makes IPv6 a whole lot more palatable to a rather large number of administrators. One of the three big RIRs has already run out of IPv4 space, the second
Re: Yup; the Internet is screwed up.
I had dual ISDN from nynex in the 90s. 128k woohoo! It cost me $500+/mth. j On Fri, Jun 10, 2011 at 9:59 PM, Jeff Kell jeff-k...@utc.edu wrote: On 6/10/2011 7:43 PM, Jeroen van Aart wrote: I wonder, what's wrong with dialup through ISDN? You get speed that is about the same as low end broadband I'd say. And I think it'd be available at these locations where DSL is not. Well, it was available. I had one ~15 years ago, and a Cisco 801 to boot. There was a big build-out in some areas, the small-town local Bell (not yet Borg'ed into the conglomerate) went all digital (well, digital at the time) on their new nnx CO. Still recall the Northern Telecom network interface boxes on the sides of houses. Closer to the city, it was order and wait as you had to be crossed over or patched to the nearest ISDN CO. They weren't wholesale digital. Most of that has converted over to DSL. But ISDN is still available (we have some video conferencing gear that uses bonded ISDN). Jeff -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
Re: The stupidity of trying to fix DHCPv6
On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong o...@delong.com wrote: And like I said before, we have more pressing things to do than tinker some more with DHCPv6. Meh... We can achieve a big win for relatively low cost very quickly and make IPv6 much more palatable to a wide audience of enterprise administrators. I can't really say that there's much more pressing than that. Yes, the issues you described above also fit into that category, so, I'd say this is about equal. Right. Please, everyone - this is not just an IPv4 way of thinking. This is different types of networks and network users. Just because your experience and your network don't have anything affected by these issues with DHCPv6 / RA doesn't mean that others don't. IPv6 adoption is driven by exhaustion, but it's limited by glitches like this. -- -george william herbert george.herb...@gmail.com
Re: The stupidity of trying to fix DHCPv6
On Jun 10, 2011, at 10:21 PM, George Herbert wrote: On Fri, Jun 10, 2011 at 7:03 PM, Owen DeLong o...@delong.com wrote: And like I said before, we have more pressing things to do than tinker some more with DHCPv6. Meh... We can achieve a big win for relatively low cost very quickly and make IPv6 much more palatable to a wide audience of enterprise administrators. I can't really say that there's much more pressing than that. Yes, the issues you described above also fit into that category, so, I'd say this is about equal. Right. Please, everyone - this is not just an IPv4 way of thinking. This is different types of networks and network users. Just because your experience and your network don't have anything affected by these issues with DHCPv6 / RA doesn't mean that others don't. IPv6 adoption is driven by exhaustion, but it's limited by glitches like this. -- -george william herbert george.herb...@gmail.com This is different types of networks and network users and also different operational, administrative, and security domains. I am also getting frustrated with the endless discussions that could be immediately shortened by tinkering with DHCP to add one or two additional options -- a minimal cost process. Why is the argument not about business needs instead of technical purity? See these quotes from 2009 and let us collectively get off the dime! On Oct 22, 2009, at 3:03 PM, Vasil Kolev wrote: В 11:10 -0700 на 22.10.2009 (чт), Owen DeLong написа: OK... Here's the real requirement: Systems administrators who do not control routers need the ability in a dynamic host configuration mechanism to assign a number of parameters to the hosts they administer through that dynamic configuration mechanism. These parameters include, but, are not limited to: 1. Default Router 2. DNS Resolver information 3. Host can provide name to server so server can supply dynamic DNS update 4. IP Address(es) (v4, v6, possibly multiple v6 in the case of things like Shim6, etc.) 5. NTP servers 6. Boot server 7. Site specific attribute/value pairs (ala DHCPv4 Options) These assignments MUST be controlled by a server and not by the router because the router is outside of the administrative control of the Systems Administrator responsible for the hosts being configured. And to add a real-world case for this - two months ago at HAR (hacking at random, a convention in the Netherlands) I was in the network team, handling fun stuff like DHCP servers, DNS, etc.. We also provided IPv6 connectivity there (we had a /16 IPv4 zone and a /48 IPv6 zone), and at some point we asked the question around - ok, how should we provide DNS and other useful information for the V6 only people? After a while with all the brains around, the decision was to write it on the datenklos through the field, where people can read it and configure it in their browsers. This would've been funny if it wasn't so sad. OTOH, for V4 everything with the DHCP worked fine (as it has always done, even at an event of this size), as is my experience with all the networks I've administered. Saying that DHCP doesn't work for me is extremely weird, as to me this means someone made specific effort to fuck it up. Finally - we have something that works, that's called DHCP. It might not be perfect, it might have some weird issues and implementations, but it's actually making our lives easier, is tested and works. I'd love anything that would be better, but as an option, not as the only choice I have. And it's not just the protocol that I care about. I care about that it's implemented in a HOST, where I can play with the software as much as possible, instead on a ROUTER, which is a vastly different device with rarely-updated OS, and even in the case where they're both the same machine(as in small office environments), they're again handled at different layers (kernel vs userspace). There are reasons that we're using what we're using, and not all of them are because we're masochistic idiots. -- Regards, Vasil Kolev Following on the comments above: The security domain for HOST should not overlap the security domain for ROUTER. That is the primary driver of the separate administration of HOST and ROUTER. Heaven help us if the latest M$ virus, or even social-engineering distributed malware began to affect BGP! Give the router managers the NTP server addresses and their DHCP forwarding list and leave them alone to produce a robust and reliable transport facility! James R. Cutler james.cut...@consultant.com
The Business Wisdom of trying to fix DHCPv6
James R. Cutler james.cutler at consultant.com Fri Feb 6 18:00:52 UTC 2009 DHCP items are end system considerations, not routing network considerations. The network operations staff and router configuration engineers do not generally concern themselves with end systems. End systems generally are managed quite independently from the routing network. And, they are more subject to the vagaries of day to day business variability. Note the one place in the quoted message below. The only overlap is broadcast forwarding for DHCP initiation. Besides, configuration control is hard enough for router engineers without adding the burden of changing end system requirements. Adding the forwarding entries is almost too much already! ;) So, for routing network operators to denigrate DHCP is probably due to lack of consideration of the end user system requirements. And those who denigrate DHCP and say just hard code it make end system management that much more difficult. I still conclude that DHCP is a useful tool for both IPv4 and IPv6 systems. В 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. James R. Cutler james.cut...@consultant.com
Re: Yup; the Internet is screwed up. - Land Assistance...
Yes thank you very much Mr J for the links you provided. :) We have actually done our research, unlike the gent having a rant in the initial linked article, and were aware of the abundance of both low cost 2g, 3g and free wifi in the area. Again, as I explained it is one of the reasons for selecting settlement in the area. The savings of not having to pay for broadband access for the transceivers on each of our cows will more than off set the investment in the new milking shed (all cows are fitted with wifi/2/3g transceivers with bluetooth integrated headsets so we can do a broadcast to them telling them it's time to come in for milking). However, what does concern me is the lack of free wifi choice and the fact that only one provider is going to be delivering it and the terms they plan to offer such free access and the fact that we are generally opposed to using American Telephone and Telegraph because of their perceived alignment with some political or social groups. What we would like to see is a government mandate that all network providers in the area step up and form a long term working party for the establishment of short, mid and long term outcomes that will fully represent the interests of foreign rural farming investors such as my company. In keeping with the general tone of many technical internet mailing lists, I would also like to point out that you have not assisted in addressing the question, which I might remind you is around regulations for installation of irrigation and not the availability of free wifi from a company that very clearly has vested interests in locking my watering system investment out of the market so they can dominate the industry and impose different levels of water supply based on their shareholders interests. Farmer Don On 11/06/2011 2:23 p.m., Joly MacFie wrote: That would be http://maps.google.com/maps?q=40.778547+-73.966897 Fortunately American Telephone and Telegraph are on the case http://bit.ly/jTak0Q j
Re: Yup; the Internet is screwed up. - Land Assistance...
Yep, don't mention it One regulation you may run afoul of is the the new zero tolerance quiet zone enforcement Cowbells are definitely out, mooing dubious. http://newyork.cbslocal.com/2011/06/01/nina-in-new-york-grouchiness-prevails-in-central-park/ On Fri, Jun 10, 2011 at 10:56 PM, Don Gould d...@bowenvale.co.nz wrote: Yes thank you very much Mr J for the links you provided. :) We have actually done our research, unlike the gent having a rant in the initial linked article, and were aware of the abundance of both low cost 2g, 3g and free wifi in the area. Again, as I explained it is one of the reasons for selecting settlement in the area. The savings of not having to pay for broadband access for the transceivers on each of our cows will more than off set the investment in the new milking shed (all cows are fitted with wifi/2/3g transceivers with bluetooth integrated headsets so we can do a broadcast to them telling them it's time to come in for milking). However, what does concern me is the lack of free wifi choice and the fact that only one provider is going to be delivering it and the terms they plan to offer such free access and the fact that we are generally opposed to using American Telephone and Telegraph because of their perceived alignment with some political or social groups. What we would like to see is a government mandate that all network providers in the area step up and form a long term working party for the establishment of short, mid and long term outcomes that will fully represent the interests of foreign rural farming investors such as my company. In keeping with the general tone of many technical internet mailing lists, I would also like to point out that you have not assisted in addressing the question, which I might remind you is around regulations for installation of irrigation and not the availability of free wifi from a company that very clearly has vested interests in locking my watering system investment out of the market so they can dominate the industry and impose different levels of water supply based on their shareholders interests. Farmer Don On 11/06/2011 2:23 p.m., Joly MacFie wrote: That would be http://maps.google.com/maps?q=40.778547+-73.966897 Fortunately American Telephone and Telegraph are on the case http://bit.ly/jTak0Q j -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
