Re: Mac OS X 10.7, still no DHCPv6
On Sun, 27 Feb 2011, Ray Soucy wrote: (I'm just waiting for Apple's lawyers to try an get names out of me...) But yes, it does appear that Apple is addressing the issue: 8 cat /etc/ip6addrctl.conf # default policy table based on RFC 3484. # usage: ip6addrctl install path_to_this_file # # $FreeBSD$ # #Format: #Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 :::0:0/96 10 4 8 Awesome! Best Regards,
Re: Mac OS X 10.7, still no DHCPv6
On Sun, Feb 27, 2011 at 05:55:53PM -0800, Owen DeLong wrote: The lack of NTP and certain other options in SLAAC is still a disappointment and I would argue that a fully matured SLAAC process would include a mechanism for specifying extensible choices of things. That's O=1 and stateless DHCPv6. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Re: Sunday Funnies: Using a smart phone as a diagnostic tool
Subject: Sunday Funnies: Using a smart phone as a diagnostic tool Date: Sun, Feb 27, 2011 at 09:00:18PM -0500 Quoting Jay Ashworth (j...@baylink.com): Do you have a smartphone? Blackberry? iPhone? Android? Do you use it as a technical tool in your work, either for accessing devices or testing connectivity -- or something else? If so, what kind of phone, and what (if you don't mind letting on) are your magic apps for this sort of work? Nokia n900. The only apps I installed was a sudo and vpnc; the rest IIRC is in there already. With Nokia shoving its collecitve head into the dark rear end of Microsoft, I have few if any hopes for a successor from Esbo[0]. My guess would be a r00ted Androidish device next time around. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 The FALAFEL SANDWICH lands on my HEAD and I become a VEGETARIAN ... [0] Swedish for Espoo, the small suburb west of Helsingfors (Helsinki) where the HQ is. pgpYnolBFBJTo.pgp Description: PGP signature
Re: Mac OS X 10.7, still no DHCPv6
In message 1298850835.2109.33.camel@karl, Karl Auer writes: On Mon, 2011-02-28 at 09:39 +1100, Mark Andrews wrote: DHCP kills privacy addresses. DHCP kills CGAs. For temporary addresses couldn't a client clamp the upper limits of its received lifetimes to the desired lifetimes, then rebind instead of renew, sending a DECLINE if it gets the same address (as it presumably will)? Not quite the same. With privacy addresses you still have a stable address. The temporaryness would then be pretty much in the hands of the client (arguably where it belongs). That does kill the privacy aspect of temporary addresses, at least locally. Perhaps that is only a partial loss, as the addresses would still be private as far as the wider world was concerned. How does ISC DHCPv6 allocate addresses? Random, sequential...? Regards, K. --=20 ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 --=-tH4fLyHaqQtSrebFpt31 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1q5BMACgkQMAcU7Vc29oeHIQCfcFAeUYv13rGhF4ViACJe8xHI QZIAoNAfG744pfSZSM3p4fGNpzyXg6It =hxri -END PGP SIGNATURE- --=-tH4fLyHaqQtSrebFpt31-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Mac OS X 10.7, still no DHCPv6
On Sun, 27 Feb 2011, Owen DeLong wrote: But the ND messages don't tell you anything other than the Mac address about which host it actually is. In theory, at least, snooping the DHCP messages might include a hostname or some other useful identifier. It ought to be possible to look at SMB or mDNS messages to get more information about what the host claims to be... Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Trafalgar: North 5 to 7, occasionally gale 8 in Biscay. Moderate or rough. Squally showers. Good.
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 7:35 PM, Tony Finch wrote: It ought to be possible to look at SMB or mDNS messages to get more information about what the host claims to be... We can't trust those, they're easily manipulated and/or situationally-irrelevant. Or not present at all, if the endpoint customer is security-conscious. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 1:10 21AM, Randy Bush wrote: I'm not saying there are no uses for DHCPv6, though I suspect that some of the reasons proposed are more people wanting to do things the way they always do, rather than making small changes and ending up with equivalent effort. add noc and doc costs of all changes, please Sure. How do they compare to the total cost of the IPv6 conversion excluding SLAAC? (Btw, for the folks who said that enterprises may not want privacy-enhanced addresses -- that isn't clear to me. While they may want it turned off internally, or even when roaming internally, I suspect that many companies would really want to avoid having their employees tracked when they're traveling. Imagine -- you know the CEO's laptop's MAC address from looking at Received: lines in headers. (Some CEOs do send email to random outsiders -- think of the Steve Jobs-grams that some people have gotten.) You then see the same MAC address with a prefix belonging to some potential merger or joint venture target. You may turn on DHCPv6 to avoid that, but his/her home ISP or takeover target may not.) --Steve Bellovin, http://www.cs.columbia.edu/~smb
Re: Mac OS X 10.7, still no DHCPv6
On 02/28/2011 08:25 AM, Steven Bellovin wrote: On Feb 28, 2011, at 1:10 21AM, Randy Bush wrote: I'm not saying there are no uses for DHCPv6, though I suspect that some of the reasons proposed are more people wanting to do things the way they always do, rather than making small changes and ending up with equivalent effort. add noc and doc costs of all changes, please Sure. How do they compare to the total cost of the IPv6 conversion excluding SLAAC? (Btw, for the folks who said that enterprises may not want privacy-enhanced addresses -- that isn't clear to me. While they may want it turned off internally, or even when roaming internally, I suspect that many companies would really want to avoid having their employees tracked when they're traveling. Imagine -- you know the CEO's laptop's MAC address from looking at Received: lines in headers. (Some CEOs do send email to random outsiders -- think of the Steve Jobs-grams that some people have gotten.) You then see the same MAC address with a prefix belonging to some potential merger or joint venture target. You may turn on DHCPv6 to avoid that, but his/her home ISP or takeover target may not.) One of the items we worried about at OLPC (not that I remember if we ended up doing anything about it), is that in some countries, kidnapping is a very serious problem. Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. It must be *possible* to be anonymous, even if some environments by policy won't provide service if you choose to be anonymous. - Jim
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote: Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. We already have this with MAC addresses, unless folks bother to periodically change them, do we not? --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On Sun, Feb 27, 2011 at 11:53 PM, Franck Martin fra...@genius.com wrote: Oh... did not know about the heavy baggage... No, when I first played with IPv6 only network, I found out that RD was silly, it gives an IP adddress but no DNS, and you have to rely on IPv4 to do that. silly, so my understanding is then people saw the mistake, and added some DNS resolution... Because the only option was to get DHCPv6 to get the DNS, but then why create RD in the first place? So I found this whole saga, to put it mildly stupid, like when people were talking about migrating to IPv6 but the root servers did not even have an IPv6 address: silly! So I really don't care between RD and DHCPv6, what I care, is that they should be able to do their job correctly on their own. Really, if you look back at the archives of this list these arguments are starting to get silly as you put it. It seems that every few months, as people discover that IPv6 isn't going away and they should brush up on it, people go through this process of debating the way IPv6 was designed as if it were 1998, and ultimately make posts like this. IPv6 is simple, elegant, and flexible. DHCPv6 was always a core component of IPv6 (just like ICMPv6 is a core components of IPv6, or should we throw ping and traceroute into RA as well...) This is why we have flags in RA to signal how addressing is done on a network for a prefix: A - Autonomous Flag, allows hosts to perform stateless addressing for a prefix. O - Other Flag, signals that additional configuration information is available (such as DNS) and DHCPv6 should be used. M - Managed Flag, signals that hosts should request a stateful address using DHCPv6. The real point, initially at least, for stateless addressing was to make the Link-Local scope work. It's brilliantly elegant. It allows all IPv6 configuration to be made over IPv6 (and thus use sane constructs like multicast to do it). Router Advertisements shift gateway and prefix configuration to the routers (which are the devices that actually know if they're available or not) rather than a DHCP server. If you set things up right, making a change to your RA will be seen by hosts almost instantly, and you won't need to go through the headache of waiting for DHCP leases to expire before hosts see that a network isn't available and let go of that route. One thing to keep in mind is that even though DHCPv6 and DHCP have a similar name, they're still pretty different. DHCPv6 was designed as part of IPv6. DHCP was an afterthought. Like many things in IPv6, they have been re-designed and included as a core component of IPv6. Don't go making assumptions that DHCPv6 was added to IPv6 to turn IPv6 into IPv4, and don't try to modify DHCPv6 to make that the case, please. What is needed now is protocol stability, and implementation of the current standards, not the re-writing of them mid-deployment. RDNSS is what I would consider silly. IPv6 already allows for an environment in which stateless is used and DHCPv6 only provides DNS (and other) information. This is because none of the flags are exclusive. In fact, you can use both Stateless and DHCPv6 on the same network, and host will get two IPv6 addresses (for example to configure servers with pre-determined addresses). This was the design intent. If you don't use DHCPv6 to assign addresses and are using SLAAC, you can still use DHCPv6 to provide other information only, or DHCPv6 Light, and this is already supported in most routing platforms to be configured right on the router. Implementation-wise, DHCPv6 Light and RDNSS have almost no difference. What RDNSS manages to do is embed DNS into RA (where it doesn't belong IMHO) seemingly for the sake of not calling it DHCPv6. Keeping DNS information out of RA is a Good Thing (which makes RDNSS a Bad Thing). Why? Because DNS might not always be the method we use for mapping names to addresses; it might see a rewrite like IP itself has seen, and there will likely be a desire to provide hosts with more configuration information. Looking DNS information into RA is a slippery slope. What's next, another option to RA for next-server information? DHCPv6 is separate from RA because they know that the needs for host configuration are more likely to change over time than IPv6 itself, and keeping them separate keeps IPv6 stable. The question isn't Stateless or DHCPv6. The question is Why are people implementing IPv6 without a core component? That's pretty much like saying you support IPv6 but not including ICMPv6 or MLD. This isn't a war of Stateless vs. DHCPv6. They're both the same thing. They're both core components of IPv6, and they both provide specific, non-conflicting, functionality. The argument of Having to implement DHCPv6 is more work is silly for these same reasons. Well I'm not going to support address scope because that's more work. Thankfully, with Apple seemingly supporting DHCPv6, that means Windows, Linux,
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 8:52 PM, Ray Soucy wrote: IPv6 is simple, elegant, and flexible. This is the first time I've ever seen 'IPv6' in the same sentence with 'simple', 'elegant', or 'flexible', unless preceded by 'not'. ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On 02/28/2011 08:44 AM, Dobbins, Roland wrote: On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote: Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. We already have this with MAC addresses, unless folks bother to periodically change them, do we not? And we certainly discussed randomising MAC addresses, for exactly the reasons stated. - Jim
Re: Mac OS X 10.7, still no DHCPv6
On 2011-02-28, at 08:44, Dobbins, Roland wrote: On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote: Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. We already have this with MAC addresses, unless folks bother to periodically change them, do we not? Only between hosts that are in the same layer-2 broadcast domain. By embedding the MAC into the layer-3 address, the concern is that the information becomes accessible Internet-wide. Joe
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 9:01 PM, Joe Abley wrote: By embedding the MAC into the layer-3 address, the concern is that the information becomes accessible Internet-wide. Given the the toxicity of hotel networks alone, my guess is that it already is pretty much available Internet-wide, at least to those who stand to illicitly profit by it the most. ; And let's not get started on IMEIs, ESNs, and MEIDs, heh. SMTP headers and various IM client sessions are also quite revealing, for that matter - and in near- or real-time, in many cases. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On 2/28/2011 8:44 AM, Dobbins, Roland wrote: On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote: Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. We already have this with MAC addresses, unless folks bother to periodically change them, do we not? Not globally, no. Jeff
Re: Mac OS X 10.7, still no DHCPv6
On 28/02/2011 13:52, Ray Soucy wrote: The real point, initially at least, for stateless addressing was to make the Link-Local scope work. It's brilliantly elegant. It allows all IPv6 configuration to be made over IPv6 (and thus use sane constructs like multicast to do it). Wonderful, brilliant design. Router Advertisements shift gateway and prefix configuration to the routers (which are the devices that actually know if they're available or not) rather than a DHCP server. If you set things up right, making a change to your RA will be seen by hosts almost instantly, and you won't need to go through the headache of waiting for DHCP leases to expire before hosts see that a network isn't available and let go of that route. Yes, it's all brilliant, wonderful. Elegant too, this idea of having two sets of protocols, because two is always better than one. It provides balance. I will be a lot more sympathetic about listening to arguments / explanations about this insanity the day that the IETF filters out arp and ipv4 packets from the conference network and depends entirely on ipv6 for connectivity for the entire conference. But we couldn't do that??!?!, I hear you say. I understand completely. Nick
Re: Sunday Funnies: Using a smart phone as a diagnostic tool
- Original Message - From: Joshua William Klubi joshua.kl...@gmail.com On Mon, Feb 28, 2011 at 2:00 AM, Jay Ashworth j...@baylink.com wrote: Do you have a smartphone? Blackberry? iPhone? Android? Try a Nokia N900 Maemo device, I've had an n800 for about 3 years now. Original battery, even, though it is time for a replacement. I passed on the n810 for a bunch of reasons, though. Didn't like the carrier selection for the n900. Do you use it as a technical tool in your work, either for accessing devices or testing connectivity -- or something else? yes if ur a real IT person and your very well versed in terms of knowledge and you use gadgets then you should know it is a swiss knife among all mobile devices. I'll use here a phrase that's current at the TV network where I work, used when someone who's getting paid to make the show suddenly discovers something everyone else in the room already knew: Welcome to the show. you can easily compare the difference, with N900 you don't need all those APP markets you have all the apps develop for Linux at your disposal, just use apt-get and then ur done. Though as with all Application Managers, they make backout hell; I use FBreader on my n800 as probably my primary app... and the newest build has a couple of *really* nasty bugs. And it's a pain in the *ass* to go back to an older build, without getting married to every detail of how the appmgr works. Or going off the reservation, after which you'll be prompted to 'upgrade' forever... HTC thunderbolt is not a bad looking phone. one most important thing about all the mobile phone devices out there it is only Nokia that support full networking stack of IPV6 on it no hacking needed to get it running. Note that the Thunderbolt will be an LTE700 phone, and therefore (or so I'm told) natively IPv6 on the air-interface; this will likely make that less of a problem than on older phones. Cheers, -- jra
RE: Mac OS X 10.7, still no DHCPv6
-Original Message- From: Jeff Kell [mailto:jeff-k...@utc.edu] Sent: Monday, February 28, 2011 8:49 AM To: Dobbins, Roland Cc: nanog group Subject: Re: Mac OS X 10.7, still no DHCPv6 On 2/28/2011 8:44 AM, Dobbins, Roland wrote: On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote: Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. We already have this with MAC addresses, unless folks bother to periodically change them, do we not? Not globally, no. Jeff Can someone explain what exactly the security threat is? If you are going to say that knowing the MAC address of the end device allows the bad guy to know what type of equipment you have and as such to attempt known compromises for said equipment, then please just don't reply. :) - Brian
Re: Mac OS X 10.7, still no DHCPv6
On 2011-02-28, at 09:51, Nick Hilliard wrote: I will be a lot more sympathetic about listening to arguments / explanations about this insanity the day that the IETF filters out arp and ipv4 packets from the conference network and depends entirely on ipv6 for connectivity for the entire conference. It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. [I also find the knee-jerk it's different from IPv4, the IETF is stupid memes to be tiring. Identifying questionable design decisions with hindsight is hardly the exclusive domain of IPv6; there are tremendously more crufty workarounds in IPv4, and far more available hindsight. Complaining about IPv6 because it's different from IPv4 doesn't get us anywhere.] Joe
Re: Mac OS X 10.7, still no DHCPv6
On 2011-02-28, at 09:53, Brian Johnson wrote: Can someone explain what exactly the security threat is? The threat model relates to the ability for a third party to be able to identify what subnets a single device has moved between, which is possible with MAC-embedded IPv6 addresses but not possible with addresses without embedded local identifiers. It's analogous to someone tracking credit card use and being able to infer from the vendor crumbs where an individual has been. I don't think this has ever been cited as a global, general threat that must be eliminated (just as people are generally happy to use the same credit card as they move around the planet and don't generally stress about the implications). However, I think it's reasonable that it's a concern for some. There is no global, fixed value of acceptable when it comes to privacy. Joe
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 9:59 PM, Joe Abley wrote: There's no point worrying about v6-only operations if we can't get dual-stack working reliably. I think this is the most insightful, cogent, and pertinent comment made regarding IPv6 in just about any medium at any time. [Yes, I know that dual-stack brings its own additional complexities to the table, but there really isn't any other choice, is there?] --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On 28/02/2011 14:59, Joe Abley wrote: I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. That's dual-stack as in dual-stack-except-one-of-the-stacks-really-doesn't-work-properly-so-we'll-fudge-around-it? :-) Look, my original point is that RA is a brilliant solution for a problem which never really existed. Now, can we all just ignore RA and work towards DHCPv6 because that's what's actually needed in the real world? [I also find the knee-jerk it's different from IPv4, the IETF is stupid memes to be tiring. Identifying questionable design decisions with hindsight is hardly the exclusive domain of IPv6; there are tremendously more crufty workarounds in IPv4, and far more available hindsight. Complaining about IPv6 because it's different from IPv4 doesn't get us anywhere.] Sure. We had lots of hindsight with ipv4, which should have indicated to people that we had just the sort of functionality that we needed from dhcp, even if dhcpv4 was badly implemented. But instead of sorting out DHCPv6 and making it do what we needed, we ended up with two protocols which ought to complement each other, but don't quite, and also can't quite operate independently because of historical turf wars in the IETF (now ended, thankfully). Complaining about knee-jerk reactions would have been fine in the early days, but it is 14 years, 3 weeks, 0 days, 2 hours and 8 minutes since I sent my first ipv6 ping, and we still haven't got there for basic ipv6 LAN connectivity. We haven't got there because I can't plug in my laptop into any arbitrary ipv6-only network and expect to be able to load up ipv6.google.com. Is that too high a standard to work towards? :-) Nick
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 5:44 AM, Dobbins, Roland wrote: On Feb 28, 2011, at 8:40 PM, Jim Gettys wrote: Again, having a permanently known identifier being broadcast all the time is a potentially a serious security/safety issue. We already have this with MAC addresses, unless folks bother to periodically change them, do we not? MAC addresses don't generally leave the local broadcast domain. Having a MAC address as a permanent identifier is a very different problem from having that MAC address go into a layer 3 protocol field. Owen
Re: Mac OS X 10.7, still no DHCPv6
On 2011-02-28, at 10:27, Nick Hilliard wrote: On 28/02/2011 14:59, Joe Abley wrote: I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. That's dual-stack as in dual-stack-except-one-of-the-stacks-really-doesn't-work-properly-so-we'll-fudge-around-it? :-) You're describing where we are. I'm talking about where I think we should be planning to arrive. Look, my original point is that RA is a brilliant solution for a problem which never really existed. Now, can we all just ignore RA and work towards DHCPv6 because that's what's actually needed in the real world? RA and DHCPv6 work together. It's different from DHCP in IPv4. Run with it. Sending people back to the drawing board at this late stage in the game (a) isn't going to happen and (b) isn't going to help anybody. We haven't got there because I can't plug in my laptop into any arbitrary ipv6-only network and expect to be able to load up ipv6.google.com. Is that too high a standard to work towards? :-) As I thought I mentioned, yes. Forget v6-only right now. Dual-stack is an operationally-harder problem, and it's a necessary prerequisite. Joe
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 10:27 PM, Owen DeLong wrote: Having a MAC address as a permanent identifier is a very different problem from having that MAC address go into a layer 3 protocol field. Given the plethora of identifiable information already frothing around in our data wakes, I'm unsure this is as big a deal as it might initially seem, especially given the existence of VPNs and proxy servers. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 10:27 PM, Nick Hilliard wrote: We haven't got there because I can't plug in my laptop into any arbitrary ipv6-only network and expect to be able to load up ipv6.google.com. - One day a master from another monastery came upon Abley as he was watching a young child sounding out letters from a spelling primer. I do not believe we should waste time trying to get IPv6 working in a dual-stack environment, said the sojourner, we should instead discuss what is wrong with IPv6, and how to fix it through the standards process and detailed vendor implementation guidelines. Abley then seized the book from the child and flung it into a nearby rubbish bin, saying, I wish this child to learn how to write sonnets in iambic pentameter. At that moment, the master was enlightened. - ; --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
Really, if you look back at the archives of this list these arguments are starting to get silly as you put it. Yes and no... It seems that every few months, as people discover that IPv6 isn't going away and they should brush up on it, people go through this process of debating the way IPv6 was designed as if it were 1998, and ultimately make posts like this. This may apply to some fraction of posters, but, I think many of the posters in this thread are actually fairly knowledgeable on IPv6. IPv6 is simple, elegant, and flexible. Parts of it are. Other parts are rigid, inflexible, and represent design decisions only theorists could love. DHCPv6 was always a core component of IPv6 (just like ICMPv6 is a core components of IPv6, or should we throw ping and traceroute into RA as well...) The intertwining of RA/DHCPv6 as it currently stands in IPv6 is an example of a design decision only theorists could love. In the real world, you have organizations where the people that manage hosts and host policy are not the people that run routers. In such environments, creating this kind of cross-organizational dependency that requires a constant coordination of even trivial changes on either side is far from optimal. This is why we have flags in RA to signal how addressing is done on a network for a prefix: A - Autonomous Flag, allows hosts to perform stateless addressing for a prefix. O - Other Flag, signals that additional configuration information is available (such as DNS) and DHCPv6 should be used. M - Managed Flag, signals that hosts should request a stateful address using DHCPv6. That's all well and good, but, when you consider the real world implications, it starts to break down in most organizations... Now, the people that run the routers have full control over the selection of addressing schemes for the network. The people who set host policy have no control short of statically configuring the hosts or getting buy-in from the people that run the routers for their particular preference in address selection methods. Yes, in a theoretical world, everyone gets along and cooperates easily and stuff just works out with whatever decision is agreed upon. In the real world, this becomes a constant source of tension between the two groups and increases workload on both sides of the equation unnecessarily. The real point, initially at least, for stateless addressing was to make the Link-Local scope work. It's brilliantly elegant. It allows all IPv6 configuration to be made over IPv6 (and thus use sane constructs like multicast to do it). All well and good, but... Router Advertisements shift gateway and prefix configuration to the routers (which are the devices that actually know if they're available or not) rather than a DHCP server. If you set things up right, making a change to your RA will be seen by hosts almost instantly, and you won't need to go through the headache of waiting for DHCP leases to expire before hosts see that a network isn't available and let go of that route. Which also means: 1. Multiple subnets on the same media that are intended for different hosts and have different routers are no longer feasible. (Yes, you can argue they're less than desirable in IPv4 and I would agree, but, they exist in the real world for a variety of layer 8-10 reasons and re-engineering an organization to make it fit into IPv6 is non-trivial). 2. RA has the problem of treating all routers claiming to have the same priority are of equal value to all hosts. Routers are considered fully interchangeable units and it is assumed that all routers are a viable path to everything. DHCPv4 actually provides facilities for dealing with more complex topologies where different destinations may be in different directions from different hosts. It also allows for providing different default gateways to different hosts based on policy decisions. Yes, in the most basic cases, RA can be superior to getting routing information from DHCP. However, in the real world, there are many cases where it simply breaks things and is a step backwards from capabilities in use in IPv4. One thing to keep in mind is that even though DHCPv6 and DHCP have a similar name, they're still pretty different. DHCPv6 was designed as part of IPv6. DHCP was an afterthought. Like many things in IPv6, they have been re-designed and included as a core component of IPv6. Don't go making assumptions that DHCPv6 was added to IPv6 to turn IPv6 into IPv4, and don't try to modify DHCPv6 to make that the case, please. What is needed now is protocol stability, and implementation of the current standards, not the re-writing of them mid-deployment. While you have
Re: Mac OS X 10.7, still no DHCPv6
On 28/02/2011 15:45, Dobbins, Roland wrote: At that moment, the master was enlightened. One day a master from another monastery came upon Dobbins and Abley as they were watching a 14 year-old cripple learning how to fly. I do not believe we should waste time teaching children to walk, said Abley. Indeed not, agreed Dobbins, a waste of time and a distraction from the long term goal of flight. We have kept the child restrained from birth so that he can concentrate on the loftier ideal. The sojourner then seized the book from the child, flung it at Abley and Dobbins, called social services to lodge a complaint about child neglect, then stalked off in disgust, rolling his eyes and muttering under his breath about the rank stupidity of humanity. At that moment, Dobbins and Abley were enlightened. Nick
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 6:59 AM, Joe Abley wrote: On 2011-02-28, at 09:51, Nick Hilliard wrote: I will be a lot more sympathetic about listening to arguments / explanations about this insanity the day that the IETF filters out arp and ipv4 packets from the conference network and depends entirely on ipv6 for connectivity for the entire conference. It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. I disagree. Those of us who know what it costs to do double maintenance on a continuing basis would like to drive a stake through the heart of IPv4 sooner rather than later. IPv6-only viability is the real goal. This is, in the long run, a transition from v4 to v6. Dual-stack is an interim stop-gap, not an end solution. Dual stack is mostly working reliably at this point. There are some improvements needed in IPv6 for enterprises and they are needed for both dual stack and for IPv6 only, so, I'm not sure why that becomes particularly relevant to this thread. However, we should always keep our eye on the prize as it were. That's the eventuality of realizing huge cost savings (lower CAM utilization, better scaling, etc.) of a v6-only world. [I also find the knee-jerk it's different from IPv4, the IETF is stupid memes to be tiring. Identifying questionable design decisions with hindsight is hardly the exclusive domain of IPv6; there are tremendously more crufty workarounds in IPv4, and far more available hindsight. Complaining about IPv6 because it's different from IPv4 doesn't get us anywhere.] How about attempting to point out the areas where IPv6 could be improved, which, is how I regard most of this thread. Owen
Re: Mac OS X 10.7, still no DHCPv6
1. Multiple subnets on the same media that are intended for different hosts and have different routers are no longer feasible. (Yes, you can argue they're less than desirable in IPv4 and I would agree, but, they exist in the real world for a variety of layer 8-10 reasons and re-engineering an organization to make it fit into IPv6 is non-trivial). Owen, you seem to be fixated around the idea that you can't have multiple prefixes on the same subnet. Set the routers to disable SLAAC, Setup DHCPv6 to only respond with address information for the specific hosts you want to control for each prefix (this DHCPv6 server can be run by someone different than the person configuring routers). Hosts will use the gateway for the prefix they've been assigned. I'm not sure why you insist otherwise. I've actually been working on such a setup for web-based host registration and using a shadow ULA prefix until registered, then they get a real DHCPv6 response. And yes, you're correct, it would be much better to keep different hosts on different VLANs, this is just a possible solution to your problem statement. I wouldn't be opposed to DHCPv6 options to deliver routes to hosts (e.g. prefix, prefix-length, gateway, and metric) not just default route information. But I'm not sure that anything is really lost in terms of functionality under the current implementation, you just have to approach it in a slightly different way. RDNSS encourages people not to implement functional DHCPv6 clients, so I'm not sure how you find it to be a good thing for the problem statement above. On Mon, Feb 28, 2011 at 11:01 AM, Owen DeLong o...@delong.com wrote: Really, if you look back at the archives of this list these arguments are starting to get silly as you put it. Yes and no... It seems that every few months, as people discover that IPv6 isn't going away and they should brush up on it, people go through this process of debating the way IPv6 was designed as if it were 1998, and ultimately make posts like this. This may apply to some fraction of posters, but, I think many of the posters in this thread are actually fairly knowledgeable on IPv6. IPv6 is simple, elegant, and flexible. Parts of it are. Other parts are rigid, inflexible, and represent design decisions only theorists could love. DHCPv6 was always a core component of IPv6 (just like ICMPv6 is a core components of IPv6, or should we throw ping and traceroute into RA as well...) The intertwining of RA/DHCPv6 as it currently stands in IPv6 is an example of a design decision only theorists could love. In the real world, you have organizations where the people that manage hosts and host policy are not the people that run routers. In such environments, creating this kind of cross-organizational dependency that requires a constant coordination of even trivial changes on either side is far from optimal. This is why we have flags in RA to signal how addressing is done on a network for a prefix: A - Autonomous Flag, allows hosts to perform stateless addressing for a prefix. O - Other Flag, signals that additional configuration information is available (such as DNS) and DHCPv6 should be used. M - Managed Flag, signals that hosts should request a stateful address using DHCPv6. That's all well and good, but, when you consider the real world implications, it starts to break down in most organizations... Now, the people that run the routers have full control over the selection of addressing schemes for the network. The people who set host policy have no control short of statically configuring the hosts or getting buy-in from the people that run the routers for their particular preference in address selection methods. Yes, in a theoretical world, everyone gets along and cooperates easily and stuff just works out with whatever decision is agreed upon. In the real world, this becomes a constant source of tension between the two groups and increases workload on both sides of the equation unnecessarily. The real point, initially at least, for stateless addressing was to make the Link-Local scope work. It's brilliantly elegant. It allows all IPv6 configuration to be made over IPv6 (and thus use sane constructs like multicast to do it). All well and good, but... Router Advertisements shift gateway and prefix configuration to the routers (which are the devices that actually know if they're available or not) rather than a DHCP server. If you set things up right, making a change to your RA will be seen by hosts almost instantly, and you won't need to go through the headache of waiting for DHCP leases to expire before hosts see that a network isn't available and let go of that route. Which also means: 1. Multiple subnets on the same media that are intended for different hosts and have different routers are no
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 11:14 PM, Owen DeLong wrote: IPv6-only viability is the real goal. This is, in the long run, a transition from v4 to v6. Dual-stack is an interim stop-gap, not an end solution. I think most everyone agrees with this. However, getting experience with dual-stack is better than no experience with IPv6 at all. This doesn't mean that dual-stack should be rolled out everywhere; just that doing so may in fact make sense in some situations, and will often result in folks getting some operational experience with IPv6 vs. none at all until some time in the distant future. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 11:15 PM, Nick Hilliard wrote: At that moment, Dobbins and Abley were enlightened. hahaha ; Hey, I think dual-stack is pretty ugly - just that it's less ugly than getting no operational experience with IPv6 at all on production networks until some point in the indeterminate future. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 7:34 AM, Joe Abley wrote: On 2011-02-28, at 10:27, Nick Hilliard wrote: On 28/02/2011 14:59, Joe Abley wrote: I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. That's dual-stack as in dual-stack-except-one-of-the-stacks-really-doesn't-work-properly-so-we'll-fudge-around-it? :-) You're describing where we are. I'm talking about where I think we should be planning to arrive. Your description sounds more like where we should be making a plane change. The eventual destination is IPv6-only. Dual-stack is a temporary stopover along the way. However, you are partially right in that we should be focusing on arriving at the first stop-over until we arrive there. Then we can start navigating from there to the final destination. Look, my original point is that RA is a brilliant solution for a problem which never really existed. Now, can we all just ignore RA and work towards DHCPv6 because that's what's actually needed in the real world? RA and DHCPv6 work together. It's different from DHCP in IPv4. Run with it. Sending people back to the drawing board at this late stage in the game (a) isn't going to happen and (b) isn't going to help anybody. And the model breaks badly at layers 8-10 in most enterprises and many other organizations. We haven't got there because I can't plug in my laptop into any arbitrary ipv6-only network and expect to be able to load up ipv6.google.com. Is that too high a standard to work towards? :-) As I thought I mentioned, yes. Forget v6-only right now. Dual-stack is an operationally-harder problem, and it's a necessary prerequisite. For some situations at this point, that may not actually be true. It will be soon enough that it won't even be possible. Owen
Re: Mac OS X 10.7, still no DHCPv6
On Mon, 28 Feb 2011 10:04:23 EST, Joe Abley said: I don't think this has ever been cited as a global, general threat that must be eliminated (just as people are generally happy to use the same credit card as they move around the planet and don't generally stress about the implications). It's not a global threat. However, it *is* a *specific* threat to some people. We support the ability of students to restrict directory information to various levels, from don't list home address to we won't admit they are a student without a court order or other authorization. I happen to know that 299 students (out of roughly 7,000) in our graduating class currently have their privacy set high enough to exclude them from being listed in the program for the 2011 graduation ceremony. Sure would be a shame if the network itself insisted on making them trackable... (Some of these students are just privacy minded, but we have a fair number that are children of diplomats/etc, or are literally in hiding from ex'es or non-custodial parents and have restraining orders out - these people *really* don't want to be tracked/found...) pgpKebaVWF0qI.pgp Description: PGP signature
Re: Mac OS X 10.7, still no DHCPv6
On 28 Feb 2011, at 16:57, valdis.kletni...@vt.edu wrote: On Mon, 28 Feb 2011 10:04:23 EST, Joe Abley said: I don't think this has ever been cited as a global, general threat that must be eliminated (just as people are generally happy to use the same credit card as they move around the planet and don't generally stress about the implications). It's not a global threat. However, it *is* a *specific* threat to some people. We support the ability of students to restrict directory information to various levels, from don't list home address to we won't admit they are a student without a court order or other authorization. I happen to know that 299 students (out of roughly 7,000) in our graduating class currently have their privacy set high enough to exclude them from being listed in the program for the 2011 graduation ceremony. Sure would be a shame if the network itself insisted on making them trackable... (Some of these students are just privacy minded, but we have a fair number that are children of diplomats/etc, or are literally in hiding from ex'es or non-custodial parents and have restraining orders out - these people *really* don't want to be tracked/found...) But you still need to know who they are so that when the court order pops through your door and it turns out they have been brewing up anthrax in the biology lab you'll want to be able to identify the IP address that was responsible for the nick binladen on the \terrorists channel on EFnet, yeah? I really do not care less if people are tracked/found/whatever externally, so long as internally I can identify with some fair degree of certainty who had that address at any one time. And so in order to fix this we have people writing perl scripts to hoover up tidbits of information from snoop ports or routers. At least with DHCP you actually get a log on a box who who had what. -- Leigh Porter
OT: What vexes VoIP users?
OT, but NANOG is almost always good for quick clue ... For those who have residential VoIP, what provider {features | bugs} are most vexing? For those who provision residential VoIP, what subscriber {expectations | behaviors} are most vexing? Thanks in advance, Eric
RE: What vexes VoIP users?
Some provider woes: FAX over VOIP is a PITA. I've not yet seen an ATA or softswitch that handled it reliably. E911 for mobile devices sucks. Regulations, and the E911 system, do not seem to have the flexibility for handling this in a seamless way. Call routing (on a more global scale) sucks. Keeping calls pure IP is sexy, but the routing protocol for it is nonexistent (and please don't say ENUM).
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011 8:45 AM, Owen DeLong o...@delong.com wrote: On Feb 28, 2011, at 7:34 AM, Joe Abley wrote: On 2011-02-28, at 10:27, Nick Hilliard wrote: On 28/02/2011 14:59, Joe Abley wrote: I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. That's dual-stack as in dual-stack-except-one-of-the-stacks-really-doesn't-work-properly-so-we'll-fudge-around-it? :-) You're describing where we are. I'm talking about where I think we should be planning to arrive. Your description sounds more like where we should be making a plane change. The eventual destination is IPv6-only. Dual-stack is a temporary stopover along the way. However, you are partially right in that we should be focusing on arriving at the first stop-over until we arrive there. Then we can start navigating from there to the final destination. Look, my original point is that RA is a brilliant solution for a problem which never really existed. Now, can we all just ignore RA and work towards DHCPv6 because that's what's actually needed in the real world? RA and DHCPv6 work together. It's different from DHCP in IPv4. Run with it. Sending people back to the drawing board at this late stage in the game (a) isn't going to happen and (b) isn't going to help anybody. And the model breaks badly at layers 8-10 in most enterprises and many other organizations. We haven't got there because I can't plug in my laptop into any arbitrary ipv6-only network and expect to be able to load up ipv6.google.com . Is that too high a standard to work towards? :-) As I thought I mentioned, yes. Forget v6-only right now. Dual-stack is an operationally-harder problem, and it's a necessary prerequisite. For some situations at this point, that may not actually be true. It will be soon enough that it won't even be possible. Owen is right. Ipv6-only is a very near term reality for networks with very fast growing edges like mobile phones and wireless machine to machine communications. It is not prudent to install an electricity meter today with a 30 year expected life span ... and include ipv4. These systems are being deployed today as ipv6 only, not in the future. Also, you can expect many types of mobile phones to be ipv6-only soon. Ipv4 is not going away, dual stack fell short of being the universal transition mechanism but is still useful in many palaces -especially content hosts, and ipv6-only will pop up soon in as many places as it possibly makes sense. Remember, from a network planner / designer / architect perspective, ipv4 is not a resource for future network growth. Owen
RE: What vexes VoIP users?
Power supply! Old POTS is remote-power-suplied, so the phone will work for hours, days or even weeks from remote battery power. In my area, one mobile network was off after 4h, the other after 10h, but my good-old analogue telefone did work all the time during an 40h power outage (it was 11 years ago). Juergen. -Original Message- From: Nathan Eisenberg [mailto:nat...@atlasnetworks.us] Sent: Monday, February 28, 2011 6:33 PM To: NANOG list Subject: RE: What vexes VoIP users? Some provider woes: FAX over VOIP is a PITA. I've not yet seen an ATA or softswitch that handled it reliably. E911 for mobile devices sucks. Regulations, and the E911 system, do not seem to have the flexibility for handling this in a seamless way. Call routing (on a more global scale) sucks. Keeping calls pure IP is sexy, but the routing protocol for it is nonexistent (and please don't say ENUM).
Re: What vexes VoIP users?
Simplicity. POTS lets me plug almost anything in from the past who-knows-how-many-years and it just works. When it breaks, I can go next door and borrow a telephone. When I can pick up an automagically configured VoIP device from a huge selection down at the local electronics shop and when it just works at my house and my kids houses then it will be interesting. VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. -- Leigh On 28 Feb 2011, at 17:55, na...@ilk.net wrote: Power supply! Old POTS is remote-power-suplied, so the phone will work for hours, days or even weeks from remote battery power. In my area, one mobile network was off after 4h, the other after 10h, but my good-old analogue telefone did work all the time during an 40h power outage (it was 11 years ago). Juergen. -Original Message- From: Nathan Eisenberg [mailto:nat...@atlasnetworks.us] Sent: Monday, February 28, 2011 6:33 PM To: NANOG list Subject: RE: What vexes VoIP users? Some provider woes: FAX over VOIP is a PITA. I've not yet seen an ATA or softswitch that handled it reliably. E911 for mobile devices sucks. Regulations, and the E911 system, do not seem to have the flexibility for handling this in a seamless way. Call routing (on a more global scale) sucks. Keeping calls pure IP is sexy, but the routing protocol for it is nonexistent (and please don't say ENUM).
Re: What vexes VoIP users?
On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. -- Leigh Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year!
Re: What vexes VoIP users?
On Mon, 28 Feb 2011 13:29:08 EST, Bret Clark said: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I do believe that the ILEC's are mostly losing POTS lines to cell phones, not to VoIP. I myself have a cell phone but no POTS service at my home address. On the other hand, I *am* seeing a metric ton of Vonage and Magic Jack ads on TV these days - if VoIP is too niche, how are those two making any money? pgpCRfSUaSLpa.pgp Description: PGP signature
Re: What vexes VoIP users?
On 2/28/2011 1:29 PM, Bret Clark wrote: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. -- Leigh Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! Very true, remember that VOIP includes Packet Cable (as opposed to SIP from Vonage etc all) from cable providers which is largely a POTs replacement service from the end users stand point. Comcast is now a top 5 phone provider in the US. This is anecdotal, but most of the Magic Jack (which is SIP AFAIK) purchases I see are non-technical people. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: What vexes VoIP users?
On 28 Feb 2011, at 18:29, Bret Clark wrote: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. -- Leigh Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! And how many grandmothers do you think are responsible for this downturn? Not many I'll bet. The downturn will be down to cell phones and the odd person who gets cable and finds they can do with skype or something. People are not, en-masse, going away from POTS and towards plugging a VoIP device into the back of their router. -- Leigh Porter
Re: What vexes VoIP users?
On 28 Feb 2011, at 18:37, valdis.kletni...@vt.edu wrote: On Mon, 28 Feb 2011 13:29:08 EST, Bret Clark said: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I do believe that the ILEC's are mostly losing POTS lines to cell phones, not to VoIP. I myself have a cell phone but no POTS service at my home address. On the other hand, I *am* seeing a metric ton of Vonage and Magic Jack ads on TV these days - if VoIP is too niche, how are those two making any money? I do not live over there, I have never seen a Vonage or Magic jack or any other VoIP service ad on TV in the UK, ever. It is quite a different market here. I can get POTS services over the same copper from, I'd say, about 5 different companies. Maybe more, I have not counted. I guess the competition already available on the copper would largely preclude anything but the cheapest VoIP service. -- Leigh
Re: What vexes VoIP users?
They are in the US. Comcast tallies 8.6 million household telephone service accounts, making it the United States' third-largest telephone provider. As of February 16, 2011 Comcast has 8.610 million voice customers. http://en.wikipedia.org/wiki/Comcast#Home_telephone People are not, en-masse, going away from POTS and towards plugging a VoIP device into the back of their router. -- Leigh Porter -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: What vexes VoIP users?
On Mon, 28 Feb 2011, Leigh Porter wrote: On 28 Feb 2011, at 18:37, valdis.kletni...@vt.edu wrote: On Mon, 28 Feb 2011 13:29:08 EST, Bret Clark said: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I do believe that the ILEC's are mostly losing POTS lines to cell phones, not to VoIP. I myself have a cell phone but no POTS service at my home address. On the other hand, I *am* seeing a metric ton of Vonage and Magic Jack ads on TV these days - if VoIP is too niche, how are those two making any money? It's more cellphones than VoIP or cable provider services, but the latter two are still eating POTS' lunch in the US - even if you don't count something like FiOS where Verizon tears out your copper POTS and moves your line to their ONC. It is quite a different market here. I can get POTS services over the same copper from, I'd say, about 5 different companies. Maybe more, I have not counted. I guess the competition already available on the copper would largely preclude anything but the cheapest VoIP service. Sounds very different indeed. In the US, it's basically your local Ma Bell derivative, or something not-POTs. Anecodtally, as of this morning we just dropped one of our POTS lines for the cable company's alternative. Cost dropped from $69/mo to $29/mo right there. With say, Verizon POTS you're looking at nearly $30/mo just for dialtone, with everything else (outbound calls, LD, caller ID...) extra. Now there is some added value in real POTS, but it's awfully hard to justify the cost difference. -- Jameel Akari
Re: What vexes VoIP users?
Since our company is a VoIP company, I will chime in to this topic. Let's start off with the definitions so everyone is on the same page: vex |veks| verb [ trans. ] make (someone) feel annoyed, frustrated, or worried, esp. with trivial matters : the memory of the conversation still vexed him | [as adj. ] ( vexing)the most vexing questions for policymakers.] Alright, now that that's out of the way... I am only referring to small medium business and some enterprise (Those are all our customers, we do not do residential) - Seemingly complex. - Worried about the What if the internet goes down scenario. - Call quality. - Price - Location - Outages Responses: - Seemingly complex... Very true. Most VoIP companies, both hosted and on premises are difficult/time consuming to setup and make work they way you want it. - What if the internet goes down. This one is a challenge. POTS actually have issues too, but when analog phone service goes down, there is no light on the phone indicating that the phones are not working so many customers perceive there is a problem. With the FCC mandating all POTS move to a VoIP backend (which for long hauls, is mostly already true) POTS will experience the same downtime as the internet. However as we all know, the internet is built to tolerate outages. For most people they don't understand how the internet actually works. - Call quality... If a VoIP company pays for good bandwidth and maintains good relationships with peers, the only concern is the last-mile(From the CO to location). Now there is much more that plays in quality, ie. codec selection, voice buffer, locality to the pbx. - Price... Believe it or not people are worried about paying less for better service. Who would have thought? - Location... Location is super important both in the last mile and PBX. - Last mile: In older locations the copper in the ground is aged, if you can't get fiber and your stuck using T1, lines, then hopefully you are in a location that keeps the copper in the ground properly maintained. If you are in older locations, which one of our offices are, there are remedies, you can contact your bandwidth provider and have them do a head to head test using a BERD (bit error rate detector) and they can find the problem. But that's a whole other topic. -PBX: Some people believe that on premise is the best location for a PBX, this may or may not be true. I happen to believe that keeping it off premise is the way to go. You get up-time, redundancy, locality, and mobility. You just plug in your phone and your phone is up and running. Move offices.. got bandwidth? Your good to go. No equipment to worry about, say a power outage happens, your voicemail still works people call in and are in call queues and have no clue you are down. Feels more like POTS with an enterprise backend. -Outages: If the internet does fail, most providers offer WAN survivability. The customer plugs in phone lines into the router and if the internet goes down, they can make emergency calls or calls to the world limited by the number of lines the router can accept and are plugged in of course. Now in all our experience going on 7 years now, 90% of the time WAN outages happen, guess what also dies, the POTS! Who would have thought that when cables get cut, that the phone lines were also part of the cables? There you go, some common worries, with some answers to hopefully sooth the vexed VoIP user. Bret Palsson Sr. Network Systems Administrator www.getjive.com On Feb 28, 2011, at 11:37 AM, valdis.kletni...@vt.edu wrote: On Mon, 28 Feb 2011 13:29:08 EST, Bret Clark said: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I do believe that the ILEC's are mostly losing POTS lines to cell phones, not to VoIP. I myself have a cell phone but no POTS service at my home address. On the other hand, I *am* seeing a metric ton of Vonage and Magic Jack ads on TV these days - if VoIP is too niche, how are those two making any money?
Re: What vexes VoIP users?
On 28 Feb 2011, at 19:03, Jameel Akari wrote: Sounds very different indeed. In the US, it's basically your local Ma Bell derivative, or something not-POTs. Anecodtally, as of this morning we just dropped one of our POTS lines for the cable company's alternative. Cost dropped from $69/mo to $29/mo right there. With say, Verizon POTS you're looking at nearly $30/mo just for dialtone, with everything else (outbound calls, LD, caller ID...) extra. Now there is some added value in real POTS, but it's awfully hard to justify the cost difference. -- Jameel Akari Yeah I am thankful for the competition we have over here now! I think that if I were 'over there' then I would be using VoIP as well. -- Leigh Porter
Re: What vexes VoIP users?
Another vexation for VOIP in the SMB environment is that it rarely works particularly well (if at all) in light of a multiple-external-address NAT pool. You simply have to map all of your VOIP phones in such a way that they consistently get the same external IP every time or shit breaks badly. Owen On Feb 28, 2011, at 11:11 AM, Bret Palsson wrote: Since our company is a VoIP company, I will chime in to this topic. Let's start off with the definitions so everyone is on the same page: vex |veks| verb [ trans. ] make (someone) feel annoyed, frustrated, or worried, esp. with trivial matters : the memory of the conversation still vexed him | [as adj. ] ( vexing)the most vexing questions for policymakers.] Alright, now that that's out of the way... I am only referring to small medium business and some enterprise (Those are all our customers, we do not do residential) - Seemingly complex. - Worried about the What if the internet goes down scenario. - Call quality. - Price - Location - Outages Responses: - Seemingly complex... Very true. Most VoIP companies, both hosted and on premises are difficult/time consuming to setup and make work they way you want it. - What if the internet goes down. This one is a challenge. POTS actually have issues too, but when analog phone service goes down, there is no light on the phone indicating that the phones are not working so many customers perceive there is a problem. With the FCC mandating all POTS move to a VoIP backend (which for long hauls, is mostly already true) POTS will experience the same downtime as the internet. However as we all know, the internet is built to tolerate outages. For most people they don't understand how the internet actually works. - Call quality... If a VoIP company pays for good bandwidth and maintains good relationships with peers, the only concern is the last-mile(From the CO to location). Now there is much more that plays in quality, ie. codec selection, voice buffer, locality to the pbx. - Price... Believe it or not people are worried about paying less for better service. Who would have thought? - Location... Location is super important both in the last mile and PBX. - Last mile: In older locations the copper in the ground is aged, if you can't get fiber and your stuck using T1, lines, then hopefully you are in a location that keeps the copper in the ground properly maintained. If you are in older locations, which one of our offices are, there are remedies, you can contact your bandwidth provider and have them do a head to head test using a BERD (bit error rate detector) and they can find the problem. But that's a whole other topic. -PBX: Some people believe that on premise is the best location for a PBX, this may or may not be true. I happen to believe that keeping it off premise is the way to go. You get up-time, redundancy, locality, and mobility. You just plug in your phone and your phone is up and running. Move offices.. got bandwidth? Your good to go. No equipment to worry about, say a power outage happens, your voicemail still works people call in and are in call queues and have no clue you are down. Feels more like POTS with an enterprise backend. -Outages: If the internet does fail, most providers offer WAN survivability. The customer plugs in phone lines into the router and if the internet goes down, they can make emergency calls or calls to the world limited by the number of lines the router can accept and are plugged in of course. Now in all our experience going on 7 years now, 90% of the time WAN outages happen, guess what also dies, the POTS! Who would have thought that when cables get cut, that the phone lines were also part of the cables? There you go, some common worries, with some answers to hopefully sooth the vexed VoIP user. Bret Palsson Sr. Network Systems Administrator www.getjive.com On Feb 28, 2011, at 11:37 AM, valdis.kletni...@vt.edu wrote: On Mon, 28 Feb 2011 13:29:08 EST, Bret Clark said: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I do believe that the ILEC's are mostly losing POTS lines to cell phones, not to VoIP. I myself have a cell phone but no POTS service at my home address. On the other hand, I *am* seeing a metric ton of Vonage and Magic Jack ads on TV these days - if VoIP is too niche, how are those two making any money?
Re: What vexes VoIP users?
We haven't run into that issue and have very large clients. I'm interested to find out where you may have run into that issue? -Bret On Feb 28, 2011, at 12:25 PM, Owen DeLong wrote: Another vexation for VOIP in the SMB environment is that it rarely works particularly well (if at all) in light of a multiple-external-address NAT pool. You simply have to map all of your VOIP phones in such a way that they consistently get the same external IP every time or shit breaks badly. Owen On Feb 28, 2011, at 11:11 AM, Bret Palsson wrote: Since our company is a VoIP company, I will chime in to this topic. Let's start off with the definitions so everyone is on the same page: vex |veks| verb [ trans. ] make (someone) feel annoyed, frustrated, or worried, esp. with trivial matters : the memory of the conversation still vexed him | [as adj. ] ( vexing)the most vexing questions for policymakers.] Alright, now that that's out of the way... I am only referring to small medium business and some enterprise (Those are all our customers, we do not do residential) - Seemingly complex. - Worried about the What if the internet goes down scenario. - Call quality. - Price - Location - Outages Responses: - Seemingly complex... Very true. Most VoIP companies, both hosted and on premises are difficult/time consuming to setup and make work they way you want it. - What if the internet goes down. This one is a challenge. POTS actually have issues too, but when analog phone service goes down, there is no light on the phone indicating that the phones are not working so many customers perceive there is a problem. With the FCC mandating all POTS move to a VoIP backend (which for long hauls, is mostly already true) POTS will experience the same downtime as the internet. However as we all know, the internet is built to tolerate outages. For most people they don't understand how the internet actually works. - Call quality... If a VoIP company pays for good bandwidth and maintains good relationships with peers, the only concern is the last-mile(From the CO to location). Now there is much more that plays in quality, ie. codec selection, voice buffer, locality to the pbx. - Price... Believe it or not people are worried about paying less for better service. Who would have thought? - Location... Location is super important both in the last mile and PBX. - Last mile: In older locations the copper in the ground is aged, if you can't get fiber and your stuck using T1, lines, then hopefully you are in a location that keeps the copper in the ground properly maintained. If you are in older locations, which one of our offices are, there are remedies, you can contact your bandwidth provider and have them do a head to head test using a BERD (bit error rate detector) and they can find the problem. But that's a whole other topic. -PBX: Some people believe that on premise is the best location for a PBX, this may or may not be true. I happen to believe that keeping it off premise is the way to go. You get up-time, redundancy, locality, and mobility. You just plug in your phone and your phone is up and running. Move offices.. got bandwidth? Your good to go. No equipment to worry about, say a power outage happens, your voicemail still works people call in and are in call queues and have no clue you are down. Feels more like POTS with an enterprise backend. -Outages: If the internet does fail, most providers offer WAN survivability. The customer plugs in phone lines into the router and if the internet goes down, they can make emergency calls or calls to the world limited by the number of lines the router can accept and are plugged in of course. Now in all our experience going on 7 years now, 90% of the time WAN outages happen, guess what also dies, the POTS! Who would have thought that when cables get cut, that the phone lines were also part of the cables? There you go, some common worries, with some answers to hopefully sooth the vexed VoIP user. Bret Palsson Sr. Network Systems Administrator www.getjive.com On Feb 28, 2011, at 11:37 AM, valdis.kletni...@vt.edu wrote: On Mon, 28 Feb 2011 13:29:08 EST, Bret Clark said: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I do believe that the ILEC's are mostly losing POTS lines to cell phones, not to VoIP. I myself have a cell phone but no POTS service at my home address. On the other hand, I *am* seeing a metric ton of Vonage and Magic Jack ads on TV these days - if VoIP is too niche, how are those two making any money?
Re: What vexes VoIP users?
Sorry I didn't include this in the last email... We have large clients who have phones registered on multiples of public IPs from the same location. Works no problem. We do some trickery on our side to make that happen, but I thought all VoIP companies would do that. -Bret On Feb 28, 2011, at 12:25 PM, Owen DeLong wrote: Another vexation for VOIP in the SMB environment is that it rarely works particularly well (if at all) in light of a multiple-external-address NAT pool. You simply have to map all of your VOIP phones in such a way that they consistently get the same external IP every time or shit breaks badly. Owen On Feb 28, 2011, at 11:11 AM, Bret Palsson wrote: Since our company is a VoIP company, I will chime in to this topic. Let's start off with the definitions so everyone is on the same page: vex |veks| verb [ trans. ] make (someone) feel annoyed, frustrated, or worried, esp. with trivial matters : the memory of the conversation still vexed him | [as adj. ] ( vexing)the most vexing questions for policymakers.] Alright, now that that's out of the way... I am only referring to small medium business and some enterprise (Those are all our customers, we do not do residential) - Seemingly complex. - Worried about the What if the internet goes down scenario. - Call quality. - Price - Location - Outages Responses: - Seemingly complex... Very true. Most VoIP companies, both hosted and on premises are difficult/time consuming to setup and make work they way you want it. - What if the internet goes down. This one is a challenge. POTS actually have issues too, but when analog phone service goes down, there is no light on the phone indicating that the phones are not working so many customers perceive there is a problem. With the FCC mandating all POTS move to a VoIP backend (which for long hauls, is mostly already true) POTS will experience the same downtime as the internet. However as we all know, the internet is built to tolerate outages. For most people they don't understand how the internet actually works. - Call quality... If a VoIP company pays for good bandwidth and maintains good relationships with peers, the only concern is the last-mile(From the CO to location). Now there is much more that plays in quality, ie. codec selection, voice buffer, locality to the pbx. - Price... Believe it or not people are worried about paying less for better service. Who would have thought? - Location... Location is super important both in the last mile and PBX. - Last mile: In older locations the copper in the ground is aged, if you can't get fiber and your stuck using T1, lines, then hopefully you are in a location that keeps the copper in the ground properly maintained. If you are in older locations, which one of our offices are, there are remedies, you can contact your bandwidth provider and have them do a head to head test using a BERD (bit error rate detector) and they can find the problem. But that's a whole other topic. -PBX: Some people believe that on premise is the best location for a PBX, this may or may not be true. I happen to believe that keeping it off premise is the way to go. You get up-time, redundancy, locality, and mobility. You just plug in your phone and your phone is up and running. Move offices.. got bandwidth? Your good to go. No equipment to worry about, say a power outage happens, your voicemail still works people call in and are in call queues and have no clue you are down. Feels more like POTS with an enterprise backend. -Outages: If the internet does fail, most providers offer WAN survivability. The customer plugs in phone lines into the router and if the internet goes down, they can make emergency calls or calls to the world limited by the number of lines the router can accept and are plugged in of course. Now in all our experience going on 7 years now, 90% of the time WAN outages happen, guess what also dies, the POTS! Who would have thought that when cables get cut, that the phone lines were also part of the cables? There you go, some common worries, with some answers to hopefully sooth the vexed VoIP user. Bret Palsson Sr. Network Systems Administrator www.getjive.com On Feb 28, 2011, at 11:37 AM, valdis.kletni...@vt.edu wrote: On Mon, 28 Feb 2011 13:29:08 EST, Bret Clark said: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I do believe that the ILEC's are mostly losing POTS lines to cell phones, not to VoIP. I myself have a cell phone but no POTS service at my home address. On the other hand, I *am* seeing a metric ton of Vonage and Magic Jack ads on TV
RE: What vexes VoIP users?
Odd - do the phones just randomly egress from different IPs in the pool if you don't? Is this perhaps a too-long registration interval issue? Short registration timers seem to deal with keeping the state table appeased on most firewalls. Any chance the NAT device has some god-forsaken ALG agent installed that's trying to proxy the SIP traffic? (Yes, I hate ALGs. They are evil.) Nathan -Original Message- From: Owen DeLong [mailto:o...@delong.com] Sent: Monday, February 28, 2011 11:26 AM To: Bret Palsson Cc: nanog@nanog.org Subject: Re: What vexes VoIP users? Another vexation for VOIP in the SMB environment is that it rarely works particularly well (if at all) in light of a multiple-external-address NAT pool. You simply have to map all of your VOIP phones in such a way that they consistently get the same external IP every time or shit breaks badly. Owen On Feb 28, 2011, at 11:11 AM, Bret Palsson wrote: Since our company is a VoIP company, I will chime in to this topic. Let's start off with the definitions so everyone is on the same page: vex |veks| verb [ trans. ] make (someone) feel annoyed, frustrated, or worried, esp. with trivial matters : the memory of the conversation still vexed him | [as adj. ] ( vexing)the most vexing questions for policymakers.] Alright, now that that's out of the way... I am only referring to small medium business and some enterprise (Those are all our customers, we do not do residential) - Seemingly complex. - Worried about the What if the internet goes down scenario. - Call quality. - Price - Location - Outages Responses: - Seemingly complex... Very true. Most VoIP companies, both hosted and on premises are difficult/time consuming to setup and make work they way you want it. - What if the internet goes down. This one is a challenge. POTS actually have issues too, but when analog phone service goes down, there is no light on the phone indicating that the phones are not working so many customers perceive there is a problem. With the FCC mandating all POTS move to a VoIP backend (which for long hauls, is mostly already true) POTS will experience the same downtime as the internet. However as we all know, the internet is built to tolerate outages. For most people they don't understand how the internet actually works. - Call quality... If a VoIP company pays for good bandwidth and maintains good relationships with peers, the only concern is the last-mile(From the CO to location). Now there is much more that plays in quality, ie. codec selection, voice buffer, locality to the pbx. - Price... Believe it or not people are worried about paying less for better service. Who would have thought? - Location... Location is super important both in the last mile and PBX. - Last mile: In older locations the copper in the ground is aged, if you can't get fiber and your stuck using T1, lines, then hopefully you are in a location that keeps the copper in the ground properly maintained. If you are in older locations, which one of our offices are, there are remedies, you can contact your bandwidth provider and have them do a head to head test using a BERD (bit error rate detector) and they can find the problem. But that's a whole other topic. -PBX: Some people believe that on premise is the best location for a PBX, this may or may not be true. I happen to believe that keeping it off premise is the way to go. You get up-time, redundancy, locality, and mobility. You just plug in your phone and your phone is up and running. Move offices.. got bandwidth? Your good to go. No equipment to worry about, say a power outage happens, your voicemail still works people call in and are in call queues and have no clue you are down. Feels more like POTS with an enterprise backend. -Outages: If the internet does fail, most providers offer WAN survivability. The customer plugs in phone lines into the router and if the internet goes down, they can make emergency calls or calls to the world limited by the number of lines the router can accept and are plugged in of course. Now in all our experience going on 7 years now, 90% of the time WAN outages happen, guess what also dies, the POTS! Who would have thought that when cables get cut, that the phone lines were also part of the cables? There you go, some common worries, with some answers to hopefully sooth the vexed VoIP user. Bret Palsson Sr. Network Systems Administrator www.getjive.com On Feb 28, 2011, at 11:37 AM, valdis.kletni...@vt.edu wrote: On Mon, 28 Feb 2011 13:29:08 EST, Bret Clark said: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year
Re: What vexes VoIP users?
Ahhh yes... ALG... Turn it off. -Bret On Feb 28, 2011, at 12:41 PM, Nathan Eisenberg wrote: Any chance the NAT device has some god-forsaken ALG agent installed that's trying to proxy the SIP traffic?
Re: Mac OS X 10.7, still no DHCPv6
It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. facile but fallacious fanboyism o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own. o if ipv6 can not stand on its own, then dual-stack is a joke that will be very un-funny very shortly, as one partner in the marriage is a dummy. randy
Re: Mac OS X 10.7, still no DHCPv6
On 2011-02-28, at 15:27, Randy Bush wrote: o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own. Do you think I was suggesting that IPv6 as a protocol doesn't need to be able to stand on its own two feet? Because I wasn't; that's patently absurd. However, a fixation on v6-only operation makes no sense for general-purpose deployment when most content and peers are only reachable via IPv4. I appreciate that there are walled gardens, captive mobile applications, telemetry networks and other niche applications for which v6-only networks make sense today. I'm not talking about them. I'm talking about the network that supports what the average user thinks of as the Internet. The immediate task at hand is a transition from IPv4-only to dual stack, regardless of how many NATs or other transition mechanisms the IPv4 half of the dual stack is provisioned through. Joe
Re: What If....
On 2011-02-26 10:34, bill manning wrote: The IANA function was split? RFC 2860 already did that. It seems to work well. http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf I'm glad to see they are up to date: Paper submissions should include a three and one-half inch computer diskette in HTML, ASCII, Word or WordPerfect format (please specify version). Brian
Re: Mac OS X 10.7, still no DHCPv6
o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own. Do you think I was suggesting that IPv6 as a protocol doesn't need to be able to stand on its own two feet? you may want to read your words and the thread which followed. randy
Re: Mac OS X 10.7, still no DHCPv6
On 2/27/2011 11:53 PM, Franck Martin wrote: No, when I first played with IPv6 only network, I found out that RD was silly, it gives an IP adddress but no DNS, and you have to rely on IPv4 to do that. silly, so my understanding is then people saw the mistake, and added some DNS resolution... Because the only option was to get DHCPv6 to get the DNS, but then why create RD in the first place? Well, for the malware authors, it really is an awful lot of trouble to go broadcasting gratuitous ARPs claiming to be the default gateway, and then blasting those spoofed gratuitous ARPs at the gateway claiming to be the clients, and having to do all that packet-forwarding foo just to get to be the man-in-the-middle... when you can just generate an RA and you don't even have to set the evil bit!! And why bother with all those silly DNS-changer malware pointing the resolvers off to Inhoster-land so you can provide your own interesting answers for interesting names you'd like to phish, when you can just sit there and listen on the DNS anycast address and answer the ones you want!! And why bother parsing out the Facebook friends or AOL buddies or MSN contacts list to spew out those phishing URLs to everybody we know, when we can just sit back and let Bonjour/Rendezvous/iChat do all the work for us? Plug and Play malware is the future :-) Jeff
Re: Mac OS X 10.7, still no DHCPv6
On 2011-02-28, at 15:38, Randy Bush wrote: you may want to read your words and the thread which followed. The phrase you apparently missed (or which was not sufficient for me to explain myself clearly) was viable, general-purpose solution. Joe
RE: Mac OS X 10.7, still no DHCPv6
From: Randy Bush Sent: Monday, February 28, 2011 12:27 PM To: Joe Abley Cc: NANOG Operators' Group Subject: Re: Mac OS X 10.7, still no DHCPv6 It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. facile but fallacious fanboyism o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own. o if ipv6 can not stand on its own, then dual-stack is a joke that will be very un-funny very shortly, as one partner in the marriage is a dummy. randy Dual stack isn't always the best approach. For networks that pass a large amount of traffic to a relatively small number of destinations, NAT64/DNS64 on a native v6 platform might be a better migration approach. If 90% of your traffic is v6, it is probably less trouble to use NAT64/DNS64 to reach that 10% than it is to dual-stack. Networks such as the sort described above would be expected to see the majority of their traffic migrate very quickly to v6 once only a few remote networks are v6 capable. This is a case where the pain is front-loaded. The amount of NAT64/DNS64 required to support such a topology is great at first, then quickly steps down as the destinations exchanging the most traffic become v6 capable, and then gradually tails off as the outliers catch up. G
Re: What vexes VoIP users?
Any idea how to workaround the uverse broken alg? I've had to do some fun hacks to work around it. Sometimes I can reboot or crash them with the cisco notify for config check. Jared Mauch On Feb 28, 2011, at 2:45 PM, Bret Palsson b...@getjive.com wrote: Ahhh yes... ALG... Turn it off. -Bret On Feb 28, 2011, at 12:41 PM, Nathan Eisenberg wrote: Any chance the NAT device has some god-forsaken ALG agent installed that's trying to proxy the SIP traffic?
Re: Mac OS X 10.7, still no DHCPv6
In a message written on Mon, Feb 28, 2011 at 06:49:36PM +1100, Karl Auer wrote: I do think though, that assuming DHCP is the way to get some of these things might be shooting from the hip. Perhaps there is a better way, with IPv6? DHCP is a terrible protocol for 2011, and will be an old school throwback by 2040. The fact that it's the option on the table for IPv6 is a shame. The difficulty is that now everyone is in a tearing hurry; they just want everything to work the exact same way, and they want it NOW. There is suddenly no time to work out better ways. And goodness knows there must be a better way to boot a remote image than delivering an address via DHCP! Those who designed IPv6 appear to have ignored the problem space. They could have offered a better solution, but did not. There seemed to be this idea that most of what DHCP did was deliver an address, which is a very naive way of looking at it. So they came up with a new method to get an address and ignored the rest of the usage models. Bootp nee DHCP was designed in an era where a TCP stack in an embedded device was a costly addition. Now a full TCP/IP stack comes for free with a $0.50 micro-controller. If RA's could give out a configuration IP address hosts could tftp/http/whatever down a config file, text, xml, some new format. There could have been innovation in the space, and the time to sell people that it was the right thing to do. For some reason though we all went head in the sand. And I mean all, operators ignored the IETF until it was too late, the IETF decided the operators didn't know what they were talking about and/or were stuck in an IPv4 world. So now we have a gap, a very short time frame, and only one half done solution on the table. We'll likely have to run with it as starting over now would take too much time. It's really a gigantic missed opportunity that probably will only come along every few decades. Maybe the next time around we'll do better. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp2jW5w0TAkB.pgp Description: PGP signature
Re: What If....
Le lundi 28 février 2011 à 15:50 -0500, Edward Lewis a écrit : At 9:35 +1300 3/1/11, Brian E Carpenter wrote: http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf I'm glad to see they are up to date: Paper submissions should include a three and one-half inch computer diskette in HTML, ASCII, Word or WordPerfect format (please specify version). Any problem with Postscript or PDF? Somewhat less clumsy with versions than Word*. Computer diskette... timing :) Certainly a deterrent against paper submissions. ;) Quite green of them! Positive! ;) mh
Re: What If....
On 28 Feb 2011, at 20:50, Edward Lewis wrote: At 9:35 +1300 3/1/11, Brian E Carpenter wrote: http://www.ntia.doc.gov/frnotices/2011/fr_ianafunctionsnoi_02252011.pdf I'm glad to see they are up to date: Paper submissions should include a three and one-half inch computer diskette in HTML, ASCII, Word or WordPerfect format (please specify version). Certainly a deterrent against paper submissions. ;) Quite green of them! Because a lump of plastic with metal bits is far greener than a few bits of potentially re-cycled paper ;-) -- Leigh
Re: What vexes VoIP users?
On Feb 28, 2011, at 1:29 PM, Bret Clark wrote: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. -- Leigh Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I would suggest that the exponential decrease in POTS is driven by cell phones, not VOIP - I just get my cell phone from the store, any store, and use it, almost anywhere. It's just like my land line but without the wire tether. I get wireless without VOIP complications. Of course, we could discuss Long Distance rates for land lines vs cell or Skype (VOIP for almost free). But that is really another discussion. James R. Cutler james.cut...@consultant.com
Re: Mac OS X 10.7, still no DHCPv6
In message 28d10d13-988b-4c7d-833b-eba6e1bc1...@hopcount.ca, Joe Abley writes : On 2011-02-28, at 09:51, Nick Hilliard wrote: I will be a lot more sympathetic about listening to arguments / = explanations about this insanity the day that the IETF filters out arp = and ipv4 packets from the conference network and depends entirely on = ipv6 for connectivity for the entire conference. It's hard to see v6-only networks as a viable, general-purpose solution = to anything in the foreseeable future. I'm not sure why people keep = fixating on that as an end goal. The future we ought to be working = towards is a consistent, reliable, dual-stack environment. There's no = point worrying about v6-only operations if we can't get dual-stack = working reliably. [I also find the knee-jerk it's different from IPv4, the IETF is = stupid memes to be tiring. Identifying questionable design decisions = with hindsight is hardly the exclusive domain of IPv6; there are = tremendously more crufty workarounds in IPv4, and far more available = hindsight. Complaining about IPv6 because it's different from IPv4 = doesn't get us anywhere.] Because the machines we deploy today may still be running in 10 years and we don't want them stopping the network going IPv6 only then. Joe= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: What If....
On Feb 28, 2011, at 11:11 AM, Michael Hallgren wrote: I'm glad to see they are up to date: Paper submissions should include a three and one-half inch computer diskette in HTML, ASCII, Word or WordPerfect format (please specify version). Any problem with Postscript or PDF? Somewhat less clumsy with versions than Word*. Computer diskette... timing :) No, there is no problem with sending electronic-only submissions. The requirement to include a 3.5 floppy is only if you send them paper (I wonder if anyone still does that...). Regards, -drc
Hughesnet outage - where can I ask?
I run a small network in the jungle of Venezuela which is fed by a rebranded Hughesnet connection. We just had a four day failure where the only protocol that worked was ICMP and we were completely without communication. Traceroutes all failed in a bizarre way when using UDP, TCP or GRE packets but traceroute with ICMP worked fine. Our provider (Bantel) is blaming Hughesnet but I'm not finding anything to back that up in forums or in searching the web. I don't want to bother this forum's members with my questions regarding what the traceroute results show and what the problem might be. Is there another forum where these questions would be appropriate? Thanks in advance. Greg
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 12:34 PM, Joe Abley wrote: On 2011-02-28, at 15:27, Randy Bush wrote: o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own. Do you think I was suggesting that IPv6 as a protocol doesn't need to be able to stand on its own two feet? Because I wasn't; that's patently absurd. It is both absurd and pretty much exactly what you said. However, a fixation on v6-only operation makes no sense for general-purpose deployment when most content and peers are only reachable via IPv4. I guess this is a matter of perspective. For some of us that already have complete dual stack deployments, focusing on the issues present in IPv6-only operation is just the next logical step. In some cases, I would say that the v6-only considerations are well worth considering as you prepare to deploy dual-stack so that you don't deploy dual-stack in such a way as to create unnecessary inter-protocol dependencies that will hurt you later. The reality is that IPv6-only networks are not likely in the foreseeable future is only a true statement if your foreseeable future ends in the past. There are already a certain number of functional operating deployed IPv6-only networks. Further, it's not going to be more than a few months before we start seeing networks that have very limited or degraded IPv4 capabilities, if any, due to the inability to grant addresses to new networks in some areas. I appreciate that there are walled gardens, captive mobile applications, telemetry networks and other niche applications for which v6-only networks make sense today. I'm not talking about them. I'm talking about the network that supports what the average user thinks of as the Internet. And how do you think the average residential end user is going to see the IPv4 internet next year? The immediate task at hand is a transition from IPv4-only to dual stack, regardless of how many NATs or other transition mechanisms the IPv4 half of the dual stack is provisioned through. Yes, but, given the nearly immediate runout of IPv4, I would say that doing so in a way that best facilitates IPv6-only hosts being functional is very much worthy of consideration in this process. Owen
Re: What vexes VoIP users?
They are in the US. Comcast tallies 8.6 million household telephone service accounts, making it the United States' third-largest telephone provider. As of February 16, 2011 Comcast has 8.610 million voice customers. http://en.wikipedia.org/wiki/Comcast#Home_telephone People are not, en-masse, going away from POTS and towards plugging a VoIP device into the back of their router. Twenty bucks says the first poster is correct; I'm willing to bet that most of the Comcast VoIP customers are handed off as RJ11 into legacy POTS lines in the target residence. In fact, I've had trouble finding any way to get our cable company to hand off their telephony service digitally, making the claims of digital phone service a little laughable as they still hand it off analog. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: What vexes VoIP users?
It's only an issue if you have a single gateway which is serving up multiple public addresses. SIP is not the only traversal that breaks in this environment, but, it does choose to break in some of the most interesting (especially to troubleshoot when you don't know that's what is causing the problem) ways. This was not the result of smart nat or ALG issues. I will say that I have not seen a lot of environments that have a single gateway that maps clients to a variety of external addresses and that may account for the number of colleagues that haven't seen this issue before. It is real. It does exist. It is all kinds of fun (not!) to troubleshoot the first time you encounter it. (The SIP gets through the traversal just fine, but, usually one half (and not consistently the same half) of the RTP streams don't.) Owen On Feb 28, 2011, at 1:00 PM, Jared Mauch wrote: I've found that sip alg on devices is badly broken and must be disabled. This is true of ios and various consumer electronics devices. Nat traversal for multiple devices is not an issue in any case I have seen. Turning off smart nat usually solves it. Jared Mauch On Feb 28, 2011, at 2:34 PM, Bret Palsson b...@getjive.com wrote: Sorry I didn't include this in the last email... We have large clients who have phones registered on multiples of public IPs from the same location. Works no problem. We do some trickery on our side to make that happen, but I thought all VoIP companies would do that. -Bret On Feb 28, 2011, at 12:25 PM, Owen DeLong wrote: Another vexation for VOIP in the SMB environment is that it rarely works particularly well (if at all) in light of a multiple-external-address NAT pool. You simply have to map all of your VOIP phones in such a way that they consistently get the same external IP every time or shit breaks badly. Owen On Feb 28, 2011, at 11:11 AM, Bret Palsson wrote: Since our company is a VoIP company, I will chime in to this topic. Let's start off with the definitions so everyone is on the same page: vex |veks| verb [ trans. ] make (someone) feel annoyed, frustrated, or worried, esp. with trivial matters : the memory of the conversation still vexed him | [as adj. ] ( vexing)the most vexing questions for policymakers.] Alright, now that that's out of the way... I am only referring to small medium business and some enterprise (Those are all our customers, we do not do residential) - Seemingly complex. - Worried about the What if the internet goes down scenario. - Call quality. - Price - Location - Outages Responses: - Seemingly complex... Very true. Most VoIP companies, both hosted and on premises are difficult/time consuming to setup and make work they way you want it. - What if the internet goes down. This one is a challenge. POTS actually have issues too, but when analog phone service goes down, there is no light on the phone indicating that the phones are not working so many customers perceive there is a problem. With the FCC mandating all POTS move to a VoIP backend (which for long hauls, is mostly already true) POTS will experience the same downtime as the internet. However as we all know, the internet is built to tolerate outages. For most people they don't understand how the internet actually works. - Call quality... If a VoIP company pays for good bandwidth and maintains good relationships with peers, the only concern is the last-mile(From the CO to location). Now there is much more that plays in quality, ie. codec selection, voice buffer, locality to the pbx. - Price... Believe it or not people are worried about paying less for better service. Who would have thought? - Location... Location is super important both in the last mile and PBX. - Last mile: In older locations the copper in the ground is aged, if you can't get fiber and your stuck using T1, lines, then hopefully you are in a location that keeps the copper in the ground properly maintained. If you are in older locations, which one of our offices are, there are remedies, you can contact your bandwidth provider and have them do a head to head test using a BERD (bit error rate detector) and they can find the problem. But that's a whole other topic. -PBX: Some people believe that on premise is the best location for a PBX, this may or may not be true. I happen to believe that keeping it off premise is the way to go. You get up-time, redundancy, locality, and mobility. You just plug in your phone and your phone is up and running. Move offices.. got bandwidth? Your good to go. No equipment to worry about, say a power outage happens, your voicemail still works people call in and are in call queues and have no clue you are down. Feels more like POTS with an enterprise backend. -Outages: If the internet does fail, most providers offer WAN survivability. The customer plugs in phone lines
Re: What vexes VoIP users?
On 2/28/2011 5:19 PM, Joe Greco wrote: http://en.wikipedia.org/wiki/Comcast#Home_telephone People are not, en-masse, going away from POTS and towards plugging a VoIP device into the back of their router. Twenty bucks says the first poster is correct; I'm willing to bet that most of the Comcast VoIP customers are handed off as RJ11 into legacy POTS lines in the target residence. Of course they are, since users oddly enough like using their existing phones, extensions, and wiring. In fact, I've had trouble finding any way to get our cable company to hand off their telephony service digitally, making the claims of digital phone service a little laughable as they still hand it off analog. This is a bit disingenuous, are CD's not digital because the speakers you play the music from analog devices? You can plug any ATA into the existing home wiring, including the ones that Vonage deploys: http://support.vonage.com/doc/en_us/649.xml -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: What vexes VoIP users?
On Feb 28, 2011, at 1:33 PM, Cutler James R wrote: On Feb 28, 2011, at 1:29 PM, Bret Clark wrote: On 02/28/2011 01:17 PM, Leigh Porter wrote: VoIP at the last mile is just too niche at the moment. It's for people on this list, not my mother. -- Leigh Baloney...if that was the case, then all these ILEC's wouldn't be whining about POT's lines decreasing exponentially year over year! I would suggest that the exponential decrease in POTS is driven by cell phones, not VOIP - I just get my cell phone from the store, any store, and use it, almost anywhere. It's just like my land line but without the wire tether. I get wireless without VOIP complications. Of course, we could discuss Long Distance rates for land lines vs cell or Skype (VOIP for almost free). But that is really another discussion. James R. Cutler james.cut...@consultant.com Pretty soon, cell phones will, essentially, be VOIP devices. In fact, some already are. In fact, one could argue that LTE cell phones are in essence what VOIP will be when it grows up. It is clear that eventually voice will simply be an application on a packet switched data network. I believe that the frontier after that will be to replace HDMI with high-speed ethernet and media will go from being a source-selector/sound-display solution to a packet-switched source-network-destination solution where the destination will be either a time/place shifting device (recorder) or an output (audio/video). This frontier can't be crossed until multi-gigabit household networking becomes commonplace, so, it will be a few years, but, I believe it will eventually occur. I also believe that the RIAA/MPAA/etc. will do everything the can to prevent it which will likely delay it for several more years. Owen
Re: What vexes VoIP users?
From: Joe Greco jgr...@ns.sol.net I have no idea why anyone would be paying Ma Bell $69/month for a phone line, unless you like giving them your money or something. In my neck of the woods (Washington DC), the POTS line is the one that works during a bad power outage, and has qualitatively different failure modes than my cable service. Whether that's something one wants to purchase is a different question. David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
Re: What vexes VoIP users?
On 2/28/2011 5:19 PM, Joe Greco wrote: http://en.wikipedia.org/wiki/Comcast#Home_telephone People are not, en-masse, going away from POTS and towards plugging a VoIP device into the back of their router. Twenty bucks says the first poster is correct; I'm willing to bet that most of the Comcast VoIP customers are handed off as RJ11 into legacy POTS lines in the target residence. Of course they are, since users oddly enough like using their existing phones, extensions, and wiring. So then let's argue that ILEC-delivered POTS is digital too, because it went on fiber to the local SLC hut... In fact, I've had trouble finding any way to get our cable company to hand off their telephony service digitally, making the claims of digital phone service a little laughable as they still hand it off analog. This is a bit disingenuous, are CD's not digital because the speakers you play the music from analog devices? So's your handset. So let's look for a rational comparison instead. Take your CD player's analog audio output and run it fifty feet, making sure to route it along some nice fluorescent lights. Even with a good shielded cable, analog signal is notorious for picking up noise. Now take your CD player's TOSLINK output and run it that same fifty feet. I'm aware of the spec limits, but most modern gear with good cables will do this without a problem - we're discussing the difference between analog and digital here in any case. Anyways, listen to both and then let's talk about the difference that carrying a signal in an analog format needlessly can make. You can plug any ATA into the existing home wiring, including the ones that Vonage deploys: http://support.vonage.com/doc/en_us/649.xml So here's the *point*: if you have digital phones, maybe VoIP but could also certainly be any of the proprietary digital systems, why should you have to run through the ambiguity of a digital-to-analog-to-digital conversion? With end-to-end digital, you can have reliable call supervision and status, OOB Caller-ID delivery, crystal clear call quality, probably the ability to handle multiple calls intelligently, no hook race conditions, etc. When you throw that one stupid and pointless analog hop in there, you are suddenly limited and broken in so many ways. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: What vexes VoIP users?
From: Joe Greco jgr...@ns.sol.net=0AI have no idea why anyone would be = paying Ma Bell $69/month for a phone=0Aline, unless you like giving them y= our money or something.=0A=0AIn my neck of the woods (Washington DC), the P= OTS line is the one that works =0Aduring a=A0bad=A0power outage, and has qu= alitatively different failure modes than my =0Acable service.=A0 Whether th= at's something one wants to purchase is a different =0Aquestion.=0A=0ADavid= Barak=0ANeed Geek Rock? Try The Franchise: =0Ahttp://www.listentothefranch= ise.com =0A=0A=0A In my neck of the woods, you can get a basic POTS line for $15/month if it's important to you, local calls billed by the number of calls and the normal LD charges. Add a basic DSL service to that ($20) AND add a basic unlimited VoIP service to that ($20) and suddenly you have the benefits of POTS for emergencies *plus* Internet connectivity *plus* unlimited worldwide calling for ~$60/month, which seems to me to be a better deal than what Ma Bell is likely to be giving you even if you're managing to pay them $69/month. Toss in a UPS and a computer and you can even use the Internet during power outages. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Mac OS X 10.7, still no DHCPv6
On 2011-02-28, at 17:04, Owen DeLong wrote: On Feb 28, 2011, at 12:34 PM, Joe Abley wrote: On 2011-02-28, at 15:27, Randy Bush wrote: o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own. Do you think I was suggesting that IPv6 as a protocol doesn't need to be able to stand on its own two feet? Because I wasn't; that's patently absurd. It is both absurd and pretty much exactly what you said. Well, you misunderstood what I meant, which I'm sure is my own fault. I'm sure my view of the world is warped and unnatural, too, but most of you know that already. :-) To me, delivering IPv6 to residential Internet users is the largest missing piece of the puzzle today. Those users generally have no technical support beyond what they can get from the helpdesk, and the race to the bottom has ensured that (a) the helpdesk isn't of a scale to deal with pervasive connectivity problems and (b) any user that spends more than an hour on the phone has probably burnt any profit he/she might have generated for the ISP that year, and hence anything that is likely to trigger that kind of support burden is either going to result in customers leaving, bankruptcy or both. Small (say, under 50,000 customer) ISPs in my experience have a planning horizon which is less than five years from now. Anything further out than that is not foreseeable in the sense that I meant it. I have much less first-hand experience with large, carrier-sized ISPs and what I have is a decade old, so perhaps the small ISP experience is not universal, but I'd be somewhat surprised giving the velocity of the target and what I perceive as substantial inertia in carrier-sized ISPs whether there's much practical difference. So, what's a reasonable target for the next five years? 1. Deployed dual-stack access which interact nicely with consumer CPEs and electronics, the IPv4 side of the stack deployed through increased use of NAT when ISPs run out of numbers. 2. IPv6-only access, CPE and hosts, with some kind of transition mechanism to deliver v4-only content (from content providers and v4-only peers) to the v6-only customers. Perhaps it's because I've never seen a NAT-PT replacement that was any prettier than NAT-PT, but I don't see (2) being anything that a residential customer would buy before 2016. Perhaps I'm wrong, but I don't hear a lot of people shouting about their success. Note, I'm not talking about the ISPs who have already invested time, capex and opex in deploying dual-stack environments. I'm talking about what I see as the majority of the problem space, namely ISPs who have not. Joe
Re: What vexes VoIP users?
So then let's argue that ILEC-delivered POTS is digital too, because it went on fiber to the local SLC hut... It is, at least in some cases, and its even VOIP in a few (Occam BLC's for example). Having said that its almost never derived voice of any type into the home because of life line requirements. So's your handset. That was kind of the point :) So let's look for a rational comparison instead. Take your CD player's analog audio output and run it fifty feet, making sure to route it along some nice fluorescent lights. Even with a good shielded cable, analog signal is notorious for picking up noise. Now take your CD player's TOSLINK output and run it that same fifty feet. I'm aware of the spec limits, but most modern gear with good cables will do this without a problem - we're discussing the difference between analog and digital here in any case. Anyways, listen to both and then let's talk about the difference that carrying a signal in an analog format needlessly can make. You're working under the incorrect assumption that a user can't simply plug into the back of their EMTA and I assure that isn't the case. An operator can choose to not use the in home wiring, and in some installs this is the right method, but in the case of decent wiring and existing analog sets the user is happy with there's no reason to do so. You can plug any ATA into the existing home wiring, including the ones that Vonage deploys: http://support.vonage.com/doc/en_us/649.xml So here's the *point*: if you have digital phones, maybe VoIP but could also certainly be any of the proprietary digital systems, why should you have to run through the ambiguity of a digital-to-analog-to-digital conversion? I hate to tell you, but residential users don't to buy a new phone. They don't see any problem with their existing analog set and usually they're right. We've been dealing with analog to digital conversions, at least one and sometimes two, in the local LEC system for decades without impacting MOS. (It wasn't until GR-303 and TR-08 interfaces became common on switches that remote terminals got the signal digitally.) With end-to-end digital, you can have reliable call supervision and status, OOB Caller-ID delivery, crystal clear call quality, probably the ability to handle multiple calls intelligently, no hook race conditions, etc. When you throw that one stupid and pointless analog hop in there, you are suddenly limited and broken in so many ways. ... JG What's broken for a residential user? For that matter I'd rather get rid of every digital phone in our business, they're a waste of money, and run pure soft phones but until people start caring about voice (they don't, check cell MOS scores) and adopt wideband voice in numbers there is 0 reason for a home user to change. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 http://twitter.com/kscotthelms
Re: What vexes VoIP users?
- Original Message - From: Joe Greco jgr...@ns.sol.net With end-to-end digital, you can have reliable call supervision and status, OOB Caller-ID delivery, crystal clear call quality, probably the ability to handle multiple calls intelligently, no hook race conditions, etc. When you throw that one stupid and pointless analog hop in there, you are suddenly limited and broken in so many ways. Sure. But I don't think it's the analog hop that people are really concerned about *per se*... it's the fact that the traditional analog last-mile *connects you to a real CO*, with a real battery room, that's engineered -- in most cases, to cold-war standards, *through a loop with very low complexity*. If you have DC continuity and good balance to ground on a copper pair, you are *done*; no intermediate gear, no batteries, no config files, nothing. All I need at the residence is a 500 set, and the complexity of *those* is super low, too. The real, underlying problem is that people take insufficient notice of all the complexity pinch points that they're engineering into loops in exchange for the extra controllability they get because everything's digital end to end. When I'm bringing 31 T-spans into my call center, that extra complexity is easily justifiable. For grandma's phone? Not so much. And it doesn't *matter* whether it's riding on a cable internet link the complexity of which is already amortized: you're now *adopting* that complexity onto the voice service... the semantics of which (used to be) very well understood and not at all complex at all. From the user perception standpoint, I think, it's a tipping point thing... just like Madison WI. Cheers, -- jr 'that was *not* an invitation' a
Re: What vexes VoIP users?
- Original Message - From: Owen DeLong o...@delong.com Pretty soon, cell phones will, essentially, be VOIP devices. In fact, some already are. In fact, one could argue that LTE cell phones are in essence what VOIP will be when it grows up. TTBOMK, that isn't *quite* true, yet, Owen. The only US carrier with LTE deployed is VZW, and their only *handset* with LTE is the not-yet-quite-shipped HTC Thunderbolt... and it is my understanding that their first generation release of handsets will *not* be doing PSTN voice as VoIP over the LTE data connection; they'll be dual-mode handsets, using traditional (IS-95? IS-136?) CDMA voice on a separate RF deck. The two reasons I've heard have to do with battery life and the immaturity of the protocol stack or its implementations. LTE-data-only with VoIP for the carrier PSTN service is indeed their goal, but I don't think you can say Already are quite yet. Cheers, -- jra
Re: SLA for voice and video over IP/MPLS
On Sun, Feb 27, 2011 at 4:20 PM, Anton Kapela tkap...@gmail.com wrote: One won't find many, but a common rule of thumb is most apps will be 'fine' with networks that provide 10E-6 BER or lower loss rates. Anton, Who uses BER to measure packet switched networks? Is it even possible to measure a bit error rate on a multihop network where a corrupted packet will either be discarded in its entirety or transparently resent? 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: What vexes VoIP users?
So let's look for a rational comparison instead. Take your CD player's analog audio output and run it fifty feet, making sure to route it along some nice fluorescent lights. Even with a good shielded cable, analog signal is notorious for picking up noise. Now take your CD player's TOSLINK output and run it that same fifty feet. I'm aware of the spec limits, but most modern gear with good cables will do this without a problem - we're discussing the difference between analog and digital here in any case. Anyways, listen to both and then let's talk about the difference that carrying a signal in an analog format needlessly can make. You're working under the incorrect assumption that a user can't simply plug into the back of their EMTA and I assure that isn't the case. No, I'm not, we were talking about a CD player, and I assure you it *is* the case that I *can* do that. An operator can choose to not use the in home wiring, and in some installs this is the right method, but in the case of decent wiring and existing analog sets the user is happy with there's no reason to do so. There may be no compelling reason to do so, at least. However, digital gear offers benefits, and some people want them. Others, like me, live in bad RF environments where POTS picks up too much noise unless you very carefully select your gear and shield your cables. Further, the digital phones support other features, such as the ability to manage multiple calls seamlessly, present Caller-ID reliably (even while you are on another call), etc. You can plug any ATA into the existing home wiring, including the ones that Vonage deploys: http://support.vonage.com/doc/en_us/649.xml So here's the *point*: if you have digital phones, maybe VoIP but could also certainly be any of the proprietary digital systems, why should you have to run through the ambiguity of a digital-to-analog-to-digital conversion? I hate to tell you, but residential users don't to buy a new phone. I hate to tell *you*, but the LEC's and cable companies like to hand off POTS to small businesses too. They don't see any problem with their existing analog set and usually they're right. Your argument: This works fine for most people therefore it will work for everyone. Is that really what you're saying? What's broken for a residential user? That depends. I've got many years of experience with POTS. How about a POTS phone that won't automatically hang up when the call is complete? Really annoying when it's a speakerphone and you have to get up and walk across the room to press one stupid button. (Our Cisco 79xx gear is *stellar* both in speakerphone quality and in handling such things). How about listening to the local radio station's broadcast on your POTS line while making calls, because the cheap Taiwanese phone isn't sufficiently shielded? I don't really want or need to go on; POTS *stinks* compared to digital. I have no objection to you wanting your lines handed off as POTS, but I'd like mine delivered digitally. For that matter I'd rather get rid of every digital phone in our business, they're a waste of money, and run pure soft phones but until people start caring about voice (they don't, check cell MOS scores) and adopt wideband voice in numbers there is 0 reason for a home user to change. That's a matter of the consumer and their needs and wants. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: What vexes VoIP users?
On 28 Feb 2011, at 23:15, Jay Ashworth wrote: - Original Message - From: Joe Greco jgr...@ns.sol.net With end-to-end digital, you can have reliable call supervision and status, OOB Caller-ID delivery, crystal clear call quality, probably the ability to handle multiple calls intelligently, no hook race conditions, etc. When you throw that one stupid and pointless analog hop in there, you are suddenly limited and broken in so many ways. Sure. But I don't think it's the analog hop that people are really concerned about *per se*... it's the fact that the traditional analog last-mile *connects you to a real CO*, with a real battery room, that's engineered -- in most cases, to cold-war standards, *through a loop with very low complexity*. If you have DC continuity and good balance to ground on a copper pair, you are *done*; no intermediate gear, no batteries, no config files, nothing. All I need at the residence is a 500 set, and the complexity of *those* is super low, too. The real, underlying problem is that people take insufficient notice of all the complexity pinch points that they're engineering into loops in exchange for the extra controllability they get because everything's digital end to end. When I'm bringing 31 T-spans into my call center, that extra complexity is easily justifiable. For grandma's phone? Not so much. Exactly the point I made earlier. POTS is simple, it does what it does and it is pretty good at it. Now, in the background, you have a whole lot of engineering. But I would trust a DMS100 far more than any of the stuff that routes IP. POTS is cheap, easy, scalable and resistant to many disasters that would soon wipe any VoIP network out. -- Leigh Porter
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011 12:28 PM, Randy Bush ra...@psg.com wrote: It's hard to see v6-only networks as a viable, general-purpose solution to anything in the foreseeable future. I'm not sure why people keep fixating on that as an end goal. The future we ought to be working towards is a consistent, reliable, dual-stack environment. There's no point worrying about v6-only operations if we can't get dual-stack working reliably. facile but fallacious fanboyism o if ipv6 can not operate as the only protocol, and we will be out of ipv4 space and have to deploy 6-only networks, it damned well better be able to stand on its own. o if ipv6 can not stand on its own, then dual-stack is a joke that will be very un-funny very shortly, as one partner in the marriage is a dummy. +1 Well said. V6 needs to stand on its own. Cb randy
Re: What vexes VoIP users?
On 2/28/2011 15:35, Joe Greco wrote: There may be no compelling reason to do so, at least. However, digital gear offers benefits, and some people want them. Others, like me, live in bad RF environments where POTS picks up too much noise unless you very carefully select your gear and shield your cables. Further, the digital phones support other features, such as the ability to manage multiple calls seamlessly, present Caller-ID reliably (even while you are on another call), etc. ISDN would have fit the bill nicely as a digital home phone line. However, it never became popular in the US. I once read on Wikipedia that it was popular in Germany. ~Seth
Re: Mac OS X 10.7, still no DHCPv6
Small (say, under 50,000 customer) ISPs in my experience have a planning horizon which is less than five years from now. Anything further out than that is not foreseeable in the sense that I meant it. I have much less first-hand experience with large, carrier-sized ISPs and what I have is a decade old, so perhaps the small ISP experience is not universal, but I'd be somewhat surprised giving the velocity of the target and what I perceive as substantial inertia in carrier-sized ISPs whether there's much practical difference. Ready or not, IPv6-only (or reasonably IPv6-only) residential customers are less than 2 years out, so, well within your 5-year planning horizon, whether those ISPs see that or not. Denial is an impressive human phenomenon. So, what's a reasonable target for the next five years? In five years we should be just about ready to start deprecating IPv4, if not already beginning to do so. 1. Deployed dual-stack access which interact nicely with consumer CPEs and electronics, the IPv4 side of the stack deployed through increased use of NAT when ISPs run out of numbers. Icky, but, probably necessary for some fraction of users. Ideally, we try to avoid these multi-NAT areas being done in such a way that the end user in question doesn't also have reasonably clean IPv6 connectivity. 2. IPv6-only access, CPE and hosts, with some kind of transition mechanism to deliver v4-only content (from content providers and v4-only peers) to the v6-only customers. This is, IMHO, preferable to option 1. Perhaps it's because I've never seen a NAT-PT replacement that was any prettier than NAT-PT, but I don't see (2) being anything that a residential customer would buy before 2016. Perhaps I'm wrong, but I don't hear a lot of people shouting about their success. Personally, I think DS-Lite is the cleanest solution, but, it isn't without its issues. The reality is that post-runout IPv4 is going to be ugly, regardless of whether it's NAT64 ugliness, LSN ugliness, or DS-LITE ugliness. IPv4 is all about which flavor of bitter you prefer at this point. The sweetness is all on IPv6. Note, I'm not talking about the ISPs who have already invested time, capex and opex in deploying dual-stack environments. I'm talking about what I see as the majority of the problem space, namely ISPs who have not. The majority of the problem space IMHO is end-user-space at ISPs that have put at least some dual-stack research effort in, but, haven't come to solutions for end-users. However, we're less than 2 years away from seeing what happens in those environments without IPv4. Owen
Re: What vexes VoIP users?
- Original Message - From: Joe Greco jgr...@ns.sol.net With end-to-end digital, you can have reliable call supervision and status, OOB Caller-ID delivery, crystal clear call quality, probably the ability to handle multiple calls intelligently, no hook race conditions, etc. When you throw that one stupid and pointless analog hop in there, you are suddenly limited and broken in so many ways. Sure. But I don't think it's the analog hop that people are really concerned about *per se*... it's the fact that the traditional analog last-mile *connects you to a real CO*, with a real battery room, that's engineered -- in most cases, to cold-war standards, *through a loop with very low complexity*. Yeah, um, well, hate to ruin that glorious illusion of the legacy physical plant, but Ma Bell mostly doesn't run copper all the way back to a real CO with a real battery room these days when they're deploying new copper. So if you have a house built more than maybe 20 years ago, yeah, you're more likely to have a pair back to the CO, but if you've ordered a second line, or you're in a new subdivision and you're far from the CO, the chances you're actually on copper back to the CO drops fairly quickly. If you have DC continuity and good balance to ground on a copper pair, you are *done*; no intermediate gear, no batteries, no config files, nothing. All I need at the residence is a 500 set, and the complexity of *those* is super low, too. Yes, it's elegant in a traditional way. I certainly agree. It has some benefits. It also has some downsides in terms of usability, things we wouldn't have noticed in 1970 but today we do. In an age when cell phones can handle multiple calls and deliver Caller-ID for a waiting call, it's nice to see feature parity on your landline. The real, underlying problem is that people take insufficient notice of all the complexity pinch points that they're engineering into loops in exchange for the extra controllability they get because everything's digital end to end. Looked at a different way, the cold-war reliability of the POTS network maybe isn't quite as important as it once was. If you have a cell phone and a VoIP line, maybe you're actually better off. If a plane crashes into your local CO, perhaps you lose POTS and even your cell because the tower was at the local CO. But if you've got a cell and a VoIP line that runs over cable, maybe you actually have more diversity. When I'm bringing 31 T-spans into my call center, that extra complexity is easily justifiable. For grandma's phone? Not so much. And it doesn't *matter* whether it's riding on a cable internet link the complexity of which is already amortized: you're now *adopting* that complexity onto the voice service... the semantics of which (used to be) very well understood and not at all complex at all. Yes, but you *gain* capabilities as well as losing some of the benefits of the old system. We're gaining the ability to do things like texting and transmitting pictures to 911 via the cellular network, for example. Things change. Maybe some people do not need a cold-war relic of a phone anymore. From the user perception standpoint, I think, it's a tipping point thing... just like Madison WI. Cheers, -- jr 'that was *not* an invitation' a What, you want me to invite you for pizza in Madison? I hear there's some good places near the Capitol... ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: What vexes VoIP users?
- Original Message - From: Owen DeLong o...@delong.com This no intermediate gear term, it does not mean what you think it means... Loading coils, Bridge-Taps, WDFs, Protection Blocks, etc. all could be classified as intermediate gear. Many of these things have been the bane of DSL installations, so, you cannot claim that they have no effect on the circuit. Sure. But they're not really gear in the meaning in which we use that term, and they do not add complexity to it in the meaning in which *I* was using that term. There are no batteries, CPUs, configuration files, etc, on any of those items. I will grant that thing like TR-303 RSUs do introduce those complexities, but they're generally treated as part of the CPU, IME, and engineered and maintained that way, and they're not really all *that* configurable either, as I understand them. When I'm bringing 31 T-spans into my call center, that extra complexity is easily justifiable. For grandma's phone? Not so much. For grandma, probably not. For myself, I like having a phone on my laptop that works just about any where in the world and allows me to make local calls in the US. As do I. And we do. Was this subthread not about whether VoIP was *generically* ready to replace the PSTN's present last-mile provisioning? Cheers, -- jra
Re: What vexes VoIP users?
- Original Message - From: Joe Greco jgr...@ns.sol.net Yeah, um, well, hate to ruin that glorious illusion of the legacy physical plant, but Ma Bell mostly doesn't run copper all the way back to a real CO with a real battery room these days when they're deploying new copper. So if you have a house built more than maybe 20 years ago, yeah, you're more likely to have a pair back to the CO, but if you've ordered a second line, or you're in a new subdivision and you're far from the CO, the chances you're actually on copper back to the CO drops fairly quickly. Ok, sure. But probably to an RSU, which -- as I noted to Owen just now -- is engineered and monitored to quite a bit higher standards than I'm betting Comcast or FiOS is. If you have DC continuity and good balance to ground on a copper pair, you are *done*; no intermediate gear, no batteries, no config files, nothing. All I need at the residence is a 500 set, and the complexity of *those* is super low, too. Yes, it's elegant in a traditional way. I certainly agree. It has some benefits. It also has some downsides in terms of usability, things we wouldn't have noticed in 1970 but today we do. In an age when cell phones can handle multiple calls and deliver Caller-ID for a waiting call, it's nice to see feature parity on your landline. Oh, I'm not arguing that. The question, for me, has always been are we taking full account of the *features* we get from traditionally engineered copper POTS in doing our cost benefit analysis to newer technologies... and my answer was always don' look like it to me. The real, underlying problem is that people take insufficient notice of all the complexity pinch points that they're engineering into loops in exchange for the extra controllability they get because everything's digital end to end. Looked at a different way, the cold-war reliability of the POTS network maybe isn't quite as important as it once was. If you have a cell phone and a VoIP line, maybe you're actually better off. If a plane crashes into your local CO, perhaps you lose POTS and even your cell because the tower was at the local CO. But if you've got a cell and a VoIP line that runs over cable, maybe you actually have more diversity. That's possible; there are *lots* of end-site use cases. But that's end-user engineering; you could *always* improve your diversity if you were willing to put the time, though (and money) into it. And it doesn't *matter* whether it's riding on a cable internet link the complexity of which is already amortized: you're now *adopting* that complexity onto the voice service... the semantics of which (used to be) very well understood and not at all complex at all. Yes, but you *gain* capabilities as well as losing some of the benefits of the old system. We're gaining the ability to do things like texting and transmitting pictures to 911 via the cellular network, for example. Things change. Maybe some people do not need a cold-war relic of a phone anymore. some people is, for me, the important phrase in that sentence. Cell phones have killed off pay phones and utility-grade watches; I'm not sure we're the better for it in either case. And SMS to 911 is still a *teeny* little capability; I think there's *one* whole PSAP in the US equipped for it so far. From the user perception standpoint, I think, it's a tipping point thing... just like Madison WI. Cheers, -- jr 'that was *not* an invitation' a What, you want me to invite you for pizza in Madison? I hear there's some good places near the Capitol... ...to political arguments on NANOG. Sorry not to show my work. :-) Cheers, -- jra
Re: What vexes VoIP users?
- Original Message - From: Owen DeLong o...@delong.com TTBOMK, that isn't *quite* true, yet, Owen. The only US carrier with LTE deployed is VZW, and their only *handset* with LTE is the not-yet-quite-shipped HTC Thunderbolt... That's the US market. We are, as usual, traditionally well behind the rest of the world. and it is my understanding that their first generation release of handsets will *not* be doing PSTN voice as VoIP over the LTE data connection; they'll be dual-mode handsets, using traditional (IS-95? IS-136?) CDMA voice on a separate RF deck. The two reasons I've heard have to do with battery life and the immaturity of the protocol stack or its implementations. Sad. There are definitely LTE-data-only VOIP handsets in other deployments. Of course. Silly me. :-) Cheers, -- jra
Re: What vexes VoIP users?
On Feb 28, 2011, at 7:24 PM, Jay Ashworth wrote: - Original Message - From: Joe Greco jgr...@ns.sol.net Yeah, um, well, hate to ruin that glorious illusion of the legacy physical plant, but Ma Bell mostly doesn't run copper all the way back to a real CO with a real battery room these days when they're deploying new copper. So if you have a house built more than maybe 20 years ago, yeah, you're more likely to have a pair back to the CO, but if you've ordered a second line, or you're in a new subdivision and you're far from the CO, the chances you're actually on copper back to the CO drops fairly quickly. Ok, sure. But probably to an RSU, which -- as I noted to Owen just now -- is engineered and monitored to quite a bit higher standards than I'm betting Comcast or FiOS is. Well, I have to go back to the hurricanes of 04 for a personal view of this higher standards. Cable went down because of cable cuts (expected) and because of no power backup longer than a short time with batteries. CO's faired a scoch better but when their battery banks went dry it was over because the gensets never autostarted and there was no one here on the coast in central Florida to intervene. All cell phones were toast except old Bell South. Local worked through both Cat 3's and then LD came back later. Don't know whether it was towers with only short term batts or power to fiber was disrupted. 36+ hours after both Cat 3's all BellSouth wireless was back up but with load issues as you can imagine. Other carriers took days. My home internet is wireless to my colo and then via 4 carriers out. All but one carrier died after 24+ hours of outage. Colo was fine an humming. Feedback later was that the problems were due to poor maintenance of generators and failover equipment and understanding of disasters. Bottom line is my VOIP worked because I had luck or at least I was proactive and my cell worked because I was lucky. Today, given the margins and the amount of reinvestment and maintenance I doubt that either cable or POTS would hack a disruption like this which is not out of the question. I doubt that they would do as good. Tom PS as for the comment that your mother wouldn't use VOIP, my mother in her 80's uses VOIP and loves it.
Re: What vexes VoIP users?
On Mon, 28 Feb 2011, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com Sad. There are definitely LTE-data-only VOIP handsets in other deployments. Of course. Silly me. :-) Couldn't fine Owens original post, so I'll ask here. Which are these handsets? Could you provide some names, please? Since I work for an LTE operator and haven't heard about them I'd really like to know. Considering the USB dongles get hot enough to fry eggs off of, I was under the impression it wasn't really possible to make a handset with a big enough battery to give any decent standby-time at this point in the tech evolution? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Switch with 10 Gig and GRE support in hardware.
On Sun, Feb 20, 2011 at 3:15 PM, George Bonser gbon...@seven.com wrote: On 2/18/11 6:30 AM, Matt Newsom matt.new...@rackspace.com wrote: I am looking for a switch with a minimum of 12 X 10GE ports on it, that can has routing protocol support and can do GRE in hardware. Does anyone have a suggestion that might fit. Keep in mind I am looking for something in the 1-2U range and not a chassis. Hard to tell from the data sheet: http://www.xbridgeservices.com/images/files/7450_ess.pdf But it looks like the Alcatel-Lucent 7450 ESS-1 might do it. Not sure if it has 4, 8, or 12 10G ports, though. The data sheet is confusing to me and it would be oversubscribed but that might be OK in your applications. Brocade TurboIron 24X fits all of those criteria. -Jeff
Re: Hughesnet outage - where can I ask?
On Mon, 28 Feb 2011 17:27:31 -0430, Greg Ihnen wrote: I run a small network in the jungle of Venezuela which is fed by a rebranded Hughesnet connection. We just had a four day failure where the only protocol that worked was ICMP and we were completely without communication. Traceroutes all failed in a bizarre way when using UDP, TCP or GRE packets but traceroute with ICMP worked fine. Our provider (Bantel) is blaming Hughesnet but I'm not finding anything to back that up in forums or in searching the web. I don't want to bother this forum's members with my questions regarding what the traceroute results show and what the problem might be. Is there another forum where these questions would be appropriate? Thanks in advance. Greg As ugly workaround maybe make IP over ICMP tunnel http://thomer.com/icmptx/ My idea that maybe PEP (some acceleration software for tcp/udp) failed
Re: [v6z] Re: What vexes VoIP users?
On Mon, Feb 28, 2011 at 3:00 PM, Joe Greco jgr...@ns.sol.net wrote: In my neck of the woods, you can get a basic POTS line for $15/month if it's important to you, local calls billed by the number of calls and the normal LD charges. Add a basic DSL service to that ($20) AND add a basic unlimited VoIP service to that ($20) and suddenly you have the benefits of POTS for emergencies *plus* Internet connectivity *plus* unlimited worldwide calling for ~$60/month Or just move to California, order residential dry-loop DSL from ATT (not sure about via resellers) and they are required by law to give you dial-tone and access to 911. $20/month for the DSL, $0/month for the VOIP (via Google Voice and Asterisk) and you've got the best of all worlds. Scott.
Re: Switch with 10 Gig and GRE support in hardware.
Jeff, I would try the 4900M http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6021/ps9310/Data_Sheet_Cat_4900M.html http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps6021/ps9310/Data_Sheet_Cat_4900M.html Theo On Mon, Feb 28, 2011 at 6:06 PM, Jeff Hartley intensifysecur...@gmail.comwrote: On Sun, Feb 20, 2011 at 3:15 PM, George Bonser gbon...@seven.com wrote: On 2/18/11 6:30 AM, Matt Newsom matt.new...@rackspace.com wrote: I am looking for a switch with a minimum of 12 X 10GE ports on it, that can has routing protocol support and can do GRE in hardware. Does anyone have a suggestion that might fit. Keep in mind I am looking for something in the 1-2U range and not a chassis. Hard to tell from the data sheet: http://www.xbridgeservices.com/images/files/7450_ess.pdf But it looks like the Alcatel-Lucent 7450 ESS-1 might do it. Not sure if it has 4, 8, or 12 10G ports, though. The data sheet is confusing to me and it would be oversubscribed but that might be OK in your applications. Brocade TurboIron 24X fits all of those criteria. -Jeff -- Theo Sison Solutions Architect Google SNR: 720.663.THEO http://www.linkedin.com/in/tsison
Re: Mac OS X 10.7, still no DHCPv6
On Feb 28, 2011, at 9:16 PM, Leo Bicknell wrote: Those who designed IPv6 appear to have ignored the problem space. This is true of many, many aspects of IPv6. And those of us who didn't get involved in the process to try and address (pardon the pun, heh) those problems bear a burden of the responsibility for the current state of affairs. So, it's very obvious that there's a lot of work to be done in order to make pure IPv6 viable for a non-isignificant proportion of the user base (including spimes and such in that population). Dual-stack is an appropriate transitional mechanism to make some steps towards that goal in some circumstances, and so it shouldn't be summarily dismissed, that's all. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On Mar 1, 2011, at 7:00 AM, Owen DeLong wrote: In five years we should be just about ready to start deprecating IPv4, if not already beginning to do so. That's been said about so many things, from various legacy OSes to other protocols such as SNA and SMB/CIFS. None of those things are as prevalent as IPv4 is today. And yet, they're still around to haunt us. I think we're going to be dealing with IPv4 for a long, long time - far longer than two years. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com The basis of optimism is sheer terror. -- Oscar Wilde
Re: Mac OS X 10.7, still no DHCPv6
On Mon, Feb 28, 2011 at 04:00:16PM -0800, Owen DeLong wrote: Ready or not, IPv6-only (or reasonably IPv6-only) residential customers are less than 2 years out, so, well within your 5-year planning horizon, whether those ISPs see that or not. Denial is an impressive human phenomenon. Denial is indeed impressive: v6 only is not the only option for residential customers already used to functioning behind NAT. I, for one, welcome our new CGN overlords... In five years we should be just about ready to start deprecating IPv4, if not already beginning to do so. Considering it's taken us 15 years to get this far... I think that's pretty optimistic. Anyone care to start the IPv4 dead pool, Price is Right style, for when the last v4 NLRI is removed from the DFZ? --msa